@Xavier12,
In response to
I must add that the issues can be related to
- W3TC (not memcached itself) and the changes applied by W3TC to WordPress config files, OR
- a buggy database, being either psa database or the WordPress database (the latter being less likely).
I will explain step by step, so you can reproduce the steps that allow you to analyse the issue.
For the sake of convenience, the steps are numbered (in chronological order, i.e. a sequence of steps to follow).
1) check whether the WordPress database actually has the values that it should have:
- the name of the WP instance should coincide with what you would normally see in the WordPress Toolkit panel (henceforth: WPT) AND in the Plesk page for the domain in question,
- the correct domain name should be stored in the WP database,
and note that both values are to be found at the top of the options table for WP, (often) called [prefix]wp_options.
If those values are correct, a "synchronize" would do the trick normally.
The synchronize action implies that some relevant data from a WP instance is being inserted in the psa database, in three tables. Let´s proceed.
2) check for inconsistencies in the tables (in the order below)
- WordPressInstances
- WordPressInstancesDomains (hardly relevant, but check anyway)
- WordPressInstancesProperties (most relevant)
and also verify that the troublesome domain or WP instance contains the proper data with respect to domain and/or the name chosen for the WPT instance.
Note that the command "plesk repair db" can do a lot, but this command essentially does not do a lot for the above mentioned tables and does nothing for WP databases.
However, this command allows us to get rid of any common errors in the psa database and some "occasional" errors in the before mentioned tables, that are related to WP.
In short, if you have found some inconsistencies, do the following
- run the "plesk repair db" command,
- recheck any values that were inconsistent before running the above command,
and some of the values are still incorrect, just edit them manually.
The actions above simply imply that we can now turn to the most common root cause of the problem, without having to worry about interference by other potential errors.
3) check the wp_config.php file, which should contain some entries for W3TC.
Move the entries, related to W3TC, to the bottom of the wp-config.php file, preferably just before the php closing tag.
Actually, that should do the trick, just finish the job with a "scan" in the WPT panel and everything should be fine.
Note that you could skip steps 1 and 2, but I would strongly advice against doing so.
The actions mentioned above are mostly sufficient, so in general the story would end here.
However, I know that WPT and/or WP can be quite stubborn, so I will proceed with two additional steps, concerning two methods of "enforcement".
4) enforce some proper settings in the tables mentioned in point 2, i.e. enforce a correct appearance in both the WPT and the domain panel: deactivate W3TC and scan again.
The above action implies that most (but not all) of the troublesome W3TC configuration will be erased, resulting in a proper scan by WPT and hence proper values in all relevant tables.
Again, note that this action should be sufficient, but it can occur that this is not the case.
For instance, earlier upgrades of old versions of WP can be contributing to the problem and hence be impeding a final resolution of all issues.
So, let´s proceed with the final form of enforcement.
5) enforce that all settings for WP are proper, consistent and clean: install a new clean (and latest) version of WP in a subdomain.
One should follow these steps to perform this task properly (in chronological order):
- make a (full) backup of the original domain containing the WP instance
- install the latest version of WP in a (temporary or permanent) subdomain (note: do not call the subdomain "dev.<domain>.<tld>", that can or will cause future problems)
- go to "Domains > [domain] > Databases (click) > Export dump (click)" for the original domain containing the WP instance (yes, just to be sure)
- go to "Domains > [subdomain] > Databases (click) > phpmyadmin for the SUBdomain (click)" and remove all tables (yes, that is correct)
- go to "Domains > [domain] > Databases (click) > Copy (click, ONLY on the original domain containing the WP instance, NOT the subdomain)" and select "Copy to existing database > [database for SUBdomain] (select)" and make sure that you have checked the "Create a full copy" option (yes, make sure)
- copy the wp-config.php to the root directory of the SUBdomain, with the command: cp -p [path domain]/wp-config.php [path SUBdomain]/wp-config.php.
orig (yes, be careful!)
- copy theme data to the subdomain: cp -pr [path domain]/wp-content/themes [path SUBdomain]/wp-content/
- copy plugin data to the subdomain: cp -pr [path domain]/wp-content/plugins [path SUBdomain]/wp-content/ (note that you also have to copy the mu-plugin directory)
- copy uploads data to the subdomain: cp -pr [path domain]/wp-content/uploads [path SUBdomain]/wp-content/
- it is
not recommended at all to copy cache or backup directories, since these directories are mostly containing old or even faulty backups/caches of the original WP instance
- verify that the WP instance on the subdomain is working properly and as expected and,
if and only if this check is passed, proceed with the next steps
- go to "Domains > [subdomain] > Website Copying (select) > "Website in Plesk" (select) ; Site name: domain (containing the WP instance) ; "Delete all existing files" (select)"
- go to "Domains > [domain] > File manager (click)" and delete the file wp-config.php (yes, delete, do not delete wp-config.php.orig)
- go to "Domains > [domain] > File manager (click)" and rename the file wp-config.php.
orig to wp-config.php (yes, that is all)
and that is it, a "new" WP instance with completely clean files is created within a couple of minutes, with a spare WP instance on the SUBdomain to play around with.
Note a proper order of execution should be followed, so please stick to the chronological order presented above.
Also note that I am aware of the fact that the experienced reader will notice that I added some steps that are not really necessary, but convenient for the less experienced.
And sure, note that I can make typos, so check the process and the text. And make the backups, just in case.
The WPT will recognize the "new" WP instance properly and a proper appearance in both the WPT and the Domain panel is the result.
The main advantages are that old buggy code, left over from previous upgrades, is completely removed. And, in my humble opinion, it is good to have a test SUBdomain.
As a final remark, there is one other potential culprit: WP databases being fragmented. But that is a whole other story.
Hope the above helps a bit!
Regards......
Facebook
Twitter
