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.
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.
I’m not a sysadmin by any means, but I like to think that I know how to setup a little server environment. Having used Vagrant for a long time now helps, it definitely lowered the bar of getting into it.
One thing that has puzzled me for quite some time, is so silly that I wanted to document it. Maybe I can have a good laugh about it when I look back at this in a couple months. Long story short: PHP uses a different
php.ini file for each program it loads in. This can be in the command line, or anything really.
So if you want to install the mcrypt extension for example (in my case on Ubuntu:
sudo apt-get install php5-mcrypt) and wonder why it isn’t loading when you use PHP on the command line; make sure the extension is loaded in
/etc/php5/cli/php.ini. In case you use PHP-FPM as well, make sure to load the extension in
/etc/php5/fpm/php.ini as well.
I have spent hours to find it, only to forget this is a thing a couple weeks later when it showed up again. Call me silly, but a quick Google search learned me that lots of people are struggling with this issue as well. If this post isn’t just going to give me a good laugh when I find it in a couple months, maybe it will help someone who stumbles upon it.
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.