| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
This is not needed by the use I'm doing of it, but seems more consistent to me.
Future users of this hook may need this data to make their mind.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
The po plugin remame + canrename hook combination will need this.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
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.)
|
|
This is easier to remeber, and less error-prone than passing it all the
pages in the wiki.
|
|
|
|
|
|
|
|
|
|
|
|
Wired up check_canedit and check_canremove, still need to deal with
check_canattach, and test.
|
|
Still need to wire up the calls to check_* , but it's cold out here and my
hands are going numb, so enough for now.
|
|
|
|
Add an inject function, that can be used by plugins that want to replace
one of ikiwiki's functions with their own version. (This is a scary thing
that grubs through the symbol table, and replaces all exported occurances
of a function with the injected version.)
external: RPC functions can be injected to replace exported functions.
Removed the stupid displaytime hook, and use injection instead.
|
|
Need to use a hook because an exported function cannot be reliably
overridden. The replacement verstion was actually only affecting plugins
loaded after it.
formattime doesn't need a hook, since there's no reason to export it.
|
|
* Add an underlay for javascript, and add ikiwiki.js containing some utility
code.
* toggle: Stop embedding the full toggle code on each page using it, and
move it to toggle.js in the javascript underlay.
|
|
|
|
page, and is preserved across rebuilds.
|
|
|
|
suggestion from smcv
|
|
|
|
|
|
|
|
|
|
Reasons include:
- easier to type
- might want postprocessor directives again sometime, and listdirectives
can then use the directive/* files for either
- that it's done as a preprocessor step is an internal detail (and not a
very accurate one, really :-)
|
|
|
|
|
|
|
|
|
|
|
|
The locked pages configuration is moving to a locked_pages option in the
setup file, and the allowed attachments configuration to
allowed_attachments. The admin prefs page can still be used for these, but
that's depreacted and will only be shown if there's currently a value.
|
|
Conflicts:
IkiWiki/Plugin/git.pm
debian/changelog
po/ikiwiki.pot
|
|
|
|
|
|
To generate your own, use ikiwiki -dumpsetup ikiwiki.setup
Update docs.
|
|
|
|
|
|
They were a bit confusing, since they did not actually set the default, and
example values are sufficient.
|
|
|
|
|
|
|
|
The fix for colons involved adding "./" to some urls. Due to the weird way
inline called urlto, these snuck into feed urls and permalinks. Fix it by
adding an optional third parameter to urlto.
|
|
Implemented for regular wikilinks, with a test suite.
|
|
|
