IME_Admin

This is now resolved. Thanks to everyone for letting me know about the issue.

I have identified the specific coding issue and commented out the portion that is causing the page to break. The site now loads without an issue. I have forwarded this information on to Jason and all of the web developers in hopes that they can identify whether or not this code is needed any longer while on PHP 5.3.6. Once again, my sincere apologies for this temporary issue the upgrade had caused. Sincerely, Matt

I have contacted Jason regarding this issue. Unfortunately, due to recent exploits in the PHP 5.2.x branch that occurred on our network, we had to make emergency/proactive updates to the PHP distribution installed on the WFG servers. We have now moved to the 5.3.6 release, which brings it completely up-to-date. Unfortunately, there is something in the /0ad index code that is breaking it with PHP 5.3. This is probably due to deprecated coding. I am going to work with Jason and other members of WFG to resolve this issue as quickly as possible. I sincerely apologize for this issue, but it had to be upgraded in order to 1) protect all assets and clients across our network, and 2) keep the servers up-to-date with the latest (supported) PHP 5.3 development branch. Thank you for reading. -- Matt IME Network Admin

Hmm... interesting. This problem seems to be resolved for both Jason and I. Is there anyone else out there that can confirm these errors are still occuring? I'm curious now if it is specifically with your account Tim, with maybe having something to do with your membergroup status or a particular mod, I'm not too sure. Maybe a deletion of your PM's will help, or rehashing your account if all else fails. I don't want to ask you to do anything too drastic here, but your httpd error_logs aren't even showing hints of the errors anymore since the previous ones were resolved. Let's hear some feedback from others if we can Thanks everyone!

This issue should now be resolved. Please let me know if you encounter any additional errors regarding this in the future. Thanks!

