ClassicPress and PHP 7.4 compatibility

Simone · January 3, 2020, 9:40am

Partially OT: but CP is PHP 7.4 compatible?

Pross · January 3, 2020, 9:56am

I think currently it may throw some deprecated warnings, wp 5.3 included this patchset to fix 7.4 issues, these patches are not in CP (yet?)
https://core.trac.wordpress.org/ticket/47704

edit: Actually I see there is an open issue already for this

github.com/ClassicPress/ClassicPress

PHP 7.4 compatibility

opened 05:38PM - 20 Sep 19 UTC

closed 01:26AM - 19 Feb 20 UTC

nylen

type: wp backport

## Expected behavior No errors/notices in PHP 7.4. ## Current behavior Unkn…own but almost certainly not fully compatible. ## Possible solution Backport relevant changes from WordPress. Here is a list so far (not complete): - https://core.trac.wordpress.org/changeset/46112 Update getID3 library to fix issues with PHP7.4 - https://core.trac.wordpress.org/changeset/46113 Comment out magic quote functions [in getID3 library] - https://core.trac.wordpress.org/ticket/48046 Add array cast before `count()` in class-wp-xml-server.php (this is really for PHP 7.3) And tangentially related: - https://core.trac.wordpress.org/ticket/48041 Add PHP info to travis output - https://core.trac.wordpress.org/changeset/46149 Remove redundant PHP 4 code from `do_action()` ## Steps to reproduce (for bugs) Verify that all affected code paths are covered by automated tests (the XML-RPC one probably isn't) and look at the Travis CI build output.

james · January 5, 2020, 7:25pm

We’ll need to do a new release to add full compatibility for PHP 7.4, when the GitHub issue @Pross linked to is fully resolved.

anon95694377 · December 20, 2020, 7:53am

What is the current state of PHP 7.4 compatibility?

I spotted a deprecated notice after switching to PHP 7.4:

Deprecated: implode(): Passing glue string after array is deprecated. Swap the parameters in /home/REDACTED/Sites/REDACTED/wp-includes/Requests/Transport/fsockopen.php on line 195

This is a CP 1.2.0 installation.

stefanos82 · December 20, 2020, 10:17am

Weird…so far I haven’t had any warning and I use PHP 7.4.11 with XDebug and full warning messages.

Simone · December 20, 2020, 1:35pm

Weired.
It was fixed in PR 541…
Took a quick look in one of my sites and the glue is in the right place…

anon95694377 · December 21, 2020, 1:15am

Interesting, and thanks for the feedback. I downloaded a fresh copy of CP 1.2.0, used it to replace the wp-admin and wp-includes folders, and all is well.

So at some point a previous CP update failed to replace the fsockopen.php file.

stefanos82 · December 21, 2020, 12:43pm

I think you have detected an upgrade deficiency.

I have checked various websites I have setup locally and so far only 1 fixed the warning while upgrading; the rest retained the old syntax which is not good.

P.S.: @wadestriebel is there a particular reason why quotes are being automatically removed after publishing a reply?

Simone · December 21, 2020, 1:39pm

Same here.
1/3 sites have the wrong file in place.
Even reinstalling from dashboard don’t fix.
Forcing an update don’t work from dashboard and from wp-cli.
File permissions are ok.

anon95694377 · February 17, 2021, 4:40am

I’ve discovered another installation didn’t upgrade to CP 1.2.0 properly. The file

wp-includes/SimplePie/Parse/Date.php

was an old version with the implode function parameters in the wrong order.

Manually copying the wp-includes folder from a fresh CP zip solved it.

There seems to be a fairly fundamental problem with the CP core update process.

1stepforward · February 18, 2021, 1:51pm

Out of interest, what version of CP were you upgrading from? And was the site originally built on CP or is it a WP migration?

anon95694377 · February 19, 2021, 1:44am

I was upgrading from the previous version, and this was a site which started with CP (no WP migration). I think (but I’m not certain) that the initial install was CP 1.1.4.

1stepforward · February 19, 2021, 10:51pm

I don’t think this is related to PHP 7.4 after all. I’ve discovered that fsockopen.php and SimplePie/Parse/Date.php don’t get updated when using PHP 7.3 either. So the problem appears to be related to the actual upgrade process rather than the version of PHP.

anon95694377 · February 20, 2021, 2:38am

Good detective work. For my part, the site was on PHP 7.3 when created and updated to CP 1.2.0, but is now on 7.4.

1stepforward · February 20, 2021, 4:40pm

I think I might know what’s happening now.

During the update process, the “updater” compares the checksum of files in the existing installation (let’s say CP 1.1.4) with those at https://api.wordpress.org/core/checksums/1.0/?version=4.9.15&locale=en_US (locale may vary). If the checksums match, the file is ignored.

If we take fsockopen.php as an example, the copy of the file in CP 1.1.4 is the same as in WP 4.9.15 and so the checksum will also be the same.

But, if fsockopen.php has been changed since 1.1.4 - as it was in CP 1.2.0 - this change won’t be recognised, as the “upgrader” is comparing the checksums of the CP 1.1.4 version with the WP 4.9.15 version – which, as already mentioned, are identical.

So, when upgrading to CP 1.2.0, fsockopen.php is subsequently added to a “skip” list and ignored - along with several other files.

I may be miles off with this so @james will need to confirm.

james · March 12, 2021, 6:37pm

This is something that we will be fixing ASAP. I haven’t looked in detail but this explanation makes sense to me too. Here’s a GitHub issue to coordinate the work needed to fix this: Use the correct checksums when updating · Issue #679 · ClassicPress/ClassicPress · GitHub