| Commit message (Collapse) | Author | Age |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
can be used to avoid a security check that is a good safe default, but
problimatic overkill in some situations.
I decided to underdocument this, because the option looks ugly, and I don't
want people randomly turning it on because it looks like a good idea. So if
you need it, you'll get an error message mentioning how to fix it.
|
| | |
| |
| |
| | |
As documented in the forum post.
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
| |
| |
| | |
Previous fix mised a few cases.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Still need to consider all the edge cases..
|
| |/
|
|
| |
(Done for svn, git.)
|
| | |
|
| |
|
|
| |
converted. (Simon McVittie)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The committer's email address is not used (because leaking email addresses
is not liked by many users). Closes: #451023
A "Web-commit" trailer is added, to allow telling the difference between
web commits and direct commits.
|
| |
|
|
|
| |
* Add a postscan hook.
* search: Use postscan hook, avoid updating index when previewing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Smileys need to be double-escaped to work, since the smiley plugin runs as
a sanitize hook, and markdown helpfully removes one level of escapes first.
There were some bugs in the smiley handling code that made escaped smileys
still be expanded. After unescaping a smiley, it needed to move pos forward
past it or the next pass would expand it.
Also, once the m//g got to the end, it seemed to loop back through and make
one more pass (a difference in perl 5.10's regexp exngine? I observed that
pos was undefined when this happened, so added a `last unless defined pos`.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
todo items from the html shipped in it.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|