[PPPM-3732] Wordpress Toolkit problem after check for updates

[trialotto]

@Brujo,

Thanks for the feedback!

You stated

line 78 was missleading the issue was the 2 last lines afterwards in the wp-config 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 - so for me its proofed the WPT sucks when this valid entrys are in the conf file.

I have to clarify one thing, in order to give a response to your post.

I have mentioned or hinted in another post that the code in line 78 is not that relevant, it is just referring to wp-config (i.e. instructions to read data from that file).

The problem with the "ghost WP instances" (i.e. WP instances that are not recognized by WPT) is that something happens with the ability to read files, primarily wp-config.php.

Note that I kept the above rather "eloborate", since I do not know the actual root cause of the problem yet (and it involves more than only the wp-config file).

Anyway, by removing the two lines you mentioned, you create a partial work-around by suppressing the symptoms of the problem.

That does not imply that the root cause of the problem is solved, the before should be emphasized.

However, your post contains some handy information: it really narrows down the area in which the root cause of the problem can be found.

By the way, the same questions for you as for @g4marc:

- did you by any chance migrate these WP domains from another server?
- what about your WP security settings for the troublesome domains, can you post them?

Any feedback would be appreciated.

Regards....

 

[Brujo]

@Brujo,

- did you by any chance migrate these WP domains from another server?
- what about your WP security settings for the troublesome domains, can you post them?

1. No this WP Instance was created last year on this Server under Plesk 12.0.x (therefore just a upgrade from 12.0.x > 12.5)
2. Settings -> see attachement
3. Autoupdate = Off

For double check I added this 2 entrys to another working WP Instance which was fine recogniced in Plesk and cleared the cache of this instance and voila its broken too in Plesk with the same error meassage but different line. So the WPT dosent like "add_filter"

add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

Yes I know this entrys should not be set in wp-config and insteed better in a plugin (as on WP Codex described), but I have no control what domain owners put into the wp-config or not... Therefore the WPT must be more failsafe tolerant for such things...


kind regards Brujo

 

[trialotto]

@Brujo,

Am I understanding it correctly: are you add the add_filter() functions to a wp-config.php file???

If true, than WPT is behaving normally: filters do not belong to wp-config.php (see the codex concerning autoupdates for WordPress), they do belong to a "functions" php script (by preference, when customizing functions files, use a separate functions file and add that to the appropriate theme, in order to prevent any WP related issues).

Note that you can change the ownership of the wp-config.php file to root:root in order to prevent that customers are adding abnormal lines of code to the config file.

That is, if I am not mistaken, that is something that does work, but I can also recall from the past that some WPT related issues can occur.

The above (i.e. setting root:root for wp-config) is a strict solution, it works great to prevent that the "mad scientists" under your customers will affect functioning of WP and the WPT.

In general, a less strict solution is applying the "security check" from the WPT: one can "secure" the configuration file.

However, if anything odd is already present in the wp-config file, than it will not help to secure the configuration file afterwards.

You state

Therefore the WPT must be more failsafe tolerant for such things...

and I disagree.

The WPT (or any other tool) cannot practically defend against (unnecessary) code errors.

AND, if I did not understand it correctly and the add_filter() functions are in a proper (functions) file, then the following applies:

a) in theory, the WPT should be able to identify conflicting settings, set by filters (like the ones you used to test), but that is not really practical: the filters can be anywhere, (and)

b) I agree that the WPT CAN (but does not have to) be more fault tolerant to "update settings", but this can be achieved by (automatically setting)

1 - define( 'AUTOMATIC_UPDATER_DISABLED', true/false );
2 - define( 'WP_AUTO_UPDATE_CORE', true/false/minor );

in the wp-config.php file. Note that this would give WPT more flexibility and hence added value, (and)

c) your current issue/problem is resulting from

1 - incorrectly applied filters, (OR)
2 - another issue, not directly related to "update settings",

and note that I am pretty sure that the root cause of the problem is related to the "other issue", as mentioned in point 2.


Nevertheless, I am gratefull for your feedback, since it points me to a specific direction: readability and portability of the WP config file, if a "security check" has been executed.

Even though your filter settings maybe applied incorrectly, it hints that some "overriding" of settings can confuse WPT (and that is valuable information).

