From Jason Blevins:
Create a "History" page for each wiki page.
Link to it, and to the "Diff" page from "Recently Revised".
Also, correct a bug in listing/deleting links to uploaded
video and audio files.
Maruku uses greedy Regexps in a number of places, which,
in unfavourable circumstances, can lead to exponential
slowdowns (an apparent hang).
We worked around one such bug in Revision 355. Recently,
Toby Bartels found another (in Table Header parsing).
The "real" solution seems to be to make sure the Regexps
are not greedy. (Thanks to Sam Ruby for spotting the problem!)
Reverted the workaround in Revision 355, fixed Toby's
bug, and several other similar Regexps.
Add support, in the LaTeX export, for blackboard bold
digits and lowercase latin letters. If these are
present, LaTeX will
\usepackage{mathbbol}
N.B.: this uses the stmaryrd font for blackboard bold
letters, instead of the msbm font.
Tests included. (Yes, you need to update itex2MML as well.)
Using <object> and <embed> were forbidden for obvious
security reasons. Instiki now permits embedding video
via the HTML5 <video> element (Ogg/Theora encoded videos
only, with .ogg or .ogv extensions). You can even upload
videos with
[[foo.ogg:video]]
Instiki now support x-sendfile. See the Proxying page for
configuring Apache (with the x-sendfile module). Lighttpd
should work similarly.
Update Rails to latest Edge (hopefully converging on RC2!).
Dunno why this was buggered again. ":back" doesn't seem to function as it used to.
Also, when uploading a file from page "foo", it's important to return to "foo" after
a successful upload, rather than redirecting to the HomePage.
Finally, a favicon tweak.
A Maruku-syntax <div> with an unclosed IAL (and, it seems, at least one equation)
would cause Instiki to hang. Badly. Requiring a 'kill -9' to terminate it.
Reverting the OpenDiv and CloseDiv Regexps to my, more simple-minded, versions
fixes the problem.
Instiki now runs on the Rails 2.3.0 Candidate Release.
Among other improvements, this means that it now
automagically selects between WEBrick and Mongrel.
Just run
./instiki --daemon
On Webs with file uploads enabled, uploaded files were stored
(in version 0.16.1 and earlier) in the public/ directory.
This was a security threat. A miscreant could upload a .html file.
When a user clicked on the link to the file, it was opened (unsanitized)
in the browser.
As of version 0.16.2, uploaded files are stored in the webs/
directory. Now, when the user clicks on the link, the file is sent
with the
Content-Disposition: attachment
header set, which causes the file to be downloaded, rather than opened
in the browser. As always, files downloaded from the internets should be
treated with caution. At least, this way, they are not aoutomatically
opened in the browser.
To move your existing uploaded files to the new location, do a
rake upgrade_instiki
When a Web uses one of the Markdown Text Filters, and you export
all the pages as a zip file, you'd like the MathML and SVG to
render when the pages are viewed locally. This means saving them
with a .xhtml extension. Users of non-XHTML-capable browsers or
Textile users should still get .html files.
Ruby's String.sub!(pattern, replacement) routine is fundamentally
broken. But the block version works fine.
Using the broken routine in the Chunk handler was a subtle mistake.
WikiWord (and the like) could wreak havoc in equations. Protect them
(the way <a>, <pre> and <code> blocks are protected).
For some reason, this doesn't seem to work in inline equations.
Maruku is doing something funny there ... => one failing Unit Test.
For the file_list action, include the pages which link to the given file(s).
This required rejiggering so that that information is actually retained in the database.
Unfortunately, you'll actually need to revise the page(s) in question, because that's the
only time this information is updated in the database.
Some more tests from Clint Ruoho. The main branch of Instiki (and, I guess,
the old sanitizer) are vulnerable.
Also: under Ruby 1.8.x, CGI.unescapeHTML screws up horribly decoding NCRs
which represent high-bit ASCII characters. UTF-8 agrees with 7-bit ASCII,
but CGI.unescapeHTML doesn't seem to know that they disagree for i>127.
