Should be to the published action. This
didn't work right for inter-web links.
(Reported by Mike Shulman)
Also, change some .length's to .size's
(for Andrew Stacey)
Refactor the upgrade_instiki rake task.
Based on the (very nice) JHerdman's
64d305f2a8
but defaults to 'production' environment, instead.
Instiki users don't know about production/development/test.
Instiki defaults to 'production'. So should its associated rake tasks.
Added the ability to rename existing pages.
[[!redirects Some Page Name]] redirects Wikilinks [[Some Page Name]] to
the current page (assuming "Some Page Name" does not exist).
Real pages trump redirects (though this may change, depending on
user feedback).
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.
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!).
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.
CMyApp is a WikiWord (at least, on other Wiki systems, like TWiki).
Should allow that here
Also, choose a more obscure name for the thread-local variable tracking
included chunks.
Use "Thread.current[:included_by]" instead of the Class variable,
"@@included_by".
The former will work on some newfangled multi-threaded Webserver stack,
which uses separate threads to handle multiple simlutaneous requests
(one request/thread). Dunno that the rest of the application is
thread-safe, but using a class variable, in this context, probably isn't.
Thanks to Sam Ruby for the suggestion.
