| Age | Commit message (Collapse) | Author |
|---|
|
This way, do=goto will go to the page relative to
the current location, while the permalinks in feeds
will be absolute (unless an url is not configured at all).
|
|
the htmlscrubber to look at page rather than destpage caused htmlscrubber_skip to not work for meta directives.
|
|
|
|
With a relative xrds-location, the openid perl client module will fail.
I haven't checked the specs to see if it needs to be absolute, but all
examples I've seen are absolute, so it seems a very good idea.
|
|
|
|
array of things that need built. (Backwards compatability code keeps plugins using the old interface working.)
|
|
The idea here is that <meta name="foo" description="bar">
can be written like [[!meta name="foo" description="bar">.
Of course, [[!meta foo=bar]] is still supported; this new feature
provides some DWIM when trying to directly convert a meta tag into
a meta directive.
|
|
(cherry picked from commit 8b6fde73669ddf9204acb3d334c3984566f3c59d)
Conflicts:
IkiWiki/Plugin/meta.pm
|
|
This is needed so that when a negated pagespec like "!author(foo)"
stops matching, due to the page being changed, ikiwiki knows that
the match was influenced by the page content.
|
|
Conflicts:
IkiWiki/Plugin/meta.pm
|
|
|
|
This makes them consistent with the rest of the meta keys. A wiki rebuild
will be needed on upgrade to this version; until the wiki is rebuilt,
double-escaping will occur in the titles of pages that have not changed.
|
|
|
|
|
|
|
|
Joey pointed out that sort=x usually takes a sort order.
|
|
I've left meta_title in, undocumented, as a possible replacement for
sort=title in IkiWiki 4.0 or something.
|
|
Also rename cmpspec_translate (internal function) to sortspec_translate
for consistency.
|
|
|
|
This allows correct sorting of titles, names, etc., with:
[[!meta title="David Bowie" sort="Bowie, David"]]
[[!meta title="The Beatles" sort="Beatles, The"]]
|
|
|
|
plugins from the setup file.
|
|
value. (Thanks, NicolasLimare)
|
|
Unlike generic meta foo tags, meta description is known to be safe, so can
be special cased to be allowed despite the html scrubber. This makes meta
description much more useful, since it is otherwise limited to being used
by other plugins like map.
|
|
With the htmlscrubber disabled, it was adding a <meta name=title>
tag for the title, which is pointless.
|
|
using a template that does not include page content.
|
|
I made match_* functions whose influences can vary depending on the page
matched set a special "" influence to indicate this.
Then add_depends can try just one page, and if static influences are found,
stop there.
|
|
Also, this fixes 2 bugs in dependency info.
|
|
If a pagespec fails to match, I had been throwing the influences away, but
that is not right. Consider `backlink(foo)`, where foo does not exist.
It still needs to be added as an influence, because if it is created, it
will influence the pagespec to match.
But with that fix, `link(bar)` had as influences all pages, whether they
link to bar or not. Which is not necessary, because modifiying a page to
add a link to bar will directly cause the pagespec to match.
So, in match_link (and all the match_* functions for page metadata),
only return an influence if the match succeeds.
match_backlink had been implemented as the inverse of match_link, but that
is no longer completly true. While match_link does not return an influence
on failure, match_backlink does.
match_created_before/after also return the influence on failure, this way
if created_after(foo) currently fails because foo does not exist, it will
still update the page with the pagespec if foo is created.
|
|
|
|
Also update docs, test suite.
|
|
Simplify, change default content depends number to 1,
change interface to make more sense.
|
|
|
|
Previously, [[!meta redir="foo"]] on bar, where bar/foo exists, would
depend on "foo" (which matches nothing, probably) rather than "bar/foo".
(cherry picked from commit f27ec09b72f886415e63fe394e18d9c3cb3913bf)
|
|
|
|
This is sorta an optimisation, and sorta a bug fix. In one
test case I have available, it can speed a page build up from 3
minutes to 3 seconds.
The root of the problem is that $links{$page} contains arrays of
links, rather than hashes of links. And when a link is found,
it is just pushed onto the array, without checking for dups.
Now, the array is emptied before scanning a page, so there
should not be a lot of opportunity for lots of duplicate links
to pile up in it. But, in some cases, they can, and if there
are hundreds of duplicate links in the array, then scanning it
for matching links, as match_link and some other code does,
becomes much more expensive than it needs to be.
Perhaps the real right fix would be to change the data structure
to a hash. But, the list of links is never accessed like that,
you always want to iterate through it.
I also looked at deduping the list in saveindex, but that does
a lot of unnecessary work, and doesn't completly solve the problem.
So, finally, I decided to add an add_link function that handles deduping,
and make ikiwiki-transition remove the old dup links.
|
|
Some aggregators, like Planet, sort by mtime rather than ctime. This
means that posts with modified content come to the top (which seems odd
to me, but is presumably what the aggregator's author or operator
wants), but it also means that posts with insignificant edits (like
adding tags) come to the top too. Atom defines <updated> to be the date
of the last *significant* change, so it's fine that ikiwiki defaults to
using the mtime, but it would be good to have a way for the author to
say "that edit was insignificant, don't use that mtime".
|
|
|
|
sorting in inlines.
|
|
|
|
|
|
|
|
too many plugins.. brain exploding..
|
|
|
|
|
|
plugin, so that PageSpecs with title(...) work again
|
|
|
|
(otherwise leave it alone, so we can assign non-UUID <id>s to Atom items to avoid planet-flooding)
|
|
|
|
|
