[wp-trac] [WordPress Trac] #15134: WordPress should not try to remove themes or plugins recursively if the directory is a symlink

[WordPress Trac]

#15134: WordPress should not try to remove themes or plugins recursively if the
directory is a symlink
-------------------------------------+-----------------------
 Reporter:  vladimir_kolesnikov      |       Owner:  pbiron
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  6.0
Component:  Upgrade/Install          |     Version:
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+-----------------------

Comment (by jqz):

 This has become more of an issue now automatic plugin/theme updates are an
 option, and now that on occasion a plugin author may choose to force an
 update to patch a security vulnerability even if automatic updates are
 disabled - see https://github.com/woocommerce/woocommerce/issues/32111 -
 this can lead to a broken site that could go undetected for days.

 Replying to [comment:1 Denis-de-Bernardy]:
 > Seems to me that this is a use-case where site admins shouldn't be
 allowed to upgrade plugins, and where all installs should be maintained
 from the shell using svn, git, or scripts.

 No, it is possible have some common plugins symlinked, whilst others are
 updated in the usual WordPress way.

 > The risk is quite huge in that setup: only one site gets put on
 maintenance mode, even though the plugin update could be affecting dozens
 of sites.

 I disagree.  `plugins/some-plugin/` can symlink to `~/shared-plugins/some-
 plugin/` which in turn symlinks to `~/shared-plugins/some-plugin-1.0/`.
 Then to upgrade it is only necessary to relink `~/shared-plugins/some-
 plugin/` to `~/shared-plugins/some-plugin-1.1/`.  There is no downtime at
 all and therefore no need for maintenance mode.

 There is a very small risk that any HTTP requests in progress at the time
 of the relinking may end up parsing newer versions of any PHP files it
 hadn't already parsed.  However, that and other problems could happen
 anyway with the normal WordPress update procedure if a separate process
 was in the middle of serving an HTTP request at the time the update was
 triggered.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/15134#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform