Ryan McCue has started a discussion around plugin dependencies in WordPress, Gary Pendergast has responded. Ryan thinks it needs to be solved, Gary doesn’t – but if he did, would solve it a different way.
As a user, I don’t want to be exposed to security issues in orphaned code.
Each of them go into some technical details, some of which I understand, others which go over this front-end developers head. I was going to leave the following as a comment on Gary’s post, but it strayed a little off topic so I decided to post it here:
I’m going to cut to the chase, this discussion often resolves around Jetpack and to a lesser extent WPSEO. Each handle dependencies in different ways, Jetpack became a mega-plugin while WPSEO keeps the extensions as separate plugins.
Advanced Custom Fields needed to deal with this issue too, it started by following the WPSEO model but switched to the Jetpack model because – I understand – dealing with compatibility between different versions of the plugins hampered the development.
ACF demonstrates the problem with mega-plugins nicely: a developer convenience is overriding the user’s interests. As developers, we should be placing the interests of the user first.
Plugin dependencies allow the user to avoid running code they don’t require. If a user only runs Jetpack stats, they don’t need to XML-RPC authentication running on their site*, they don’t need to be exposed the the security issue in Jetpack 2.9.2 (see diff on Github).
I’m in this position, I run Jetpack exclusively to use the stats module. On this site, XML-RPC authentication is effectively orphan code.
Dependencies in core will limit exposure to potential security issues, how it’s solved I’ll leave to the PHP developers.
* I think. The diff for 3.4.2 to 3.4.3, another security release auto-updated appears to include a mis-tagging, so I’ve left it out. It looks like the bug was in the modules listing, something a user does not need under the dependency model.