• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

WP Toolkit cloning fails, same symptoms as in EXTWPTOOLK-456 (formerly resolved 03/31/2017)

Bitpalast

Plesk addicted!
Plesk Guru
TITLE:
WP Toolkit cloning fails, same symptoms as in EXTWPTOOLK-456 (formerly resolved 03/31/2017)
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Onyx 17.8 #40
WP Toolkit 3.6.0-1601
CentOS 7.6
PROBLEM DESCRIPTION:
Please see EXTWPTOOLK-456 and user ticket case #154684.

On all of our 17.8 #40 installations with WP Toolkit release 3.6.0-1601 the WP Toolkit cloning function fails with

"Unable to check database. Error message: Cannot do 'run_mysql_command': The PHP functions `proc_open()` and/or `proc_close()` are disabled. Please check your PHP ini directive `disable_functions` or suhosin settings."

panel.log entry:

[2019-02-23 08:37:00.581] ERR [1] '/usr/local/psa/admin/bin/filemng' '<webspace user account>' 'exec' '/var/www/vhosts/<subscription>/<domain>' '/opt/plesk/php/7.2/bin/php' '-d' 'safe_mode=off' '-d' 'display_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-c' '/var/www/vhosts/system/<domain>/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/<subscription>/<domain>' 'db' 'check' '--quick' '--silent' failed with code 1.

stdout:

stderr:
Cannot do 'run_mysql_command': The PHP functions `proc_open()` and/or `proc_close()` are disabled. Please check your PHP ini directive `disable_functions` or suhosin settings.
{"err_code":true,"err_message":"Cannot do 'run_mysql_command': The PHP functions `proc_open()` and\/or `proc_close()` are disabled. Please check your PHP ini directive `disable_functions` or suhosin settings."}​
STEPS TO REPRODUCE:
Create a Wordpress instance or use an existing instance.
Click the "Clone instance" button.​
ACTUAL RESULT:
"Unable to check database. Error message: Cannot do 'run_mysql_command': The PHP functions `proc_open()` and/or `proc_close()` are disabled. Please check your PHP ini directive `disable_functions` or suhosin settings."​
EXPECTED RESULT:
Ignore proc_open and proc_close settings. These must not be used, because in shared hosting environments these functions must always stay disabled in subscriptions.​
ANY ADDITIONAL INFORMATION:
Reinstallation of current patches did not resolve it. Also reported in user ticket #154684.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Confirm bug
 
Yes, it was resolved in an update on Saturday/Sunday night from WP Toolkit 3.6.0-1601 to WP Toolkit 3.6.0-1603. At the time when I filed the report the issue existed, but fortunately it was quickly solved.

It seems however, that there are some other new issues that that update brought in (Issue - WordPress Toolkit update disaster).
 
We now get this message when cloning:

Unable to check database. Error message: mysqlcheck: Got error: 1045: Access denied for user 'xxxxxx'@'xxxxx' (using password: YES) when trying to connect

panel.log

[2019-02-27 23:09:25.693] ERR [1] '/usr/local/psa/admin/bin/filemng' '<webspace user account>' 'exec' '/var/www/vhosts/<subscription>/<domain>' '/opt/plesk/php/7.2/bin/php' '-d' 'safe_mode=off' '-d' 'display_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-c' '/var/www/vhosts/system/<domain>/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/<subscription>/<domain>' 'db' 'check' '--quick' '--silent' failed with code 2.

stdout:

stderr:
mysqlcheck: Got error: 1045: Access denied for user 'dbuser'@'::1' (using password: YES) when trying to connect
 
Last edited:
reset/changing the password does not help.

But it would be no solution now suddenly for hundreds / thousands of database users to reset the password.
 
@moswak Could you please open a new thread for your issue? It is something completely different than what is described in this thread.
 
Back
Top