| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
posting using the BlogSpam.net API.
|
|
including spam filters.
|
|
* repolist: New plugin to support the rel=vcs-* microformat.
* goodstuff: Include repolist by default. (But it does nothing until
configured with the repository locations.)
|
|
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.)
|
|
I see that this plugin's lists of safe content are already well out of
date, and htmlscrubber_skip offers a non whitelist based approach, so let's
deprecate this plugin for 3.0.
|
|
|
|
This is easier to remeber, and less error-prone than passing it all the
pages in the wiki.
|
|
|
|
No transition code implemented, but I will probably make a 2.x release that
warns about found globlists.
|
|
|
|
|
|
I'm turning on prefix_directives for the live wiki now.
|
|
|
|
|
|
|
|
|
|
|
|
I think it is clearer to have one pagespec that controls all pages with
comments, and a separate pagespec that can be used to close new comments on
a subset of those pages.
|
|
|
|
|
|
Moved todo items to a todo page, mark the old todo item about comments as
done, etc.
|
|
|
|
Moved documentation out of contrib.
Mostly tweaked some wording. Moved documentation of various bits to other
pages (pagespec, etc), and linked to those.
Documented the new templates in wikitemplates.
Small quantities of documentation were removed. Particularly the list of
template variables, which I think is fairly obvious when editing the
template.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
