The thinking here is that having both a Discussion page and comments for
the same page is redundant, and certianly not what you want if you enable
comments for a page. At first I considered making configurable via pagespec
what pages got discussion links. But that would mean testing a new pagespec
for every page, and a redundant config setting to keep in sync. So intead,
take a lead from my previous change to make inlined pages have a comments
link, and change the discussion link at the top of regular pages to link to
their comments.
(Implementation is a bit optimised to avoid redundant pagespec checking.)
Jumping to the just posted comment was the imputus, but I killed a number
of birds here.
Added a INLINEPAGE template variable, which can be used to add anchors to
any inline template.
To keep that sufficiently general, it is the full page name, so the
comment anchors and links changed form.
Got rid of the FIXMEd hardcoded html anchor div.
More importantly, the anchor is now to the very top of the comment, not the
text below. So you can see the title, and how it attributes you.
Avoid changing the permalink of pages that are not really comments, but
happen to contain the _comment directive. I think that behavior was a bug,
though not a likely one to occur since _comment should only really be used
on comment pages.
This delays all comment formatting until the last possible time, allows
us to set metadata without worrying that commenters may be able to evade
it, and means that changes to how a comment is saved can be handled
gracefully. It also gives us somewhere to put the commenter's username
or IP address for later reference.
Google allows has a nice feature, sitesearch, that allows anyone to
limit search results to a specific site. Obviously, this feature can be
used to provide a search engine for the local ikiwiki site without the
need to install any additional software. Just enable the 'google' plugin
and make sure that --url uses the proper hostname. Thanks to Joey for
helping to get the Perl implementation right.
* Wrap everything before the content in <div class="inlineheader">
* Wrap the inlined content itself in <div class="inlinecontent">
* Wrap everything after the content in <div class="inlinefooter">
* Wrap header stuff, including actions, in <div class="pageheader">
(there is already a class="header", which is a subset of this, so
using id="header" would be confusing)
* Add class="pagefooter" to the existing <div id="footer">, for symmetry
firefox 3 smooshed the page location dropdown up to the page title,
obscuring descenders and underscores. Maybe that's a bug, since the CSS
didn't ask it to, but I think adding the extra space of a br at the top
looks better anyway.
FormBuilder makes it annoyingly hard to move a submit button to a
nonstandard place. The button name has to be "_submit" or FormBuilder will
ignore it.
The fix involved embedding the session id in the forms, and not allowing the
forms to be submitted if the embedded id does not match the session id.
In the case of the preferences form, if the session id is not embedded,
then the CGI parameters are cleared. This avoids a secondary attack where the
link to the preferences form prefills password or other fields, and
the user hits "submit" without noticing these prefilled values.
In the case of the editpage form, the anonok plugin can allow anyone to edit,
and so I chose not to guard against CSRF attacks against users who are not
logged in. Otherwise, it also embeds the session id and checks it.
For page editing, I assume that the user will notice if content or commit
message is changed because of CGI parameters, and won't blndly hit save page.
So I didn't block those CGI paramters. (It's even possible to use those CGI
parameters, for good, not for evil, I guess..)
The only other CSRF attack I can think of in ikiwiki involves the poll plugin.
It's certianly possible to set up a link that causes the user to unknowingly
vote in a poll. However, the poll plugin is not intended to be used for things
that people would want to attack, since anyone can after all edit the poll page
and fill in any values they like. So this "attack" is ignorable.
* rcs_diff is a new function that rcs modules should implement.
* Implemented rcs_diff for git, svn, and tla (tla version untested).
Mercurial and monotone still todo.
containing ikiwiki.cgi, but this should not change the urls to the style
sheets etc. Add a new forcebareurl parameter to misctemplate to allow
it to do that.
license, and copyright. This can be used to create custom RecentChanges.
* meta: To support the pagespec functions, metadata about pages has to be
retained as pagestate.
* Fix encoding bug when pagestate values contained spaces.
The customary 2.5 hours of staring at random css turtorials later, here
is a pure css latout for the static recentchanges page that, while not as good
as the old table layout, it decent. And it works well in lynx. And
should generate some pretty nice rss too.
- add a title to the editpage form;
- pass a reference to the list of buttons to the formbuilder_setup
hooks, so we can add ours;
- relax asumption about the possible submit values (use "Save Page"
explicitly);
- de-hardcode the submit buttons from the editpage template
(This was needed for compatability with a bug in CGI::FormBuilder
3.0401, but ikiwiki already needs a newer version.)
* Pass buttons to all other formbuilder_setup hooks too.
atom feeds, and also changing the publication time for a feed to the
newest modiciation time (was newest creation time).
* The patch also adds dcterms:creator to rss items that have a known author.
ESCAPE=HTML for titles in the templates for these feeds, and instead
escape the title going in to the template. Previously, the title was
sometimes double-escaped in a feed (if set via meta title), and sometimes
not (if set from the page filename).
* In the meta plugin, when a title is set, encode the html entities in it
numerically. This works better in the current landscape of a rss spec that
doesn't specify encoding, and variously broken feed consumers, according
to <http://www.rssboard.org/rss-profile#data-types-characterdata>.
and style sheet updates, and unless you're using customised versions,
you'll want to rebuild wikis on upgrade to this version to avoid
inconsistencies.
* Allow WIKINAME to to used in footers, as an example of something to put
there.
including out of disk space situations. ikiwiki should never leave
truncated files, and if the error occurs during a web-based file edit,
the user will be given an opportunity to retry.
Inspired by the many ways Moin Moin destroys itself when out of disk. :-)
* Fix syslogging of errors.
FORM-SUBMIT unusable on customised formbuilder templates. For now,
hardcode the submit buttons in editpage.tmpl instead of using the
template variable, which is ok, since the buttons are static.
* Add feeds=no option to inline preprocessor directive to turn off all types
of feeds. feeds=rss will still work, and feeds=atom was also added, for
fine control.
* $IkiWiki::version now holds the program version, and is accessible to
plugins.
- Plugins should not need to load IkiWiki::Render to get commonly
used functions, so moved some functions from there to IkiWiki.
- Picked out the set of functions and variables that most plugins
use, documented them, and made IkiWiki export them by default,
like a proper perl module should.
- Use the other functions at your own risk.
- This is not quite complete, I still have to decide whether to
export some other things.
* Changed all plugins included in ikiwiki to not use "IkiWiki::" when
referring to stuff now exported by the IkiWiki module.
* Anyone with a third-party ikiwiki plugin is strongly enrouraged
to make like changes to it and avoid use of non-exported symboles from
"IkiWiki::".
* Link debian/changelog and debian/news to NEWS and CHANGELOG.
* Support hyperestradier version 1.4.2, which adds a new required phraseform
setting.