• 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

WordPress Security Check breaks Wordpress

H9k

Regular Pleskian
I have experienced this with Plesk 12.0 and now also with 12.5, so I thought maybe I should report this.
When I use the Security Check tool for Wordpress and I put the checkbox on "Security keys" and click on "Secure", it displays an error message. Then, the website does not work anymore, because wp-config.php is completeley blank, 0 bytes in size! So I need to restore that file from backup. Very annoying.
This affects basically all Wordpress installations on the machine, no matter which one I try, if I select to secure the security keys, the wp-config.php gets blank and breaks the site.
What can the problem be?
 
Btw, the error message I get is this one:

An error occurred while checking the administrator\'s username on the WordPress installation 'XYZ'. An error occurred while checking the database prefix of the WordPress installation 'XYZ'. Check the validity of the WordPress database parameters in the wp-config.php file. An error occurred while checking security keys of the WordPress installation 'XYZ'. An error occurred while checking if the WordPress installation 'XYZ' displays its version information. Make sure that all files have reading permissions.
Weird error that has nothing to do with security keys directly. In this particular case for example, admin username, database prefixes and version information are already secured and are working fine. Only thing missing to secure is security keys...
 
@H9k,
Have you tried to go to th detail's page of WordPress instance in WordPress Toolkit before you apply "Security Keys"? Have you any error messages there or everythins is fine?

Any way, please, enable debug log in plesk by using this article - http://kb.odin.com/en/120101. Of course, if it possible
Important!
Enable debug with the following settings:

; Enable logging of external utilities calls
show.util_exec = on

; Enable logging of stdin and stdout for external utilities calls (do not use in production environment)
show.util_exec_io = on

After that, try to apply 'security keys' checker again and see errors in log.
It will help us to understand a certain reason of this issue.
 
I have some feedback regarding the security check as well on the latest RTM 12.5. This has been a bug since Preview 12.5 to now.

Clicking check security and then checking "Permissions for files and directories" is hit or miss. More often than not, the installations installed by the WordPress toolkit never seem to process, meaning on a 2nd 3rd and other run, it still shows as a red !. This is been over many fresh installs on both CentOS 6 and 7.

SOmpyPS.png


To resolve, I have to manually SSH in and set permissions on files and directories.
 
Hi there. I can confirm what Ross_fisher says btw, also happens to me on Debian 7.
Anyhoo, I looked at the details of the Wordpress install but all is fine.
I enabled the debug and this is what I got:

