People often resurrect zombie threads from many years ago for a variety of reasons. The policy is clear - they get locked, and the resurrector gets told to open a new thread if they’d like.
So why don’t we just lock all threads older than, say, a year? They’d still be on record, but wouldn’t be able to be resurrected. Seems like this would save work for the mods.
Unless this would involve some tricky or time-consuming procedure, it sounds like a good idea. What do y’all think?
As it stands now, vBulletin doesn’t give administrators the ability to mass lock threads (I knw, because I went to the vB site and checked out the demo admin panel). So, it would indeed be a terribly time-consuming task. It wouldn’t be too terribly diffficult to add this ability with a small PHP hack (Jerry, you listening?); I wrote a similar procedure for another PHP-based bulletin board package–a mass delete of locked threads.
I wiped out a DB testing it, but that’s another story. 
Another way to do it doesn’t involve any hack, just a piece of PHP code put in the Admin directory that once a month or when needed is run by an Admin. Since I don’t run vB 3.0 I will not post the code here, as I have no specific listing of the database schema for 3.0.
Doesn’t have to be PHP. Just write a nifty little sql script that goes over the Threads table, and if time of last post on a thread is earlier than, say, 6 months ago change its status to “Closed”. Run once a week. Should take about 3 minutes to write (knowing the DB schema) and about half an hour to perfect.
The Threads table should have maybe a few hundred K entries, and would have to be indexed by the Last Posting Time column anyway, making the script even easier
(something like “UPDATE threads SET status=‘Closed’ WHERE sysdate - LastPostTime > 180”. End of story. If you want to be super-efficient, use PL/SQL or equivalent, and set a variable to sysdate [now() in MySQL?] once at the top, then use that value in the WHERE clause)
Also, this doesn’t touch the vB software package in any way, shape or form. Just an external operation on the DB.
Dani
Come to think of it, they wouldn’t even need to do that. Whoever has access to the MySQL control panel can just run a QUERY right from there to do it.
My eyes are glazing over a bit, but you guys seem to know what you’re doing…
(and responding to Noone Special too)
…but that completely defeats the purpose of 1) Admins on the SDMB being able to do it while not at the machine itself, and 2) limiting direct access to the MySQL functions for security. All the PHP code would be a simple page saying “Lock all threads older than X”, and a submit button, which would send off the SQL query. You can’t give people across the Net access to the raw, unfiltered SQL ability without violating every security principle that the Board should be following.
In addition, you don’t want to give everyone access to raw SQL scripting anyways. All it takes is an accidental DROP TABLE THREAD; or ALTER SOMETHING GOOD to SOMETHING FUCKED UP;, and then it’s restore from backups time…
I was thinking more along the lines of - create the script; test it on some innocuous DB to make sure it’s good; put in in the DB server’s scheduler/crontab/whatever to run every week on Sunday at 05:00 AM.
No external access; no need for the Admins to run anything manually; no ALTER or DROP commands run inadvertantly (BTDTGTTS :()
Dani
Correct, an automatic execution has advantages. However, I took into account the problem of the wide variation in server load and Board activity - some times, or even some weeks, it might really be problematic to execute the script - depending on how long it locks the tables, it might even be a problem late at night. Until someone tests it, we wouldn’t know. Since I have no inside knowledge of the actual server, nor of the actual speed involved to search through and update as many threads as there are on the SDMB with its equipment, I defaulted to a simpler manual method.
It’s all speculation for any of us who aren’t on the physical access team. And there are many right answers, depending on the reality of the situation.
That’s why I specifically said:
Which would be jdavis and the other tech people. Test the QUERY on a test DB, save it in a text editor, and C&P to the SQL control panel when you want to run it. The forum admins would be completely out of the loop (sorry guys!)
…but my point was that the whole purpose of the function would be so it could be run on-demand by the Admins. jdavis, from my understanding, is not involved in regular housekeeping/Admin of the board and operations, but is the technical wizard keeping it up so it can operate. That’s all I’m saying - it seems to me to be something that the Staff would do, rather than the tech expert. And the suggestion for automation by Noone Special is a very good one normally, but due to the SDMB’s unusual situation of sometimes very high spot loading, it might not be the best option. I was trying to think ahead to the practicalities of the issue and implementation, as opposite to the possibilities.
None of which matters anyhow, as I know this suggestion and all the alternatives in here have been discussed numerous times before, and obviously found undesireable from either a technical or an operations standpoint. It’s sort of like arguing about which Teletubby is the straight one… 
Server loading wouldn’t really be an issue. They could do it as part of regular maintenance when the Board is offline, once a month or whatever. Even if they did it during normal operating times, it would only be as much of a load as any typical search for threads in all forums from any date.
Besides, even if they never do anything with it, it’s still fun to come up with practical ideas. Who knows? Maybe one day they’ll actually listen to us.
Quoth Est Demonstrandum:
Which succinctly illustrates one of the reasons why the Staff here (both board administrators and server administrators) are reluctant to tinker around too much under the hood.
Indeed. But to be fair, it was only a small DB for a privately-run forum attached to a chatroom, there was a backup, it was a mass delete function rather than just changing a status flag, and once the script was debugged, there were no further issues. I trust Jerry knows enough to run tests on a purpose-built DB first.
[ul]
[li]PHP (PHP Hypertext Preprocessor (Yes, that’s a recursive abbreviation.)) is a programming language commonly embedded in web pages. It’s a pretty conventional imperative language (like Perl or C).[/li][li]SQL (Structured Query Language) is a programming language made for managing databases. It’s based around making logical sets from the contents of a database and performing operations on those sets.[/li][li]MySQL is an open-source database that provides the backend to this message board. A database is useful for keeping data in a coherent structure and allowing fast access to various pieces of data via logical queries such as SQL statements.[/li][/ul]
Cheers, Derleth.
Neeeeeeeeeeeeed braaaaaaaaainsssss
Very funny, Enderw24.