comments: Add support for removing comments via web interface. (smcv)

Merge commit 'smcv/comments'

Request review for my comments branch

Partially addresses [[todo/comments]]

comments: if the remove plugin is enabled, append a "Remove comment" link

comments: only try to insert commentuser etc. into templates if the page contained [[!_comment]]

remove questions

ikiwiki has some pretty distinct fingerprints even when it's used
in unusual ways on sites that don't make it obvious it's being used:

* tova: a) rss and atom feed buttons
   b) use of toc plugin on some pages
   c) usual page.tmpl droppings
   d) (I know the tova guys :)
* awesome: a) usual page.tmpl droppings
  b) ikiwiki/ page and rest of basewiki pages exist
* UK software patents: used to use ikiwiki based on similar
  fingerprints, but not now. Removed

remove clutter

foobak bak foo

new feature

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

repolist: New plugin to support the rel=vcs-* microformat.

* repolist: New plugin to support the rel=vcs-* microformat.
* goodstuff: Include repolist by default. (But it does nothing until
  configured with the repository locations.)

increment interface version

remove clutter

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

comments: Fix cache avoidance hack.

The ?updated needs to come before the #anchor or browsers will not follow
the anchor.

update

rename: Show full names of affected pages.

refactor

formatting

table: Find links in external files in scan pass.

typo

table: Fix misparsed links in external files

linkify data from external files at the same time as data from an inlined
table would be linkified.

analysis, found another bug

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

new gitweb url form fixes some bugs too

formatting

formatting

add news item for ikiwiki 3.01

releasing version 3.01

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

A recent change to gitweb removed support for the form of diffurl  that many ikiwiki setups use. Document how to use the new url form.

* Switched to Text::Markdown. Thanks a lot!

analysis

markdown bug

* Problem with URLs with parentheses

openid bug?

yesno: Always accept English even when localised.

It seems to be a failing of i18n in unix that the translation stops at the
commands and the parameters to them, and ikiwiki is no exception with its
currently untranslated directives. So the little bit that's translated sticks
out like a sore thumb. It also breaks building of wikis if a different locale
happens to be set.

I suppose the best thing to do is either give up on the localisation of this
part completly, or make it recognise English in addition to the locale. I've
tenatively chosen the latter.

(Also accept 1 and 0 as input.)

Fix documentation about git hook to use right name. Closes: #510393

it falls back to using install

Revert "Add actual result for the example"

This reverts commit be67d10a813ae37512daacbbab9815eecd5e94ef.

We don't demo directives on directive doc pages, to avoid doing unnecessary
work at build time (not a big deal here) and to avoid broken directives if
the plugin is not enabled.

This fact could probably be documented better, but I don't want to mention
it on every page..

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

ikiwiki-makerepo: Fix injecting of empty mercurial and bzr repositories. Closes: #510518

update

po: added note about now implemented feature

Signed-off-by: intrigeri <intrigeri@boum.org>

meta branch merge required

Signed-off-by: intrigeri <intrigeri@boum.org>

bug reopened

Add actual result for the example

link to related bug

Fix version.

formatting

fix link

fix link

3.0 annoucement

formatting

formatting

add news item for ikiwiki 3.00

releasing version 3.00

fix moveprefs transition

move to correct location

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

Merge branch 'next'

need_global_renamepage_hook: proposed solution implemented in my po branch

Signed-off-by: intrigeri <intrigeri@boum.org>

* Now unofficial Ikiwiki backports for Ubuntu Intrepid

websetup: Avoid a crash when a new array setup item has been added in  a new 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.

make sure value is defined before using it as an array

French translation update from Philippe Batailler. Closes: #510216

planning a future plugin

update

Merge branch 'master' into next

htmlbalance: Demand-load HTML::TreeBuilder to avoid failing test suite if it is not present.

Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

some initial instructions for publishing wikis on github

1st comment spam

formatting

comments: Add cache avoidance.

This got lost when we added the jump-to-comment anchor.

clarify cgiurl setting

Replace blank OpenID placeholder logo with an unofficial OpenID logo developed by Anna Hess. The official logo does not seem destined to be free.

Merge branch 'master' into next

Conflicts:

debian/changelog
po/ikiwiki.pot

add news item for ikiwiki 2.72

releasing version 2.72

typo

Merge branch 'master' into next

inline: Run format hook first

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.)