I've seen it in Safari. It appears to be fixed in the webkit nightlies so it should be fixed in a future release of Safari.

Whether the fix made it into Blink and thus Chrome I don't know.

That's so peculiar. I'm getting it on all my laptop Chromes.

I've finally gotten off my ass and am debugging the code on a more recent version of PHP. I've migrated a copy of the code to a subdomain of one of my Dreamhost domains, so I'm testing to 5.2.17. Working my way through the big use cases, and once those have been worked out, I'll ask a few of you to register over there and hammer at it.

Once that feels good, I'll test a migration (I've just moved code, table structures, and the quotes) of posts and users and we can do a round of testing on that too.

More than once I've been asked about sharing the code. Clearly I'm embarrassed by the state of it, but you can't bring the system up all the way from the front end--it's simple enough to package the code and the table structures as well as the quote mechanisms (though you can add quotes through an interface, to add or delete shows or episodes you need SQL) and an admin user with a default password. The database connection information is in a config file, not in the code, but the groups of threads on the right side of the front page are hard-coded--the first two groups created will appear there.

Hmm. I wonder if it's worth adding that as an option for any thread group--display in right column. Fuck reordering, though. Also the archive thread is hardcoded in place...

I just want it to be tidy! On the inside too!

Also the HTML/CSS courses I'm taking on lynda.com are *not* helping things...

I understood about 2.7% of what you just said, but I did get this: There will be a test board where we can post goofy stuff like last time? Because that was fun.

I totally get being embarrassed by your code after a while -- it happens to me after about 6 months, let alone as long as the board has been around! -- but is there anything others of us can do to help you with refactoring, updating, and general fabulousness-polishing?

My god, the degree to which I settled in trying to separate data access from presentation is ludicrous! I'm going through the class definitions now trying to clean those up a little. So far? I've reworked the right column of the first page. See me roar!

Actually, that change should be able to also better separate logic from presentation for the main column of the index page as well. But still...

What could really stand to be tidied up/fixed/enhanced/nuked from orbit and rebuilt are:

• folder maintenance--right now they can't be deleted from the front end, and there's no way to indicate which folders belong in the right column (or in which order, but that's not the biggest deal)
• quote maintenance--this is flat out ugly. I slapped together the first thing I could manage to make it no longer a manual database process to update the tables--they are show (show code (??? ID not good enough for me?), show name), episode (season, ep number, air date (what did I think I was building? IMDB?), ep title, show code), quote (quote id, character name, season, episode (sloppy!), approved (Y/N), show code). My original intent was to have a user front end where quotes can be submitted, and then an admin interface for adding, updating, and deleting, as well as approval of submitted quotes. I got as far as the latter, but there is no way to update the show or episode database without SQL.
• database abstraction--it is loosely loosely abstracted in that all queries are run from the connectAndQuery function, and parameterised in that the credentials are stored in a config file (adding DBHOST was the first PHP 5 fix), but mysql_fetch_array is still being run where it should not--the query function just returns success/fail and doesn't insulate the code from having to know about what's behind it.
• parameterisation--I think this shouldn't be *too* bad. What would it take to make this software run a Lost board? Site title, some of the left hand column, for instance could be pulled out--It would be sensible to take identifying factors out of the code.
• user maintenance--this is pretty ugly, and no longer near efficient. Something like a dropdown that filters itself as you type would be MAGIC. Also the ability to search on something other than user name would be useful too.
• separating layers of logic--it's never going to be proper MVC, but some times the page code is way too ignorant of the data that's presented (relying on classes to output HTML, just ugly and hard to format/debug) and sometimes it's all up in there and using functions like mysql_fetch_array
• layout and semantics--I'm not saying go all HTML 5 or anything, but the HTML is a bit more complicated than it needs to be in order to achieve our goals. Header with three sections, body with two or three sections, footer--it should all start from there.
• error handling--this is far from elegant on the front end, and barely utilitarian on the back end (did you know the errors and all the information you could need to know are written to a file whenever that red message appears onscreen? and that there's an admin-only page to view them? yeah, there's a reason that's not been mentioned).
• session cookies--good LORD, is this ever a hack! Let me just say--there's a better way to do this. I don't know what it is, but it does exist. It has to. And I do wonder--would a "remember me on this computer" option be useful in addition to the "remember me ALWAYS" we already have implemented?

That's off the top of my head. The one I marked in red is the one I am working on right now since it's the first thing that pained me upon debugging for PHP 5, not because it's the most important or anything. It is hideous and hideously embarrassing, though.

Aren't you glad you asked?

Who has the time on their hands to help out? What would you like to help out with?

What would you like to help out with?

I think most of us are limited to standing ready with the fearsome brow mop.

And I do wonder--would a "remember me on this computer" option be useful in addition to the "remember me ALWAYS" we already have implemented?

If it were there, I would absolutely use it.

I'm a) a decade out of the industry and b) about to head into summer camp fundraising and tour, but I'd be game. I could probably start taking a look at parameterization, at least digging through and seeing what was site specific that would need to be generalized. Even if I didn't do the coding, just the checking, would that still be useful to you? Once I got in and puttered a bit it would quickly be clear if I'd be able to do any code or not.

Hey, thanks, Liese!

Let me just make sure the main test site has the full up to date production code and then I'll give you credentials. Any dynamic pages where we're making any assumptions about the site's name (Phoenix as well as Buffista) we should pull out. I *think* the emailing should be fine--it defaults to the email address of user #1.

Profile address good?

Okay--the local test site is running the latest PHP 4.x code. I have tested the basic functionality on a 5.2 server and found the big issues, but I think it's ready for a first wave of five or so testers.

Can I have five volunteers? And please tell me if your profile address is the one I can use to send you the test site information.