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.
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.
Make this version (minimally) usable with Textile Markup:
For Webs with "Textile", "RDoc" or "Mixed" markup option selected,
send text/html instead of application/xhtml+xml. This makes this
software minimally usable with those markup dialects.
"Markdown+itex2MML", "Markdown+BlahTeX/PNG" and "Markdown" should work
as before, sending application/xhtml+xml to capable browsers.
Bump the version number.
Deleting a page removes all revisions of that page.
Deleting a Web removes all pages (and all revisions thereof)
and all wiki_files belonging to that Web.
In the Stylesheet Tweaks, the owner of a Web can specify an @import rule
to pull in CSS styles form an external file. This worked in the "show"
view, but was broken in the "published" view.
Fixed.
Also, update a functional test to match Revision 313.
Be a little gentler in recovering from Instiki::ValidationErrors, when saving a page.
Previously, we threw away all the user's changes upon the redirect. Now we attempt
to salvage what he wrote.
Update dnsbl_check plugin to latest version.
Update Maruku to latest version.
In the wiki_controller, only apply the dnsbl_check before_filter
to the :edit, :new, and :save actions, instead of all actions.
This makes mundane "show" requests faster, but does not
compromise spam-fighting ability.