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.) |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| NEWS | ||
| README.Debian | ||
| changelog | ||
| compat | ||
| control | ||
| copyright | ||
| examples | ||
| postinst | ||
| preinst | ||
| rules | ||
README.Debian
It's a good idea, and in some cases a requirement, to rebuild your wikis when upgrading to a new version of ikiwiki. If you have a lot of different wikis on a system, this can be a pain to do by hand, and it's a good idea to automate it anyway. This Debian package of ikiwiki supports rebuilding wikis on upgrade. It will run ikiwiki-mass-rebuild if necessary when upgraded. The file /etc/ikiwiki/wikilist lists the setup files of wikis to rebuild, as well as the user who owns the wiki. Edit this file and add any wikis you set up. You can also allow users to maintain their own list of wikis to rebuild, by listing their usernames in /etc/ikiwiki/wikilist without corresponding setup files. ikiwiki will then read their lists of wikis from .ikiwiki/wikilist in their home directories. The examples directory contains the source to some example wiki setups.