[2015-09-08 19:40:15] DEBUG [util_exec] [9ae7af09ddad9ff93fa81c1e375630c2][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs security-keys are_keys_correct, stdin:
[2015-09-08 19:40:15] DEBUG [util_exec] [9ae7af09ddad9ff93fa81c1e375630c2][0] Finished in 0.82005s, Error code: 0, stdout:
[2015-09-08 19:40:15] DEBUG [util_exec] [874fd0a93f8e4e32383757ed71de9ff3][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs security-keys fix_keys, stdin:
[2015-09-08 19:40:16] DEBUG [util_exec] [874fd0a93f8e4e32383757ed71de9ff3][0] Finished in 0.21445s, Error code: 0, stdout: Success: Security keys were updated successfully.
[2015-09-08 19:40:16] DEBUG [util_exec] [95d7dc4f0cca00664b9d1657d95316d5][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs admin-username is-secure, stdin:
[2015-09-08 19:40:16] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'admin-username' 'is-secure'] with exit code [1]
[2015-09-08 19:40:16] DEBUG [util_exec] [95d7dc4f0cca00664b9d1657d95316d5][0] Finished in 0.06075s, Error code: 1, stdout: , stderr: {"err_code":0,"err_message":"Strange wp-config.php file: wp-settings.php is not loaded directly."}
[2015-09-08 19:40:16] ERR [1] PleskUtilException: '/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'admin-username' 'is-secure' failed with code 1.
[2015-09-08 19:40:16] DEBUG [util_exec] [55ef1d8038c5d] Starting: send-error-report /opt/psa/admin/bin/send-error-report 'warning'
[2015-09-08 19:40:16] DEBUG [util_exec] [55ef1d8038c5d] Finished in 0.0008s, Result: TRUE
[2015-09-08 19:40:17] DEBUG [util_exec] [a4351ef93fb6d274940b6d0a358760c2][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs db-prefix get, stdin:
[2015-09-08 19:40:17] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'db-prefix' 'get'] with exit code [1]
[2015-09-08 19:40:17] DEBUG [util_exec] [a4351ef93fb6d274940b6d0a358760c2][0] Finished in 0.06043s, Error code: 1, stdout: , stderr: {"err_code":0,"err_message":"Strange wp-config.php file: wp-settings.php is not loaded directly."}
[2015-09-08 19:40:17] ERR [1] PleskUtilException: '/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'db-prefix' 'get' failed with code 1.
[2015-09-08 19:40:17] DEBUG [util_exec] [55ef1d815980e] Starting: send-error-report /opt/psa/admin/bin/send-error-report 'warning'
[2015-09-08 19:40:17] DEBUG [util_exec] [55ef1d815980e] Finished in 0.0008s, Result: TRUE
[2015-09-08 19:40:18] DEBUG [util_exec] [bbfce47bfec7b8cb62d532ec7ea51c98][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs security-keys are_keys_correct, stdin:
[2015-09-08 19:40:18] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'security-keys' 'are_keys_correct'] with exit code [1]
[2015-09-08 19:40:18] DEBUG [util_exec] [bbfce47bfec7b8cb62d532ec7ea51c98][0] Finished in 0.05987s, Error code: 1, stdout: , stderr: {"err_code":0,"err_message":"Strange wp-config.php file: wp-settings.php is not loaded directly."}
[2015-09-08 19:40:18] ERR [1] PleskUtilException: '/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'security-keys' 'are_keys_correct' failed with code 1.
[2015-09-08 19:40:18] DEBUG [util_exec] [55ef1d8257d15] Starting: send-error-report /opt/psa/admin/bin/send-error-report 'warning'
[2015-09-08 19:40:18] DEBUG [util_exec] [55ef1d8257d15] Finished in 0.0008s, Result: TRUE
[2015-09-08 19:40:19] DEBUG [util_exec] [1c67a6baa0c9c6ef8d281b62d067c95f][0] Starting: wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs version-info is-secure, stdin:
[2015-09-08 19:40:19] ERR [util_exec] proc_close() failed ['/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'version-info' 'is-secure'] with exit code [1]
[2015-09-08 19:40:19] DEBUG [util_exec] [1c67a6baa0c9c6ef8d281b62d067c95f][0] Finished in 0.06139s, Error code: 1, stdout: , stderr: {"err_code":0,"err_message":"Strange wp-config.php file: wp-settings.php is not loaded directly."}
[2015-09-08 19:40:19] ERR [1] PleskUtilException: '/opt/psa/admin/bin/wpmng' '--user=foobar' '--php=/usr/bin/php5' '--' '--path=/var/www/vhosts/foobar.tld/httpdocs' 'version-info' 'is-secure' failed with code 1.
[2015-09-08 19:40:19] DEBUG [util_exec] [55ef1d835a607] Starting: send-error-report /opt/psa/admin/bin/send-error-report 'warning'
[2015-09-08 19:40:19] DEBUG [util_exec] [55ef1d835a607] Finished in 0.00082s, Result: TRUE
[2015-09-08 19:40:20] DEBUG [util_exec] [753bb194426635f3d0f3b6427a72b3ac][0] Starting: vhostmng-content , stdin: {"content":[{"cmd":"check-ac","basedir":"\/var\/www\/vhosts\/foobar.tld\/httpdocs","run_as_user":"foobar","run_as_group":"psacln","force":false,"dirs":[{"process":[],"source":".","destination":".","user":"foobar","group":"psacln","dir_perms":"755","file_perms":"644"}]}]}
[2015-09-08 19:40:20] DEBUG [util_exec] [753bb194426635f3d0f3b6427a72b3ac][0] Finished in 0.04067s, Error code: 0, stdout: ./wp-config.php.bak
[2015-09-08 19:40:20] ERR [panel] An error occurred while checking the administrator\'s username on the WordPress installation 'FooBar'.​

Now apparently security codes generated successfully says the log, but all I can say the wp-config.php file is empty. Also, why does it even start to do the other tasks?
All is green in my security check, and I only selected the security keys to be fixed.
What I can say about this install btw. is that I think it was not installed (like most installs) by Plesk, but I added it via scan method. Don't know if there is a difference...
 
@H9k,

Seems like, call
wpmng --user=foobar --php=/usr/bin/php5 -- --path=/var/www/vhosts/foobar.tld/httpdocs security-keys fix_keys
broke wp-config.php by somehow. This is not reproduced with default wp-config.php after WordPress installation (via WP Toolkit or manually). Is this config file was customized after intallation?
Also the file permissions could be a reason of this issue. They should be 600 and owned by customer which owns all other files in domain's httpdocs.

If permissions are Ok or the config was customized and it has private data which could not be published at this forum, please contact Odin Support Team for a deeply investigation.
http://talk.plesk.com/threads/impor...ution-for-the-existing-issue-question.334123/

Now apparently security codes generated successfully says the log, but all I can say the wp-config.php file is empty. Also, why does it even start to do the other tasks?

Other tasks starts because you need to get actual info about all checkers state after you applied some checker.

What I can say about this install btw. is that I think it was not installed (like most installs) by Plesk, but I added it via scan method. Don't know if there is a difference...

This is very useful info. It means that some WordPress files have wrong permissions and could be reason of this situation.
 
The permissions on the wp-config.php are correct: 0600 and owned by foobar.tld:psacln.
All files are owned by foobar.tld:psacln, and the security check says permissions are OK.
Here is the configuration file (anonymized of course):

<?php
/** Enable W3 Total Cache Edge Mode */
define('W3TC_EDGE_MODE', true); // Added by W3 Total Cache

/**
* Il file base di configurazione di WordPress.
*
* Questo file definisce le seguenti configurazioni: impostazioni MySQL,
* Prefisso Tabella, Chiavi Segrete, Lingua di WordPress e ABSPATH.
* E' possibile trovare ultetriori informazioni visitando la pagina: del
* Codex {@link http://codex.wordpress.org/Editing_wp-config.php
* Editing wp-config.php}. E' possibile ottenere le impostazioni per
* MySQL dal proprio fornitore di hosting.
*
* Questo file viene utilizzato, durante l'installazione, dallo script
* di creazione di wp-config.php. Non è necessario utilizzarlo solo via
* web,è anche possibile copiare questo file in "wp-config.php" e
* rimepire i valori corretti.
*
* @package WordPress
*/

// ** Impostazioni MySQL - E? possibile ottenere questoe informazioni
// ** dal proprio fornitore di hosting ** //
/** Il nome del database di WordPress */
//Added by WP-Cache Manager
define( 'WPCACHEHOME', '/var/www/vhosts/foobar.tld/httpdocs/wp-content/plugins/wp-super-cache/' ); //Added by WP-Cache Manager
define('DB_NAME', 'foobar_db');

/** Nome utente del database MySQL */
define('DB_USER', 'foobar_user');

define('DB_PASSWORD', 'Abcd0!12');
/** Password del database MySQL */

/** Hostname MySQL */
define('DB_HOST', 'localhost');

/** Charset del Database da utilizare nella creazione delle tabelle. */
define('DB_CHARSET', 'utf8');

/** Il tipo di Collazione del Database. Da non modificare se non si ha
idea di cosa sia. */
define('DB_COLLATE', '');

/**#@+
* Chiavi Univoche di Autenticazione e di Salatura.
*
* Modificarle con frasi univoche differenti!
* E' possibile generare tali chiavi utilizzando {@link https://api.wordpress.org/secret-key/1.1/salt/ servizio di chiavi-segrete di WordPress.org}
* E' possibile cambiare queste chiavi in qualsiasi momento, per invalidare tuttii cookie esistenti. Ciò forzerà tutti gli utenti ad effettuare nuovamente il login.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');

/**#@-*/

/**
* Prefisso Tabella del Database WordPress .
*
* E' possibile avere installazioni multiple su di un unico database if you give each a unique
* fornendo a ciascuna installazione un prefisso univoco.
* Solo numeri, lettere e sottolineatura!
*/
$table_prefix = 'nAc4rLp_';

/**
* Per gli sviluppatori: modalità di debug di WordPress.
*
* Modificare questa voce a TRUE per abilitare la visualizzazione degli avvisi
* durante lo sviluppo.
* E' fortemente raccomandato agli svilupaptori di temi e plugin di utilizare
* WP_DEBUG all'interno dei loro ambienti di sviluppo.
*/
define('WP_DEBUG', false);

/* Finito, interrompere le modifiche! Buon blogging. */

/** Path assoluto alla directory di WordPress. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Imposta lle variabili di WordPress ed include i file. */
require_once(ABSPATH . 'wp-settings.php');
 
@H9k, sorry for delay.

I have checked your config on test environment and reproduce the problem.
After it i installed an italian WordPress (latest version 4.3.1 - https://it.wordpress.org/) manually, configured it and applied 'Security keys' checker. The checker applied successfully and wp-config.php wasn't broken. You can test it in your's environment.
The problem is in an invalid UTF-8 sequences / codepoints in your wp-config.php.
What versions of WordPress are broken on your machine?

I've created a bug which will be fixed in further releases (microupdates)
 
Last edited:
No problem.
Yeah, I can confirm, the problem is with non-utf8 wp-config.php files. If I convert the file from ANSI to UTF8 using notepad++, without changing any content, then the security keys checker does not fail and does not destroy the file anymore.
 
I have some feedback regarding the security check as well on the latest RTM 12.5. This has been a bug since Preview 12.5 to now.

Clicking check security and then checking "Permissions for files and directories" is hit or miss. More often than not, the installations installed by the WordPress toolkit never seem to process, meaning on a 2nd 3rd and other run, it still shows as a red !. This is been over many fresh installs on both CentOS 6 and 7.

SOmpyPS.png


To resolve, I have to manually SSH in and set permissions on files and directories.
I have the same problem !!! Permissions for files and directories (?) .... always RED... I had CentOS7.1 with 12.5.30MU4
 
@Reqlez,

please, check your config for a invalid UTF8 sequences / codepoints in wp-config.php of your's WordPress instances.
 
Hello, I have the same issue as ross fisher... i check that all my wp-config.php files are encoded in UTF-8 in notpad ++ and i am still getting this:

SOmpyPS.png


any solution please?
 
Just to add, if i create a new wordpress installation it all works fine and no issues with the security check, i get all green checks on all of them

however, to import other wordpress, what i did is install wordpress from plesk with the wordpress toolkit and then use FTP to upload and overright the file, (an import the database of course) those are the wordpress installation that are always with the red dot, on the secutiry check, all is good except the file permissions... (granted, i doubled check the UTF-8 encoding on the wp-config.php files and they are UTF-8)

what could I be missing please? thank you
 
chmod -R a=r,a+X,u+w /var/www/vhosts/example.com/httpdocs/

Run that one, after that security check file permission will be ok.
 
thank you bulent, can you please provide a breif explanation of this approach? thank you (i am always hesitant to use chmod unless i fully understand what it is doing. note that before i do that, all the files are 664 the wp-config is 600 and all directories are 755... as it is now and the security check is still reporting the red exclamation mark
 
on other thing, there is one site that the fifth's security check from the top "Security Keys" is also stuck on the red exclamation dot. thank you
 
I think I know what the problems of the permissions is.
If you set permissions like so:
find ./ -type d -exec chmod 755 {} \;
find ./ -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

the warning should go away. However, there are some plugins that generate temporary files with the wrong permissions, so that warning might pop up again.
But it seems that Plesk is sometimes unable to fix the permissions. If done with the above commands in shell it works fine. Perhaps Plesk just removes some permission bits and does not set 755/644 explicitly? Dunno... What I know for sure is that it used to work more reliably in 12.0.
 
To chime in here, I had this issue today with Plesk Onyx.

I have been having problems with this feature which, despite multiple attempts to fix, each time I run the file permissions fix on Wordpress it just comes back. When I would update multiple Wordpress sites at once, the number of sites displayed which still had this problem would change every time I would fix it.

Turns out the culprit was the Wordfence plugin, which generates some PHP files in wp-content/wflogs/ with permissions 660 instead of 664, they are re-written pretty much constantly as a fast database or something:
Code:
-rw-rw---- 1 puser psacln  40083 Nov  3 21:31 attack-data.php
-rw-rw---- 1 puser psacln 123543 Nov  4 08:16 config.php
-rw-rw---- 1 puser psacln   1131 Nov  3 10:08 ips.php
-rw-rw-r-- 1 puser psacln  87660 Nov  4 08:16 rules.php

Here's a question/suggestion: Is there any way to set the permissions even more strictly? I'm thinking 750 for directories and 640 for files, ideally, although I'm uncertain how compatible those settings are with the FastCGI plugin.

Ideally, it would be nice to configure a file security profile for each Wordpress site, as I have certain sites which run older versions of certain themes which really do not work with the Plesk Wordpress plugin, specifically ones which have scripts inside of the theme uses for dynamically resizing images, etc.

But here's the code to run in your Wordpress home directory to lock it down:
Code:
find . -type f -print0 | xargs -0 chmod 644
find . -type d -print0 | xargs -0 chmod 755
chmod 600 wp-config.php
 
Back
Top