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:

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:

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.