Unfortunately (and I know this isn't the desired answer, but...) the error seems to be a result of an incompatibility with the PHP 5 upgrade. I told Tim many times (*wink, nudge*) about the possible negative impacts and incompatibilities of upgrading to the PHP 5 module, i.e. It is NOT 100% reverse compatible. However, and luckily enough up to this point, there have been little or no negative effects with the migration from 4.3.11 to 5.0.3. This is one of those things that unfortunately we'll have to refer to IPB directly regarding this issue (I would suggest their support forums first, then support directly) just to get a grasp on what could be causing this. It might also be a previous mod installation affecting the output as well. Whatever it is... memory exhaustion shouldn't be happening, so we need to evaluate the way the coding is being parsed. In all honesty, 8 MB (which is the amount the error is reporting) should be *more* than enough to send a simple private message, which is defined right now in the php.ini. I am very reluctant to increase this setting until we can at least identify the root of the problem. Basically, it's really something out of my control at this point to answer (so suggestions are welcome)... Unfortunately, life has preoccupied my availability to diagnose things like this that aren't directly server performance or security related. I have been working 50 hours a week, among other things. I will, however, try my best to take a deeper look in the future if it is not solved soon. Thanks.

nm... wrong thread. http://www.wildfiregames.com/forum/index.php?showtopic=8061

There shouldn't be any issues with the database tables now. The glitch last week affected just a couple of entries in the members table only and has since been corrected. And as already stated after your post, the F&G area is simply setup to not count towards total post counts. So for Argalius and the original question, the forum knows how to count (mostly, haha). Cheers.

Yes, but the forum software would have assigned that user a new ID number rather than an old one. While manually, you could have assigned the user as ID number -82372 or 1000000000000 (or even "BOB" if it was a text capable column, haha!) if you really wanted to. Nevertheless, it works, it's just not entirely correct when it comes to the database index syncing with the flow of the forum software, i.e. keeping track of the right posts and ID's and log actions, etc. I will extract and apply some corrections to the database this evening starting around 10:00 pm (CST), let's get online and coordinate this so you can enable maintenence mode temporarily while the members are restored into their correct slots. IM me or shoot me an e-mail

Probably so. Here are the last 15 members sorted by default. It uses the exact order they were inserted and via the auto-incrementing number. 781 godlike 782 Satif 783 litwol 784 sauron 785 reebash 786 Vox 787 mebus 211 Paal_101 439 Titus Ultor 791 ToBB 792 yoop 793 NTICompass 795 proxann 796 yyz 797 kingroy1 Notice the bolded entries, they appear just after 787 (you were trying to query ID #788). Therefore, I'm assuming this is the cutoff ID where the members table locked up and became corrupted. Also notice these two entries are completely out-of-order, and non-conforming to the auto-incrementing value. This was a result of them being re-added manually afterwards. All of the values after these are new registrations since the corruption occured. Additionally, 794 does not exist, so I'm assuming this member was deleted recently. Note: There are lots of other entries in the table that are also out-of-order, and this is mostly a result of the merging of the three member databases of all of the WFG forums. It indeed worked, but it was essentially like putting duct tape on a broken leg. Things will just take longer to query and to keep in order. I do have a great idea though, and it's something which may help this entire situation. I have a little method I've used in the past to reorganize ID's into the correct order without sacrificing the auto-incrementing functionality. Basically it involves downloading the database table in CSV format, and sorting it via ID column while keeping the rest of the info intact. Then converting it to SQL code (insert, into, where, etc) and recreating the table after deletion. The newly sorted values will be aligned then when the re-creation occurs, therefore allowing the forum to search, query, etc through all of the values properly. I'll probably give it a go tomorrow if Jason and Tim will allow.

Actually I am really sure that this has happened. When I ran into phpmyadmin when those errors occured I manually entered some SQL codes just for checking...they'd be run successfully although the errors would appear too, so it must have been that. Additionally, I know where I posted how often when the errors occured - those posts were all in there. Deleted them now though. ← Hey Tim! What exact errors appeared in PHPMyAdmin? and what commands did you run? Also, what specific areas were these occuring in? Just curious, maybe there is something else causing the double posts. Maybe topic and post ID's mixing or something from previous instances/sections of your forum prior to the merge. I know this hasn't become a major problem since all of your data is still here, but it's just one of those little things I'd like to figure out.

It is completely possible that the initial locking stemmed from these two users and some failed modifications, so I'll assume this is where it all started. For future reference (since I know this is the largest your community has ever been), generally it is a good idea to run that forum optimization in the IPB panel whenever you get a chance. I run one particular forum with around 100,000 posts (cleaned a ton out over the last year even), and we have over 8,000 members. I generally make it a good practice to optimize my databases every week or so. I'd recommend the same for you, or at least maybe once a month if you forget. Also, when you start to see an error code like that when attempting to move a member... the very first thing you should do is run the forum optimizer in the IPB control panel, then come back to it. Normally this will correct anything that is parsing slowly, or having a tough time finding a record. Again, I cannot stress enough, MySQL optimization is your best friend. And not even having to do it from the command line should be cake. Ok, one other thing I'm curious about, how did you enter the two members (and their ID's) back into the database? In an existing row? Or a totally new row? It is not (and I mean never) a very good idea to add back old members by creating a new row (if that was what you did). Now IF it was already existing, and it was still the correct and original ID where you plugged extra info in, then you're fine. Here's why it is NOT a good idea to create a new member row manually: As you know, members are assigned an ID number upon initial registration, but what you may not realize is this column is associated with another number which is essentially a hidden value (set by auto-increment). And sometimes, depending on if you have deleted members in the past, these numbers will not sync, but will always remain a constant distance apart with each deletion or member movement through the forum administration panel. Now, by simply readding an old ID with a new row, the auto-increment value (used for indexing and searching) will still act as if a new member is being added through the registration module, when indeed that is not the case at all. Unfortunately, you cannot prevent the auto-increment number from being assigned unless you drop the entire table, change the table type, and import all the numbers back into it (this would be slower too). Essentially what all this jargon means is this... the auto-incremented number becomes skewed when you add a new row with old data. This may sound relatively harmless, but it's actually about the most damaging thing you can do to any database since the entire basis IPB uses of searching through the forums for an ID record relies on that auto-incrementing value. So let's say (example) you have deleted a total of maybe, 7 members over time, yes? So then member number 455 would be on the auto-increment slot of 462 (the true amount of members you've ever had, plus 7 -- for those you have deleted). So then when you try to put, for example, 123 (the old ID presumably) manually into a new row, the auto-increment (again, it's hidden and cannot be altered) value might really be 732, or pick any number really, while it would be expecting and will *assume* the ID to be assigned to it will be given 725 (which your auto registration would have taken care of). Now the forum itself has no clue what changes were made outside of it's recounting and registration processes, and yes, it just keeps acting normally like you'd expect it to... So at this point, you might be alright for a few days, weeks, months, maybe even a couple of years... until you try to mess with the user (and unknowingly, that ID number) by moving it to another group. The forum inevitably goes bonkers because it has no idea how to find it, and might get stuck in a loop and lock the table up. This is when the forum has had enough, at least for the time being, and invariably tells you to stick it. Now, is this what really happened? Honestly, I really have no idea. Maybe not at all, and then you can call me the idiot for rambling about this, haha. But if you ever *have* manually edited forum members and ID info in the past through PHPMyAdmin, it may have spurred this whole thing up, but just held it in hiatus for a while... if you get what I'm saying. Awesome... everybody now... "optimization is my friend... optimization is my friend... optimization is my friend..." Excellent, did you set a global ban in .htaccess? That would probably be your best option. And be sure to set it from your root web directory so it covers everything underneath it. And before I go, the PHP 5.0.4 integration is coming around, I'm really just trying to take every precaution prior to installing it full-throttle on your server. I'd almost like to experiment by running everything through PHP5 as .php5 extensions for now to ensure both modules can run together peacefully. Then migrating over. Now, if PHP5 was 100% backwards compatible I would have rolled it out months ago. Sheesh, stupid upstart developers. j/k! ... take care

Hello everyone, including Jason and Tim! Just a little additional insight here, take it for what it's worth. I don't believe the forums will contain any miscalculated post counts as reported by some. The corruption was really only a locking error experienced on (specifically) the members table only. And although this table contains various member info and numerical data, there was only a single line which was adversely affected as a result of this minor issue. A quick repair and optimization was run immediately upon noticing the problem and the row was removed and the forums were returned to complete functionality. Losing something around the ballpark of 150 posts (if that was in all seriousness) would have to be the result of a completely unrelated issue, probably non-database related, and rather the result of old threads being removed or a particular forum being set to not count posts any longer. That would be my best guess. I also highly doubt it would be a result of posting 150 times throughout the duration of the problem (which was only a few minutes anyhow). And considering that only certain accounts up to a particular data row were functioning, that would have skewed that post-mongering likelihood even moreso (haha). Lastly, and just to clarify, there should definitely not be any reports of double posts, as that table is completely separate from where the problem occured. Nevertheless, stuff happens, and if there is anything else anyone thinks might have occured in terms of oddities over the last day or so, please post here and I will continue to monitor this thread. Thanks! P.S. Everyone be sure to remind Tim how important it is to optimize MySQL databases more than once a year! (especially when you have such an awesome and growing, active community) Haha, just kidding Timbo