CUNY Academic Commons

I've dug into this a bit and started making some big changes to our PHPCS configuration to try and highlight issues. I've added comments in the XML file to document the decision to exclude some rules from the ruleset.

My working branch at the moment is https://github.com/cuny-academic-commons/cac/tree/fix/php-compat-analysis

• There are a large number of constants and functions set to be removed in PHP 8.4. I added individual exclude rules for those so that we're aware. It's a large list that we can ignore for now, but is kind of eye-opening for the future.
• create_function() is used enough that we should probably just add a polyfill.
• get_magic_quotes_gpc() is also easy enough to add a return false polyfill.
• There are a bunch of old INI directives that I don't think are consequential. No fatal error results in the ini_set() or ini_get() of these and nothing in code seemed to be critical.
• Several things have had their behavior changed in PHP since 7.0, 7.1, or 7.2. I've excluded them because they would likely have reared their head already if they were impactful.

With all that said, a preliminary-ish report of seemingly major error frequency looks like this:

   1 PHPCompatibility.Classes.RemovedClasses.sqlitedatabaseRemoved
   1 PHPCompatibility.ControlStructures.ForbiddenBreakContinueOutsideLoop.FatalError
   1 PHPCompatibility.FunctionDeclarations.NewClosure.ThisFoundInStatic
   1 PHPCompatibility.FunctionUse.OptionalToRequiredFunctionParameters.mktime_hourHardRequired
   1 PHPCompatibility.FunctionUse.RemovedFunctions.eregDeprecatedRemoved
   1 PHPCompatibility.ParameterValues.RemovedMbStrrposEncodingThirdParam.Removed
   2 PHPCompatibility.FunctionUse.RemovedFunctions.eregiDeprecatedRemoved
   2 PHPCompatibility.Interfaces.InternalInterfaces.datetimeinterfaceFound
   2 PHPCompatibility.Operators.ChangedConcatOperatorPrecedence.Found
   2 PHPCompatibility.ParameterValues.RemovedPCREModifiers.Removed
   3 PHPCompatibility.Extensions.RemovedExtensions.eregDeprecatedRemoved
   3 PHPCompatibility.Variables.ForbiddenThisUseContexts.OutsideObjectContext
   4 PHPCompatibility.Extensions.RemovedExtensions.mysql_DeprecatedRemoved
   4 PHPCompatibility.FunctionUse.OptionalToRequiredFunctionParameters.parse_str_resultHardRequired
   4 PHPCompatibility.FunctionUse.RemovedFunctions.mysql_get_server_infoDeprecatedRemoved
   4 PHPCompatibility.Operators.RemovedTernaryAssociativity.Removed
   9 PHPCompatibility.FunctionUse.RemovedFunctionParameters.define_case_insensitiveDeprecatedRemoved
  11 PHPCompatibility.Variables.ForbiddenThisUseContexts.Global
  14 PHPCompatibility.FunctionUse.RemovedFunctions.eachDeprecatedRemoved
  41 PHPCompatibility.ParameterValues.RemovedImplodeFlexibleParamOrder.Removed

• implode() and join() previously accepted the delimiter as the second argument.(!) There are 41 cases we need to remove or hotfix because they will fatal in PHP 8.x.
• each() used to be a thing to iterate on an array? (TIL) I've already excluded a couple in which there was a fallback. We'll need to look at the remaining 14.
• There are 14 places where $this is now used incorrectly that need to be fixed.
• There are 9 define() statements with a 3rd parameter that needs to be removed.
• And then a handful of other bits and bobs that I think get decreasingly worrisome, mostly because the number of instances drops quite a bit and a lot of code seems to be hidden in weird vendor libraries and things that may not be used or is hard to actually trigger in a real world scenario.

My guess from here is that we spin off a couple tickets for the above highlights. Fixing things like join() is a bit eye-numbing, but not necessarily difficult, so it seems like a good chunk of these can disappear pretty quickly.

I do think I'm on board with just updating to PHP 8.1 to start to avoid even more edge cases. The update to PHP 8.3 next year may not be so bad. There seems to have been a much bigger shift from 8.0 to 8.1 than from 8.1. to 8.3.

Okay, one more list! Here are the plugins/themes that have files that generated the current errors. If any of these stand out as those that could just be removed, that's obviously helpful. :)

plugins/LayerSlider
plugins/_fix-simplepie-errors
plugins/acf-views
plugins/amazon-link
plugins/better-search
plugins/chatbot
plugins/constant-contact-api
plugins/custom-database-applications-by-caspio
plugins/easy-appointments
plugins/elementor-pro
plugins/event-organiser
plugins/events-calendar-pro
plugins/events-manager
plugins/export-wp-page-to-static-html
plugins/extended-categories-widget
plugins/geo-mashup
plugins/google-calendar-events
plugins/jetpack-boost
plugins/js_composer
plugins/newsletters-lite
plugins/otter-blocks
plugins/peters-custom-anti-spam-image
plugins/q-and-a
plugins/simple-tags
plugins/simply-static
plugins/threewp-broadcast
plugins/tubepress
plugins/widget-entries
plugins/wp-live-preview-links
plugins/wp-o-matic
plugins/wp-rss-multi-importer
plugins/wptouch
plugins/wysija-newsletters
themes/Avada
themes/bp-nelo
themes/elemental
themes/nelo-for-tags
themes/onetone
themes/oxygen
themes/platform
themes/project-ar2
themes/teleplaza-cbox-theme

