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.
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
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.
The internet is filled with articles about how bad PHP is. Try a quick Google search for “PHP sucks” and you find about 83 million results. Doing the same search for other languages still gives you millions of results, but PHP really stands out in these numbers.
Although I agree that PHP probably is not the most beautiful language to work with (it’s getting better), PHP must be doing something right. Most of the really detailed rants about PHP date from the old days of the language. I often feel that the arguments being used to claim that PHP sucks, are the same issues when talking about bad practices for developers. Of course you can write bad code in PHP, like you can in any language.
I’m a fan of PHP, but for different reasons than you might guess. I am very well aware of the flaws in the language and cringe every time I do silly stuff like mixing up needle and haystack order in function arguments. The claim that PHP is bad is too easy for me though, because it’s simply not true. Continue reading PHP is not that bad