The first reason is security: it’s very hard to protect against the (La)TeX equivalent of the billion laughs attack. This is, of course true of TeX/LaTeX itself, but it’s a much more serious concern when used in a web application (like Instiki, or this forum software).

The second reason is an implementation detail: in the preferred mode of use (as used in Instiki and in this forum software), a separate invocation of itex2MML is used for each formula. A macro defined in one invocation could not be “re-used” in another.

Now, neither of these would be incompatible with implementing a “global” preamble (whose content would be controlled by the website owner and not alterable by ordinary users). On the other hand, that would be rather less-than-useful on a public wiki (or forum), so there hasn’t been much user demand for such a feature either.

I guess a private wiki would be one use-case where it might be desirable …

The whole point of rbenv (or rvm) is to set up your paths correctly so that, when you type ruby, you get the desired executable. I don’t know anything about Dreamhost, and didn’t really read the rbenv installation instructions that you followed, but evidently they didn’t quite achieve the desired result.

“… although if I want to run Ruby 2.1 or 2.2 I think I’m going to have to build it from source, which I don’t know how to do yet.”

Build Ruby from source? I don’t think you want to do that (unless you really have to). It would be better to have a known-working version of Ruby, so that we don’t have to debug possible problems in your Ruby installation as well (well, OK, technically we are already doing that, since your versions of Ruby and Rubgems aren’t totally compatible).

Instiki should work fine with Ruby 1.9.3, if that’s really the most recent version you have access to. We’d just need to modify a line in config/boot.rb to take care your problem with Rubygems.

You had willy-nilly modified your Gemfile. Did you revert that modification before trying again?

Your Ruby version was 1.8.7.

Now you tell me that progress was made by downgrading your Ruby version to “<2.0”?!?

That said, I sorta understand the error about Gem.source_index. The version(s) of Rubygems which came with Ruby < 2.0 had that method. Later versions do not. So there’s a monkey-patch in config/boot.rb to supply the missing method for Ruby ≥ 2.0.

Evidently, you have the odd combination of an old (1.9.3) version or Ruby and a recent version of Rubygems.

Maybe you should start again with

an unmodified installation of Instiki.

a recent version of Ruby: I recommend 2.1 or 2.2.

Run ruby bundle install and see what happens. If that fails, post your errors here. If it succeeds, but then ./instiki fails, post your Gemfile.lock, so we can see what got installed.

On the other hand, if you’re just using ASCII characters, you can replace [[:word:]] with \w on lines 263 and 267 of vendor/bundle/ruby/1.8/bundler/gems/maruku-aa33367fa89e/lib/maruku/input/parse_span.rb and not run into any problems.

You can try embedding (X)HTML comments in the source, but they get escaped (for a variety of security-related reasons) and hence are “visible” on the page.

Longer answer: Metadata about the page can be placed in a way that does not appear in the rendered output. The syntax is that of email headers (key-value pairs, at the beginning of the page, separated from the main text by a newline):

Author: Me
Subject: My personal musings
Blortnaz: Whatever you want to put here
And now begins the main text ...

This is not quite what you asked for, but it may serve your purpose, depending on what use-case you had in mind.

Well, since the changeset that I linked to above also involves changes to vendor/plugins/form_spam_protection/lib/form_tag_helper_extensions.rb , just updating files in /app/* won’t actually work.

Moreover, updating all of the files in /app to the latest version(s) drags in other changes. The particular error that you are seeing is due to this changeset, which introduces a nice feature for wikilinks, but required some changes in /lib as well.

I think I will wait for the 19.8 release on this one. This is not a huge problem.

Currently I am awaiting the release of Passenger 5.0.7, to see whether it resolves some issues with Instiki, or whether changes on the Instiki end are also required. If all goes according to plan, I’ll roll another release sometime in the early summer.

For whatever it’s worth, though, this site runs on the latest development version of Instiki (with Passenger 4.0.59) and is perfectly stable.

I did figure out that if I tried to upload a file into instiki (which automatically creates a ‘files’ folder in the Webs directory, and moved the html file to the newly created ‘files’ folder …

Oh. I think I misunderstood your problem.

Of course you can’t create an HTML link to some random file in (a random subdirectory of) the instiki directory. That would be stupid and dangerous.

As you can see from URLs for the CSS and javascript files on your Instiki pages, you can link to files in the public directory. You can also link to files in the webs directory (as you can see from the file links that you created).

I guess also a functionality thing I noticed is that if you click on the hyperlink to an local hosted html page. Instiki calls up a download box within the browser and asks the user if they want to save the html file locally, instead of actually opening the page within the browser as an actual webpage. Is this an issue or just how instiki displays local html files?

That’s for security.

You ought to be able to trust that the content of an Instiki page is safe. Thus (for instance) you can’t edit an Instiki page and add malicious javascript to it. This protection would be vitiated, if you could put the malicious javascript in an HTML file that opened in the user’s browser as if it were just another page on the Instiki wiki.

This restriction does not apply to files in the public directory. Those had to have been placed there by the system administrator and are assumed to be safe.

to the DNSBLS hash in vendor/plugins/dnsbl_check/lib/dnsbl_check.rb. Apparently, the http://www.stopforumspam.com/ data is shared with that dnsbl list, and hence can be queried with the same kind of dnsbl lookup.

If that works, we can incorporate that in an update to Instiki. If not, we can look into implementing the API.

Different Sites have different URLs (virtual hosts, in Apache parlance), and different user-lists. For instance, the LHC Forum is another Site, running under the same Heterotic Beast instance as this one.

The thing closest to Vanilla’s “categories” is Heterotic Beast’s “Forums”. I’m not sure we need both. But we can discuss it.