| Age | Commit message (Collapse) | Author |
|---|
|
|
|
There is a tension between looking up the avatar at post time
and build time. I have not yet decided which is better.
Lookup at build time has the benefit that if a user changes their
email address, or sets up their own federated libravatar
server, on rebuild their new avatar will show up.
It also allows getting a https version of the avatar easily if
the site was using http but was changed to use https.
And it can look up avatars for posts that have already been made.
Which is a nice thing, especially as we roll this out, eh?
But it has a drawback, that it depends on the sessiondb contents
for emails and so rebuilding a site w/o that will lose info.
And, it means dns lookups every time a comment is rendered. A page
with a lot of comments on it would render them all whenever another is
posted or the page is changed, and that could significantly slow things
down. (This could be amelorated by caching the lookups.)
Since I'm undecided, I have moved it into a function that could be called
either way. Currently looking up only at post time.
|
|
HTTPS won't be set when rebuilding a site at the command line
|
|
affects rcs_getctime. A small adjustment takes care of that.
|
|
|
|
Don't fail if libravatar fails for some reason. Reasons I can think
of:
* too old version to do openid lookups (fall back to email lookup)
* network problem perhaps
|
|
|
|
This requires version 1.04 or later of Libravatar::URL.
|
|
|
|
Use Libravatar::URL to pull the avatar picture for the comment
author if we have an email address for him/her.
|
|
(cherry picked from commit 44c5b27f88fdbfb4fdd061f600039e490eaeff92)
|
|
where the htmlscrubber is enabled.
|
|
breaking manual inlining of comments.
|
|
introduced in version 3.20100505.)"
This reverts commit b34d31142b9fed28ec9cf77fe0c5d9f405d48c84.
This was the wrong approach. It broke inlining of comment(*) on eg, a
toplevel comment page.
|
|
Oddly, this hadn't caused any visible breakage. Possibly inline,
which is the only thing to use targetpage, resolves the function
to the "real" one before po gets loaded?
|
|
If the inline plugin is not being loaded, or is perhaps loaded after po
(when IkiWiki::Setup::getsetup loads all the plugins, for example),
po should not inject its custom rootpage sub, as that will lead to a
redefinition error message when inline loads.
|
|
|
|
|
|
Since the plugin abuses the checkconfig hook to launch aggregation when in
--aggregate mode, it should give other plugins that have checkconfig hooks
a chance to run before they are possibly used in rendering the aggregated
content.
|
|
cookiejar configuration setting can be used by other plugins to provide a custom `cookie_jar` object for LWP::UserAgent. (Thanks, schmonz)
|
|
|
|
introduced in version 3.20100505.)
|
|
Here wikistatedir has not been configured.
|
|
This allows per-form/feedlink group customization without having to
resort to counting.
(cherry picked from commit b134feb0dc2d9a8ff7ae447537fa8bc02811aabd)
|
|
Second (forgotten) half of bb8f76a4a04686def8cc6f21bcca80cb2cc3b2c9.
This ensures that the link URL and page title in the feed are the
correct ones.
|
|
|
|
With the previous logic, same-level items would go down one level and
then again up one level closing and re-opening UL tags each time. The
resulting redundant lists caused whitespace layout issues in the
rendered pages.
Adjust the "moving up?" logic to check if the current item base is
different from the previous item _base_. Adjust the "going down?" logic
by moving it to an earlier phase and checking for (1) parent item not being
what it should be and (2) remaining bits; the root is grown unconditionally as
long as (2) is verified.
|
|
Conflicts:
t/tag.t
|
|
|
|
Assume the aggregated content is only going to be in one of the
directories, and so stop if it's successfully removed from the
transientdir.
|
|
|
|
|
|
|
|
Problem was this: websetup loads all plugins, but does not checkconfig
them. So, htmltidy's recently added configurable command setting was unset;
this resulted in its sanitize hook failing; the sanitize hook is called
when a sidebar was enabled, and this caused the sidebar to not display.
I put in a fix, but the underlying problem is that websetup loads all
plugins but leaves them in an unconfigured and possibly broken state while
trying to display its forms.
Probably the long-term fix is to have it cache the original hook states from
before loading the plugins, and restore it after getting their configuration.
Or, even to get the configuration using a subprocess, as plugins may do things
outside the hook system.
|
|
|
|
|
|
|
|
blogspam_pagespec to do other matches against who the user is.
|
|
|
|
properly this time
|
|
This reverts commit 5d3998555ffbeb1c20b84dd4cdc46c825c07bec8.
That broke posting via blog form.
|
|
|
|
|
|
As with the tag plugin, for the moment keep the old behaviour in the test.
|
|
|
|
- Migrate the set of deletions to the {autofile} set, since it has
more or less the same effect. This affects the "deleted" case in the
test.
- If a page has just been deleted, add it as an autofile anyway: by
the time gen_autofile is called, it'll be in the list of deleted files,
so it'll just be added to {autofile}. This affects the "gone" case
in the test.
- Behaviour change: we don't forget that a page with no reason to be
re-created was deleted. This affects the 'expunged' and 'reinstated'
cases in the test.
|
|
This does cause a minor regression: index pages are now committed
individually rather than being a single commit per rebuild.
This also means the autoindex regression test needs to trigger the
autofile generation pass.
|
|
underlay.
Skip fixing links in such pages. The user will get a list of pages that
still link to the old page.
|
|
Values have to be checked against wiki_file_regexp, not just file_pruned.
Audited the rest of the code base for similar problems, found none.
|
|
|