Problem is that a lot of the lines of code in the PHP scripts for the WPT have to be scanned.

That takes time that I do not have, but I will keep you posted and updated, ok?

Regards....

 

[Brujo]

@Brujo,
Am I understanding it correctly: are you add the add_filter() functions to a wp-config.php file???

right I have set up a testdomain with a new WP instance and scaned it - works as expeckted and is recognized by WPT. Then I added this lines "like some Customers" does on there WP Instances, cleared Cache and thrn it is broken in the WPT. That was just for ensure this breaks WPT and to be able to provide some feedback.

No offense trialotto, just one note from my side to make it clear: before I start to "limit" Customers with there WP Instances in any way like chmod the wp-config or, to tell them what should be allowed or disallowed in the wp-config on a Plesk managed Server, I will deinstall the WPT if possible or at least disable the view on Plesks admin Panel as well as disable it on all Plesk Service plans for Customer Domains to avoid unneccesary call from confusing Customers why the WP Part sometimes apear/disapear in the Plesk Customer Panel Frontend: See Picture: this will be shown on Customer Panel if it is recogniced well by WPT and it is gone/missing when it is broken in WPT!


kind regars Brujo

 

[trialotto]

@Brujo,

No offense taken, I am not sure why I should ever be offended by your post.

As a general response, I would like to add that disabling the WPT is a punishment for well-behaving customers, only due to the fact that some minority of your customers behave like the "mad scientists" with WP: I personally feel that one tiny group of customers should not be having such a huge and undesirable impact on your hosting services.

Sure, I am aware that WP is a "do-it-yourself" package and that many persons believe they are an expert in the matter.

Most of the times, those self-proclaimed experts are not an WP expert: for a hosting provider like you, this leaves some choices to be made.

In the past, I personally did not allow WP hosting (for many reasons, but security issues was the main reason), but I decided to change that.

In your case, I would not make the decision to disable the WPT: it is a "unique selling proposition", i.e. customers value it and it prevents that your customers will end up at specialized hosting providers like wordpress.com.

In short, I would strongly advice you to keep the WPT and create a clear policy to avoid config mistakes by specific customers.

Note that one part of that policy is communication towards the customers and another part of that policy is inherent to Plesk´s WPT: the WPT recreates config files (if I am not mistaken) by reading and rewriting them, augemented with some additional lines.

The above suggests that you can safeguard WP config files, i.e. running a sort-of pre-flight check with a crontabbed php script, based upon WPT´s php scripts.

The latter suggestion is not a new idea, I have been busy to develop that "pre-flight check" (with some automatic corrections of wrong function calls), but all the (alleged and actual) issues with WPT keep me busy with reproducing errors, investigating whether a bug is present and preparing a bug fix (if required).

Anyway, given the nature of your issues (i.e. wrong function calls in wp-config), can we mark your isses as "resolved"?

In that case, I can keep you informed about the development of the "pre-flight check", since that would be of some benefit for you (and your customers).

Regards....

 

[g4marc]

