7da319efc6
inline has a format hook that is an optimisation hack. Until this hook runs, the inlined content is not present on the page. This can prevent other format hooks, that process that content, from acting on inlined content. In bug ##509710, we discovered this happened commonly for the embed plugin, but it could in theory happen for many other plugins (color, cutpaste, etc) that use format to fill in special html after sanitization. The ordering was essentially random (hash key order). That's kinda a good thing, because hooks should be independent of other hooks and able to run in any order. But for things like inline, that just doesn't work. To fix the immediate problem, let's make hooks able to be registered as running "first". There was already the ability to make them run "last". Now, this simple first/middle/last ordering is obviously not going to work if a lot of things need to run first, or last, since then we'll be back to being unable to specify ordering inside those sets. But before worrying about that too much, and considering dependency ordering, etc, observe how few plugins use last ordering: Exactly one needs it. And, so far, exactly one needs first ordering. So for now, KISS. Another implementation note: I could have sorted the plugins with first/last/middle as the primary key, and plugin name secondary, to get a guaranteed stable order. Instead, I chose to preserve hash order. Two opposing things pulled me toward that decision: 1. Since has order is randomish, it will ensure that no accidental ordering assumptions are made. 2. Assume for a minute that ordering matters a lot more than expected. Drastically changing the order a particular configuration uses could result in a lot of subtle bugs cropping up. (I hope this assumption is false, partly due to #1, but can't rule it out.) |
||
|---|---|---|
| Bundle | ||
| IkiWiki | ||
| cpan | ||
| debian | ||
| doc | ||
| plugins | ||
| po | ||
| t | ||
| templates | ||
| underlays | ||
| .gitignore | ||
| .perlcriticrc | ||
| CHANGELOG | ||
| IkiWiki.pm | ||
| Makefile.PL | ||
| NEWS | ||
| README | ||
| auto.setup | ||
| docwiki.setup | ||
| gitremotes | ||
| ikiwiki-makerepo | ||
| ikiwiki-mass-rebuild | ||
| ikiwiki-transition | ||
| ikiwiki-update-wikilist | ||
| ikiwiki-w3m.cgi | ||
| ikiwiki.in | ||
| mdwn2man | ||
| pm_filter | ||
| wikilist | ||
README
Use ./Makefile.PL to generate a Makefile, "make" will build the documentation wiki and a man page, and "make install" will install ikiwiki. All other documentation is in the ikiwiki documentation wiki, which is also available online at <http://ikiwiki.info/> A few special variables you can set while using the Makefile: PROFILE=1 turns on profiling for the build of the doc wiki. (Uses Devel::Profile) NOTAINT=0 turns on the taint flag in the ikiwiki program. (Not recommended unless your perl is less buggy than mine -- see http://bugs.debian.org/411786) There are also other variables supported by MakeMaker, including PREFIX, INSTALL_BASE, and DESTDIR. See ExtUtils::MakeMaker(3). In particular, INSTALL_BASE is very useful if you want to install ikiwiki to some other location, as it configures it to see the perl libraries there. See `doc/tips/nearlyfreespeech.mdwn` for an example of using this to install ikiwiki and its dependencies in a home directory.