Andy Schmidt

@brimfulof @stevenmartis – Gents, thanks for confirming this was behind your troubles. According to the source code the table name mismatch seems the most likely scenario.

I do realize, others have not been as lucky – but I haven’t been able to get a backup to one of their tables to track down how their situation differs.

Dear Geir,

If you are intimate with PHP and MySQL, you could just invest the time and step through the code and see where ELSE that message is raised. I had found the table name mismatch as being the cause when I had tracked down the problem in the WordPress code last time, thus had no reason to look beyond that.

Otherwise, I hope that someone will be able to point you to paid WordPress or third-party service option.

If everything else fails, you could take a MySQL backup of your WordPress database. I could attempt to restore it on one of my test systems and see if I can reproduce your wp-admin problem on my end without needing any of your plug-ins, uploads, media files etc. However,… I am tied down with really tight commitments for weeks to come – so I’m desperately hoping that someone else will be able to step up.

geirosset: In cases like this, you have to be very exact with you information because we can’t guess if you are omitting things for convenience or if they are truly missing, thus wrong, in your system.

What does your your wp-config actually state as the prefix parameter? Because if $table_prefix truly is “syd_” instead of “syd_wp_” then the table names would be “syd_user_roles”, not “syd_wp_user_roles” etc.

Once you CORRECTLY match up your table prefixes with the wp-config settings, then the NEXT step is to bring this in line with the information in your wp_usermeta table and in your wp_options (or whatever the correct table names are in your system).

THOSE two tables have records that normally would start with “wp_” (the default table prefix) – so those rows would have to be changed to match whatever correct value to match your ACTUAL table names AND your $table_prefix.

PS: Also, you didn’t explain when this started breaking? What is that you changed/installed etc. that caused your site to fail for the first time? Why not undo it?

• This reply was modified 9 years, 3 months ago by Andy Schmidt.

Although not likely the problem for THIS user, this particular message will occur when someone “consolidates” various WordPress projects into a single MySQL schema, and in the process CHANGES the table prefix in the wp-config and renames the tables to match the new table prefix (e.g. from “wp_…” to “mywp_…”.

There is a very unexpected dependency of the table prefix in a handful of records in the wp_usermeta table and one in the wp_options. Fortunately, it’s very easy to fix. Just look for a key starting with “wp_” (the default table prefix) and then change those rows to the keys matching the new table prefix in your wp-config, e.g. “mywp_”.

Basically, your “admin” user has “login” permission, but those records in wp_usermeta and wp_options are the ones that give that logged-in user permission to manipulate the data stored in a particular set of tables. It’s likely a carry-over from the MultiSite implementation.

Takayuki Miyoshi, thank you for contributing your plug-in. Do you have plans to include the provided patch in your official code to address the current portability problem / operating system dependence?

The reason for the tens of thousands of files is documented here – and patch is available.

The underlying problems are:

• The class defaults “$this->file_mode = 0444” and “$this->answer_file_mode = 0440” result in a chmod that explicitly restricts access to these files for nothing but “reading”.
• The “remove()” and “cleanup()” methods attempt to unlink (delete) those files – even though had been restricted to “read” access by the class default. Depending on the implementation of the underlying operating system, deleting a file that is restricted to “read-only” will fail.
• The “cleanup()” method uses @unlink – so it suppresses any PHP error logging that might have alerted to the problem, AND, it does not handle the “false” return code from the unlink – and thus ignores that condition that cleanup never succeeds.

The result can be a “denial of service” problem when tens of thousands of files start accumulating within a few weeks – and the server starts consuming extensive amount of time every 60 seconds, attempting to iterate through (and always unsuccessfully) to delete those tens of thousands of individual files.

Assuming that the default file_modes were chosen for a good reason, then (at minimum) a chmod to 0777 is needed prior to any unlink for it to succeed. Ideally, appropriate error-handling would also be addeded, rather that ignoring them.

A functional patch has been contributed – hopefully it will be implemented soon as this has been a recurring report by several users.