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”
After much deliberation, I have decided to start publishing my screencasts in a separate YouTube channel, instead of in the same channel where I’m also publishing my vlogs. The reason is simple: I think these videos are very different in approach and have a different target audience (but there will be some overlap).
While my vlogs will usually be rather personal, the screencasts are more technical and in a tutorial format. I don’t think these different types of video go well in the same channel, so I’ve decided to split them up on YouTube. You can subscribe to one of them, or both if you want to see all my videos. In the near future, I’ll be opening a section for the screencasts, as I did for my vlogs already, so you can also keep track of everything via my website here. Continue reading “A separate YouTube channel for my screencasts”
For some reason, I just can’t keep doing it, but I really want to keep a journal. I want to keep track of things happening during the day. In 6 months time, I want to be able to look up what happened today. This is not just about day to day things, but also work related.
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.
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”