Tracking reviki development

[2008-08-03] Changes to URL space / cookie bug

Various existing reviki deployments are using apache2 in front of tomcat running reviki to (amongst other reasons) improve the URL space presented.

Unfortunately using modrewrite/proxy to link inside a tomcat context isn't working well, because tomcat issues session cookies for the wrong paths. This results in jsessionid URLs even in browsers with cookies enabled. This is unfortunate for URLs that are often copied for emailing etc.

In revision:958 I've introduced a dependency on the promising Url Rewrite Filter.

This lets me eliminate the '/pages' URL prefix - an ugliness introduced because the servlet url-mappings are horrible and make it impossible (without using a filter) to send everything to a dispatcher/front-controller but use the default resource serving behaviour for certain paths. URLs now look like

http://www.example.com/reviki/wikiName/PageName

rather than

http://www.example.com/reviki/pages/wikiName/PageName

I've introduced a permanent redirect for now from /pages/(.*) => /$1. The special pages /list and the more-or-less-internal /jump now overlap with the wiki namespace pending a good idea - perhaps /special/... as the only reserved name.

[2008-07-06] Macro rendering fixed in revision:954

The <<incomingLinks:PageHere>> and <<outgoingLinks:PageHere>> macros output wiki markup which is subsequently rendered. Until revision:954 these were not rendering properly because the renderer was matching them as inline macros meaning the list tags they use in their output weren't available.

It now works great (links to this page):

This feature can be pretty useful... incomingLinks can be used for displaying particular category tags on a status page for a project using pages such as StoriesAwaitingSignOff, OpenQuestions.

[2008-06-29] New "limit" parameter for RecentChanges in revision:946.

Now documented on AboutRecentChanges.

[2008-06-29] Unlock support in revision:943, bugfix for error pages in revision:944

Locks can now be broken. In keeping with the aims of the 1.0 release (see TodoList) the locks can be broken by anyone at any time.

Also fixed a bug where error pages would fail to display.

[2008-06-17] Different approach to printing in revision:930

ctype=printable is gone, now the default ConfigCss includes a @media print section that hides the menus. This allows for more flexibility. To see the effect go to print-preview. It does mean if you've changed the standard stylesheet you'll need to

  1. Blank it to replace it with the default (yes this should be more obvious!)
  2. Make your changes again

The new stylesheet also includes prettier tables.

[2008-06-15] Printable view in revision:928

ctype=printable on the URL now gives a menu free page, with a link in the menu.

Brings up the need for a drop-down menu or similar to add these more rarely used options to - I've called it 'Print' which is misleading just to save the four characters!

[2008-06-15] ViewCvs up and running

Can now link to e.g. revision:917.

I've stuck with the debian viewcvs package for now so it isn't as pretty as some. The URLs could do with some modrewrite love too but all the linking will be via the wiki links so nevermind.

[2008-06-15] Misc bug fixes in revisions to revision:917

I've been working through a few issues encountered deploying reviki at work.

  • Timezone is now configurable, see TomcatContextXmlConfiguration.
  • wiki-content CSS class so ConfigCSS changes need not affect reviki's own layout (changing tables to have borders affected RecentChanges and similar which looked ugly - ok, well, uglier!).
  • Show date/time since page was locked as well as lock owner.

More minor improvements to come including proper ability to break locks and better feedback when creating wikis.

I'm hoping to get round to installing viewvc on the reviki SVN server. That way I can point at revisions with an inter-wiki-type link. I've been doing revision:1234 at work and that seems pretty neat - just as easy to type and a step saved for anyone wanting to review.

[2008-05-11] Configuration improvements (revision:862)

You can now configure the data directory via the reviki-data-dir context parameter. See SetupGuide/TomcatContextXmlConfiguration.

There's also improvements to configuring wiki base URLs - a base-url property. If many of the wikis run in a reviki instance are mapped to the same area of URL-space, differing only in the final path segment (the wiki name) then this saves adding a base-url for each one. Documented on ConfigFile.

[2008-05-08] Extracted XPathContext to own project revision:846

Documented on XPathContext. No doubt this will come in handy elsewhere - for me if no-one else.

[2008-05-05] Atom feed improvements and URL change revision:828

For consistency with the alternate format for search the atom feed is now at RecentChanges?ctype=atom.

I hope to introduce the ability to view more of the wiki as atom feeds and entries over time.

I've also added '?revision=NNNN' to the atom:id of the entries. It seems that bloglines (and probably others) gets really confused by multiple entries with the same id (though the specification permits this).

I've also started to write code to make it bearable to write tests against XML output in XPath. Seems like something that could be generally useful, might be worth tidying up and pulling out of reviki.

[2008-05-05] ConfigCss regression fixed revision:823

In revision:785 ConfigCss was ignored - the default styling always used. I found a better home for the code that set the default CSS URL (now in the view) but failed to notice I'd moved it after the code setting the wiki specific CSS URL.

The default now takes care not to overwrite anything previously set and I've added some tests.

Perhaps I should brighten up reviki.org to make doubly sure but CSS just isn't my thing.

Update: I've made the page titles (slightly) more colourful.

