[wp-trac] [WordPress Trac] #57386: Add filter to WP_Upgrader::install_package for copy_dir()

[WordPress Trac]

#57386: Add filter to WP_Upgrader::install_package for copy_dir()
-----------------------------+--------------------------
 Reporter:  afragen          |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  6.2
Component:  Upgrade/Install  |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  performance
-----------------------------+--------------------------

Comment (by afragen):

 Replying to [comment:21 azaozz]:
 > Thanks, I think I understand the problem here better now.
 >
 > > VirtualBox users should not have to make any changes to work around
 core.
 >
 > I agree. It is unfortunate that this bug hasn't been fixed in VB. If I
 understand how this works (looking at
 https://www.virtualbox.org/ticket/8761#comment:24) seems it would be very
 hard to trigger the bug. For this two directories with identical names
 will have to be moved, and the first has to be moved to the exact spot
 where the second was. Then if a file that exists in both directories is
 deleted in the first directory (that now occupies the spot where the
 second directory was), it gets deleted in the second directory.

 It doesn't seem to be hard to trigger the bug from VirtualBox. It seems to
 happen more consistently when a VB user is updating plugins that are large
 with a complex folder structure.

 Much of the issues with VB have been documented in the following
 locations. I'm sorry, but it's a lot. If you follow the Rollback testing
 call to action and you are using a VB environment you will likely
 encounter it.

 https://core.trac.wordpress.org/ticket/51857
 https://github.com/WordPress/wordpress-develop/pull/2225
 https://make.wordpress.org/core/2022/06/26/rollback-feature-testing-call-
 to-action/
 https://github.com/costdev/wp-virtualbox-testing

 > Wondering if VirtualBox can be detected from PHP running in the guest
 OS? Tried searching the web but no clear answer. Seems it may be possible,
 for example looking at the video card (or other hardware) manufacturer
 string. If yes, I wouldn't be opposed to having a separate function to
 detect it.
 >
 > Then it will be possible to use the new `move_dir()` by default, and
 this filter won't probably be needed.

 You will find in the above discussions as well as a long back scroll
 through #core-upgrade-install, that detecting when someone is using VB is
 likely impossible.

 > Another, "last resort" solution may be to "hide" the new `move_dir()`
 functionality inside one of the rollback functions and use it only for
 rollbacks. Not ideal but will avoid triggering the VB bug. The advantage
 is that it will work for "everybody" out of the box.

 The filter is where `move_dir()` is ''hidden'' from users who don't opt-
 in.

 The point of these separate tickets for the `WP_Upgrader::install_package`
 filter and adding `move_dir()` was to move away from the imposed testing
 requirements of Rollback as defined/discussed in #51857.

 I'm hoping the Faster Updates plugin and the inclusion of a filter might
 be able to allow VB users to use `move_dir()` without issue. More testing
 of that can more easily be done post-commit.

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