Web site work underway

Well I thought it was obvious ;) that I was talking about the forum software adding the ID prefix, not users. Users couldn’t do that for new posts anyway as posts don’t have an ID until saved in the database (that’s where the unique ID comes from, not Ruby).

So either the forum would pass the ID as a prefix to Textile when it invokes the processor during construction of the HTML page, or it does a global search and replace for known anchor types in Textile output after invoking the processor. The first requires Textile support and the second would be slow.

Well I thought it was obvious ;)

Nothing ever is, just as common sense – isn’t
Can I just point out I did say the the software (Textile) “probably doesn’t allow for and auto add of the posting reference” i.e. I made a guess what the answer to that item would actually be.

Almost forgot – the iPad “getting stuck” thing has been added as a ticket:

• https://riscosopen.org/tracker/tickets/355

The top-level list of forums (e.g. as accessed from the navigation bar at the top of every page) should now fetch much more quickly. The slow-down was actually due to a performance feature in Beast! It was doing a so-called eager load of the User object associated with the most recent Post in a given Forum during the listing of those Forums. This should mean a single database call to obtain the post and user, but in practice it ran very slowly; this seems to be due to the context in which it was used and a performance bug of sorts in the version of Rails running that part of the site. Simply getting rid of the eager-load directive speeds everything up nicely.

Excellent. Moving around the site is a lot quicker now.

Edit: having said that, if you keep selecting between the options on the navigation bar eventually you get ‘502 bad gateway’

That’s because I was bringing up the development service for more testing but ran too much into UK time overlap. With both our live and development servers up, we quickly run out of process slots for everything. Nginx’s 502 basically means “I tried to start up this app but I couldn’t do it”. I’ve now finished work for the day (local time 19:50) and killed off everything but the usual live site stuff. You shouldn’t see any more 502s today, but if you do, please do let me know – thanks.

Tickets #351 and #353 now fixed.

Rick: Surprisingly, ticket #354 is fixed ¹. I can’t do it in a particularly clean or efficient way, but having noticed that the forum Textile parser was being far too lax in the face of the occasional spammer we see here, I tightened up the security by restricting certain previously allowed HTML tags. In passing, there’s a post-Textile examination of HTML nodes which can be used to detect footnote-like things and change them to likely-to-be-unique anchors.

It isn’t 100% robust; if someone manually generated a P, A or SUP tag with the right attributes it’d get replaced, but that might not actually matter provided they were being consistent with the in-post use. It does seem to do the job well enough overall.

The CPU usage is acceptable because the code only runs when a post is edited or a new post is made; thereafter, on display, the processed HTML is being shown out of a database-stored cache anyway. So existing footnotes in historical posts will not show any change, but new posts including footnotes ² will use unique anchors and names now.

¹ Diff for the curious: Changeset 451 (and yes, I know it says “notes” instead of “nodes” in one of the comments – see Changeset #452!)

² See? :-)

I’m not sure how closely you’re keeping an eye on the bug tracker for these things, so I’ll mention it here as well: It looks like the wiki “Linked from” sections aren’t automatically updating any more. To get them to update you need to manually edit the page you just linked to. (Ticket #359)

Noted. The Wiki software hasn’t changed so this has probably always been the case (especially since it seems to be cache-related) BICBW (there’s I suppose a distant chance it could be a server thing).