| Age | Commit message (Collapse) | Author |
|---|
|
|
|
holger reported that decode_utf8 was crashing with perl 5.8.8. Earlier, I
thought that passing 0 to the function avoided this with old perls, but
that was apparently not enough, it still crashes. So, put it inside the
eval, so we can at least recover from it crashing.
|
|
|
|
Done inline on the page, `scuse.
|
|
|
|
|
|
|
|
|
|
The old code actually did the same thing, just obfuscated -- since the eval
use wasn't quoted, it used the modules on load. Thus, the error (not to
mentioned the return) was bypassed, and it just failed on load.
But that seems like the right thing to do, really, so just made it clearer
that's what happens.
|
|
|
|
Used the contrib version of the plugin page since it seemed better than the
other one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
|
|
|
|
Since ikiwiki uses open :utf8, perl assumes that files contain valid utf-8.
If it turns out to be malformed it may later crash while processing strings
read from them, with 'Malformed UTF-8 character (fatal)'.
As at least a quick fix, use utf8::valid as soon as data is read, and if
it's not valid, call encode_utf8 on the string, thus clearing the utf-8
flag. This may cause follow-on encoding problems, but will avoid this
crash, and the input file was broken anyway, so GIGO is a reasonable
response. (I looked at calling decode_utf8 after, but it seemed to cause
more trouble than it was worth. BTW, use open ':encoding(utf8)' avaoids
this problem, but the corrupted data later causes Storable to crash when
writing the index.)
This is a quick fix, clearly imperfect:
- It might be better to explicitly call decode_utf8 when reading files,
rather than using the IO layer.
- Data read other than by readfile() can still sneak in bad utf-8. While
ikiwiki does very little file input not using it, stdin for the CGI
would be one way.
|
|
|
|
|
|
This is necessary so that things that fork to the background,
like pinger, and inline ping, don't block other cgis from running.
Note that websetup also calls unlockwiki, before refreshing / rebuilding
the wiki. It makes perfect sense for that not to block other cgis.
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
* Stop busy-waiting in lockwiki, as this could delay ikiwiki from waking up
for up to one second. The bailout code is no longer needed.
* Remove support for unused optional wait parameter from lockwiki.
|
|
|
|
Fixed by making the cgi wrapper wait on a cgilock.
If you had to set apache's MaxClients low to avoid ikiwiki thrashing
your server, you can now turn it up to a high value.
The downside to this is that a cgi call that doesn't need to call lockwiki
will be serialised by this so only one can run at a time. (For example,
do=search.) There are few such calls, and all of them call loadindex,
so each still eats gobs of memory, so serialising them still seems ok.
|
|
|
|
|
|
|
|
... that I previously completely missed.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
This is not needed now that tagpage returns a page name starting with a
slash.
(Also fixes a minor bug that the edit links started with double slashes due
to the hack.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Yahoo! has been pounding on ikiwiki.cgi again. While I'd prefer ikiwiki to
generate sites that avoided robots hitting it in other ways, I'm adding a
robots.txt, at least temporarily.
|
