fix(graphql): escape host in resolve-uris preg_match pattern

[kuuak]

Problem

graphql_resolve_relative_uris() interpolates the site/FE hosts straight into a preg_match pattern:

$site_url = preg_replace('/https?:\/\//', '', get_site_url());
$next_url = preg_replace('/https?:\/\//', '', get_next_url());

if (! preg_match("/^https?:\/\/($site_url|$next_url)/i", $result)) return $result;

The pattern uses / as its delimiter, but the interpolated hosts are not escaped. On a sub-path install the host contains a slash (e.g. localhost/us), so the first / inside the host is read as the closing delimiter and PHP parses the remainder (us|localhost:3000...) as modifiers — hitting the |:

PHP Warning: preg_match(): Unknown modifier '|' in .../graphql/resolve-uris.php on line 54

Because this filter runs on graphql_resolve_field for every uri/url/link/guid/sourceUrl/mediaItemUrl field, the warning (plus a full stack trace) is emitted on essentially every GraphQL request, flooding the logs.

It's a latent bug on root-domain installs (host has no slash) and only surfaces once the site runs under a sub-path — or if a host ever contains another regex-special char.

Fix

Wrap both hosts in preg_quote(..., '/') so slashes and other regex-special characters are matched literally.

Notes

• Behaviour is unchanged on root-domain installs; the pattern was previously broken/truncated on sub-path installs, so this also makes the host match actually correct there.
• These were notice/warning-level entries, not fatals — the site kept working, but the log noise (and per-request stack-trace overhead) is eliminated.
• Discovered on a downstream project (samantree.com) running under /us.

[Copilot]

Pull request overview

This PR fixes a regex parsing bug in the WordPress GraphQL URI resolver by properly escaping the backend (WP) and frontend (Next.js) URL fragments before interpolating them into a preg_match() pattern. This prevents warnings (and associated stack traces) on sub-path installs (e.g. /us) and ensures the host/path match works correctly.

Changes:

• Escape $site_url and $next_url using preg_quote(..., '/') before building the preg_match() pattern.
• Add an inline comment explaining why escaping is required (slashes in sub-path installs).