[2008-05-05] HtmlUnit functional tests now run in ant (revision:814)

It will download tomcat, built and deploy a war, start tomcat, wait for it to come up, run the tests against it and clean up. Magic. I was particularly impressed with

 <waitfor maxwait="30" maxwaitunit="second" checkevery="500">
   <http url="http://localhost:8080/reviki/"/>
 </waitfor>

...I was expecting to have to do something horrible like take a guess and sleep.

Unfortunately some manual setup of the test wiki is still required (documented in the ant file). If we supported file repositories perhaps ant could do this too. Another possible enhancement is XSLT or similar to munge the tomcat port to something less likely to clash.

[2008-04-28] Configurable base URL revision:789

As noted on ConfigFile you can now set a property that determines the base URL for the wiki. Now when the reviki tomcat instance is behind something like Apache there is much more freedom as to what the URL space looks like. You can easily have http://www.example.com/wiki/FrontPage and http://microsite.example.com/team/FrontPage both being served from the same tomcat.

If you don't set the base URL it will continue to be based on the request and the '/pages/wikiName/PageName' structure.

Update (revision:807): Missed the resource URL for the search suggest feature's CSS. That's fixed in revision:807.

[2008-04-20] Atom feed fixes revision:755

The atom feed is now valid. Issues were:

  • Missing author element
  • Missing id element (now set to URI of feed)
  • Date format issues

The validator now gives warnings about update times (due to a move, so expected) and multiple entries with the same id (which are valid as they are changes to the same page).

[2008-04-20] XHTML validator now works properly and is in SVN

The (trivial) XHTML validator - XHTMLValidate - is now somewhat packaged up and is in SVN. I switched from using a catalog resolver to using a custom entity resolver as it still seemed to be going to the web when access was available, explaining why the tests were sometimes very slow.

[2008-04-17] NightlyBuilds now available

Erm that's it really.

http://downloads.reviki.org/nightly/

[2008-04-15] ConfigAutoProperties

I'm working on addressing one of the attachment related stories for the 1.0 release.

The plan is to add ConfigAutoProperties which will be a text page containing the contents of the [auto-props] section of the svn config file. These will be used for new attachments.

This ought to make browsing the SVN repository directly more pleasing. The common practical problem is that the PDF files are incorrectly added as to SVN as text (as they often are for the first few bytes until you hit a compressed stream).

I'll also address using these mime types at attachment download time too (I think we currently always set application/octet-stream).

Update revision:720: We now have ConfigAutoProperties with some default content to be documented on AboutConfigAutoProperties. Decided there's no point setting mime-type on download because the current behaviour results in the browser / OS mime-type mappings being used which is probably more comprehensive. Will gladly revisit if anyone has a use case.

[2008-03-31] XHTML validation

So it turns out this page is horribly, horribly invalid finally valid as of revision:682.

Time to find a validator I can hook into the HtmlUnit functional tests and the unit tests for the renderer.

Update (revision:660):

  • We have XHTML DTD validation hooked into the functional tests. Surprisingly slow though, even with catalog remappings for the W3C DTDs.
  • This page is valid except for an issue with ul elements generated by the renderer.

Update revision:675:

  • Search result highlighting is now valid XHTML.
  • Diffs now valid XHTML.

Remaining:

  1. Attachments page invalid when no previous revisions (empty <ul>).
  2. Duplicate form input ids on attachments page.
  3. Still need to hook the validation up to the markup renderer.
  4. Fix renderer output (block elements inside p mostly).
  5. Fix new rendering glitch above (the **).
  6. Figure out why the validation is so slow.
  7. Add at least the WikiCreole page text as a more substantial functional test. The existing tests mostly test one element or the interaction between two elements.

[2008-03-30] A favicon revision:650

Sites without a favicon look dull, something the current reviki design needs no help with! I'm no graphics wizard but on the basis that something's better than nothing:

favicon.ico

That'll do for a while. Cheers to the folks at dynamicdrive for making this easy (heh, perhaps too easy...)

Favicon maker- Create a favicon from any image

[2008-03-30] Title revision now last changed revision revision:637

The title revision is the last changed revision, rather than the accessed revision. As it was it just wasn't useful information, now you can get some idea of how old a page is. One problem common to all forms of documentation is parts inevitably get stale. It's good to have a visual indication of how recently the page has been updated. Perhaps for that reason the last changed date / user should be more visible...

[2008-03-30] Atomic commit for adding attachment and link revision:629

For a while now we've had uploading an attachment split across two commits, one creating the PageName-attachments directory (if requried) and the other committing the attachment file. As of revision:619 it got worse - we now automatically add a link to the attachment to the associated page.

Time to tidy SVNPageStore/BasicSVNOperations to make it easy to create the directory and the file in the same commit. This will be needed for RefactorRename too.

Update revision:629: The mutator methods on BasicSVNRepository now do less to give the SVNPageStore more control over combining modifications. All the operations needed to upload an attachment are now a single commit. Having to assemble all the actions up-front - because SVNRepository isn't re-entrant - leads to a clumsy separation of figuring out if something needs to be done and doing it - suspect we could pull out a prepare / perform interface. Revisit for RefactorRename.