| Age | Commit message (Collapse) | Author |
|---|
|
search works correctly for wikis that are located in subdirectories of domains.
|
|
When redirecting to a page, ie, after editing, ensure that the url is
uri-encoded. Most browsers other than MSIE don't care, but it's the right
thing to do.
The known failure case involved editing a page that had utf-8 in the name
using MSIE.
|
|
blogspam.net.
|
|
|
|
|
|
|
|
using a template that does not include page content.
|
|
|
|
(cherry picked from commit 13e9383b48857daa206387f3486eb00e3b171a68)
|
|
files if a sourcedir of "./" was specified.
|
|
|
|
for a wikilink (including eg, leading slashes).
Before, the htmllink would display the link to the template as if it were a
wikilink, but what was stored was not, which could lead to confusing
situations.
|
|
This sometimes caused infinite recursion when rebuilding a wiki
with po files.
|
|
|
|
Don't generate inlined page content if the template does not use it.
|
|
|
|
|
|
This does mean the year calendars depend on existence of all posts made in
the year and have to be updated.
|
|
|
|
This avoids all calendars rebuilding when a new page is added
that will only show in one of them.
|
|
The names in the documentation were completly different, but
also seemed better chosen than the names in the code.
|
|
git log --follow seems to sometimes show merges from before the file was
ever created. So, skip them, a file shouldn't be first created during a
merge anyway.
|
|
Meh, git.
|
|
Conflicts:
debian/changelog
|
|
This will be a bit more expensive, but --getctime does not need to be fast.
And getting the real creation time a very useful when untangling blog
histories that involve renames.
|
|
|
|
This is consistent with the year display, and I think it is less
visually confusing than using the full month names.
|
|
|
|
I broke this recently.
|
|
to an archive page from the wrong year.
|
|
It was just broken for calendars with an explicit month or year, not
triggering at all.
Now it will update those at appropriate times.
|
|
and fix a bug in pagespec variable name
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To avoid breaking plugins, also support the old pagespec_match_list
calling convention, with a deprecation warning.
|
|
This was tricky because of the caching, and because use_pagespec always
adds a dependency. That would have made year calendars depend on the whole
pagespec, which is overly broad. So I removed the caching, format_month,
and in format_year just look at %pagesources to see if month pages are
available.
In format_month, I make it always call use_pagespec, so each month calendar
gets the right dependency and any influcences added. This means a bit more
work, but the added work is fairly minimal, and presence dependencies
remove a *lot* of work it used to do.
(100% untested!)
|
|
Also, fixed up the dependency type for time=mtime. That has
to remain a content dependency, sadly.
|
|
|
|
This dependency was missing before switching to use_pagespec.
It is correct to add it, but it needs to be combined with the regular
"pages" dependency to ensure that it does not match extra pages.
(Also fixed its dependency type.)
|
|
Conflicts:
IkiWiki.pm
IkiWiki/Render.pm
debian/changelog
|
|
|
|
Benchmarking refresh of a a wiki with 25 thousand pages showed
file_pruned() using most of the time. But, when refreshing, ikiwiki already
knows about nearly all the files. So we can skip calling file_pruned() for
those it knows about. While tricky to do, this sped up a refresh (that
otherwise does no work) by 10-50%.
|
|
|
