E2E: Support WordPress installs served from a subdirectory#79166
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
Size Change: 0 B Total Size: 8.05 MB |
92d144e to
04661f0
Compare
|
Flaky tests detected in 7c23f7a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27821405494
|
When WP_BASE_URL points to a subdirectory install (e.g. http://localhost/wp/), Playwright resolves root-relative URLs against the origin only, dropping the subdirectory path. This broke: - page.goto( '/...' ) calls throughout the specs (the harness now resolves them against the full baseURL in the page fixture); - toHaveURL( '/wp-admin/...' ) assertions in browser-history and change-detection specs (now relative, which Playwright resolves against baseURL); - requestUtils.request calls with a leading slash in the collaboration fixtures, which silently fetched the wrong host path and failed the nonce scrape (now relative, matching visitAdminPage style). No behavior change for root installs: with a baseURL of http://localhost:8889/, relative and root-relative forms resolve to the same URLs.
04661f0 to
7c23f7a
Compare
What?
Makes the Playwright e2e harness and a handful of specs work when
WP_BASE_URLpoints to a WordPress install served from a subdirectory (e.g.http://localhost:8888/wp/).Why?
Playwright resolves root-relative URLs (
/wp-admin/...) against the origin only —new URL( '/x', 'http://host/sub/' )yieldshttp://host/x, silently dropping the subdirectory. The suite currently assumes a root install (which wp-env always provides), so running it against a subdirectory install fails in three distinct ways:page.goto( '/...' )calls (79 call sites across the specs) navigate to the wrong host path — e.g. the font-library spec's front-end check lands on the server's root page instead of the post.expect( page ).toHaveURL( '/wp-admin/...' )assertions build the expected URL without the subdirectory and never match.requestUtils.request.get( '/wp-admin/options-writing.php' )in the collaboration fixtures fetches the wrong path, the_wpnoncescrape returnsnull, and every collaboration spec fails inbeforeEachwithTypeError: Cannot read properties of null (reading '1').How?
e2e-test-utils-playwright): thepagefixture now rewrites root-relativegoto()URLs against the fullbaseURL(including its path). This fixes all existinggoto( '/...' )call sites in one place, with no change needed in specs.toHaveURLstrings inbrowser-historyandchange-detectionspecs and the tworequestUtils.requestpaths in the collaboration fixtures are now relative (no leading slash), which Playwright resolves againstbaseURL— the same stylevisitAdminPagealready uses.No behavior change for root installs: with
baseURLending in/, relative and root-relative forms resolve identically.Testing Instructions
/wp/) with the Gutenberg plugin and e2e test plugins mapped as in.wp-env.test.json.WP_BASE_URL=http://localhost:<port>/<subdir>/ npm run test:e2e -- test/e2e/specs/admin/font-library.spec.js test/e2e/specs/site-editor/browser-history.spec.jsnpm run test:e2e), behavior is unchanged.Testing done
Ran the full suite against a subdirectory MAMP install (
WP_BASE_URL=http://localhost:6888/test/test-2/): the previously failing font-library, browser-history, change-detection, and all collaboration specs pass with these changes. Spot-checked specs against the default wp-env root URL to confirm no regressions.