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.
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.
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.
Another request from the old (and apparently defunct) Instiki Bug Tracker:
allow single letter WikiLinks, e.g. "[[a]]". Requested by a Japanese user.
Fixed.
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.
Another very amusing 3-year old bug from the main Instiki Bug Tracker
(don't they ever fix anything?): the chunk-handling code was supposed
to prevent recursive [[!include ...]] statements. Alas, instead of
actually preventing them it would -- when it encountered a recursive
include -- churn away until Rails ran out of stack space.
Fixed.
Previously,
<nowiki>[[!include foo]]</nowiki>
would produce some garbage, like
chunk18226682includechunk
instead of the desired rendered text,
[[!include foo]]
Fixed.
By default, Rails will cache
example.com/mywiki/show/SomePage
and
www.example.com/mywiki/show/SomePage
In Instiki, this just leads to stale cached pages and frustration.
Fix that behaviour.
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.
