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.
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.
This is a topic that I’ve talked about with a lot of people in the past couple years. I’ve used a GUI myself for a while, but always came back to the command line application. It is simply faster, it’s scriptable and supports all the goodies in Git, while a GUI only exposes a subset of its features.
There is definitely a bit of a learning curve, but it’s not as steep as it might seem. Once you get the hang of the three basic commands (status, add and commit), you will notice that you can keep track of your own history already.
Today we did our first Google Day. For those of you who don’t know the 20% time offer, Google offers her employees 20% of their time to work on side projects. We decided that the side projects we work on are preferably projects that benefit the company in the long run, but can be anything.
At first I wanted to (finally) dive into some other programming language, like Ruby or finally get my hands on some Node.js. None of this all happened though, as we discovered during some discussion that we really needed a project management tool and we never took the time to properly set things up. Continue reading Our first Google Day
I see this question over and over again. With the amount of PHP frameworks being available, it’s not hard to imagine how confused a learning PHP developer must feel when they try to pick the right framework. While in reality, it doesn’t really matter what PHP framework you choose. Laravel, Symfony, Zend, all are really well thought out and maintained frameworks. They are different, of course, but you won’t hurt yourself by picking one over the other. Continue reading It doesn’t matter what PHP framework you choose
Earlier this year, I made the decision to stop doing full time WordPress work. In my new day job, I still work with WordPress though. The big difference is that I now have a bigger toolbox to select the best tool for the job at hand from.
Working on just WordPress projects for a couple of years was great. In fact, I would do it again right away if I had to. For me it was great though, to step out of the WordPress bubble and start using different frameworks and technologies that are better suitable for the project. Continue reading Why I don’t do full time WordPress work anymore
Last night I published my first ever vlog. After discussing it with them for a while, Daniel Espinoza and Matt Stauffer had started publishing their first vlogs already, so it was time for me to step up and do what I announced earlier.
Making this video was the most awkward thing I have done in a long time, but I’m happy it’s out there now. It feels like future videos will be easier to make now this first one is done. Continue reading My first ever vlog…
For a while now, I’ve been trying to think of ways to do more with video. At the top of my todo list is something called “the vlog experiment”.
I asked on Twitter why I didn’t know of any developers who post vlogs. I got a lot of responses, but nobody was able to name someone. Finally, Jeffrey Way’s response gave me the push I needed. The fact that there are no developers out there posting vlogs, probably means that there is room for someone to start doing this (or it means that it’s a bad idea, but let’s not assume that’s the case…). Continue reading Vlogging as a developer
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?