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.
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.
Today I published the pre launch page for my side project Lapisense. In case you missed it, it’s a hosted activation and updates API for WordPress based products. If you don’t like running a plugin that does this for you, Lapisense might be a nice fit for your products.
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. 🙂
The number one remark I heard when I launched WPupdatePHP, is that users shouldn’t be bothered with this. In an ideal world, this is true, but in reality this isn’t going to stand for long. Allow me to explain why:
The core WordPress team can’t get every single hosting company to comply. I admire their intentions, but in reality this is not going to help everybody.
At the time of this writing, PHP 5.4 is actually already nearing its EOL date and we’re still figuring out how to make PHP 5.2 and 5.3 platforms go away…
The end user is one of our most important, but underestimated, assets in this battle. They have the strongest voice in this all.
WordPress has PHP 5.2 as the minimum required PHP version. For a while now, PHP 5.4 has been listed as the recommended version. That’s a big step in the right direction, but I feel we can do more to help push the requirements forward.
At Radish Concepts we work with a lot of different platforms, frameworks and even languages. Most of our PHP projects are based on the Laravel framework, but we also do a lot of WordPress projects. When writing code for Laravel based projects, we obviously use namespaces and such, something we can’t do in publicly available WordPress plugins (since namespaces require PHP 5.3).
What we’d really love to do is be able to use namespaces for example, in our WordPress plugins as well. In addition to that, PHP 5.2 and 5.3 are really, really old. Even though lots of the Linux distributions tend to backport security fixes, it’s never a reassuring thought to read that PHP 5.2 has been unsupported for over 4 years now. We need to move on, as a community. Continue reading Time to update your PHP version
Tim Nash has published his predictions for the next year. The entire piece is worth a read, since I think Tim’s predictions are not far off, but the Bumping up PHP 5.2 part obviously sparked my interest:
[…] should we be aiding hosting companies, in supporting out of date potential security black holes. It’s clear that until hosting companies are forced to update they are not going to. So if WordPress was to change it’s minimum version number then hosting companies have no choice but to upgrade.
This is about the same as Anthony Ferrara has been telling us (also read his followup post: Being A Responsible Developer). I truly believe that the hosting companies are in a demand driven market. They will update their PHP versions as soon as large open source software projects like WordPress announce that they will bump their PHP version requirement for future releases.
If you like to read predictions for the new year (like I do), go read the full list of Tims predictions for 2015. As I said before, he’s not far off and I’m sure it will be a great inspiration for future projects or things to learn, like it was for me.
I think it’s time to start requiring PHP 5.4 in WordPress plugins. Even though WordPress still requires only PHP 5.2, I think it’s silly to keep telling people to run their websites on software that is no longer maintained for over four years now.
With plugins though, we can make up these requirements by ourselves, we don’t need to stick to the version that WordPress requires. In fact, I believe it’s going to make it easier for WordPress to move to PHP 5.4 and up as soon as more plugins already paved the road.
For todays video, I wanted to praise WordPress for what it does so well. It’s simply the best CMS out there. With over 21% of the entire internet being powered by WordPress, it’s hard to argue that this is not the most popular CMS out there.