Set a standard pretty permalink structure for the local dev environment.

[johnbillion]

Trac ticket: https://core.trac.wordpress.org/ticket/64227

This addresses two issues with the e2e test workflow.

Tricky Trixie

Last night at 01:11 UTC the latest tag for the PHP-based wordpressdevelop Docker images was changed from 8.2 to 8.3. Merging this change causes all the images to be rebuilt in the same way as we saw for Core-63876.

The e2e tests workflow doesn't specify a PHP version, so runs after that point switched from PHP 8.2 to 8.3.

Switching from PHP 8.2 to 8.3 also meant switching from Debian Bullseye using cURL 7.74.0 to Debian Trixie using cURL 8.14.1. In cURL 7.77.0 a change was made that means localhost always resolves to either 127.0.0.1 or ::1 and never consults /etc/hosts.

In the Docker config for the local dev environment, localhost points to the host machine, not to 127.0.0.1. We're not the only ones affected by this.

During installation, WordPress calls wp_install_maybe_enable_pretty_permalinks() which performs a loopback request to check that pretty permalinks work. If they do, they get enabled by default. Due to the above change in cURL, this loopback to localhost:8889 doesn't resolve to the host as expected, and the request fails, preventing pretty permalinks from being enabled.

Then we finally get to the e2e tests. The e2e tests assume that pretty permalinks are enabled. They don't get enabled explicitly. When a test requests /this-does-not-exist it ironically receives an HTTP 200 response rather than the expected 404 because pretty permalinks are not enabled, causing URL path info to be ignored and the home page to be served.

This is why the the e2e tests that assume pretty permalinks are in place were passing on PHP 8.2 and now fail on the new PHP 8.3 image with cURL 8.

Awkward apt-get

The e2e tests only run on Chrome.

The e2e workflow installs browsers for Playwright using npx playwright install --with-deps in accordance with to the Playwright documentation for CI. This installs dependencies for running headless Chromium which aren't otherwise included by default on the container images.

By default, Playwright installs Chromium, Firefox, and Webkit, but we only need Chromium. By excluding Firefox and Webkit, a massively reduced set of dependencies are pulled in by apt-get. The affected step goes from ~15 minutes to ~30 seconds.

This fix isn't technically needed to get the e2e tests passing again, but it does mean the workflow run doesn't bump right up against the 20 minute timeout for the workflow.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[desrosj]

A few other thoughts:

• We need to make sure that any changes made to address this issue do not cause a failure on PHP 7.4-8.2. If someone is using PHP < 8.3 locally, the tests should still pass as expected.
• I'm curious why the permalink format was being set through a env:cli command in the GHA workflows, but the same does not appear to happen when running test:e2e in general. Does this mean running the suite locally is not appropriately setting this?

[johnbillion]

I'm curious why the permalink format was being set through a env:cli command in the GHA workflows, but the same does not appear to happen when running test:e2e in general. Does this mean running the suite locally is not appropriately setting this?

The permalink format is not explicitly set at all for the e2e tests workflow, only for the performance test workflow. It should be set everywhere for consistency and reliability.

[github-actions]

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 props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props johnbillion, desrosj.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[desrosj]

After looking at this a bit, I think it's fine to restore the E2E test suite. However, loopback requests being broken is something that creates other issues. For example, a Site Health issue is triggered because the loopback test fails. Also, it's likely that scheduled events do not fire reliably, and other issues I haven't thought of just yet.

After some back and forth with Claude, it seems this is likely the best fix without changing the port, or making changes to the Docker images themselves (this seems reasonable, but don't understand what those changes would actually be just yet):

Use WP_SITEURL vs WP_HOME split — Define WP_SITEURL as http://wordpress-develop (for internal PHP→nginx requests) and WP_HOME as http://localhost:8889 (for browser links). WordPress uses WP_SITEURL for server-side requests and WP_HOME for front-end links. This is the most idiomatic WordPress fix.

Seems like merging this short term and creating a ticket to follow up in the coming weeks makes the most sense.

[johnbillion]

I agree that perhaps switching to a different host name in the container is worth investigating, but as per the comments in curl/curl#11104 the reason localhost is used is so there's no need to mess with /etc/hosts on the host machine. Needs some research, maybe bite the bullet and go with dnsmasq or Traefik.

[johnbillion]

Committed in https://core.trac.wordpress.org/changeset/61733