| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
This change was introduced in 85f865b5d98e0122934d11e3f3eb6703e4f4c620 and
c3af3840a295780e0f32df398f2dc7d34653e75e ; it may be necessary for the meta-po
integration, but the po branch alone is supposed to work without it.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
|
|
This makes wikis such as zack's much faster in the scan pass.
In that pass, when a template contains an inline, there is no reason to
process the entire inline and all its pages. I'd forgotten to pass
along the flag to let preprocess() know it was in scan mode, leading to
much unncessary churning.
|
|
- 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.
|
|
|
|
|
|
Conflicts:
doc/todo/mdwn_preview.mdwn
|
|
|
|
|
|
This modification was initially done in editpage, in commit
a3726968bc13f19f458c372cbd7cf92ae4c6fce5, but was then lost while merging
upstream/master branch.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
version when I get time.
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
... as Joey suggested on todo/need_global_renamepage_hook
This hook is applied recursively to returned additional rename
hashes, so that it handles the case where two plugins use the hook:
plugin A would see when plugin B adds a new file to be renamed.
The full set of rename hashes can no longer be changed by hook functions, that
are only allowed to return any additional rename hashes it wants to add.
Rationale: the correct behavior of the recursion would be hard, if not
impossible, to define, if already considered pages were changing on the run.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
Conflicts:
IkiWiki/Plugin/editpage.pm
debian/control
debian/copyright
doc/todo/need_global_renamepage_hook.mdwn
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
|
|
|
|
This means that the underlay needs to have a wmd/wmd/wmd.js,
which is a trifle weird, but it isolates all the wmd stuff in a
single wmd subdirectory of the built wiki. The wmd/images creating
a toplevel images directory was particularly bad.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This plugin only affects the page edit, not the compiled wiki.
|
|
|
|
|
|
|
|
controls to ikiwiki edit pages.
|
|
|
|
|
|
|
|
|
|
close as dup todo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
