tag 473987 +patch
thanks
Hi,
The issue is that we need to convert relative links to absolute
ones for atom and rss feeds -- but there are two types of
relative links. The first kind, relative to the current
document ( href="some/path") is handled correctly. The second
kind of relative url is is relative to the http server
base (href="/semi-abs/path"), and that broke.
It broke because we just prepended the url of the current
document to the href (http://host/path/to/this-doc/ + link),
which gave us, in the first place:
http://host/path/to/this-doc/some/path [correct], and
http://host/path/to/this-doc//semi-abs/path [wrong]
The fix is to calculate the base for the http server (the base of
the wiki does not help, since the base of the wiki can be
different from the base of the http server -- I have, for example,
"url => http://host.name.mine/blog/manoj/"), and prepend that to
the relative references that start with a /.
This has been tested.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
destpage does not normally need to be worried about when creating other files
as part of the process of rendering a page. Using destpage results in
inlined pages creating two copies of such files. It works to not use destpage
in this case because the inlining page depends on the source page, so if the
source page is modified or deleted the inlining page will be updated.
Instead of using the XML-RPC v2 extension <nil/>, which Perl's
XML::RPC::Parser does not (yet) support (Joey's patch is pending), we
agreed on a sentinel: {'null':''}, that is, a hash with a single key
"null" pointing to the empty string.
The Python proxy automatically converts None appropriately and raises an
exception if a hook function should, by weird coincidence, attempt to
return {'null':''}.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Markdown is slow. Especially if it has to process an enormous page. The
most common enormous page is currently the recentchanges page, which gets
processed a lot, and contains very little actual markdown. Most of it is a
big <div>, which markdown skips ... slowly.
This is a rather sick optimisation to work around markdown's speed issues.
Now inline inserts a small, dummy div, allows markdown to quickly render
the actual page content, then replaces the dummy with the actual inlined
pages later.
Results: Rendering just a recentchanges page, with diffs included, dropped
from 4.5 seconds to 2.7 seconds on my laptop. Building the entire wiki
dropped from 46.6 seconds to 39.5 seconds.
(It would be better if inline were a *post*-processor directive.)
xml rpc only allows functions to return a single value, no lists. So getargv
needs to return a list reference, which means that the caller will see an xml
rpc array.
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.
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>
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>
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.
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.
Now aggregation will not lock the wiki. Any changes made during aggregaton are
merged in with the changed state accumulated while aggregating. A separate
lock file prevents multiple concurrent aggregators. Garbage collection
of orphaned guids is much improved. loadstate() is only called once
per process, so tricky support for reloading wiki state is not needed.
(Tested fairly thuroughly.)
license, and copyright. This can be used to create custom RecentChanges.
* meta: To support the pagespec functions, metadata about pages has to be
retained as pagestate.
* Fix encoding bug when pagestate values contained spaces.
I kept it to a simple global configuration, rather than using the
preprocessor directive for recentchanges, because that had chicken and egg
problems and seemed overcomplicated. This should work reasonably well,
though it would be good to add some more metadata so that more customised
recentchanges pages can be made.
gettext choked on a Unicode apostrophe in the aggregate plugin, which
appeared in a new error message in commit
4f872b5633. Replace it with an ASCII
apostrophe.
the code, since that process can change internal state as needed, and
it will automatically be cleaned up for the parent process, which proceeds
to render the changes.
remove the enclosing paragraph and newline markdown wraps it in.
This allows removing several hacks around this markdown behavior from
other plugins that htmlize fragements of pages.
returned (and not run in some cases) rather than the plugins directly
forcing a user to log in.
* opendiscussion: allow editing of the toplevel discussion page,
and, indirectly, allow creating new discussion pages.
the needsbuild hook. This resulted in feeds not being removed when pages
were updated, and probably other bugs.
* aggregate: Avoid uninitialised value warning when removing a feed that
has an expired guid.
links required meta to be run during scan, which complicated its data
storage, since it had to clear data stored during the scan pass to avoid
duplicating it during the normal preprocessing pass.
* If you used "meta link", you should switch to either "meta openid" (for
openid delegations), or tags (for internal, invisible links). I assume
that nobody really used "meta link" for external, non-openid links, since
the htmlscrubber ate those. (Tell me differently and I'll consider bringing
back that support.)
* meta: Improved data storage.
* meta: Drop the hackish filter hook that was used to clear
stored data before preprocessing, this hack was ugly, and broken (cf:
liw's disappearing openids).
* aggregate: Convert filter hook to a needsbuild hook.
inserting them into the html template. This ensures that markdown
acts on them, even if the value is expanded inside a block-level html
element in the html template. Closes: #454058
* Use a div in the note template rather than a span.
so that more than one plugin can use this hook.
I believe this is a safe change, since only passwordauth uses this hook.
(If some other plugin already used it, it would have broken passwordauth!)
It would be better if it were a formbuilder hook. But the formbuilder hook
is wacked.. I may need to change how that hook works, which would mean
changing the only current user of it, passwordauth).
and forces rebuilds of the pages that contain calendars. So
running ikiwiki --refresh at midnight is now enough, no need for a full
wiki rebuild each midnight.
* calendar: Work around block html parsing bug in markdown 1.0.1 by
enclosing the calendar in an extra div.
which has been reported to cause encoding problems (though I haven't
reproduced them), just catch a failure of markdown, and retry.
(The crazy perl bug magically disappears on the retry.)
Closes: #449379
Joey Hess
Manoj Srivastava
martin f. krafft
Adeodato Simó
Josh Triplett
Patrick Winnertz
Joey Hess
Thomas Schwinge
Nis Martensen