This works around a perl crasher bug, and also avoids bloating pages
with enormous diffs.
rcs_recentchanges modified to return a list in an array context.
If a diff of the firsst commit in a git repo was requested, it would fail and
print to stderr since first^ isn't valid. Using git show will always work.
set to the destination page. This avoids need for hacks to munge the urls
in preview mode, which fixes several bugs.
* Several destpage fixes in plugins.
Adds an optional xrds-location parameter to the openid meta handler,
which allows for XRDS delegation.
A good document on XRDS is
http://www.windley.com/archives/2007/05/using_xrds.shtml
Signed-off-by: martin f. krafft <madduck@madduck.net>
correct, and it's certianly not correct now, since the wiki is locked
before rcs_commit is ever called, and should not be unlocked by
rcs_commit either.
Markdown is such a splintered mess.. The current debian package provides
only Text::Markdown::Markdown, while all versions of Text::Markdown support
Text::Markdown::markdown, and old versions also support the capitalised version,
while new ones don't.
It's getting to the point where `grep /markdown/i %symbol_table` is the only
sane way to figure out what function to call..
* rcs_diff is a new function that rcs modules should implement.
* Implemented rcs_diff for git, svn, and tla (tla version untested).
Mercurial and monotone still todo.
Add special handling for <meta name="robots" ...> which needs not be
scrubbed as it's harmless.
Signed-off-by: martin f. krafft <madduck@madduck.net>
(cherry picked from commit b15d0299a7f7b147e89d8a202d6cca1c21491af2)
A new regexp fixes this bug:
http://ikiwiki.info/bugs/No_link_for_blog_items_when_filename_contains_a_colon/
I traced this down to htmlscrubber. If disabled,
it works. If enabled, then $safe_url_regexp
determines the URL unsafe because of the colon and
hence removes the src attribute.
Digging into this, I find that RFC 3986 pretty
much discourages colons in filenames:
"""
A path segment that contains a colon character
(e.g., "this:that") cannot be used as the first
segment of a relative-path reference, as it would
be mistaken for a scheme name. Such a segment must
be preceded by a dot-segment (e.g., "./this:that")
to make a relative- path reference.
"""
on the other hand, with usedirs, any link to
another page will be prepended by ../ anyway, so
that makes them okay again.
The solution still seems not to use colons.
In any case, htmlscrubber should get a new regexp,
courtesy of dato.
I have tested and verified this.
Signed-off-by: martin f. krafft <madduck@madduck.net>
As was already done for linkfication, links generated in a prevew page
are relative to the top of the wiki, so it has to be told that the destpage
is there.
I was using "" to indicate this, but that may confuse some preprocessor
plugins, which treat parameters with an empry value specially (sparkline is one
such). Instead, use "/", which is more accurate anyway and works just as well.
which forced a scan of the page to make available metadata that
appeared after the inline directive. Problem is that scan made it forget
about any other files rendered due to the page. The scan also turns out
to be unnecessary now, since meta persistently stores state and it's
always available. So it was just removed.
(as preserving the full list across preview would be tricky). Userdirs
were still being offered as an option there, remove them.
* Fix a bug where user A created a page concurrently with user B, and
when B previewed it would redirect B to A's new page, losing B's work.
Instead, don't redirect and let conflict handling resolve it.
containing ikiwiki.cgi, but this should not change the urls to the style
sheets etc. Add a new forcebareurl parameter to misctemplate to allow
it to do that.
of XML::RPC's default of us-ascii. Allows interoperation with
python's xmlrpc library, which threw invalid encoding exceptions and
caused the rst plugin to hang.
Some browsers interpret about: URIs like a limited version of data:
URIs. In particular, some versions of Internet Explorer interpret
arbitrary HTML content in about: URIs.
just avoid actually writing the files. This is necessary because ikiwiki
saves state after a preview (in case it actually *did* write files),
and if will_render isn't called its security checks will get upset
when the page is saved. Thanks to Edward Betts for his help tracking this
tricky bug down.
Joey Hess
martin f. krafft
Adeodato Simó
Josh Triplett