| Age | Commit message (Collapse) | Author |
|---|
|
Reindented, moved a TODO from page to code, trimmed some unnecessary
comments, and simplified the use of mkstemp.
|
|
|
|
titles, rather than the default page name. Based on a patch from Jaldhar H. Vyas, Closes: #484510
|
|
* ikiwiki-mass-rebuild: Make group list comparison more robust.
* search: Work around xapian bug #486138 by only stemming locales
in a whitelist.
|
|
class and id too.
|
|
|
|
- Add a Help link.
- If the pageterm is too long, hash it.
|
|
This occurred when a plugin, loaded earlier, filled out a template in its
checkconfig, before recentchanges's checkconfig had run. Since such a
template won't be a recentchanges template, just test for the value being
uninitialized and skip processing.
|
|
as well as for pages that contain a given link ("link:bar").
|
|
|
|
Using the title obscured path info, and made search results look
inconsistent. Since nothing else uses the title like that, it didn't make
sense for search to.
|
|
|
|
|
|
|
|
|
|
Because the search plugin needed it, also because it's one of the few
plugins that didn't already have it.
I also considered adding it to htmlize, but I really cannot imagine caring
what the destpage is when htmlizing. (I'll probably be poven wrong later.)
|
|
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.
|
