fix: keep the System Status report's positional filter working - #1710
Merged
jakejackson1 merged 1 commit intoSep 2, 2026
Merged
Conversation
6.17 rekeyed the system report's items array from positional integer keys to named string keys, so the four sections an add-on knew as 0-3 became `php`, `directories`, `global` and `security`. `gfpdf_system_status_report_items` is a public filter keyed by that same index, so every listener writing `$items[1]['my_row']` silently stopped reaching the report — no error, no notice, the row just vanished. Gravity PDF Core Booster's Outdated Templates warning is one of them. 6.17.0 has not shipped, so nothing is broken in the field yet; the 6.17 release line carries the same change and needs the same fix before it does. The rekey is worth keeping. Two sections were added at the head of the report and every section added after would renumber the ones below it again, which is what made the index a bad contract in the first place. So rather than ask third parties to change their code, the old shape is served alongside the new one. `get_report_items()` now hands the four sections to `gfpdf_system_status_report_items` at the indexes they sat at before 6.17, through `apply_filters_deprecated()`, and reads the result back off those same indexes. A listener written against the old shape neither sees nor needs a change; one that has moved on gets `_deprecated_hook` under `WP_DEBUG` naming the replacement. The sections added since — the deprecation groups — are held back from it. They have no index of their own, and giving them one would renumber the four below them, which is the break this exists to avoid. An index the listener invents has no section to land in and is dropped: pre-6.17 that auto-vivified a table with rows and no title, which is not a shape worth reproducing. `gfpdf_system_status_report_sections` is the replacement. It is keyed by section name and fires last, so it sees the whole report including anything the positional filter contributed. Nothing schedules the old filter's removal, which is why it isn't registered on `Deprecation` — that registry is the v3 layer 7.0 removes, and an unregistered call through it would render an empty version. `POSITIONAL_SECTIONS` is a frozen historical record rather than something derived from `get_report_structure()`. Deriving it would auto-expose a future fifth section at index 4, and re-break every listener the moment a section is inserted above `security`. The tests lock both halves: that each index still reaches the section it stood for, and that the filter is handed exactly four. Integration suite green single-site and multisite (1623 tests), PHPCS clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Coverage report for commit: ffb5c2c Summary - Lines: 92.99% | Methods: 88.31% | Branches: 81.37%
🤖 Jest coverage report |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Coverage report for commit: ffb5c2c Summary - Lines: 83.49% | Methods: 89.61%
🤖 PHPUnit coverage report |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
jakejackson1
added a commit
that referenced
this pull request
Sep 2, 2026
Cherry-picked from `development` (#1710), so this line ships the rekey and the shim that keeps it compatible together, rather than 6.17.0 breaking a public filter and a later release un-breaking it. The commit before this one rekeys the system report's items array from positional integer keys to named string keys, so the four sections an add-on knew as 0-3 become `php`, `directories`, `global` and `security`. `gfpdf_system_status_report_items` is a public filter keyed by that same index, so every listener writing `$items[1]['my_row']` silently stops reaching the report — no error, no notice, the row just vanishes. Gravity PDF Core Booster's Outdated Templates warning is one of them. The rekey is worth keeping. Two sections are added at the head of the report and every section added after would renumber the ones below it again, which is what made the index a bad contract in the first place. So rather than ask third parties to change their code, the old shape is served alongside the new one. `get_report_items()` now hands the four sections to `gfpdf_system_status_report_items` at the indexes they sat at before 6.17, through `apply_filters_deprecated()`, and reads the result back off those same indexes. A listener written against the old shape neither sees nor needs a change; one that has moved on gets `_deprecated_hook` under `WP_DEBUG` naming the replacement. The sections added since — the deprecation groups — are held back from it. They have no index of their own, and giving them one would renumber the four below them, which is the break this exists to avoid. An index the listener invents has no section to land in and is dropped: before the rekey that auto-vivified a table with rows and no title, which is not a shape worth reproducing. `gfpdf_system_status_report_sections` is the replacement. It is keyed by section name and fires last, so it sees the whole report including anything the positional filter contributed. Nothing schedules the old filter's removal, which is why it isn't registered on `Deprecation` — that registry is the v3 layer 7.0 removes, and an unregistered call through it would render an empty version. `POSITIONAL_SECTIONS` is a frozen historical record rather than something derived from `get_report_structure()`. Deriving it would auto-expose a future fifth section at index 4, and re-break every listener the moment a section is inserted above `security`. Kept as a commit of its own rather than squashed into the one below, so both stay byte-comparable against their upstream counterparts — which is what this branch exists for. The tests move to this line's `tests/phpunit/unit-tests/` path and its `WP_UnitTestCase` base; the assertions are unchanged. Suite: 1187 tests, up 3 from 1184 on the commit below, with no new errors or failures. The 3 errors and 2 failures that remain are the pre-existing `Helper\Mpdf\Test_Request` borrowed-`vendor_prefixed` artifact and the PHP 8.5 licensing deprecations, both reproduced on an untouched worktree. PHPCS clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4 tasks
jakejackson1
deleted the
fix/system-report-deprecate-positional-filter
branch
September 2, 2026 03:48
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
6.17 rekeyed the System Status report's items array from positional integer keys to named string keys, so the four sections an add-on knew as
0–3becamephp,directories,globalandsecurity.gfpdf_system_status_report_itemsis a public filter keyed by that same index, so any listener writing$items[1]['my_row']silently stopped reaching the report — no error, no notice, the row just disappears. Gravity PDF Core Booster's Outdated Templates warning is one of them, and it is unlikely to be the only one.The rekey itself is worth keeping. Two sections were added at the head of the report and every section added after would renumber the ones below it again, which is exactly what made a positional index a bad contract. But third parties shouldn't have to change their code for it, so this serves the old shape alongside the new one instead.
get_report_items()hands the four sections togfpdf_system_status_report_itemsat the indexes they sat at before 6.17, throughapply_filters_deprecated(), and reads the result back off those same indexes. A listener written against the old shape neither sees nor needs a change. One that has moved on gets a_deprecated_hooknotice underWP_DEBUGnaming the replacement,gfpdf_system_status_report_sections— keyed by section name, fired last, so it sees the whole report including anything the positional filter contributed.6.17.0 has not shipped, so nothing is broken in the field yet. The 6.17 release line (
feat/system-report-detect-legacy-templates-6.16.1) carries the same change and needs the same fix before it does.Try it
Drop this in an mu-plugin, open Forms → System Status, and look at Directories and Permissions:
On
developmenttoday the row is missing. With this branch it renders, and withWP_DEBUGon you also get a notice pointing at the replacement filter. Swapping to the new filter drops the notice and keeps the row:Test plan
Test_Controller_System_Report: each legacy index still reaches the section it stood for (including that a removed row stays removed, and that an index the listener invents is dropped rather than drawn as an untitled table); the positional filter is handed exactly the four sections it knew, while the deprecation section it never saw still reaches the report; and a row added by section name through the new filter lands.Design notes
Why the deprecation sections are held back from the old filter. They have no index of their own, and giving them one would renumber the four below them — the break this exists to avoid. They reach the report through
get_report_structure()and the new named filter only.Why an invented index is dropped.
build_gravitypdf_report()matches$items[ $table['id'] ], so a key with no matching section id has nowhere to land regardless of the read-back. Pre-6.17,$items[4]auto-vivified$structure[0]['tables'][4]with rows and notitle; Gravity Forms reads the caption withrgar()so it drew an untitled table rather than erroring. Not a shape worth reproducing.Why
POSITIONAL_SECTIONSis a literal, not derived fromget_report_structure(). It is a historical record, not configuration. Deriving it — even filtering outDeprecation::get_groups()— would auto-expose a future fifth section at index 4, and re-break every legacy listener the moment a section is inserted abovesecurity. It is marked frozen, and the tests catch both an append and a reorder.Why it doesn't go through
Deprecation::apply_filters(). That wrapper sources the version, replacement and removal text from the deprecation registry, which is the v3 layer 7.0 removes.gfpdf_system_status_report_itemsisn't a v3 feature and has no removal scheduled, so registering it would put a developer-facing filter rename into the Deprecated report section and the admin notice alongside "removed in 7.0" guidance. Called unregistered it would render an empty version string. Plainapply_filters_deprecated()is the right primitive here.move_gravitypdf_active_plugins_to_gf_addons()is unaffected — its positional indexes are into Gravity Forms' own report, which is handed to it before the Gravity PDF report is merged on.