Also, how hard would it be to make the post a page variable that displays with the error message? I'd hate to spend a lot of time posting a message only to find that it errored out and is lost in the ether.

If we're doing that, I'd think that below the HR is the place to go, wouldn't you? Perhaps even put it back in the posting box, with an error message above and no buttons?

If we're doing that, I'd think that below the HR is the place to go, wouldn't you? Perhaps even put it back in the posting box, with an error message above and no buttons?

Aesthetically, this makes total sense. My concern is that the error message won't be seen until and unless the user scrolls all the way to the bottom.

How about a NAME tag in front of the error (e.g. t a name="error" t /a ) and have the reloaded page URL include an #error at the end so that the page automagically displays the error section?

Sounds like a plan.

How do you want to work it? You want me to code up a dummy page without the PHP? Or do you already have some PHP-coded page that I can work with to fancify the error message?

I haven't finished the logicking yet, so a mockup is best.

Okeley dokeley. I should have some time tomorrow. I may even have time to work on that admin "search-for-user-email" upgrade. :)

ita, you are completely amazing.

Daniel, when I hit that link it gave me your WX identity. You might want to go back in and take out the text between the @@ signs so it won't do that anymore.

ROFL. I had forgotton about that. Thanks.

Copied from WX. I think much of this is more technical in nature and so doesn't need to wait for the Bureaucracy-decision-making-mechanisms to be put in place:

Oh, and about archiving threads: it would be great if the Nillys would still work even when threads have been archived. Might links have to be redone?

Maybe. Let's look at the archiving options.

1) Threadsuck old threads, compress them into zipped files and remove them from the database This is what I thought had been decided a while back in BBaBB. Advantage: would take up the least amount of space. Disadvantage: Nillys to the thread would no longer work. ita came up with the idea of having any links to the original thread take you to the spot on the archive page where the link to zipped thread is. This could be done automatically via the code. Users would have to first download the thread. At that point, they could use their browser's "find in this page" option to find what they're looking for. Not ideal, but it works.

2) Threadsuck old threads, remove them from the database, but DON'T compress them into zipped files. Advantage: With a small tweak to the threadsuck function (adding a name tag to the front of each post) and some other coding changes, Nillys could still work. Disadvantage: Would take up a lot more space. Question: Do we put entire threads in one file, or split them up into (say) 1000 post chunks?

3) Move old threads into a new Archive Database. Advantages: It's a database so it could have the same functionality (searching, etc.) as the original thread database. Disadvantage: As Archive Database grows, we could run into the same database-too-big problems we're having now. Questions: How much coding and HD space would this require relative to option 2)?

I'm most pro option 1. Not least of all because I'm most used to it. Options 2 and 3 don't significantly reduce the total amount of space we're taking up.