Fix http://bug.to/issues/show/335
and
http://bug.to/issues/show/334
We now bundle the uploaded files directory
(and the public/ directory for the (X)HTML
export) in the Zipball when exporting a Web.
Also, correct the Print View to produce proper links
uploaded files.
... is to settle these encoding issues
once and for all.
Let's override the accessor methods, which
seems to offer a simpler solution.
Now with tests (for whatever that helps)...
Move the truncate() method into ApplicationHelper.
Move another method around, for no particularly
good reason. Controllers really shouldn't have
public methods that don't correspond to actions.
Add a Source view. [Based on a suggestion by Andrew Stacey]
Fix a well-formedness bug in the list action, due to
boneheaded truncation algorithm. [Reported by Roby Bartels]
Omit a (seemingly superfluous)
javascript hack which causes
Gecko-based browsers to request
/my_wiki/s5/null
when they load an s5 slideshow.
Also a stylistic cleanup in
the wiki_controller.
When redirected to another page, flash
messages will not display if the query
string is longer than 10192 bytes. In
Instiki, certain rescue operations
involve redirection, with the updated
content of the page passed as a query
parameter. Fall back to using the stored
content (ie, don't pass a query parameter)
if the content is too long.
Previously, if the user tried to submit content which was
malformed utf-8, Instiki would complain loudly to him.
A slightly more user-friendly approach was suggested by
the latest Rails 2.3.4, and a conversation with Sam Ruby
(who suggested some improvements).
Now, instead of complaining, we remove the offending bytes,
leaving a well-formed utf-8 string, which we pretend is what
the user meant to submit.
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)
1. Ensure that "rollback" respects locked pages.
2. Expire revisions of an edited page. Use a before_save
hook to deal with the situation where a page's name
has been changed.
1) WEBrick should respond to TERM signals
(needed by MacOSX and, perhaps, others).
2) HTTP redirects for redirected pages should be 301's.
3) Add a flash message for redirection to "new" page
when the target of "show" action is not found.
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.
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.
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.
Fix Session CookieOverflow bug when rescuing an InstikiValidation error.
Fix some random things which will cause problems with Ruby 1.9. (Plenty
more where those came from.)
Make session secret persist across restarts. (Been meaning to do this for
a while: no more "stale cookie" warnings fter restarting the server.
Avoid cookie overflow in session store.
Start work (which may not pan out) on a new sanitizer. Right now, it passes
all but 1 of the HTML5lib Sanitizer's unit tests. But it doesn't do much
of anything to ensure well-formedness. This is not an issue for Maruku-processed
content, but it is a concern for <nowiki> blocks.
(One solution would be to use the HTML5lib parser on <nowiki> blocks.)
In any case, this baby is 3 times as fast as the HTML5lib sanitizer.
