We're flailing wildly with scope here.

I agree with the idea of an emergency edit page, but we of course have to choose a < substitute less like a hug.

I'm with John on the craziness of finding errors and presenting a useful error message to the hapless user. Dammit, man, can't you hack WX and gank us the code?

edit: Hil, that's Occammish in its brilliance.

Hil, that's Occammish in it's brilliance.

Damn. Give that girl a medal.

What they said.

Any Perl guru worth his salt (insert encryption gag here) will tell you that you need to use an HTML-parsing module in order to do the subject justice, and there's no such thing in PHP.

John, you might want to take a look at [link] -- but I can't vouch for the quality of the code.

Go, Hil. That version of emergency editing makes much sense.

About tables: I like them. Please don't take them away. Unless we can't work this out, which would be sad.

About presenting a useful error message to the hapless user:

The main point is containing the damage, right? And the parsing solutions we've looked at so far (lovely as they are) do not present the user with their intent, they merely prevent the user from breaking the page. Which is what we want, yes, not pretty but functional.

So why not go with the earlier suggestion that just kills the errant portion by replacing the < and > with something harmless, rather than trying to correctly close or correct it. It's still ugly, the user still has to edit if s/he wants it to be pretty, but it's still non pagekill.

Let's see. So you would still check your hash and/or array. Assume you've found a genuinely orphaned <u>. Hmm...but you wouldn't know that you've found one until you hit the end, which would be an appropriate time to append closing tags, but would take even more effort to go back again to the guilty party and edit.

So maybe that's not actually simpler.

You could still do something like...check your hash and/or array. Find orphan. Toss post into Hil's safeedit. Advise user that their code is ugly and to fix it please, without giving them the benefit of particularly helpful error messages. The board is still safe, although the user may be more or less agitated if they can't find, say, the mismatched quote, and thereby is forced to completely edit out their post. But even this doesn't offer the advantage of any less resource usage.

I gotta think some more.

What have you used tables for on the site, Liese? Or is it ita's user-stats tables you like? I like those too.

I haven't. I like other people's tables. I like the ability to table when information isn't easily represented in lists or other happy-html formats.

I used to table, but it was only for the long dead leather pants taxonomy. Which is now faq'd, and therefore irrelevant to this discussion.

Edited to say that, of course, this is all just opinion, and therefore certainly subject to the hive mind. If we consense on killing the tables I'm fine with it. I'm just voicing an opinion in favor of having the tables.

I cannot table.

But I like ita's tables.

t /not able to follow intricate discussion above

I agree with Liese up to a point. But that point is

Advise user that their code is ugly and to fix it please

which implies "prevent them from posting".

I'm a bit unhappy about presenting users with that kind of negative experience.

I'd be more happy with a "fix it, post it, tell them 'by the way,it needed fixing' please check" message. And perhaps a hint about how to get HTML advice, who from, where to post a question, that kind of thing?

And any solution that I have in my head, I'd have to say, involves chucking extra closing tags in at the end of the post, not inserting them at the right point.

To do that, you'd have to read the whole post into a data structure, like a hash of arrays or array of hashes or something like that, it seems to me. That's what those parsing modules do.

OK thought on bandwidth?

There's still a kind of bug whereby if I have closed and reopened my browser since the last time I was here, my bookmark for the Message Centre doesn't work.

It goes to message_center.php, but redirects me to index.php, so there's two extra page hits, and index.php is quite big compared to Message Centre.

As a user, I would never ever look at the front page -- I don't need to.