| Age | Commit message (Collapse) | Author |
|---|
|
I think this will give better results overall.
I made %IkiWiki::preprocessing accessible and used it to avoid indexing
at unnecessary points.
|
|
|
|
|
|
The omega docs suggest doing this if the term may contain upper case, which
it could here.
|
|
"substr outside of string"
|
|
this seems to be the thing to use for a unique id
|
|
|
|
|
|
|
|
|
|
Still some TODOs to fill in.
|
|
Everything is done except for the actual indexing. I plan to do incremental
indexing as pages change.
|
|
avoid overoptimising.
|
|
|
|
This implements the previously documented hashed password support.
While implementing that, I noticed a security hole, which this commit
also fixes..
|
|
|
|
|
|
explicitly pass 0 (FB_DEFAULT) as the second parameter. Apparently perl 5.8 needs this to avoid crashing on malformed utf-8, despite its docs saying it is the default.
|
|
between the two versions.
|
|
just expanded to nothing.
|
|
orphaned page.
|
|
|
|
Something has changed in CGI.pm in perl 5.10. It used to not care
if STDIN was opened using :utf8, but now it'll mis-encode utf-8 values
when used that way by ikiwiki. Now I have to binmode(STDIN) before
instantiating the CGI object.
In 57bba4dac132a06729eeec809f5e1a5adf829806, I changed from decoding
CGI::Formbuilder fields to utf-8, to decoding cgi parameters before setting
up the form object. As of perl 5.10, that approach no longer has any effect
(reason unknown). To get correctly encoded values in FormBuilder forms,
they must once again be decoded after the form is set up.
As noted in 57bba4da, this can cause one set of problems for
formbuilder_setup hooks if decode_form_utf8 is called before the hooks, and
a different set if it's called after. To avoid both sets of problems, call
it both before and after. (Only remaining problem is the sheer ugliness and
inefficiency of that..)
I think that these changes will also work with older perl versions, but I
haven't checked.
Also, in the case of the poll plugin, the cgi parameter needs to be
explcitly decoded before it is used to handle utf-8 values. (This may have
always been broken, not sure if it's related to perl 5.10 or not.)
|
|
|
|
|
|
Turns out duplicate index files do not need to be stored when usedirs is in
use, just when it's not. Ikiwiki is quite consistent about using page/ when
usedirs is in use. (The only exception is the search plugin, which needs
fixing.)
This also includes significant code cleanup, removal of a incorrect special
case for empty files, and addition of a workaround for a bug in the amazon
perl module.
|
|
|
|
|
|
|
|
|
|
number of system calls in half. (Still room for improvement.)
|
|
|
|
|
|
stuck on shared hosting without cron. (Sheesh.) Enabled via the `aggregate_webtrigger` configuration optiom.
|
|
srcfile now has an optional second parameter to avoid it throwing an error
if the source file does not exist.
|
|
|
|
anonymous users to edit only matching pages. Closes: #478892
|
|
|
|
This allows the toc to be displayed when previewing an edit. It also avoids headers in the page template from showing up in the toc.
|
|
Also, simplified finding the url to the top of the site.
|
|
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>
|
|
lacking one.
|
|
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.
|
|
for "show".
|
|
|
|
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.)
|
|
I had to move it to sanitize so all the markup is htmlized, so it can scan
for <pre> and <code>.
|
