Introduce slug-specific hooks to manage plugin loading order

[schlessera]

As already discussed in #41346, I'd like to propose a simple mechanism that can solve the loading order problems that inter-dependent plugins can have.

The main mechanism just adds an action that is named after the plugin that was just loaded. In this way, other plugins are able to initiate actions based on when another plugin was loaded.

A similar mechanism has been used in WP-CLI to solve the problems in the loading order of commands that rely on each other. You can read more about how commands can control their loading order here: ​https://make.wordpress.org/cli/2017/05/03/managing-command-dependencies/

Furthermore, this also allows for a small extension that can automatically resolve loading order, provided it knows about the dependency to look for. This is used in WP-CLI as well, where it is easy to deduce the parent command to look for, as described here: ​https://make.wordpress.org/cli/2017/05/31/command-dependencies-revisited/. For plugins, this could be solved by adding a simple plugin slug to the plugin header. I'll introduce a separate ticket to that regard.

I will upload a patch that adds the above-mentioned action, together with pre_plugin_loaded and post_plugin_loaded actions that give further control to plugins.

In case anyone wonders whether that might open the door to abuse and have plugins block loading of other plugins: that is already easily possible right now. A plugin can just remove whatever plugins it dislikes from the list of active plugins on activation hook.

[schlessera]

Initial implementation (with simple & naïve plugin name detection)

[Bueltge]

@schlessera Have you seen the comment on the initial issue in this context from @ChriCo ?

https://core.trac.wordpress.org/ticket/41346#comment:11

I mean also to that we get more solid surface for the hook instead of plugin_loaded_{$plugin_slug}, like do_action( "plugin_loaded", $plugin, $plugin_slug );

[ChriCo]

Wouldn't it be better, when we're talking about "Plugin A depends on Plugin B", to define something similar to the Script/Style API to define "depends_on"?

Also, - just some throw ins to this topic - instead of introducing new (dynamic) hooks, which are hard to document and rely on, wouldn't it better to create some improved code with e.G. Plugin_Registry, Plugin_Configuration, ...? This would also benefit by providing more information to the plugin bootstrap itself and maybe also moving the definition of plugin configuration data via docblock (get_plugin_data) to some more performant implementation.