Scope the empty-column filter to columns nobody chose - #10
Merged
Conversation
Reviewing 2.0.5 turned up three defects, all in the column filter it added. An explicit `columns=` list was filtered like any other. Asking for `[procore_team columns="name,email_address"]` rendered only Name — the column was requested by name and removed without a header, a cell or an explanation. The filter now runs only over the default column set, which is the set the author never chose; a hand-written list is rendered verbatim. The filter could not do most of what it claimed. `Format::cell()` returns an em dash for a missing value in every format except email, so testing for an empty string only ever matched a suppressed email address. Every other empty column survived as a full column of dashes, while the commit message, the changelog and readme.txt all said otherwise. The placeholder is now a named constant and `Format::is_blank()` judges a cell by meaning rather than length, which makes the documented behaviour true. A column's fate depended on its neighbours. The never-render-an-empty-table fallback restored the whole list, so `columns="email_address"` kept the Email column while `columns="name,email_address"` dropped it — same data, opposite outcome, and adding a column to a working shortcode could silently remove a different one. Honouring explicit lists removes the inconsistency at its root. Three tests, one per defect; each was confirmed to fail against the previous behaviour before the fix was restored. The 2.0.5 changelog entry is corrected where it claimed something that never shipped, and `docs/shortcodes.md` now documents what the filter does and where it stops. Also excludes `/vendor` rather than `/vendor/bin` from `.distignore`. Every dependency is dev-only, and the release workflow was passing an extra `--exclude=vendor` to compensate — building from `.distignore` alone shipped the entire dev tree. Verified: 106 tests pass, PHPCS WordPress-Extra + WordPress-Docs clean across 52 files, and Plugin Check reports no errors or warnings on the staged distributable with every category and experimental check enabled at severity 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
Reviewing the 2.0.5 diff turned up three defects, all in the column filter it introduced. Each was confirmed by rendering the shortcode, not by reading.
An explicit
columns=list was filtered like any other[procore_team columns="name,email_address"]rendered only Name. The column was named in the shortcode and removed with no header, no cell and no explanation. The filter's own docblock claimed the opposite — "A column an author asked for explicitly is always kept" — but nothing in the code distinguished an author's list from the registry defaults.The filter now runs only over the default column set. A hand-written list is rendered verbatim, empty or not.
The filter could not do most of what it claimed
Format::cell()returns an em dash for a missing value in every format exceptemail, so a test for an empty string could only ever match a suppressed email address — and exactly one column in the whole endpoint registry uses that format. Every other empty column survived as a full column of dashes, while the commit message ("a description or phone nobody has filled in"),CHANGELOG.mdandreadme.txtall described a feature that was not there.The placeholder is now the named constant
Format::PLACEHOLDER, andFormat::is_blank()judges a cell by meaning rather than by length.[procore_rfis]against a project where no RFI has a due date now drops the column, as documented.A column's fate depended on its neighbours
Because the never-render-an-empty-table fallback returned the unfiltered list,
columns="email_address"kept the Email column whilecolumns="name,email_address"dropped it. Same data, same setting, opposite outcome — adding a column to a working shortcode could silently remove a different one. Honouring explicit lists removes this at the root.Tests
Three tests, one per defect. Each was run against the previous behaviour first and observed to fail before the fix was restored:
Also
docs/shortcodes.mdgains an Empty columns section stating what the filter does and where it stops..distignoreexcludes/vendorrather than/vendor/bin. Every dependency is dev-only and the release workflow was passing an extra--exclude=vendorto compensate, so anyone building from.distignorealone shipped the whole dev tree.Verification
WordPress-Extra+WordPress-Docs— clean across 52 files🤖 Generated with Claude Code