Stop documenting 'filter' as an available field

[swissspidy]

filter is a property of WP_Post and WP_User, not a column of either table. Core's own docblock says so: "Stores the post object's sanitization level. Does not correspond to a DB field." It holds raw, edit, display and so on — how the object was sanitized, nothing about the post or the user.

In practice it is a constant:

Command	What filter prints
wp post list	raw, for every row
wp user list	empty, for every row
wp post get	never shown

wp post get has never displayed it, so advertising it only for the list commands was inconsistent as well as useless.

This drops it from the documented fields on wp post list and wp user list and leaves the commands themselves alone. The property is still on the objects, so asking for it by name still yields what it always did — nothing advertises it any more.

The field list was never exhaustive

Worth knowing when reading this diff: "documented" and "works" have never been the same set for these commands. WP_Post resolves anything it does not declare through __isset()/__get(), so all of the following work as fields on wp post list today, and none of them are listed under AVAILABLE FIELDS:

Field	Result today	Documented
post_category	[1]	no
tags_input	works	no
page_template	works	no
ancestors	works	no
any post meta key	e.g. my_meta → hello	no

So AVAILABLE FIELDS is the useful subset rather than a whitelist, and removing an entry from it says "this is not worth reaching for" rather than "this no longer resolves". filter simply joins the group above.

Why documentation only

I first tried actually suppressing it, and that turned out to be the wrong trade. Removing it from a WP_Post means either unsetting the property or building an array of the object's properties, and both cost more than they are worth:

• unset( $post->filter ) does not remove the field. property_exists() still returns true for a declared property after unsetting it, so the formatter still reports it accessible; and WP_Post::__isset() falls through to metadata_exists( 'post', $this->ID, $key ), so the name becomes a post-meta lookup — a query per row, returning a post meta value literally named filter if one existed.
• get_object_vars( $post ) drops every field in the table above. wp post list --fields=ID,post_category returns [1] today and would return an empty column with a warning.

wp post get lacks those magic fields precisely because it does build an array, so making list match get would mean list losing something real. Not worth it to hide a field that no longer appears in the docs.

Refs wp-cli/wp-cli#5286

Summary by CodeRabbit

• Documentation
  • Updated wp post list and wp user list documentation to remove filter from the listed optional fields.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 25f39510-5022-48b9-883d-6f03c3c50ae5

📥 Commits

Reviewing files that changed from the base of the PR and between fcf429a and f4f5662.

📒 Files selected for processing (3)

• README.md
• src/Post_Command.php
• src/User_Command.php

💤 Files with no reviewable changes (3)

• src/Post_Command.php
• README.md
• src/User_Command.php

Included review availability: Your plan includes up to 2 reviews per rolling hour; 1 remains after this review.

---

📝 Walkthrough

Walkthrough

The change removes filter from the documented optional fields for wp post list and wp user list in the README and user command documentation.

Changes

List field documentation

Layer / File(s)	Summary
Update list field documentation README.md, src/User_Command.php	The post and user list documentation no longer lists filter as an optional available field.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: ⚪ Minimal · up to f4f56

This localized documentation-only change removes misleading filter field entries without changing command behavior, so no actionable merge-blocking risk remains after normal checks and review.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: removing filter from documented available fields.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/wp-cli-issue-5286-n50evd-drop-filter-field

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.