JPKCOM_DISABLE_COMMENTS_VERSION
public
mixed
JPKCOM_DISABLE_COMMENTS_VERSION
= '1.0.13'
public
mixed
JPKCOM_DISABLE_COMMENTS_VERSION
= '1.0.13'
Report comments and pings as closed in a REST post response.
jpkcom_disable_comments_close_rest_status(mixed $response) : mixed
Removing post type support is not enough for post, page and
attachment: WP_REST_Posts_Controller::get_item_schema() carries a
hardcoded $fixed_schemas list for those three in which comments is
always present - the post_type_supports() check applies only to other
post types. The schema therefore keeps comment_status and ping_status,
and the response kept reporting the stored value, typically open, on a
site that refuses comments.
The fields are rewritten rather than removed, so the block editor and any other consumer keep the response shape they expect.
A REST write can still store comment_status: open - the schema stays
writable - but the value is inert: comments_open is filtered to false,
and this filter reports the field as closed regardless.
Prepared response, a WP_REST_Response in practice.
The response with both status fields set to closed.
Whether a REST request on the comment routes is a block-editor Notes request.
jpkcom_disable_comments_is_note_request(WP_REST_Request $request) : bool
Notes (core since 6.9) are comments of type note, created and read
through /wp/v2/comments. A request counts as a note request when
type parameter is exactly
note - the same strict comparison core's controller makes
('note' === $request['type']), for GET and POST alike;/wp/v2/comments/<id> and that comment exists
and is of type note (any method; core refuses to change a comment's
type on update).The route is read from get_route() and matched the way core matches it:
case-insensitively, against the same [\d]+ item pattern, and with $
accepting a trailing newline as core's @^…$@i does. A trailing slash is
tolerated as well. The ID is taken from the route because the URL
parameters are not populated yet on rest_pre_dispatch: dispatch()
matches the route only after the filter, and a batch sub-request is passed
with its URL parameters cleared.
The controller itself does not use the ID in the route: it reads
$request['id'], and get_param() prefers the JSON body, the form body
and the query string to the URL parameters. /wp/v2/comments/<note>?id=<n>
would therefore load comment <n>. An item request with an id parameter
is a note request only when that parameter is numeric and equal to the ID
in the route. Read here, before routing, get_param( 'id' ) returns exactly
the value core will prefer later, since the URL parameters are still empty.
Core's own permission checks still decide who may read or write notes.
The request about to be dispatched.
True for a note request, false for anything else.
Whether a comment query asks for notes and nothing else.
jpkcom_disable_comments_is_note_query(WP_Comment_Query $query) : bool
Mirrors how WP_Comment_Query::get_comment_ids() reads the requested
types: type and type__in are merged, and an empty string means "all
types". The query counts as a note query only when, after dropping those
empty entries, exactly note remains. all, comment, an empty type, a
mix such as [ 'note', 'comment' ] or a spelling core would not treat as a
note (NOTE, note,comment) do not qualify.
The query about to run.
True when only notes are requested.