| Age | Commit message (Collapse) | Author |
|---|
|
error() from such hooks; it will cause a nicely formatted error message to be inserted into the page.
|
|
|
|
needed since the doc wiki is using an [[img]]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
former, while slower, has a much better html parser that avoids numerous bugs.
|
|
|
|
|
|
|
|
transition works again.
|
|
|
|
can call IkiWiki::Setup::load, and the values will be loaded into %IkiWiki::Setup::setup.
|
|
|
|
|
|
|
|
|
|
This is truely horribly disgusting. CGI::tmpFileName, in current perls, is
an undocumented function (which should be a clue..) that takes the original
filename of an uploaded attachment, and returns the name of the tempfile
that CGI has stored it in.
In old perls, though, CGI::tmpFileName does not take a filename. It takes
a key from the object's {'.tmpfiles'} hash. This key is something
crazy like '*Fh::fh00001group' -- apparently the stringification of a
filehandle object.
Just to add to the fun, tmpFileName doesn't take the key, it expects a
refernce to the key. Argh?!
But the fun doesn't stop there, because in perl 5.8, CGI.pm is also broken
in two other ways. The upload() method is supposed to return a filehandle
to the temp file. It doesn't. The param() method is supposed to return
a filehandle to the temp file, that stringifies to the original filename.
It returns just the original filename, no filehandle.
Combine all these bugs, and you end up with this disgusting commit. Since
I have no way to get the filehandle, I *need* to get the tempfile name.
If I had the filehandle, I could probably pass it into tmpFileName, and
it might strigify to the right key name. But I don't, so the only way to
determine the key is to grub through the .tmpfiles hash ourselves.
And finally, one the temp file name is discovered, a filehandle can finally
be obtained by (re)opening it.
I recommend that this commit be reverted when perl 5.8 is a mercifully
faded memory.
I'm really, really, really glad I'm actually being paid for working on
this right now!
|
|
|
|
|
|
So the problem is that ikiwiki would generate a relative link like
href="colon:problem", which web browsers treat as being in the "colon:"
uri scheme.
The best fix seems to be to make url beautification fix this, by slapping
a "./" in front.
|
|
currently has no attachments.
|
|
|
|
|
|
|
|
* The editpage form now uses the raw page name, not the page title, in its
'page' cgi parameter. Using the title was ambiguous and made it
impossible to tell between some pages, like "foo/bar" and "foo__47__bar",
sometimes causing the wrong page to be edited.
* This change means that some edit links need to be updated.
Force a rebuild on upgrade to this version.
* Above change also allowed really fixing escaped slashes from the blogpost
form.
|
|
|
|
closed toggles will not be displayed as the page is loading.
|
|
Also fix to work in preview mode.
|
|
|
|
|
|
|
|
|
|
* toc: Revert change in 2.45 that made it run at sanitize time. This breaks
use of toc in a sidebar.
* Call format hooks when generating page previews, thus fixing toc display
there, as well as fixing inlins to again display in page previews, since
it's started using format hooks. This also allows several other things,
like embed, that use format hooks, to work during page preview time.
* Format hooks should not rely on getting an entire html document, as they
will only get the body during page preview.
* toggle: Deal with preview mode when adding javascript.
|
|
|
|
|
|
<http://universaleditbutton.org/>
Not forcing a rebuild on upgrade just for this.
|
|
|
|
|
|
work with ikiwiki. Reportedly, version 0.9.9 is too old to work. Closes: #486592
|
|
is flagged as utf-8, but contains invalid characters such as 0x92. To prevent it from crashing, re-encode the content before calling it, which will ensure that it's really utf-8.
|
|
map: Support show=description.
|
|
|
|
|
|
titles, rather than the default page name. Based on a patch from Jaldhar H. Vyas, Closes: #484510
|
|
This special case crops up when generating the parentlink to the toplevel
index page. urlto("") had been generating a link to "./" (or "../" etc)
for that, which is fine, if the web server redirects that to the toplevel
index.html. It's less fine if there is no web server.
I actually ran into the problem first when using gopher. (Yes, yes, don't
laugh.. see upcoming tip.) But it also crops up when browsing local wiki
files.
Of course, the index.html is stripped back off if usedirs is enabled.
|
|
|