I'll update the linting script as well to see if it highlights anything different.

Jeremy, thanks so much for these initial findings.

Where it's easy to polyfill, let's do so. We're looking for easy wins here.

Here's where we keep track of plugins that are no longer available to be activated by Commons members: https://github.com/cuny-academic-commons/cac/blob/0dae44ae21267be15269350c8a76f057183cc809/wp-content/mu-plugins/cac-functions.php#L866 We also have tools on the production site like wp cac-network-info query that let us see who's using these plugins. In most cases we need to go ahead and fix the plugins in question no matter what, but in cases where the fixes are non-trivial, it will be helpful to see usage details based on the tools I've mentioned.

When handling hotfixes, it would be nice to take note of whether the plugin is actively maintained. Many of the plugins on your list probably are not actively maintained; see #20829 and related tickets. When a plugin has been abandoned, we can patch our version without much concern. In the (probably rare) case where an actively-updated plugin needs to be patched, it would be nice to send upstream patches, if it's not a huge amount of extra work.

Splitting off new tickets from this one, to fix families of related errors, seems like a good step.

Whew! Big branch merged into 2.5.x and I think things are looking fairly good. I neglected to spin up additional tickets in advance, but will open a few now to document what all has happened.

A few outstanding issues:

1. cbox-theme has a handful of PHP 8.x errors. All except one are auto-fixable. I'll create a PR against that repo.
2. dk-pdf has some PHP 8.x errors that are addressed in their 1.9.9 update, which I'm guessing Boone will grab for the next release.
3. anthologize has PHP 8.x errors, some of which are part of vendor libraries that may be unused, others of which might actually be real. I'm less sure about this repo since it was last updated 6 years ago. Boone - any thoughts here?
4. The extremely old default WordPress.org theme, "default", has an issue and I'm working through WP.org slack and core.trac to see if it can be updated. If not, it will be easy to hotfix.
5. geo-mashup has an unlikely to be triggered error. I've opened a support thread and have not yet received a response.
6. chatbot has a small error. I reported it on the forums and they quickly released a new 6.0.6 version to address it.

Some additional tickets:

• #21615 for the introduction of PHP 8.x polyfills
• #21616 for new RequirePrimaryKeySniff errors (not critical for PHP 8.x)
• #21617 to update the wp-cli-cac plugin exclusion list

Regarding dk-pdf, it looks like I tried to updated it to 1.9.9 in October, but the linter determined it was incompatible with PHP 7.x. So I had to revert. https://github.com/cuny-academic-commons/cac/commit/24adf4ead7585dd3c627b36855b9c0ef2a5f0848 I would like to minimize plugin updates that happen at the very same time as the Reclaim migration, but this might be a special case: the old version is incompatible with Reclaim, and the new one is incompatible with legacy hosting. I've opened #21625 to cover it.

I'll review Anthologize right now to see if PHP 8 compat is easy to accomplish.

I started looking at Anthologize but quickly got overwhelmed. I'm going to commit a few changes to the plugin code itself, but as for the dependencies, I'd say let's just ignore the errors for now and then test actual functionality after the migration to Reclaim.

Boone - I'm okay waiting with Anthologize, but I may be able to clarify some stuff pretty quick too. I've been looking at https://github.com/chnm/anthologize as the source of truth, but it's a few tags behind. Is there a better repo?

Thanks, Jeremy. Use the 0.8.x branch: https://github.com/chnm/anthologize/tree/0.8.x

Excellent - that Anthologize update actually takes care of almost everything. I submitted a PR against that branch to address one more issue https://github.com/chnm/anthologize/pull/117

I've added a PR to the cbox-theme repo based on the 1.7.x branch that addresses some curly brace issues in the theme framework.

Jeremy, thanks for the PRs! I've released version 0.8.2 of Anthologize, which includes the fixes. Though if you've already hotfixed, that can remain in place and the Anthologize update will be applied the next time I update plugins.

As for cbox-theme, it's not publicly released in the wordpress.org repo, and I don't have a regular routine for updating it. The 1.7.x branch on GitHub is (minimally) maintained, and is shipped with Commons In A Box releases. But the version running in the CAC repo is different, and far older. I'm not confident that a full update to the latest 1.7.x version of cbox-theme on the Commons will "just work". If you'd like to try it, please be my guest; we could then update the submodule in the cac repo. Otherwise, the path of least resistance may be to patch the version shipped in the CAC repo.

cbox-theme on the Commons is running as a parent theme on one site (see #12064). I highly doubt that the PHP 8 fixes will break anything, but since I set up cbox-theme for that site, I can take a look to see if there will be any problems locally and will report back if there is anything that needs to be addressed.

I've tested the v1.7.x branch of cbox-theme with PHP 8.1 locally and while looking through the cbox-theme admin dashboard, I found an outdated documentation link, but other than that, everything looks like it is working as expected. I've pinned cbox-theme to the latest v1.7.x commit and have committed the changes to the reclaim-migration branch: https://github.com/cuny-academic-commons/cac/commit/bd411b93428bc09b23fad999d5f4be5367c35cbe .

Thank you!