David E. Smith

This specific issue only affect my “legacy” environment, where we’re still using an older version of WP-CLI for that very reason…

I’d argue that if the rest of your plugin only requires PHP 5.2, that this component should also only require PHP 5.2 (independent of the version requirement for other software, such as the CLI). Especially since, at first glance, it looks like the only issue is the new-style array constructor. That said, I certainly understand where you’re coming from. And I’d be on your side if this didn’t affect me personally ??

There is a workaround – wp --skip-plugins foo will run just fine in most cases (excepting those cases where a plugin implements its own CLI-specific features, like this one does). Means I’ll have to update some scripts, which is certainly annoying but not THAT annoying.

(Mods: Please remove the modlook tag, that was a mis-click on my part)

Ah. It wasn’t really clear (to me at least) that, in addition to enabling the logging settings in the plugin, that you’d also have to set some other settings (with other implications beyond the scope of the plugin). I thought you’d just log these events in the database somewhere. ?? Thanks for the quick response. Based on this, I’ll have to really think about whether the side-effects of this logging would outweigh the benefits to me.

Nobody has reported any other issues, so I think you’re good. Thank you again!

That update at least eliminated the hard crash. I’ll check with the owner of the site to verify that all the functionality still works as expected, but I’ll bet it’s fine. Thanks for the super-fast response!

I was hoping for an option that wouldn’t cost a hundred dollars ??

It looks like I can parse my pre-existing XML, and use that to create a bunch of new posts with wp-cli. Something like:

(slurp content from old XML into a temp array or similar)
(dump content from old XML to temp file)
wp post create (tempfile) --post_type=podcast --post_title=(mytitle) --post_date=(date) --comment_status=closed --ping_status=closed
(get post id)
wp post meta add episode_type audio
wp post meta add audio_file (file url)
wp post meta add enclosure (file url)
(maybe add filesize and duration meta by analyzing the provided MP3)

I don’t immediately see how to associate a post with a series, but on the test site I’m looking at right now there’s only one podcast series. Once I’m able to spin up some more filler, it’ll probably be fairly obvious.

I’ll try to write a blog post about it, if/when I can get it all to work. ??

The plugin appears to work again as expected, once updated with master from above. Thanks for looking into this!

That seems to have broken things in a different way (again, on PHP 5.3):

Fatal error: Can't use function return value in write context in /var/www/html/mysitehere/wp-content/plugins/lazy-loading-responsive-images/src/class-plugin.php on line 170

Assuming things still work on newer versions of PHP, and you don’t need to do a quick rollback, don’t worry too much about it. I’ll try to look at it next week and send a patch.

Point of order: the statement “PHP 5.6 is the only version still getting security updates” is technically not correct. PHP 5.3 and 5.4 are still receiving backported security updates from Red Hat (and thus CentOS, Scientific, etc.) until November 2020 and June 2024, respectively.

“Not supported by the original author” is not the same as “not supported”; such is the beauty of open source software.

Looks like a simple enough fix. I modified the version check (line 23 of seriously-simple-podcasting.php) to use < instead of <= in the version_compare call. I assume your intent is that 5.3.3 is allowed, but 5.3.2 (and below) are not; you were excluding 5.3.3.

If your intent was that the user must be running 5.3.4 or greater, and 5.3.3 is not supported, then you may want to update the comments in that file to match.

There’s likely nothing inherent to any of our sites that would make them suddenly stop working if PHP were upgraded, but there’s no clear, vendor-supported path for such an upgrade. In our case, the vendor is Red Hat; RHEL 6 ships with PHP 5.3.3, plus back-ported security and bug fixes.

[davsmi@wuis7843 ~]$ php --version
PHP 5.3.3 (cli) (built: Nov 7 2016 11:21:30)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

Just to head this one off at the pass: Anyone that’s interested in a much longer and deeper discussion of the pros and cons of increasing the minimum version of WordPress should take a look at this Trac issue. This Yoast ticket was/is just about suppressing the alert generated by this plugin.

I suppose we’ll have to agree to disagree. Or maybe just disagree. ??

I’m not staying on PHP 5.3 because I love staying on really old versions of software, believe it or not. And my developers would prefer, all other things being equal, to be on a newer version as well. In this case, though, we’re beholden to a third-party (Red Hat) and what software they will and won’t support. There are plenty of options for installing newer versions of PHP (Remi, EPEL, Software Collections), but actually using any of them effectively voids our support agreement, not just for the PHP components but for the whole system. If I went to my directors and said “hey we want to risk breaking our whole OS so we can keep using one plugin” they’d laugh me out of the conference room.

Given the choice between a single plugin and our whole server farm, I know which one I’m likely to choose.

We’re running on PHP 5.3, which isn’t yet a problem with WHIP, but which may be in the future. For support reasons, we use Red Hat Enterprise Linux, which includes PHP 5.3 with backported bug fixes and security fixes. They will continue backporting fixes until at least late 2020. Further, my environment is a controlled corporate one, not a general Web host open to the public, and our developers are aware of the limitations of PHP 5.3 and accept them as a trade-off for greater stability in our Web environment as a whole.

Given that we understand the issues involved with an older version of PHP, and have made a conscious and educated choice to continue using it, is there a filter/hook we can use to suppress and disable this alert? Most of our users are non-technical, and this alert will only raise needless alarm.

I’m seeing this as well. WordPress 4.7.2, PHP 5.3 (the security-patched version distributed by Red Hat).