> It's not just the core team that has to change, it's all the plugins. Most > sites have considerable custom theme code - the one I'm responsible for does.
Plugins can also upgrade just as easily, because the alternative already works for all supported PHP versions. > I could run that query, but I wouldn't be comfortable doing it because there > are no tests for that old code. I do have tests, but most all of them step > over the PHP backend and focus on the output of the twig templates because > that's easier to test in the first place. I do have a sanity test that > iterates over 150 pages of the site looking for PHP and JavaScript errors in > the output or console, but that's a bare minimum. This part I can reassure you on directly: you don't need tests to make this specific change safely. `array($a, $b)`, `list($a, $b)`, and `[$a, $b]` compile to byte-identical opcodes. it's a guaranteed language equivalence, not a behavioural one that could differ at runtime, see https://3v4l.org/rlQa6/vld#v So a mechanical `array()` -> `[]` rewrite can't change what your code does, tests or no tests. That's a very different risk profile from a normal untested refactor. > A lot of WordPress sites are ran by small outfits with no coder on staff at > all and they delegate the server operation to a provider. I don't think this is a language-design concern. A deprecation doesn't break anything on upgrade day; it emits a notice, and removal is a full major version away. An unmaintained site isn't chasing new PHP majors in the first place, so the scenario where it lands on a version that has *removed* `list()`/`array()` without anyone touching the code essentially doesn't arise on its own. And where it does arise, it's because a managed provider moved the PHP version under software that doesn't support it. Verifying that the code runs on the target version is the provider's responsibility. That's true for every deprecation and removal PHP has ever shipped, and it isn't a reason to hold the language's grammar fixed.