Hi Trialetto,
all my problems with this one domain, that crashed every morning will have to do with the issue of WP 4.4 version and higher, guess.
i run 3 Servers and i have that problem on ALL servers! so its hard for me to understand, that there is a fix (MU#72) that solve the problem in all cases!

- did you by any chance migrate these WP domains from another server?
- what about your WP security settings for the troublesome domains, can you post them?

no, i don't have migrated WP from another server. WP was installed during WPT
what do you mean with "WP security settings? where i can find that in Plesk? (shown on image at Brujos posting)

the way, that the domain crashes was, that i had updated WP to the new version (4.4.1) because this domain has no autoupdate activated. Most of my WP instance don't have it, i have to update it manually.
There are many other WP-instances, that i have to update it by hand. It only works in every specific domain over the WP-admin-panel! it don't work over WPT, because of permission, problems. But all WP instances are installed with WPT, so i was wondering, taht it don't work directly with WPT.
I have no crashes at all (except the the path-error in WPT) all other domains work without any problems, only this specific one crashes every morning, when plesk do that check for psa MU updates. (i run 12.0.18 with MU#74 and don't have updated to 12.5)

there are always the same files, that are deleted, thats strange. if there is an permissions-problem during installition of files, it shoul'nt be possible to delete it, i guess?
i checked all permissions from another instance and could'nt find differences. What i can see, is, that the new files, that were installed over that update (i don't know, from were it comes!) in /wp-content/languages have another permission, than the other files! i have tested it, to change it to the right ones, that it should have, but it makes no differences between permissions, that is set from plesk, or the "right" ones, that belong to that owner and group. every morning, i have to upload missing files!

another question is: how can i check it, that MU#72 is installed?
what/witch files was changed and how can i find out, hw this changes affects to the path problem?
why is there a update on this domain, while i don't have activated it? is there a specific file, that looks for update in WP?

is it possible, that SELinux in enforced mode could have a effect for that problems? i have a warning for that in configuration troubleshooter:
on check i get: Die Überprüfung der Konfigurationsdateien ist fehlgeschlagen
and if i click on details i find that:

[2016-01-11 09:58:33][INFO] ==> Installed Plesk version/build: 12.0.18 CentOS 6 1200140821.14

[2016-01-11 09:58:33][INFO] ==> Detect system configuration
[2016-01-11 09:58:33][INFO] OS: CentOS release 6.5 (Final)
Kernel \r on an \m
[2016-01-11 09:58:33][INFO] Arch: x86_64

[2016-01-11 09:58:33][INFO] ==> Validation of given db password
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> Web server configuration checker version: 1.0.3

[2016-01-11 09:58:33][INFO] ==> Execution log dir: /usr/local/psa/tmp

[2016-01-11 09:58:33][INFO] ==> STEP 1: Checking for custom configuration templates...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 2: Checking for the JkWorkersFile directive in the Apache configuration...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 3: Checking associations between domains and IP addresses...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 4: Checking for corrupted reference between IP collections and IP addresses...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 5: Checking for links between APS applications and subscriptions...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 6: Checking for the Zend extension declaraion in php.ini...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 7: Check symbolic links for latest virtual host config files...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 8: Checking for system users home directories consistency...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 9: Checking for records with empty name field in the Configurations table...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 10: Checking for SElinux state...
[2016-01-11 09:58:33][WARNING] SElinux in enforced mode is detected. It might lead to failures in configs regeneration because of invalid contexts.
Please check http://kb.parallels.com/115299 for details.
[2016-01-11 09:58:33][INFO] Result: Warning

[2016-01-11 09:58:33][INFO] ==> STEP 11: Checking for nginx ULIMIT value...
[2016-01-11 09:58:33][INFO] Result: OK

[2016-01-11 09:58:33][INFO] ==> STEP 12: Checking for extra configurations in database not owned by any object...
[2016-01-11 09:58:33][INFO] Result: OK

Found errors: 0; Found Warnings: 1

i checked that fix in http://kb.parallels.com/115299
but after fixing and restart, the warning is still there...

I'm going to be nuts...

ah, and sorry for my bad english!
Thx again, man!

 

[trialotto]

@q4marc,

Some brief responses, after I have quoted some lines from your response.

what do you mean with "WP security settings? where i can find that in Plesk?

In the left (horizontal) menu, under "Server Management" there is "WordPress", i.e. the link to the WPT. Click on that link and select a domain and click on "Check Secuirty".

But all WP instances are installed with WPT, so i was wondering, taht it don't work directly with WPT.

Actually, the APS catalog is being used for installing WP instances, not the WPT. A small and barely relevant difference.

another question is: how can i check it, that MU#72 is installed?

If the result from the command "plesk version" shows "Update #74", then the micro-update 72 is already installed.

For a detailed analysis: run the command "find / -name microupdates" and it will give you the directory in which a subdirectory MU72 will be present.

why is there a update on this domain, while i don't have activated it? is there a specific file, that looks for update in WP?

From your response, I deduct that you have one troublesome domain, with the problem being (in short) an update conflict, even though you did not enable "autoupdate" in the WPT?

If the above is a correct summary, then there is one scenario that also explains the selinux notification and the permissions issue: a config customization in the troublesome domain.

In that case, you have an update setting in WordPress configuration files (with the value "true") and this will cause WP to update itself and all plugins and themes (!), resulting in

- plugin conflicts,
- theme conflicts,
- potential wrong permission structure,
- selinux notifications (you can ignore that for the time being, but these notifications are very likely)
- WPT errors (of various kinds)

You can check the one troublesome domain for custom update settings (i.e. the WP update settings) by

a) looking for

