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. 🙂
I’ve been working on a proof of concept for solving dependency management in WordPress plugins for a while now. It was in a private repository on GitHub, where I would invite some people in to work out the most obvious issues, while keeping it a bit on the down-low (this is a big change, potentially, after all).
Now it’s time though. The WordPress Composer Installer repository is now open to the public. Note that this is not more than a proof of concept, albeit it a working one. There are some hoops to jump through to get this working, but all these steps can be automated once I make this a fully featured plugin.
Recent blog posts like Ryan McCue’s take on solving dependencies and Gary Pendergast’s response to that are likely to fire this discussion up again. I will publish a more detailed post about why I think this is important, but I’m on a short vacation while I’m typing this and should probably be out enjoying sunny London. ☀️
I struggle with being a procrastinator. I’ve become better at managing things to do over the years, but still often find myself in the “unproductive phase” as David Cain explains it in his excellent piece: How to get yourself to do things. Seriously, go read it.
When I read his post, it rings so many bells and it makes perfect sense. I probably should print his graphs and hang them on the wall as a constant reminder that the “productive phase” is never far away.
This morning I found out that the Instagrate plugin I use to import my Instagram pictures in my Moblog category, adds an HTML comment with a link to their website in every single post they import. As you might understand, I wasn’t really pleased about that, so I tweeted:
This lead to a rather nice conversation with the developer of the plugin, who immediately pushed out a fix release that no longer adds this HTML comment to the posts. Minutes after, he pushed out another fix release that also removes the HTML comments for all posts it has ever imported.
Thank you Iain for being so kind and for the quick way you dealt with this issue. Instagrate is still the plugin I will recommend for importing Instagram pictures as blog posts.
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.
Eric Mann has published a post on his blog titled Bundling and Bloatware, in which he describes his frustrations with the Jetpack plugin doing a lot of the exact opposite of what’s in the core WordPress philosophy:
The epitome of everything opposite of this drive to pare WordPress down to a barebone feature set was Jetpack by Automattic. […] It began to add more and more features as the Automattic team brought other projects into the fold, though. Today, Jetpack bundles 33 discrete features, each of which could ship (and in many cases has shipped) as a separate WordPress plugin.
This goes well with the post I wrote a little while ago, about lean and mean plugins. It’s also something that I struggle with every time I use Jetpack (3/34 features enabled here on this site). I’m all for a modular approach in Jetpack, so we can load just the modules that we need on our servers. Heck, I would even prefer them to continue to release all these plugins as actual separate plugins.
When you go read the post, be sure to check out the comments as well. Some of the Jetpack development have joined the conversation there and more or less defend the decisions the Jetpack plugin has made. I can’t say I agree with them, but at least this post opened up the conversation again.
Andrey Savchenko, better known as Rarst, announced that he’s removing all his WordPress plugins from the official repository. He’s been talking about it for a while, but now finally pulled the trigger on this decision.
Things like the mandatory support forum for each plugin, without the option to disable it or use an external support system, is something that has been bugging me a lot. Now WordPress core will start accepting pull requests on GitHub (as announced in Matt’s Town Hall talk at WordCamp San Francisco), the version control state of the plugins repository becomes even more painful:
While SVN is usable it is hardly pleasant or popular for modern development, lacking in newer distributed version control paradigms, performance, and other conveniences. More so WordPress actively discourages using its repository for active development, reducing it to storage mechanism with updates only happening for release versions.
I agree on a lot of Rarst his points, but am not really at the point of removing my plugins from the repository myself. What I do hope, is that decisions and bold statements like this post can become a catalyst for all the changes in the WordPress ecosystem.
While I’m sitting in the departure area at Schiphol Airport, sipping on a Starbucks drink, I suddenly realised that it was over three weeks since my last post here. So far so good with my blogging resolutions…
And now there’s a special of the Dutch Webdesigner Magazine being published, with two articles by me in it. To top that off, I’ll be speaking at WordCamp Norway this weekend. People will visit this site and will see a very inactive blog, so this is just a quick update that I’m still alive and will get into blogging more soon.
If you are at WordCamp Norway this weekend, come say hi and we’ll have a chat. I’d love to talk to people using WooCommerce, or about any subject really.
Over the past couple months, I’ve been writing a couple plans to put more structure in the development of our WooCommerce plugin. Today, the first steps will become visible to the public. The Develop WooCommerce blog has just been made available for the public.
“Keeping track of the WooCommerce core plugin development” is the first post on there that I’ve published yesterday, in which I explain what our plan is with this blog and why we think it’s important. The post explains that we’re keen to improve the development structure and planning, to ensure WooCommerce can remain one of the best choices when it comes to eCommerce on the WordPress platform.
In my post on the main WooThemes blog, I’ve explained some more about why we decided to start a separate blog for WooCommerce core development.
If you happen to work a lot with our WooCommerce plugin, I recommend you start following this new blog. It’s the best way to stay on top of everything happening around the development of the WooCommerce core plugin.