| Age | Commit message (Collapse) | Author |
|---|
|
The ?updated needs to come before the #anchor or browsers will not follow
the anchor.
|
|
|
|
|
|
linkify data from external files at the same time as data from an inlined
table would be linkified.
|
|
|
|
ikiwiki setups use. Document how to use the new url form.
|
|
It seems to be a failing of i18n in unix that the translation stops at the
commands and the parameters to them, and ikiwiki is no exception with its
currently untranslated directives. So the little bit that's translated sticks
out like a sore thumb. It also breaks building of wikis if a different locale
happens to be set.
I suppose the best thing to do is either give up on the localisation of this
part completly, or make it recognise English in addition to the locale. I've
tenatively chosen the latter.
(Also accept 1 and 0 as input.)
|
|
|
|
Closes: #510518
|
|
|
|
ikiwiki release, and is thus not present in the setup file yet.
This happened with camelcase_ignore. The code tried to convert the undef
value for it into an array.
|
|
|
|
is not present.
|
|
This got lost when we added the jump-to-comment anchor.
|
|
developed by Anna Hess. The official logo does not seem destined to be free.
|
|
Conflicts:
debian/changelog
po/ikiwiki.pot
|
|
|
|
|
|
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.
|
|
|
|
People seem to be able to expect to enter www.foo.com and get away with it.
The resulting my.wiki/www.foo.com link was not ideal.
To fix it, use URI::Heuristic to expand such things into a real url. It
even looks up hostnames in the DNS if necessary.
|
|
Conflicts:
IkiWiki/Plugin/googlecalendar.pm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sorting in inlines.
|
|
aggregation is run, even if the usual time has not passed. Closes: #508622 (Michael Gold)
|
|
|
|
|
|
rather than closing the pipe, which it dislikes. (thm)
|
|
titlepage normally escapes, but so does formbuilder.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Had forgot to include it in the option list.
|
|
|
|
|
|
The old method failed for '[' x 3.
|
|
time).
|
|
Used the contrib version of the plugin page since it seemed better than the
other one.
|
|
|
