Planned web site down time

In order to apply some upgrades, the web site will be offline for an hour two over the next couple of days (Tuesday 15th, Wednesday 16th March 2011).

Please see this news article for details. A similar message has also been sent to the comp.sys.acorn.announce newsgroup.

The lion’s share of this has been completed ahead of schedule on Tuesday evening. I may have to do the odd extra restart and we’ll have to wait and see if the automatic nightly maintenance restart works – on paper it should.

I’ve added a comment to the news article with more information.

Looks good!

However, a minor issue I’ve found with the new wiki – it doesn’t look like it’s possible to set up an anchor name in a header (i.e. “h4(#wibble). Hello”) if the anchor name contains spaces. It used to be possible to do this by using +’s to seperate the words in the anchor, but now it looks like all pages which used to have +’s in the anchor name have had them changed to %20’s, and neither %20’s, +’s, nor actual space characters will cause the wiki to accept the h4() marker. See the BMU feature matrix page for some examples.

Is there any magic you can work at your end to fix all the broken pages or does it look like it’s going to be a manual process? I suspect you could just replace the spaces with underscores, but finding an automated way to fix all the links which point to the anchors might be a bit trickier.

I wrote:

we’ll have to wait and see if the automatic nightly maintenance restart works – on paper it should.

Almost! The Hub server didn’t restart, but the new Apache services did. I forgot to update a setting for PATH in ~/.profile. Fixed and re-tested with a ‘clean’ shell.

This is looking to be a great all-round improvement. Nice work! :-)

Jeffrey wrote;

it doesn’t look like it’s possible to set up an anchor name in a header (i.e. “h4(#wibble). Hello”) if the anchor name contains spaces

People were getting away with murder on the old Wiki because it had some very permissive Textile behaviour and because it didn’t do any of the cross referencing that the new Wiki supports. The migration script grew and grew with more and more patches to rationalise the content. The long and twisty reason for your difficulties is:

1. Numerous Wiki pages used Textile to link to other Wiki pages, rather than Wiki syntax. This is in part because people understood the Textile "alias-text":link-uri format but not the Wiki [[link-uri|alias-text]] format.
2. Those links made the invalid assumption of a URL format generated by the old Wiki, which included “+” instead of “space”. The new Wiki does not recognise or map such links. An earlier version of the migration script patched “+” to “%20” to try and work around this but was only partially successful.
3. Later I realised that the situation was far worse; early migrations showed almost all pages being listed as orphans due to Textile links. I had to build recognition of in-Wiki Textile links right into the Wiki itself. Both “direct” and referenced (where "alias-text":link-ref and [link-ref]link-uri are used together) are recognised along with special case code to cope with absolute specifiers of URIs from the document root, though it can still be defeated with directory traversal URIs – though if you do this, you risk pages being marked as orphans. The Wiki thus attempts to auto-correct all such links even in new edits and pages (though I noticed recently that it doesn’t handle “mailto:” links properly, treating them as Textile links because of no “/” present in the link-uri part of the string).
4. With Textile under RedCloth 4, named anchors cannot have upper case characters in them for some reason. The recognised set of characters seems to be very small. Since “+” doesn’t map to " " anymore either, I had earlier code already converting “+” to “%20” and kept it. In practice this was unhelpful as “%20” doesn’t seem to be recognised in named anchors by Textile either. An underscore would have been a better bet but I overlooked it.

The bottom line seems to be that you need to replace such examples by hand and an underscore is a good choice. Textile won’t recognise “+” or " " in an anchor name. That’s why the first two examples below are rendered as plain text, while the third works.

h4(#with space). This has a space

h4(#with+plus). This has a plus

This has an underscore, as in with_underscore

You will also note that Textile absolutely insists on a blank line between block markup elements now. It used to require this between its own markup elements, but didn’t need it for HTML-like markup, so <br> could appear right before h2. and the h2. would work fine. A blank line is now needed. Again, the migration script tries to patch common patterns but can’t patch every possible case as my regular expression designing abilities just aren’t that good!

There are some pages that are badly damaged by the move to the new Wiki. Those using JavaScript section numbering are prime examples. Others have broken Textile table syntax that we either got away with before somehow, or nobody noticed. Some of our content management system’s pages assumed things that don’t work under new Textile too, so we have to sort those out by hand. Eventually it should all settle down and hopefully be worth the pain to have more consistent and reliable Textile handling coupled with a more stable and feature rich Wiki.

Further to the above, I hope to start the long process of updating Subversion for all the site changes soon. Once that’s done you’ll be able to inspect the migration and Textile link patch code and suggestions for alterations are welcome. It’s a bit late for migration now, unless we want to wind back to the I2 database contents from last night and re-run the migration from that; however the Textile link patching within the Wiki runs all the time and might need some tweaks.

I wonder if any light could be shed on the following. I’ve just attempted to edit software compatability list (to correct the absent |<^. before MicroSpell). When I clicked ‘Submit’ I was greeted with a lovely red box at the top of the screen declaring “Your edit was blocked by spam filtering”!

I get the same. Instiki does have a rather aggressive looking list of keywords and since we’re a site guarded by Hub log-in, I’m not sure it’s necessary at all. I’ll look into it.

Everyone – keep the bug reports coming! Here or the bug tracker is fine. Please assign to milestone “2nd public site release” if you remember.

I note you have similar problems to Jeffrey on that software list too, with “.” in link names leading to “h3(#…)” getting dumped raw into the view. Just change them to underscores – once the spam thing is fixed! – to sort that out. It may be easier to copy the text into a normal text editor and use search & replace there (I never could understand why web browsers don’t embed a ‘real’ text editor component; WebKit on Mac OS X really ought to embed TextEdit in plain text mode).

Sorted. Pattern “soma” (found in ‘somascape.org’) was too generic. I’ve removed some of the more obviously “risky” spam patterns so it hopefully won’t catch anyone out again.

I can’t remember whether the old wiki used to use the page title as an h1 heading at the top of pages. It doesn’t now (and perhaps never did – in which case never mind, I guess).

It never did. The new one did but that led to duplicate titles for pages which included their own, so I got rid of the layout title and left it up to page authors to decide.

The bottom line seems to be that you need to replace such examples by hand and an underscore is a good choice.

OK, no problem.

For legacy reasons, I’ve added a redirection controller into the Wiki so that references to “/wiki/pages/foo+bar+baz” get turned into “/wiki/show/foo%20bar%20baz” automatically. We seem to have quite a few external links into the Wiki from the static content management system, forum posts and so-on so this seemed a sensible measure.

New links generated from outside the Wiki should probably use the new URLs – likely to happen just by default as people copy and paste them from browser address bars. New links to other pages within the Wiki should always use Wiki syntax, as previously mentioned.

The wiki guide page states:

“If you try and edit the same page as someone else, you’ll be warned that they’re doing so. You should wait and try again later. Never edit a page being edited by someone else.”

I just had an ‘Application error’ problem when editing (submitting) a page. Now when I go to edit it again, I’m warned “AnonymousCoward? has been editing this page for 2 minutes.” How long do I have to wait for it to time out? Or in cases such as this, is it acceptable to continue? Thanks.

1. If you’re editing it yourself, that’s fine.
2. I’ve noticed the bug where it says “AnonymousCoward” instead of the real editor’s name; I’ll look into that later (not that urgent).
3. No obvious errors are logged; it may be that your system had some stuff cached in the browser which referred to old URLs, e.g. old RSS feeds, since the only thing I can see is a few attempts to pull the old RSS feeds (I don’t redirect these as the new feeds are in a completely different format and may trip up some RSS readers). Attempts to use old, unsupported URLs within the Wiki tend to result in 500 errors, annoyingly, because of the way Rails works.

Thanks.

it may be that your system had some stuff cached in the browser which referred to old URLs

Quite possibly. It’s not a browser I’d choose to use: IE 6!

Ah, that’s not supported and testing shows that MSIE 8 and 9 have utterly awful performance. If you can’t access Firefox, Chrome, Opera, Safari or NetSurf from your current location, you’d be better of waiting until you can.

If you can’t access Firefox, Chrome, Opera, Safari or NetSurf from your current location, you’d be better of waiting until you can.

I agree!

…can’t remember whether the old wiki used to use the page title as an h1 heading at the top of pages. It doesn’t now (and perhaps never did – in which case never mind, I guess).

It never did. The new one did but that led to duplicate titles for pages which included their own, so I got rid of the layout title and left it up to page authors to decide.

I may change my mind on that. There seem to be more pages without titles than with and it’s quite disorientating when they’re missing.

…then again, quite a few pages seem to have obscure page titles and headings which are more legible. So forget it, I’ll leave things as-is.

There seem to be more pages without titles than with and it’s quite disorientating when they’re missing.

[…] obscure page titles and headings which are more legible. So forget it, I’ll leave things as-is.

So in that case, am I right in thinking all the apps etc. linked to from Software Information require headings adding (e.g. h2)?

I’d leave them alone personally, not worth the effort. Besides, that’s what the title bar is for.

Out of interest, how exactly did you change it to make it render more quickly in NetSurf? Was there anything particular you avoided?

The main slowness I’ve seen on ROOL pages, is once logged in it fetches over HTTPS, and that’s really slow for e.g. loads of bitmaps on RISC OS hardware.

Anyway, the update looks great. Well done. :)