Make WordPress Core

Opened 5 years ago

Last modified 20 months ago

#46040 new defect (bug)

Broken symlinks prevent updates

Reported by: joemoto's profile joemoto Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.0.3
Component: Upgrade/Install Keywords: has-patch needs-testing
Focuses: Cc:


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 to cPanel, and already received a response. The author of the pull request 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.

Attachments (2)

46040.patch (4.7 KB) - added by joemoto 5 years ago.
46040.diff (5.2 KB) - added by joemoto 5 years ago.

Download all attachments as: .zip

Change History (7)

5 years ago

This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.

5 years ago

5 years ago

#2 @joemoto
5 years ago

cPanel has fixed the issue in , but the symlink issue should still be handled by the WordPress filesystem classes.

#3 @SergeyBiryukov
3 years ago

  • Component changed from General to Upgrade/Install

#4 @Palijn
21 months ago

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

#5 @costdev
20 months ago

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!

Note: See TracTickets for help on using tickets.