It’s been a while since I last posted something about the whole dependencies horror that I’m still trying to deal with in the WordPress ecosystem. Justin Sternberg’s post on the future of the CMB2 library got the discussion going again and soon after, we were at the dependencies discussion again.
It was mainly the discussion about overhead in bundling code that made me want to write a long reply, because I disagree with this quote:
What I hate is seeing someone use cmb2 when their own plugin is ten lines. But that’s them not understanding libraries and weight.
This post started as a comment on Justin’s blog post, but I figured it would make a lot more sense as a post on my own blog as it covers a lot more than Justin’s initial question about CMB2. Here goes… Continue reading Bundling libraries is not overhead, it’s a best practice
The video of my presentation about the Love-Hate Relationship Between Composer and WordPress at WordCamp Netherlands this year has been published on WordPress.tv:
You can find the slides on Speakerdeck. It was a great audience with some really good questions that have given me plenty of food for thought regarding the whole subject. It’s too much to cover in this post, so I’ll be going in some more detail in separate posts soon. I think there is a bright future for Composer in the WordPress ecosystem, there are some things that need to change first though.
There is a lot of confusion in the WordPress ecosystem when it comes to the issues around bundling dependencies. Peter Suhm has published a detailed post about this exact issue: A Warning About Using Composer With WordPress, where I have left the following (partial) comment:
So imagine both of us loading library x in our plugins, both requiring a version that’s incompatible with each other. No matter how well tested your plugin is, if I get a chance to load my autoloader before yours, I can load a version of the library that is not compatible with yours and your plugin will break (at least, the end user will see it like that and the horror of finding the culprit begins)…
This obviously is not a Composer issue, but related to the way WordPress loads its plugins. It’s also not a well known issue, since Composer isn’t used a lot in the WordPress ecosystem (yet!), especially not in distributed plugins. But as Composer becomes more used, more collisions like this will happen. Without a proper dependency management system in place, this is really hard to solve.
My WordPress Composer Installer proof of concept is as close to solving this issue as I’ve ever been. If there is anyone more experienced with the plugins installer in WordPress and maybe knows their way around Composer as well, I could use some help. 🙂
We’ve been telling customers to always be on the latest and greatest version of everything WordPress related. It has become the de facto answer to any bug report: “Are you running the latest version of plugin x and y?”. That’s fine, for most use cases. But what if I’m in a situation where I can’t be at the latest version? Or what if I find a bug in the latest version and have to restore to an older version?
Of course, we run our version control for websites. We can restore older versions of plugins after we find a bug. This requires us to have the premium plugin in our own version control, writing our own history. While this works fine, there are a couple really big downsides to this. Continue reading Premium WordPress plugin developers, can we have access to your version control please?