[wp-trac] [WordPress Trac] #60504: Plugin dependencies: Account for mu-plugin as dependency

[WordPress Trac]

#60504: Plugin dependencies: Account for mu-plugin as dependency
----------------------------------------+---------------------
 Reporter:  johnbillion                 |       Owner:  (none)
     Type:  defect (bug)                |      Status:  new
 Priority:  normal                      |   Milestone:  6.5
Component:  Upgrade/Install             |     Version:  trunk
 Severity:  critical                    |  Resolution:
 Keywords:  needs-testing dev-feedback  |     Focuses:
----------------------------------------+---------------------
Changes (by costdev):

 * keywords:  needs-testing => needs-testing dev-feedback


Comment:

 @johnbillion Thanks for opening this ticket!

 Indeed, Must-Use plugins were not considered valid dependencies in the
 Plugin Dependencies feature (going back aways in the discussions).
 However, you raise a valid issue if a site already has a plugin in its
 Must-Use plugins that becomes a dependency of a plugin in the Plugins
 repository.

 So, it's possible that said plugins could just be moved to the `mu-
 plugins` folder along with the Must-Use dependency. However, Must-Use
 plugins may be installed by hosts/developers. Any other plugin can be
 installed by a site owner/developer/administrator, so that doesn't seem
 like a feasible approach.

 So, currently, the following things would need to be done, at least:

 === Core patch
 1. Move the initialization of Plugin Dependencies until after `do_action(
 'muplugins_loaded' );` so that the Must-Use plugin's "loader" file can
 tell Core what its filename is via the `wp_plugin_dependencies_slug` hook.
 2. Ensure all calls to `get_mu_plugins()` and `get_plugins()` ''update''
 the `plugin_data` option, rather than replace it (as is currently done in
 `get_plugins()`.
 3. Add a new `$mustuse_plugins` property to `WP_Plugin_Dependencies`.
 4. In `WP_Plugin_Dependencies::get_plugins()`, store `get_mu_plugins()` in
 the new `$mustuse_plugins` property, and ensure these are also merged into
 `self::$plugins` to avoid several `array_merge( self::get_plugins(),
 self::$mustuse_plugins )` calls elsewhere.
 5. In `WP_Plugin_Dependencies::sanitize_dependency_slugs()`, add
 `(\.php)?` to the regex.
 6. In `WP_Plugin_Dependencies::has_unmet_dependencies()` make the
 `foreach()`'s internal condition:
 7. In `WP_Plugin_Dependencies::convert_to_slug()`, don't replace `'.php'`
 with `''` anymore. Instead, just `trim( $plugin_file, './' )` to remove
 potential `./file.php` or `../../../file.php` entries.

 {{{#!php
 <?php

 if (
         ! isset( self::$mustuse_plugins[ $dependency ] ) &&
         ( false === $dependency_filepath || is_plugin_inactive(
 $dependency_filepath ) )
 ) {
         return true;
 }
 }}}
 8. Test updates.
 9. Additional tests to cover Must-Use plugins.

 === Site owners/Hosts/Developers
 1. As Core has no way to know the name of the "loader" file used for the
 Must-Use plugin, add a filter to your loader file to let Core know the
 filename.

 {{{#!php
 <?php

 add_filter(
         'wp_plugin_dependencies_slug',
         function ( $slug ) {
                 if ( 'woocommerce' === $slug ) {
                         $slug = basename( __FILE__ );
                 }
                 return $slug;
         }
 );
 }}}

 I've done the above and done some manual testing locally, and this seems
 to work fine, though I can't say I've fully tested the approach in such a
 short period of time.

 -----

 This is likely going to need some discussion, so pinging @afragen,
 @pbiron, @azaozz and @desrosj to get in on this too if they have the time.

 @knutsp Can you add some detail about how you think the Text Domain will
 need to play a part here? Thanks!

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