Broken symlinks prevent updates

[joemoto]

Soon after cPanel updated EasyApache 4 (EA4) (ea-php-cli-1.0.0-3.3.1.cpanel.x86_64) to use caching (a faster way to select the PHP executable, such as php-cli), I noticed some failed plugin updates. If appears that updated cPanel servers now create ".ea-php-cli.cache" broken symbolic links in the directory where a PHP script was executed by CLI (such as a CRON job or manual call). The links are to a fake target (such as "ea-php71"), which is used by the perl script to select the executable.

I already submitted ​https://github.com/CpanelInc/php-cli/issues/2 to cPanel, and already received a response. The author of the pull request ​https://github.com/CpanelInc/php-cli/commit/883e8f1f3f37998d4501de4d4276c8a9d290fae3 may be changing how it caches; possibly creating the cache files in the "~/.cpanel" directory and cleaning up the littered files in the users' web directories.

I have a working fix for WordPress, that I will attach in a moment. The cause and effect is not limited to cPanel and WordPress, and the issue should be fixed on both sides.

To replicate:

1. Have WordPress 5.0.3 installed on a cPanel server that has ea-php-cli-1.0.0-3.3.1.cpanel.x86_64 installed. -- You can check using rpm -q ea-php-cli-1.0.0-3.3.1.cpanel. Also '/usr/local/bin/php' is a text (perl) file, and not a binary/executable.
2. Login into SSH/CLI and call any PHP file in a plugin, such as php wp-content/plugins/akismet/class.akismet-cli.php.
   1. You should then see a broken symlink in the "wp-content/plugins/akismet/" directory.
3. Change the version number in the main plugin file "wp-content/plugins/akismet/akismet.php" to something lower, such as "4.0".
4. Go to the WordPress >> Updates page and try to update the plugin.
   1. You will see an error "An error occurred while updating Akismet: The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions. .ea-php-cli.cache"
5. You can delete the symlink or apply the patch, and the update will be successful.

[joemoto]

cPanel has fixed the issue in ​https://github.com/CpanelInc/php-cli/issues/2 , but the symlink issue should still be handled by the WordPress filesystem classes.

[Palijn]

Hi, trying to resurrect this bug as it apparently has never been fixed, although a patch exists here.

Context : I am trying to update the MailPoet extension (more than 600000 active installs).
However, the extension suggest that if one does not want (or cannot) rely on the WordPress Cron, it is possible to run from the linux cron the .php file that lies in the mailpoet extension folder.
When installed under a cPanel setup, each run will generate the dreaded .ea-php-cli.cache symlink that will make the extension update fail.
The only way out then is to

rm .ea-php-cli.cache

and update the extension after having disabled the crontab entry (because Mailpoet suggests to run it every 1 min , which is probably never enough to actually update the extension before the next link generation !)

Wordpress properly handling the symlink on extension update, whatever the way, would be a godsend !
Thanks for your attention

[costdev]

Hi @Palijn, if you can you test the changes in 46040.diff and confirm whether the issue is resolved for you, that would be great to help this ticket move forward. 🙂 Thanks!