summaryrefslogtreecommitdiff
path: root/debian/rules
diff options
context:
space:
mode:
authorJoey Hess <joey@gnu.kitenet.net>2009-03-08 18:46:18 -0400
committerJoey Hess <joey@gnu.kitenet.net>2009-03-08 18:49:34 -0400
commitd3b4c2dbd13f6721042db7a7b6843851c9037551 (patch)
tree217212203e3eaa09f0bf2b4dca8b2e49d175be1e /debian/rules
parent1edad6dca70175fd44b4f2e4e3bd8b3b16bbc055 (diff)
avoid potential infinite loop in smiley expansion
- In 3.05, ikiwiki began expanding templates in scan mode, for annoying, expensive, but ultimatly necessary reasons of correctness. - Smiley processing has a bug: It inserts a span for the smiley, and then continues searching forward in the content for more, starting at $end_of_smiley+1. Which means it searches for smilies in the span too! And if it somehow finds one, we get an infinite loop here. - This bug can, probably, only be tickled if a htmllink to show the smiley fails, because the smiley file doesn't exist, or because ikiwiki doesn't know about it. In that case, a link will be inserted to _create_ the missing page, and that link will include the smiley inside the <a></a>. - When a template is expanded in scan mode, and it contains an inline, the sanitize hook is run during scan mode, which never happened before. That causes the smiley processor to run, before ikiwiki is, necessarily, aware that all the smiley files exist (depending on scan order). So it inserts creation links for them, and triggers the bug. I've put in the simple fix of jumping forward past the inserted span, and it does fix the problem. I will need to look in a bit more detail into why an inline nested inside a template is fully expanded during the scan pass -- that really shouldn't be necessary, and it makes things much slower than they need to be.
Diffstat (limited to 'debian/rules')
0 files changed, 0 insertions, 0 deletions