| Age | Commit message (Collapse) | Author |
|---|
|
Also, sort the list of page types.
|
|
Conflicts:
debian/changelog
|
|
|
|
|
|
|
|
|
|
We build an array of [ plugin name, long name ] pairs, where long name
is an optional argument to hook(). So, a syntax plugin could define
long "friendly" name, such as "Markdown" instead of mdwn, and we would
then pass this array to formbuilder to populate the drop-down on the
edit page.
|
|
Not needed since it returns a list of pages, not a fail/success object.
|
|
|
|
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.
|
|
When finding the pageurl, it was calling bestlink unnecessarily.
Since at this point $page contains the full name of the page that
is being inlined, there is no need to do bestlink's scan
for it.
This is only a minor optimisation, since bestlink is only called
once per displayed, inlined page.
|
|
|
|
This reverts commit 2f96c49bd1826ecb213ae025ad456a714aa04863.
I forgot about internal pages. We don't want * matching them!
I left the optimisation in pagecount, where it used to live.
Internal pages probably don't matter when they're just being
counted.
|
|
I forgot to check if it was called from preprocess, and it is
not; it's called by a format hook. If an error is thrown from
a format hook, wiki build fails, so we don't want that.
|
|
|
|
Add an optimisation for the semi-common case of a "*" pagespec. Can
avoid doing any real processing in this case.
|
|
|
|
|
|
* pagespec_match_list: New API function, matches pages in a list
and throws an error if the pagespec is bad.
* inline, brokenlinks, calendar, linkmap, map, orphans, pagecount,
pagestate, postsparkline: Display a handy error message if the pagespec
is erronious.
|
|
wish to, if the configuration makes signin optional for commenting.
|
|
* Add IkiWiki::ErrorReason objects, and modify pagespecs to return
them in cases where they fail to match due to a configuration or syntax
error.
* inline: Display a handy error message if the inline cannot display any
pages due to such an error.
This is perhaps somewhat incomplete, as other users of pagespecs do not
display the error, and will eventually need similar modifications to inline.
I should probably factor out a pagespec_match_all function and make it throw
ErrorReasons.
|
|
|
|
|
|
printed at that point if it's not available, allowing the admin to see it during wiki setup. Closes: #520015
|
|
|
|
Conflicts:
debian/changelog
debian/control
|
|
Signed-off-by: intrigeri <intrigeri@boum.org>
|
|
|
|
|
|
The darcs backend appends @web to the names of web committers, so remove it
when extracting.
|
|
|
|
|
|
|
|
Conflicts:
doc/ikiwiki-makerepo.mdwn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
debian/control
|
|
The munged ids were looking pretty nasty, and were not completly guaranteed
to be unique. So a md5sum seems like a better approach. (Would have used
sha1, but md5 is in perl core.)
|
|
Well, that was a PITA.
Luckily, this doesn't break guids to comments in rss feeds,
though it does change the links.
I haven't put in a warning about needing to rebuild to get
this fix. It's probably good enough for new comments to get the
fix, without a lot of mass rebuilding.
|
|
with "comment_" in their name. Closes: #521322
|
|
This was being buggy and returning the file's last change time, not its
creation time.
(I checked all the others (except tla) and they're ok.)
|
|
This was being buggy and returning the file's last change time, not its
creation time.
|
|
It would be better to use urlto() here, but will_render
has not yet been called on the feed files at this point, so
it won't work. (And reorganizing so it can be is tricky.)
|
|
|