define( 'AUTOMATIC_UPDATER_DISABLED', true/false );

OR

define( 'WP_AUTO_UPDATE_CORE', true/false/minor );

in the wp-config.php file, (and)

b) looking for

add_filter( 'automatic_updater_disabled', '__return_true' );

OR

add_filter( 'auto_update.... ) (many filters of this form exist)

in the various php files.

In order to do the check in point b, just cd into the directory /var/www/vhosts/<troublesome domain>/httpdocs and run: grep -rin "add_filter( 'auto*" ./*

I certainly hope that you can find one of the custom update settings, since that would explain a lot.

Can you report back?

Regards.....

 

[Brujo]

Anyway, given the nature of your issues (i.e. wrong function calls in wp-config), can we mark your isses as "resolved"?

Well yes, for me it is now a known issue now - I informed the Customer and will see if he is willed to change if not I dont care and life with some broken instances on the WPT view...

 

[trialotto]

@Brujo,

You are right.....no worries!

 

[g4marc]

Hi,
sorry for that late feedback, but i checked anything else with tests, so i'm late!

@q4marc,


In the left (horizontal) menu, under "Server Management" there is "WordPress", i.e. the link to the WPT. Click on that link and select a domain and click on "Check Secuirty".

don't work for me, because of that path-issue of WPT! its still there!

Actually, the APS catalog is being used for installing WP instances, not the WPT. A small and barely relevant difference.

where i can find it on server-files? i still have that problem with deleted files on one of the WP-instances, so i have to upload these files to get webpage to work!
i checked database of plesk (wordpressinstanceld) and set forceUpdates to "false" - no difference!

there must be a cache-file where it is documented, witch instances are damaged or need to be updated, because every morning the wp-instance is incomplete!

From your response, I deduct that you have one troublesome domain, with the problem being (in short) an update conflict, even though you did not enable "autoupdate" in the WPT?

If the above is a correct summary, then there is one scenario that also explains the selinux notification and the permissions issue: a config customization in the troublesome domain.

In that case, you have an update setting in WordPress configuration files (with the value "true") and this will cause WP to update itself and all plugins and themes (!), resulting in

- plugin conflicts,
- theme conflicts,
- potential wrong permission structure,
- selinux notifications (you can ignore that for the time being, but these notifications are very likely)
- WPT errors (of various kinds)

checked with deleting all foreign plugins - no effect to that problem.

You can check the one troublesome domain for custom update settings (i.e. the WP update settings) by

a) looking for

define( 'AUTOMATIC_UPDATER_DISABLED', true/false );

OR

define( 'WP_AUTO_UPDATE_CORE', true/false/minor );

in the wp-config.php file, (and)

b) looking for

add_filter( 'automatic_updater_disabled', '__return_true' );

OR

add_filter( 'auto_update.... ) (many filters of this form exist)

in the various php files.

In order to do the check in point b, just cd into the directory /var/www/vhosts/<troublesome domain>/httpdocs and run: grep -rin "add_filter( 'auto*" ./*

I certainly hope that you can find one of the custom update settings, since that would explain a lot.

Can you report back?

Regards.....

found that in config.php:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

should be the correct setting to avoid autoupdate.

if i delete all wp-files and set the whole page to a fresh wp with all required plugins and theme, i'm afraid, that this work will be fruitless, because of an old cache-file, that overwrites my new files everytime...
for this reason, i have to know, where i can find this cache-file for deleting it. Obviously the files in that path: usr/local/psa/var/cache are not the right one. i deleted it allready, but without any difference...next morning, the webpage was crashed like every morning!

At all this trouble with this single domain, i would like to remind, that the WPT Path issue is'nt fixed on all my servers! since December 9. with the Update of WP instance to 4.4 it shows only "/httpdocs/" without the correct path to wp-instances!
i'm wondering about the fix with that MU#72, because it takes no effect to all my servers! i can't understand that!
so i need a soloution for this problem too...

thanks a lot

Marc