Plugin dependencies

Basically, I think WP core would benefit greatly from introducing some sort of dependency configuration for plugins to register themselves so that WP core can selectively load only those plugins necessary for certain functions.

What dependencies? Core updates should not be beholden to plugins or themes. It’s the other way around.

Core WordPress bends over backwards for old function compatibility.

if you happen to have an average number of plugins installed

Do you mean 80 plugins? ??

Number of plugins installed should not be a consideration for updating code: it should all work and usually does.

I could debug and disable plugins myself, but what if the worst offenders are woocommerce and WP widgets (core) based on my xdebug profile? I’m pretty sure I shouldn’t need all of my plugins to query attachments via Ajax..

When in doubt, disable all plugins first. That way you’ll upgrade and then can find out immediately after if you’ve a problem when you activate your plugins.

If there is then you’ll need to do that debug work anyway. Some of the core updates are “UPDATE OR YOUR INSTALLATION WILL SUFFER HUGE” (Invader Zim reference).

This particular setup currently has 60.. and like I said two seemingly big culprits based on my testing were woo, and the setup code path for the WP widgets system.. both of which probably have no interest in manipulating the query attachments Ajax call anyway.

Perhaps I misspoke when I said dependency – I mean there must be a better way for WP to handle plugins than to load *everything* even when most of them aren’t needed … It’s wasted resources. For example, a way to load only those plugins which have an interest in the various actions and filters that we can know will be called for a given request.

It’s definitely a difficult problem, but I think it is something that would make WP a more mature platform than it is now.

For example, a way to load only those plugins which have an interest in the various actions and filters that we can know will be called for a given request.

That’s the problem.

How do you know what filters, actions, etc, that a plugin will use without actually loading that plugin to find out? The only way that I can think of is to have another digest file that lists all of those out, and that’s a very bad way to do things. Just from what I know I do myself, what happens when a developer forgets to add an action to that file? Or misspells a filter name?

The only “real” way around this is using the newer PHP feature of class namespaces and autoloading. That would help to a point, but not completly. You would still have to load the plugins base code in order for WordPress to know that it’s there, but then the plugin )or theme) could load the various classes that it needs on demand rather then all at once. The biggest issue with that is that namespaces wehre introduced in PHP 5.3, and WordPress is backwards compatible to 5.2. There’s also a lot of hosting companies out there still stuck on 5.2 in their servers, so having something like that still has a very high chance of breaking a whole heap of sites around the world.

Yeah,namespaces and autoloading is probably the correct solution and I can see it is not going to happen until 7+ is more heavily adopted (or like you said at least 5.3+)..

What about a way for the admin to control what plugins can be loaded for a particular route? That would seem to be a way to make the regex route system more robust and add a way to control plugins ostensibly via the admin.. That can also help with security since right now, any plugin can do anything it wants..