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.
Update: Continue on to the comments, Kraft provides some valuable feedback both on the confusing 3.4.3 diff and XML-RPC.
Quick note re the 3.4.2…3.4.3 diff: The only change released was adding escaping in the module listing. Unrelated, there had been an upcoming events widget that had been intentionally held back when shipped to SVN for a few versions.
It wan removed from Git as it was confusing having it when it wasn’t actually in the released version of the plugin, which is picked up by that diff.
Thanks for clarifying, Kraft.
That’s what confused me and precisely the reason I was hedging when discussing it.
Regarding XML-RPC and Stats, Stats does depend on that code. The post title, ID, author, etc is synced with WP.com as that stats calculation occurs on our end as well as the option to view stats via WP.com.
Doesn’t change your point though. :-)
I’m not sure that’s a user feature – seems like more of a developer feature to me. I mentioned it briefly in my post, users don’t (and shouldn’t) care about the particulars of the code their site is running, just that it does what they want it to.
Yes, and no. A security issue in an extension would affect fewer sites, because not everyone would have that extension installed. On the other hand, a security issue in a popular dependancy would have a greater effect, in much the same way a security issue in core does.
I see this very much as a user feature, including (effectively) orphan code because dependancies are hard opens the user to bugs they may not be exposed to otherwise. The user doesn’t care until they very much do because a zero-day issue has been exploited.