Repository navigation
Conversation
`render()` ran `searchFormAction` through a local `is_network_url()` helper. Core covers the same ground in `wp_validate_redirect()`, which returns the fallback for anything that doesn't resolve to this site, so the helper and the `sanitize_url()` call feeding it can both go. One difference worth noting: core matches the host exactly, so a sibling subdomain or a differently cased spelling of this host now falls back to live search rather than being kept. Nothing in the templates sets the attribute, and the README already describes it as a page on this site. Co-Authored-By: Claude Opus 5 (1M context) <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.
Follow-up to #773.
That PR added an
is_network_url()helper to keepsearchFormActionfrom pointing the search form off-site. Core already has a function for the same question —wp_validate_redirect()— so this swaps the helper out for it:It returns the fallback for anything that doesn't resolve to this site, which also makes the
sanitize_url()call redundant —wp_sanitize_redirect()and thehttp/httpsscheme check are built in. Net: 45 lines removed, and two checks gained that the helper didn't have (malformeduser/pass/hostcomponents, and control-character stripping).Behavior
Every case in the existing rejection data provider still resolves to
'', verified against the test environment:data:,vbscript:, mixed-casejavascript:, off-sitehttps, protocol-relative, escaped slashes, suffix lookalike, userinfo,https:///,https:////, andhttps:/.Two inputs that used to be kept now fall back to live search, because core matches the host exactly:
https://sub.example.org/events/)https://EXAMPLE.ORG/events/)Both are safe destinations, so this is a narrowing, not a fix. It looks acceptable: no template in
wporg-main-2022orwporg-events-2023setssearchFormActionat all, and the README already defines the intended value as "a page that has this block in the post content" — i.e. this site. Tests moved to cover the new behavior rather than the old.A bare relative path like
events/also now resolves againstREQUEST_URIinstead of being passed through, which is only reachable if someone writes the attribute that way; the README points at page URLs.Testing
npm run test:php— 46 tests, 117 assertions, green.phpcsis clean on the changed lines. (The vendoredPHPCompatibilitysniff aborts locally on every file in the repo, including untouched ones, so that ran with the rest of the repo ruleset.)🤖 Generated with Claude Code