Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
[PPPM-3732] Wordpress Toolkit problem after check for updates
- Thread starter Brujo
- Start date
-
- Tags
- wordpress toolkit
Fixed in MU#72 - https://kb.odin.com/en/127755
My Plesk/Odin Version is: 12.0.18 Update #72, zuletzt aktualisiert: 17. Dez. 2015 04:30:14 - my Wordpress Blog is not working any more. The files seem to be there. I can not login at wp-admin. No page is showing. The update-process to WP shows followin error:
Unable to change mode for /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet: Operation not permitted Filesystem error: boost::filesystem::remove: Permission denied: "/var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess"(system:13)/opt/psa/var/apspackages/apscatalogjpqSKC.zip72b45e00-2985-9d/cache/htdocs/wp-content/plugins/akismet/.htaccess -> /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess Filesystem error: boost::filesystem::remove: Permission denied: "/var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess"(system:13)/opt/psa/var/apspackages/apscatalogjpqSKC.zip72b45e00-2985-9d/cache/htdocs/wp-content/plugins/akismet/.htaccess -> /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess
Tried to change permissions of .htaccess in subfolder via chmod 777 .htacess. Did not work. Pages are white. 500 error. No login possible. What can I do? Thanks for replies.
Frank Ix
I removed the plugin-folder akismet. Now at least pages are showing again and update via Odin worked. I guess it is no good idea letting Odin create and automatically update Wordpress. Sorry. Rather install it on my own next time ...;
Unable to change mode for /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet: Operation not permitted Filesystem error: boost::filesystem::remove: Permission denied: "/var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess"(system:13)/opt/psa/var/apspackages/apscatalogjpqSKC.zip72b45e00-2985-9d/cache/htdocs/wp-content/plugins/akismet/.htaccess -> /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess Filesystem error: boost::filesystem::remove: Permission denied: "/var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess"(system:13)/opt/psa/var/apspackages/apscatalogjpqSKC.zip72b45e00-2985-9d/cache/htdocs/wp-content/plugins/akismet/.htaccess -> /var/www/vhosts/dudada.de/blog.dudada.de/wp-content/plugins/akismet/.htaccess
Tried to change permissions of .htaccess in subfolder via chmod 777 .htacess. Did not work. Pages are white. 500 error. No login possible. What can I do? Thanks for replies.
Frank Ix
I removed the plugin-folder akismet. Now at least pages are showing again and update via Odin worked. I guess it is no good idea letting Odin create and automatically update Wordpress. Sorry. Rather install it on my own next time ...;
Last edited:
I still have a Problem with one of my wordpress Installations which was not fixed with #15 URl, Version, Plug-ins, Theme
are empty and when i click on the path I get this error:
PHP Fatal error: Call to undefined function add_filter() in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(798) : eval()'d code on line 78
are empty and when i click on the path I get this error:
PHP Fatal error: Call to undefined function add_filter() in /usr/share/plesk-wp-cli/php/WP_CLI/Runner.php(798) : eval()'d code on line 78
@AlL,
Some general remarks for the issues encountered with the WPT (a.k.a. the WordPress Toolkit).
Almost all factual issues are resolved by now (i.e. at micro-update 17 for Plesk 12.5.30 and micro-update 73 for Plesk 12.0.18).
Some factual issues are not yet resolved but do not affect the proper functioning of the WPT.
In the light of the above, one should be aware that WordPress itself and/or the updates thereof and/or plugins are often the root cause of the problem.
In general, the following rules of thumb with respect to issues should be remembered:
a) any major WordPress update is soon to be followed by a minor update: wait for that minor update, before updating the WordPress instance,
b) any (major or minor) WordPress update is followed by many plugin updates: just wait patiently, most of the first plugin patches are rubbish and will break the WordPress instance,
c) any issue, visible or potentially related to WPT, is often caused by the "mix and match" of WordPress and plugin updates,
d) most issues with WordPress itself are likely to be caused by plugins: most of the free plugins are not well-defined in terms of code and/or are disregarding the effects on other plugins.
The golden rule is in essence: keep the WordPress instance clean and mean.
And let´s compliment Plesk Team for patching (many) issues in a relatively short time period.
Regards.......
Some general remarks for the issues encountered with the WPT (a.k.a. the WordPress Toolkit).
Almost all factual issues are resolved by now (i.e. at micro-update 17 for Plesk 12.5.30 and micro-update 73 for Plesk 12.0.18).
Some factual issues are not yet resolved but do not affect the proper functioning of the WPT.
In the light of the above, one should be aware that WordPress itself and/or the updates thereof and/or plugins are often the root cause of the problem.
In general, the following rules of thumb with respect to issues should be remembered:
a) any major WordPress update is soon to be followed by a minor update: wait for that minor update, before updating the WordPress instance,
b) any (major or minor) WordPress update is followed by many plugin updates: just wait patiently, most of the first plugin patches are rubbish and will break the WordPress instance,
c) any issue, visible or potentially related to WPT, is often caused by the "mix and match" of WordPress and plugin updates,
d) most issues with WordPress itself are likely to be caused by plugins: most of the free plugins are not well-defined in terms of code and/or are disregarding the effects on other plugins.
The golden rule is in essence: keep the WordPress instance clean and mean.
And let´s compliment Plesk Team for patching (many) issues in a relatively short time period.
Regards.......
@Brujo,
Please do a "Scan for WP instances" via the Plesk Panel.
The error notification can normally be ignored, it should not even be present.
In short, there is nothing wrong with the code, it is very likely that the wp-config file cannot be found.
A new scan can help and if it does not, identify the specific WP instance that is causing the error notification and run: /opt/psa/bin/wp_instance --clear-cache <wp-instance-id>
I am pretty sure that one of both methods will resolve the issue.
Anyway, make sure that you have installed the latest micro-update.
Hope the above helps!
Regards....
Well this broken wordpress instance was fully recogniced by the wordpress toolkit until I installed MU#15 from this point on it has this issue. I am allready on MU#17 and did also the scan for new instances and scanded for updates. All my other 15 WP Instances are recognized well exept this one.
Clearing cache also do not help and shows this error
Clearing cache also do not help and shows this error
Attachments
@trialotto
sure did scan for instances and syncronize but without luck.
sure did scan for instances and syncronize but without luck.
Attachments
@Brujo,
I can recall that I did reproduce a similar error in the (recent) past and the chronological order of actions (scan, synchronize and security) has to be rather particular.
You really have to check wp-config.php manually: contents, file and directory permissions and so on. This probably will not yield remarkable results.
You can also try to reset security (toggle on/off, with exception of the items that cannot be rolled back).
I know from the reproduction of the error that the issue is occurring rather arbitrarily AND I do not know the differences between this one site and your other (15) sites, so I am at a loss.
Try to compare the settings of the one site with the settings of the other sites, mainly in the area of security (but also do compare in other area´s).
Regards....
I can recall that I did reproduce a similar error in the (recent) past and the chronological order of actions (scan, synchronize and security) has to be rather particular.
You really have to check wp-config.php manually: contents, file and directory permissions and so on. This probably will not yield remarkable results.
You can also try to reset security (toggle on/off, with exception of the items that cannot be rolled back).
I know from the reproduction of the error that the issue is occurring rather arbitrarily AND I do not know the differences between this one site and your other (15) sites, so I am at a loss.
Try to compare the settings of the one site with the settings of the other sites, mainly in the area of security (but also do compare in other area´s).
Regards....
@trialotto - thanks anyway for your support
seems to be one of the miracles
well i also minimalized the wp-config.php and also detached it from WPToolkit, did clean cache and scaned again but nope...
I start to belive it is somewhere broken where the Toolkit stores information about the Instance and this avoid to get it running again
thank you..
seems to be one of the miracles
well i also minimalized the wp-config.php and also detached it from WPToolkit, did clean cache and scaned again but nope... I start to belive it is somewhere broken where the Toolkit stores information about the Instance and this avoid to get it running again
thank you..
@Brujo,
We have tackled this possibility by clearing the cache and rerunning the scan.
One thing that you have to be aware of is that a WPT on a VPS can behave very particular, if the underlying host server is also running a WPT.
This issue has been resolved by now, but in the past, it could lead to minor corruption of stored information.
However, here is where the magic happens with updates: often an update/micro-update does the trick.
But then again, it still is annoying to see one of the WP instances not being recognized.
Regards....
We have tackled this possibility by clearing the cache and rerunning the scan.
One thing that you have to be aware of is that a WPT on a VPS can behave very particular, if the underlying host server is also running a WPT.
This issue has been resolved by now, but in the past, it could lead to minor corruption of stored information.
However, here is where the magic happens with updates: often an update/micro-update does the trick.
But then again, it still is annoying to see one of the WP instances not being recognized.
Regards....
Still have the Problem with Wordpress and Plesk 12.0.18 Update #72 to #74 at CentOS 6.5.!
After updating to 4.4 (and now 4.4.1) the wp-update info shows only /httpdocs insted the domain-name.
I have made a "search for updates" allready, but it don't fix that issue.
How i can clean-up cache, what were somebody talking about here? There is no hint for this in https://kb.odin.com/en/127725
After updating to 4.4 (and now 4.4.1) the wp-update info shows only /httpdocs insted the domain-name.
I have made a "search for updates" allready, but it don't fix that issue.
How i can clean-up cache, what were somebody talking about here? There is no hint for this in https://kb.odin.com/en/127725
Sorry, trialotto, we tested your "golden rules", but for us it is only a nice term and don't make a difference to that issue.
We tryed to install a brand new wp with wpt, without any plugins but i get the same error in WPT! (golden rules term ;o) )
We tryed do clear cache, after we found out, how we can do it. (btw: it would be great, if this would be documented in kb-odin workaround here: https://kb.odin.com/en/127725)
To cleaning cache only works without an error on wp-verions, what we don't have updated to 4.4.1 , but it don't fix the path-detection of WPT either.
During the cache cleaning at wp-instances since wp 4.4 the shell is showing that error:
ERR [util_exex9 proc_close() failed
so i'd like to think, that it has'nt work. I'm lost now, we have no idea anymore.
obviously there is a issue during autoupdate for wp too, or it has to do with that main problem: on view applications we have a error 500 every morning, because some files in root and wp-includes are deleted during a autoupdate! we have to install it manually every time!
thats annoying, so i would appreciate it, if somebody could help here...
Marc
@q4marc,
You stated
Another golden rule: never enable autoupdate for WP.
This is not related to WPT, but it is something familiar for WordPress (WP): autoupdate implies applying updates for plugins (and themes etc).
Most plugins are a root cause for issues occurring with a WP instance: most of them do not comply nicely with each other or WP itself and the only thing to do is to await a patch.
Let´s return to your issue (and the issue of many others) with the WPT.
The problem is that I cannot reproduce the error, that is, I cannot reproduce it.
However, I have been trying some things out and partially reproduced the error: it occurs more or less in the same state when migrating a domain that contains a WP instance, on a migration from a Plesk 12.0.18 to a Plesk 12.5.30 version.
Did you by any change migrate the domain that you have problems with?
Also, can you check whether your domain or subdomain has empty directories?
And, since I cannot reproduce the error, can you give me some detailed output (i.e. relevant log files)?
Regards...
You stated
Another golden rule: never enable autoupdate for WP.
This is not related to WPT, but it is something familiar for WordPress (WP): autoupdate implies applying updates for plugins (and themes etc).
Most plugins are a root cause for issues occurring with a WP instance: most of them do not comply nicely with each other or WP itself and the only thing to do is to await a patch.
Let´s return to your issue (and the issue of many others) with the WPT.
The problem is that I cannot reproduce the error, that is, I cannot reproduce it.
However, I have been trying some things out and partially reproduced the error: it occurs more or less in the same state when migrating a domain that contains a WP instance, on a migration from a Plesk 12.0.18 to a Plesk 12.5.30 version.
Did you by any change migrate the domain that you have problems with?
Also, can you check whether your domain or subdomain has empty directories?
And, since I cannot reproduce the error, can you give me some detailed output (i.e. relevant log files)?
Regards...
Hi Trialetto,
thx for your answer.
The strange thing is, that i don't have activated autoupdate for this domain (domain1.de) I have to update it over admin-panel of that domain, to get new versions.
If i try this over WPT, it don't work because of wrong permissions!? (see antother domain2.de in my error-log, there is a flag set for autoupdate and it don't work either, even on a clean install without plugins)
also i can't disable autoupdate anymore for some domains, where i had activated it. that path detection issue don't let me set anything.
This morning, wordpress was damaged again for domain1.de. same files like yesterday was deleted and permissons to files in language are set wrong.
here is a snipplet of plesk error log:
thx for help
marc
thx for your answer.
The strange thing is, that i don't have activated autoupdate for this domain (domain1.de) I have to update it over admin-panel of that domain, to get new versions.
If i try this over WPT, it don't work because of wrong permissions!? (see antother domain2.de in my error-log, there is a flag set for autoupdate and it don't work either, even on a clean install without plugins)
also i can't disable autoupdate anymore for some domains, where i had activated it. that path detection issue don't let me set anything.
This morning, wordpress was damaged again for domain1.de. same files like yesterday was deleted and permissons to files in language are set wrong.
here is a snipplet of plesk error log:
thx for help
marc
@trialotto - finaly found it why it was not recogniced and why it have output the error
line 78 was missleading the issue was the 2 last lines afterwards in the wp-config file with the add_filter entry. As soon as I removed the 2 Lines and cleared cache and scaned it was fine. As soon I added it again and scaned again it was brocken again.
this are the entrys which WPT dosent like :-(
Therefor whats the purpose of the WPT if it generate errors and show Domains broken in Plesk, within entrys in the wp-config - so for me its proofed the WPT sucks when this entrys are in the conf file and I think this shouldnt be happend
kind regards Brujo
line 78 was missleading the issue was the 2 last lines afterwards in the wp-config file with the add_filter entry. As soon as I removed the 2 Lines and cleared cache and scaned it was fine. As soon I added it again and scaned again it was brocken again.
this are the entrys which WPT dosent like :-(
Code:
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );Therefor whats the purpose of the WPT if it generate errors and show Domains broken in Plesk, within entrys in the wp-config - so for me its proofed the WPT sucks when this entrys are in the conf file and I think this shouldnt be happend
kind regards Brujo
Last edited:
@g4marc
Thanks for the detailed output.
In essence, you have two separate (but seemingly similar) problems on 2 domains:
- domain1.de exhibits a permission error,
- domain2.de exhibits an error related to "a custom directory WP installation" (this can be a permission error or the multiple issues associated with WP installed in a custom directory).
I recognize both of the issues from multiple tests to reproduce the error, but I cannot exactly reproduce them.
However, I am beginning to have a clue about what causes this behaviour, allowing me to create a more focused test (reproduction of error and work-around solution).
In the meantime: can you confirm that the permission structure in /var/www/vhosts/domain1.de/httpdocs/wp-content/themes/twentyfifteen is correct?
By the way, another question: did you by any chance migrate these WP domains from another server?
Also: what about your WP security settings for domain1.de and domain2.de, can you post them?
Regards....
Thanks for the detailed output.
In essence, you have two separate (but seemingly similar) problems on 2 domains:
- domain1.de exhibits a permission error,
- domain2.de exhibits an error related to "a custom directory WP installation" (this can be a permission error or the multiple issues associated with WP installed in a custom directory).
I recognize both of the issues from multiple tests to reproduce the error, but I cannot exactly reproduce them.
However, I am beginning to have a clue about what causes this behaviour, allowing me to create a more focused test (reproduction of error and work-around solution).
In the meantime: can you confirm that the permission structure in /var/www/vhosts/domain1.de/httpdocs/wp-content/themes/twentyfifteen is correct?
By the way, another question: did you by any chance migrate these WP domains from another server?
Also: what about your WP security settings for domain1.de and domain2.de, can you post them?
Regards....
Similar threads
