Arguably, the real bug is in the interface to add_autofile, but since
that does take a filename, not a page name, it cannot really do case
handling on its own. The only other users of add_autofile in ikiwiki proper
is autoindex, and it always uses one case. Other third party plugins might
also need to add similar workarounds though.
Since tag names are now retrieved from the file names, we must revert
the escaping process that santizes the file names. Solve by adding a
`pagetitle()` call at the end of the tagname()
(cherry picked from commit 0ee0612b1ab11d76eb3790c8db7a2ba992c54f6b)
The use of typed links for tags and some of the consequent changes
introduced some unwanted functionality variations in the tag system. Two
problems in particular could be observed, when compared to the use of
tags in older versions of IkiWiki:
* tags in feeds (both rss and atom) would use the file path as their
name (e.g. you would have <category term="tags/sometag" /> in an atom
item for a page tagged sometag with a tagbase of tags), whereas they
appeared pure before
* tags containing a slash character would appear without the slash
character but be used with the slash character in other circumstances
(effect visible by tagging a page with a name such as "with/slash")
Both of these issues are fixed by introducing a tagname() function that
takes a tag link and effectively reverses (as well as possible) the
effects of taglink().
A possible alternative route would have been the reintroduction of the
global %tags hash, but the new approach as the (arguable) benefit of
introducing a small layer of sanitation for tag names.
Using named parameters for these is overdue. Passing the session in a
parameter instead of passing username and IP separately will later allow
storing other session info, like username or part of the email.
Note that these functions are not part of the exported API,
and the prototype change will catch (most) skew, so I am not changing
API versions. Any third-party plugins that call them will need updated
though.
The commit that added the (working) support for using /tag to override
tagbase also tried to make ./tag work. Problem is, tags are links,
and ./foo is not a valid link (though I think there's a wishlist about it).
So, using ./tag really resulted in tag creation links that led to a
"bad page name" error. And even if the tag were created in the right place,
the link didn't go to it.
A tag like ./foo is searched for relative to the tagging page.
However, if multiple pages use such a tag, the only one sure
to be in common is in the root, so autocreate it there to
avoid scattering redunadant autocreated tags around the tree.
(This is probably not ideal.)
Also renamed the tagpage and taglink functions for clarity.
Made add_autofile take a generator function, and just register the
autofile, for later possible creation. The testing is moved into Render,
which allows cleaning up some stuff.
The reason to do this is basically a user interaction design decision.
It is achieved by adding an entry, associated to the creating plugin, to
%pagestate. To find out if files were deleted a new global hash %del_hash is
%introduced.
add_autofile has to have checks, whether to create the file, anyway, so this
will make things more consistent.
Correcter check for the result of verify_src_file().
Cosmetic rename of a variable $addfile to $autofile.
if "tag_autocreate=1" is set in the configuration. The pages will be created in
tagbase, if and only if they do not exist in the srcdir yet. Tag pages will be create from
"autotag.tmpl".
At this stage a second refresh is needed for the tag pages to be rendered.
Add autotag.tmpl template.
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.
This is not needed now that tagpage returns a page name starting with a
slash.
(Also fixes a minor bug that the edit links started with double slashes due
to the hack.)
The html links already went there, but internally the links were not
recorded as absolute, which could cause confusing backlinks etc.
For example, with tagbase=tags, if blog/tags/bar existed and blog/foo was
tagged bar, it would link to /tags/bar. But, the link would be recorded
simply as a link to tags/bar, and so later blog/tags/bar would appear to
have the backlink.
for extended pagespecs. The old calling convention will still work for
back-compat for now.
* The calling convention for functions in the IkiWiki::PageSpec namespace
has changed so they are passed named parameters.
* Plugin interface version increased to 2.00 since I don't anticipate any
more interface changes before 2.0.
Joey Hess
Simon McVittie
Giuseppe Bilotta
David Riebenbauer
Joey Hess
Joey Hess
Simon McVittie
joey