Plugin requires PHP 5.3.9 (when it should work with 5.2.4+)
-
ws-rss-aggregator very dubiously requires a minimum version of PHP 5.3.9, which means it doesn’t work with CentOS 6 (which has well over 3 years of support left).
Two issues with this:
1. The WP core works with PHP 5.2.4+, so plugins should also make every effort to work with 5.2.4+ as well.
2. There is no way to download an older version of wp-rss-aggregator that works on PHP 5.2.4+ (e.g. version 4.9.1 works fine with CentOS 6).
As it stands, I have to hold back updates on my system to keep version 4.9.1 on, which isn’t good in the long run. As such, I can’t recommend this plugin to anyone running a long-term release of Linux (which is most hosting firms!) because the author doesn’t support such distros it appears.
-
> The reason why WP RSS Aggregator requires PHP 5.3.9 or higher can be found here.
That page states that “old-er, unsup-port-ed ver-sions of PHP no longer receive secu-ri-ty fix-es” being the main reason for dropping support. Unfortunately, this shows ignorance of Red Hat/CentOS’s backporting of security/bug fixes to older releases, but note that they don’t backport features from later PHP releases. Hence, “PHP 5.3.3” in CentOS 6 is actually “PHP 5.3.3 plus all security/bug fixes that could be applied to the 5.3.3 codebase from all later PHP releases”.
The second link to Coen Jacobs blog shows exactly the same lack of knowledge about RHEL/CentOS PHP backports – those backports are supported until November 2020.
CentOS 6 does have PHP (5.3.3 with the backports I mentioned) in its standard repos and is installed as part of a “Basic Web server” config. Rackspace do have an iUS repo that provides both PHP 5.6.X and 7.X, but this involves significant language changes that can break PHP 5.3.X-based sites (I tried the update on one of our CentOS 6 dev systems and several sites broke).
Yes, we are slowly migrating our CentOS 6 sites to CentOS 7 with the iUS repo (PHP 5.6.X), but it will be quite a while before that is completed. As I said, some PHP 5.3.X sites give us grief when even just going to 5.6.X. which is why compatibility with PHP 5.3.3 for WordPress plugins is important to us.
It should be noted that when other popular plugins have accidentally or deliberately broken compatibility with PHP 5.3.3, they’ve usually been accommodating when I point this out and will fix their changes to work with 5.3.3. Those that don’t force us to look for alternatives and also stop recommending the incompatible plugin to anyone running a long term Linux distro (which is what most hosters do!).
BTW, I only mentioned PHP 5.2.4 because that’s what core WP supports. For example, CentOS 5 only runs PHP 5.1.6 and clearly isn’t a candidate for plugin support (its backporting support stops next month anyway). There probably aren’t (m)any long term distros left that still run PHP 5.2.4, so I’m surprised WordPress haven’t raised their core code’s PHP minimum to, say, 5.3.3.
I do suspect that plugin devs like yourselves don’t run any long term Linux distro to do plugin testing on – unfortunately, as I said, these are exactly the distros that hosters run. I’d recommend throwing in the oldest supported LTS distros of SuSE/Ubuntu/CentOS into some VMs and test against them.
Hi rklrkl!
We are happy to receive comments and suggestions from users and developers experienced with PHP or Linux, so thank you very much for your feedback!
The page to which my colleague had linked to earlier mentions multiple reasons for us raising the minimal requirements of PHP, with security fixes being only one of them. It may sound like this is the main one, but that is probably because this is what most of the other popular sources are talking about. If you look at the bottom part of that post, you will find “a word from our Lead Developer”; that’s me. In my allocution, I explain that newer PHP versions provide syntactic features that make programs more concise and therefore easier to read, maintain, and adapt. Truly, the introduction of closures in PHP 5.3 is a major breakthrough, and allows WordPress developers to avoid falling into callback hell by handling hooks where they need to be handled, not somewhere else, and without polluting the global namespace with endless functions. Together with the __invoke() magic method, this made WordPress hooks much more useful and usable, because it allows for a more structured approach to event handling. This is just an example of how new language features greatly influence the developers’ decisions to raise the minimal requirements; but at the same time, this is probably the main reason. And from what you wrote, it appears that you agree that the minimal requirements should be at least PHP 5.3; please correct me if I’m wrong.
Like you mentioned, RHEL operating systems and their derivatives including CentOS backport the most critical fixes to previous PHP versions. At the same time, this is policy of operating system families, not of PHP itself. This is why we cannot rely on what some OS maintainers do: because we cannot cater for all cases and environments where our software is used. The decision to require at least PHP 5.3.9 and not a lower 5.3.x version is mostly based on the fact that PHP 5.3.9 introduces a fix that is critical to some elements of our architecture. This fix allows the same method from multiple interfaces to be correctly interpreted in the implementing class, instead of throwing an error. Truly, re-declaring the same method with identical signature lower in the interface inheritance chain should seamlessly override the previous identical declaration. Thus, we are able to write code that is more semantically clear and natural. This is very important when writing large enterprise software, which our product aims to eventually be. We are currently adapting many useful and widely accepted standards into our codebase, and without this ability we would have to sacrifice some of those standards, or flexibility due to being unable to provide a padding between standard interfaces and our own standards.
The current trend is heading away from older PHP versions, and even though the minimal requirement for WordPress remains at PHP 5.2, the official stats indicate that the majority of people are running PHP 5.6, while the recommended version of PHP is at least 7.0. Being able to cater for 5.8% of users in our humble opinion does not justify losing the ability to improve our software for the benefit of the rest of the users. It is almost always advisable to run the latest patch version of your chosen version of PHP, which for PHP 5.3 is 5.3.29, and it would seem that it is up to the OS maintainers in this case to port the most critical fixes to that version. For a long time, the WordPress community had been hesitant to move forward from PHP 5.2. But if the developers do not write software for newer PHP versions, the hosting providers will never upgrade their environments, since there would seemingly not be a need to.
To conclude, we are sorry for the inconvenience caused by our minimal requirements. This was a carefully weighed decision made on solid grounds and for the benefit of the majority, and many more plugin developers made the same decision for similar reasons. Please don’t hesitate to contact us if you need any information about our software, or advice on running it in your environment. We hope to receive more helpful feedback from users like yourself, and promise to continue working hard to bring to you the most useful and architecturally sound solutions, while contributing to the community and standards, and drive global development forward.
- The topic ‘Plugin requires PHP 5.3.9 (when it should work with 5.2.4+)’ is closed to new replies.
