Script attached. It goes in your ubbthreads install directory, and you can delete it afterwards. [:"red"]You will require a backup from previous to the upgrade, specifically your w3t_Posts table. A new, renamed table (w3t_OldPosts) containing your old posts data is required - you will have to use PHPMyAdmin or some kind of tool or whatever to do this. Be sure and back up your current w3t_Posts table again just in case.[/]
I don't know if it's been noticed, but currently when you upgrade to 6.2, it deletes the Usernames from the w3t_Posts table, which means you lose the names of the people who posted stuff and had their username later deleted, because their username ID is 1 (appears as **DONOTDELETE**).
If you happen to have a backup of your w3t_Posts table (from 6.1.1 or earlier), with this script you can restore those lost names. You need to Restore your backup as w3t_OldPosts, then execute the script.
What it does is it grabs all posts that have been posted by Registed Users with the ID of 1, which means they were deleted. It takes their Username from the old table, and places it in the AnonName from the new table, and reflags them as unregistered posters.
When I ran it, it went through about 10,000 posts, and for some reason, some names could not be restored. Most were, though. Probably 90%. YMMV, but it's better than having **DONOTDELETE** everywhere.
If there are problems that you encounter, I'll watch this thread for replies.
I should add that I've discovered this does not happen to everyone. So, it's not a bugfix everyone will find useful, but for those few that had my prob, it should help.
Dalar, can you [:"red"] highlight in RED in your instructions that the old data has to be restored to a NEW table under a NEW name [/] and therefore the data file has to be edited at all ocurrences, where it says "w3t_post", to "w3t_post_old"? - I almost screwed up with this one.
And what about those indexes. Do they have to be renamed in the "Old" file too? Or does it not matter when w3t_post" and "w3t_post_old" use same KEY names... (This is beyond my MySql knowledge) But I think, at least it cannot hurt, changing all those names into something else doo..
To complete your script, the OLD table should be dropped thereafter. Or you carry tons of now useless information in the database.
I think I'll give your hack a try today! - Maybe this one is about to save me hours of debats with irritated suspicious users who think that some type of big brother admin was not only killing users here but also killing their entire pasts...
I did everything and ran the script. Then I checked for the result with PHP MY ADMIN. OK, the names got put into the Anon-Field. And in those cases the Reg. field was "n".
But opening a thread in Threads (flat mode) shows the Poster-Entry in the summary-table in such a case empty. Ok, I open on of those posts and see that on the left side there is "non registered" written but nothing else: The Anon Name seems not to be displayed. So there is still a problem somewhere?
I have set: "unregistered username allowed and displayed": YES
I didn't include a drop table, because I assumed anyone that would use this would also being using PHPmyAdmin or some other tool to restore the w3t_Posts_old that they'd again be able to use to drop said table.
I'll rewrite it a bit to make up for a couple of these issues.
I found what had caused some names to dissapear on my forum.
When I first tried to upload a backup to the web, PHPMyAdmin couldn't handle it - 7 MB of POST data exceeds the maximum or something. So I cut down the backup on my computer to just those posts that were posted by those with registered usernames with PosterID of '1'.
What I didn't realise until now, is that the backup I was using was old by about a month, which shouldn't matter when the posts I was concerned about were over a year old, except for the fact that I had deleted some users after this backup was done. So, that meant that when the script checked for one user that was recently deleted, it would find the correct condition to grab the username, except that the corresponding post wasn't even in the backup database because I had weeded out all registered users.
So, if you have a full backup table, all should be fine. In my case, it was lacking, and it would just stick nullspace in the AnonName. My bad.. shouldn't affect others' results though.
Carl, fromw hat I recall the setting for anon users should not matter. Either on or off, if it encounters something in the database recorded as an Anon it'll treat it as one. Are the B_Reged lines right?
Donate to UBBDev today to help aid in Operational, Server and Script Maintenance, and Development costs.
Please also see our parent organization VNC Web Services if you're in the need of a new UBB.threads Install or Upgrade, Site/Server Migrations, or Security and Coding Services.