| Age | Commit message (Collapse) | Author |
|---|
|
If git log outputs malformed utf8 in, eg, usernames, detect it and fix it
up. This avoids commits such as f71abc92aa279fbe0b7578b8c4752d775dd4a259
breaking things.
|
|
It was calling format hooks for each comment on the page.
When relativedate is enabled, that made it insert <script> tags
for each comment. And the browser loaded the same script over and over,
which was slow on its own. But that was nothing compared to running
the onload even over and over.. especially since the hook system
added a new call to the hook each time it loaded.
For a page with 10 comments, that caused the relativedate DOM parsing
code to run 1000 times, I think. Anyway, it was sloow. Now it runs once.
|
|
|
|
|
|
|
|
Remove actions from it, and avoid a broken title link.
|
|
|
|
.ikiwiki/comments_pending) for moderator review.
|
|
|
|
|
|
I suspect these are only triggered by spammers.
|
|
|
|
if suitable alternate text is unknown, then it should not be given.
empty alt text is suitable mainly for purely decorative images.
(cherry picked from commit 3cd7f67f0cf894f4fd5ba16f68e82e4f7bdbfdc5)
|
|
The form was misdisplayed when displayed via comment removal.
|
|
|
|
That resulted in double encoded display when using perl's stub
readline module. Apparently that module unconditionally upgrades
text to utf8, in a quite braindead way.
(Term::ReadLine::Gnu::Perl worked ok.)
|
|
|
|
This way, enabling the plugin via websetup is safe, it can't leave
ikiwiki in a broken state.
|
|
Use mtn for monontone and hg for mercurial. The long names cause ugly
formatting in recentchanges, which has CSS that only allows a few
characters for the commit type column.
|
|
posting using the BlogSpam.net API.
|
|
|
|
|
|
including spam filters.
|
|
IIRC I analised this and the code is right
|
|
It will set up an ikiwiki instance tuned for use in blogging.
As part of this change, move the example sites into /usr/share/ikiwiki so
they are available even if docs are not installed.
|
|
Asking for only the head worked in my tests, but I've found a site where it
didn't -- apparently ikiwiki didn't get a chance to do or finish the
refresh when HEADed. Getting the whole url, waiting for ikiwiki to finish,
avoided the update problem.
|
|
name parameter. Previously, match_created_before(), match_created_after(), match_sourcepage(), and match_destpage() did not support that, and the docs were not clear.
|
|
|
|
contained [[!_comment]]
|
|
* repolist: New plugin to support the rel=vcs-* microformat.
* goodstuff: Include repolist by default. (But it does nothing until
configured with the repository locations.)
|
|
|
|
The ?updated needs to come before the #anchor or browsers will not follow
the anchor.
|
|
|
|
|
|
|
|
|
|
linkify data from external files at the same time as data from an inlined
table would be linkified.
|
|
ikiwiki setups use. Document how to use the new url form.
|
|
ikiwiki release, and is thus not present in the setup file yet.
This happened with camelcase_ignore. The code tried to convert the undef
value for it into an array.
|
|
|
|
is not present.
|
|
This got lost when we added the jump-to-comment anchor.
|
|
|
|
|
|
inline has a format hook that is an optimisation hack. Until this hook
runs, the inlined content is not present on the page. This can prevent
other format hooks, that process that content, from acting on inlined
content. In bug ##509710, we discovered this happened commonly for the
embed plugin, but it could in theory happen for many other plugins (color,
cutpaste, etc) that use format to fill in special html after sanitization.
The ordering was essentially random (hash key order). That's kinda a good
thing, because hooks should be independent of other hooks and able to run
in any order. But for things like inline, that just doesn't work.
To fix the immediate problem, let's make hooks able to be registered as
running "first". There was already the ability to make them run "last".
Now, this simple first/middle/last ordering is obviously not going to work
if a lot of things need to run first, or last, since then we'll be back to
being unable to specify ordering inside those sets. But before worrying about
that too much, and considering dependency ordering, etc, observe how few
plugins use last ordering: Exactly one needs it. And, so far, exactly one
needs first ordering. So for now, KISS.
Another implementation note: I could have sorted the plugins with
first/last/middle as the primary key, and plugin name secondary, to get a
guaranteed stable order. Instead, I chose to preserve hash order. Two
opposing things pulled me toward that decision:
1. Since has order is randomish, it will ensure that no accidental
ordering assumptions are made.
2. Assume for a minute that ordering matters a lot more than expected.
Drastically changing the order a particular configuration uses could
result in a lot of subtle bugs cropping up. (I hope this assumption is
false, partly due to #1, but can't rule it out.)
|
|
|
|
People seem to be able to expect to enter www.foo.com and get away with it.
The resulting my.wiki/www.foo.com link was not ideal.
To fix it, use URI::Heuristic to expand such things into a real url. It
even looks up hostnames in the DNS if necessary.
|
|
Conflicts:
IkiWiki/Plugin/googlecalendar.pm
|
|
|
|
|
