| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.)
|
|
|
|
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
|
|
|
|
|
|
A new ikiwiki-transition moveprefs subcommand can pull the old data out of
the userdb and inject it into the setup file.
Note that it leaves the old values behind in the userdb too. I did this
because I didn't want to lose data if it fails writing the setup file for
some reason, and the old data in the userdb will only use a small amount of
space. Running the command multiple times will mostly not change anything.
|
|
|
|
|
|
|
|
This fixes a bug, that comments appear in recentchanges as broken links.
|
|
|
|
|
|
This improves the display of OpenIDs like 'http://id.mayfirst.org/jamie/'
(taking an example from the IkiWiki commit log).
|
|
subdomains
This leads to better display for OpenIDs like smcv.pseudorandom.co.uk
and thm.id.fedoraproject.org (to take a couple of examples from the
IkiWiki commit history).
|
|
This fixes the bug that comments are always said to be from an anonymous
user at an unknown IP address.
|
|
|
|
sorting in inlines.
|
|
None of the comment state needs to be stored through the a later run of
ikiwiki, so move it all from pagestate to a more transient storage.
This is assuming that we'll never want to add pagespecs to search against
the comment state. Pagespecs like author() are why the meta plugin does
store its meta data in pagestate -- the data can be needed later to match
against.
|
|
COMMENTAUTHORURL
Also refactor page.tmpl to use if/else rather than unless/if.
|
|
|
|
|
|
|
|
This can happen when a new field,
such as the new lasttry, is added.
|
|
|
|
wtf does it do? absolutely nothing
|
|
|
|
|
|
The thinking here is that having both a Discussion page and comments for
the same page is redundant, and certianly not what you want if you enable
comments for a page. At first I considered making configurable via pagespec
what pages got discussion links. But that would mean testing a new pagespec
for every page, and a redundant config setting to keep in sync. So intead,
take a lead from my previous change to make inlined pages have a comments
link, and change the discussion link at the top of regular pages to link to
their comments.
(Implementation is a bit optimised to avoid redundant pagespec checking.)
|
|
Jumping to the just posted comment was the imputus, but I killed a number
of birds here.
Added a INLINEPAGE template variable, which can be used to add anchors to
any inline template.
To keep that sufficiently general, it is the full page name, so the
comment anchors and links changed form.
Got rid of the FIXMEd hardcoded html anchor div.
More importantly, the anchor is now to the very top of the comment, not the
text below. So you can see the title, and how it attributes you.
Avoid changing the permalink of pages that are not really comments, but
happen to contain the _comment directive. I think that behavior was a bug,
though not a likely one to occur since _comment should only really be used
on comment pages.
|
|
aggregation is run, even if the usual time has not passed. Closes: #508622 (Michael Gold)
|
|
Not ideal, it would be nicer to jump to the actual comment posted, but no
anchor is available.
|
|
|
|
This link will supplant the usual Discussion link for pages
that have comments enabled.
|
|
|
|
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.
|
|
defaults cannot be set in getsetup, do it in checkconfig to avoid
uninitialized value warnings.
|
|
|
|
This function as factored out was a bit confusing, I think this makes more
sense.
|
|
|
|
rather than closing the pipe, which it dislikes. (thm)
|
|
titlepage normally escapes, but so does formbuilder.
|
|
|
|
sessioncgi hooks are always called with the wiki locked
|
|
|
|
|
|
|
|
loadplugin("inline") should take care of that
|
