Add support for searching posts by url - #477
jessicamgoddard wants to merge 7 commits into
Conversation
add_future_support() can widen post_status to include 'future' before add_url_search_support() runs on the same rest_post_search_query filter, so a resolved URL's post__in lookup was no longer scoped to published posts. URL-based search now explicitly forces post_status back to 'publish', matching how draft/private posts are already excluded. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
URL scheme handling and existing include constraints must be corrected.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Adds URL-based post lookup to the REST search endpoint used by post pickers.
Changes:
- Resolves pasted post URLs to published post IDs.
- Prevents draft and scheduled-post exposure.
- Adds feature tests for URL and text searches.
| File | Description |
|---|---|
src/features/class-rest-api.php |
Adds URL resolution to REST post searches. |
tests/Feature/SearchByUrlTest.php |
Tests URL lookup, visibility, and fallback behavior. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
mboynes
left a comment
mboynes
left a comment
There was a problem hiding this comment.
By its code, this is approved. However, I'm marking it as requesting changes because I think it's worth taking a beat to decide if this should be in WP Curate or not.
This impacts REST API search for the whole site in all of its contexts, both public usage and admin usage, and certainly not just when used with WP Curate. While it's relatively innocuous, I would still offer that it's a pretty significant side effect of a curation plugin. Further, nothing here is WP-curate-specific, so it doesn't have to be tied to the plugin and we don't have to weigh the tradeoffs, we can have our cake and eat it too.
My opinion is that this should not be a part of WP Curate. Instead, I think it would work great as its own standalone plugin.
| $allowed_ids = []; | ||
| foreach ( $query_args['post__in'] as $allowed_id ) { | ||
| if ( is_numeric( $allowed_id ) ) { | ||
| $allowed_ids[] = (int) $allowed_id; | ||
| } | ||
| } | ||
|
|
||
| // An empty `post__in` is ignored by WP_Query, so use 0 to force no results. | ||
| $query_args['post__in'] = in_array( $post_id, $allowed_ids, true ) ? [ $post_id ] : [ 0 ]; |
There was a problem hiding this comment.
This is a bit heavier, and more verbose, than it needs to be. We can either make it one foreach loop that compares values and break;s if it finds a match, or we could leverage a reducer. Personally, I prefer the brevity of the latter:
| $allowed_ids = []; | |
| foreach ( $query_args['post__in'] as $allowed_id ) { | |
| if ( is_numeric( $allowed_id ) ) { | |
| $allowed_ids[] = (int) $allowed_id; | |
| } | |
| } | |
| // An empty `post__in` is ignored by WP_Query, so use 0 to force no results. | |
| $query_args['post__in'] = in_array( $post_id, $allowed_ids, true ) ? [ $post_id ] : [ 0 ]; | |
| $query_args['post__in'] = array_reduce( | |
| $query_args['post__in'], | |
| fn ( $post_in, $id ) => $post_in[0] === 0 && is_numeric( $id ) && (int) $id === $post_id ? [ $post_id ] : $post_in, | |
| [ 0 ] | |
| ); |
|
Closing in favor of creating a standalone plugin. |
A client requested to be able to search for posts by pasting the URL for a desired post. This seems like a feature that could be beneficial to other
wp-curateusers as well.