fix[faustwp]: (#1872) add filter for search_pattern in handle_generate_endpoint

[latenighthackathon]

Description

Non-standard WordPress installations like Bedrock use a different directory structure where site_url() returns a path with a /wp/ prefix (e.g. /wp/generate) but $_SERVER['REQUEST_URI'] contains only /generate. This causes the preg_match in handle_generate_endpoint() to fail, resulting in 404 errors when previewing content.

This PR adds an apply_filters() call on $search_pattern so sites with non-standard directory structures can adjust the matching pattern without modifying the plugin source.

Usage example for Bedrock:

add_filter( 'faustwp_generate_endpoint_search_pattern', function ( $pattern ) {
    return str_replace( '/wp/', '/', $pattern );
} );

Related Issues

Closes #1872

Testing

Confirm the issue (before the fix)

1. Verify no filter exists on $search_pattern:

grep -n 'apply_filters.*search_pattern' plugins/faustwp/includes/auth/callbacks.php
# Expected on canary: no output

2. Verify $search_pattern uses site_url() which includes subdirectories on Bedrock:

sed -n '25,27p' plugins/faustwp/includes/auth/callbacks.php
# Expected: $search_pattern = ':^' . site_url( '/generate', 'relative' ) . ':';
# On Bedrock, site_url() returns /wp/generate, but REQUEST_URI has /generate

Confirm the fix

3. Verify the filter is applied after $search_pattern is constructed:

grep -A 12 "search_pattern = ':^'" plugins/faustwp/includes/auth/callbacks.php | head -15
# Expected: apply_filters( 'faustwp_generate_endpoint_search_pattern', $search_pattern )
# between the assignment and the preg_match

4. Verify the docblock follows WordPress standards (@SInCE, @param):

grep -B 10 'apply_filters' plugins/faustwp/includes/auth/callbacks.php | grep '@'
# Expected: @since 1.8.7 and @param string $search_pattern

Run the test suites

phpcs — confirms the filter follows WordPress coding standards:

cd plugins/faustwp && composer install && composer phpcs

JS tests — confirms no regressions:

npm install && npm run build && npm run test

WordPress PHPUnit — confirms plugin functionality:

cd plugins/faustwp
composer run docker:start
docker-compose exec -e COVERAGE=1 wordpress init-testing-environment.sh
docker exec --workdir=/var/www/html/wp-content/plugins/faustwp $(docker-compose ps -q wordpress) wp plugin install wp-graphql --activate --allow-root
docker exec --workdir=/var/www/html/wp-content/plugins/faustwp $(docker-compose ps -q wordpress) composer test
composer run docker:stop

[headless-platform-by-wp-engine]

Currently, we do not support the creation of preview deployments based on changes coming from forked repositories.
Learn more about preview environments in our documentation.

[changeset-bot]

🦋 Changeset detected

Latest commit: 8c27dce

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@faustwp/wordpress-plugin	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[josephfusco]

Thanks for the contribution!

I don't think we need a new filter here. The fix is to use home_url() instead of site_url():

$search_pattern = ':^' . home_url( '/generate', 'relative' ) . ':';

site_url() points to where WordPress core files live (includes /wp/ on Bedrock), while home_url() is the public-facing URL — which is what REQUEST_URI actually contains.

See also #1897 which addresses the same class of Bedrock subdirectory issue on the JS side.

[headless-platform-by-wp-engine]

Currently, we do not support the creation of preview deployments based on changes coming from forked repositories.
Learn more about preview environments in our documentation.