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

Some general conclusions:

• 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

A few highlights:

• 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.