| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
| |
pretty-printed dates, using the same formatting as used for page modification date display, etc.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
include feeds.
Speedup of about 25% for small inlines; could be much larger for inlines of
many, or complex pages.
Not bloating memory with excessive memoization data was the key to this.
The method chosen does not squeeze out every erg of speed possible when
inlines are nested, but that's rare. It uses less memory than other
optimisation hacks (I'm looking at you,
f937c1fb8074a512d8bb788fa275f5e90595cd47 !) already used in inline.pm.
|
| |
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
My experience is that when inlines are nested, the old behavior of
generating feeds for the nested inlines was never really desired. Since the
feeds were numbered sequentially, the numbers could easily change, and it did
not make sense to subscribe to or use those feeds. And generating those nested
feeds often meant a lot of unnecessary calculation, and data being written.
So, I dropped them.
Looking back, nested feeds originally were a free side effect of properly
handing multiple feeds on one page. Of course, that is still supported.
|
| |
|
|
| |
when ikiwiki needs authentication, rather than for any access to the cgi/wiki.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is closer to a page.
I chose not to have it override style.css, because style.css is not really
intended to be edited; the one from the underlay is intended to be used as
a base that local.css overrides.
I chose to use a plugin rather than changing the default behavior, both
because I didn't want to have to worry about possibly breaking backwards
compatability (though this seems unlikely), and because it seemed cleaner
to not include style template parameters in the main page template code.
I suppose someone might want a way to not override the toplevel
local.css, but instead include it as well as foo/local.css. Probably the
best way to do that would be to have foo/local.css @import ../local.css
(modulo browser compatability issues). Alternatively, edit page.tmpl
to always include the toplevel local.css, or swap out this plugin for
another one.
|
| |
|
|
| |
template is filled out. This improves the search plugin's indexing, since it will not include navigational elements from the page template or sidebar.
|
| |
|
|
| |
not configured.
|
| | |
|
| | |
|
| |
|
|
| |
search works correctly for wikis that are located in subdirectories of domains.
|
| |
|
|
| |
Modify makefile to update spec file version number.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Don't generate inlined page content if the template does not use it.
|
| |
|
|
| |
day.
|
| |
|
|
|
| |
The names in the documentation were completly different, but
also seemed better chosen than the names in the code.
|
| |\
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
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.
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
debian/changelog
doc/plugins/calendar.mdwn
|
| | |
| |
| |
| | |
calendar plugin.
|
| |\|
| |
| |
| |
| | |
Conflicts:
doc/bugs/transitive_dependencies.mdwn
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
To avoid breaking plugins, also support the old pagespec_match_list
calling convention, with a deprecation warning.
|
| |\|
| |
| |
| |
| |
| |
| | |
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%.
|
| | | |
|
| | |
| |
| |
| | |
Also update docs, test suite.
|