Forwarded to devs WP Toolkit Restore function throws cosmetic errors when proc_open/proc_close are disabled in PHP

[Bitpalast]

Username:

TITLE

WP Toolkit Restore function throws cosmetic errors when proc_open/proc_close are disabled in PHP

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

18.0.70 #2
Alma

PROBLEM DESCRIPTION

When proc_open/proc_close PHP functions are disabled, the WP Toolkit "restore" throws an error. It does restore the website, but the error is shown, so it seems to be cosmetic only.

STEPS TO REPRODUCE

1. Create a Wordpress website or register an existing one with WP Toolkit.
2. Make a backup using the "backup" function of WP Toolkit.
3. Restore.

ACTUAL RESULT

EXPECTED RESULT

Show no errors.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Sebahat.hadzhi]

Thanks for the report, Peter. I am unable to replicate the error. What's the PHP version and handler you are using?

 

[Bitpalast]

PHP 8.3.22, in the "additional PHP directives" section, add disable_functions = proc_open,proc_close

 

[Sebahat.hadzhi]

Thank for the update. The functions are disabled (checked with phpinfo). I deleted some tables and files prior to the restoration, switched the language to German, but still I am unable to reproduce the error. What's the MariaDB/MySQL version you are running?

 

[Bitpalast]

MariaDB 10.11.13, but that should not influence anything.
Maybe the issue is caused by a plugin or theme, e.g. that after a restore some "after_restore" function is triggered in Wordpress?

 

[Sebahat.hadzhi]

It could be. I tried disabling the functions globally and still no such error:

[root@10-69-43-55 ~]# /opt/plesk/php/8.3/bin/php -i | grep disable_functions
disable_functions => proc_open,proc_close => proc_open,proc_close

Would you mind testing that on a default WordPress installation?

 

[Bitpalast]

I was able to reproduce the issue on a test server. That test server runs a default Alma 8, an (almost) default Plesk installation. I created a test domain, then a default Wordpress installation from the WP Toolkit, then backed up, then restored. The restore showed the same error that the customer reported (on another machine). As it's on a test machine I can offer access if support wants to check it on the machine, but I'd need a ticket for it (and for the test machine I don't have a paid support contract).

 

[Sebahat.hadzhi]

Thanks, Peter. I opened a new internal report, so our team can double-check in case I am missing something. If they are also unable to reproduce the error it will be best if you can provide us with access to narrow down the reason.

 

[Sebahat.hadzhi]

Our engineers were also unable to reproduce the issue. If you can open a ticket so that can be checked directly on the machine it will be great. The reference id of the internal case is PPS-17982.

 

[Bitpalast]

Confirmed bug as EXTWPTOOLK-13356
Workaround: Restore the backup without the "Delete existing data before restoring" option.
While testing, we noticed that this issue only occurs when the newly added "Delete existing data before restoring" option is marked.
If you leave this option unchecked, the restore will work flawlessly.
Please keep in mind that restoring a backup with the "Delete existing data before restoring" option marked and the proc_open and proc_close functions disabled will restore only the FTP content, the database will be left intact and its contents will not be restored.
Optional: Temporarily enable the proc_open and proc_close functions.