The permalink format is "plain" by default

[strategio]

In the previous WP versions, the permalink format was set to "Day and name" by default.

Steps to reproduce

• Start from scratch
• Complete the WP install wizard
• Go to Settings > Permalinks

=> With WP 6.0.2, it's set to "Day and name"
=> With WP 6.1 RC1, it's set to "Plain"

Notes

It's not really causing issue to us, but we have an end-to-end test that assumes the permalinks are set to "Day and name" and it started failing as soon as we ran it with WP 6.1 RC1.

So this might be a hint that something is wrong in WP 6.1 RC1 (or maybe it's on purpose).

[sabernhardt]

The Permalink Settings page had several changes for the upcoming release, but I was able to get the same results without visiting that page. The default schema.php setting has been blank for years, so the installation process set "Day and Name" pretty permalinks somewhere else in earlier sites (and now that doesn't work).

Steps I took for 6.0.2 and 6.1-RC1:

1. Download WordPress .zip package.
2. Unzip files, add them in local server directory, create a database, and create a wp-config.php file.
3. Complete the WordPress install process for a single site (not network).
4. Visit the Posts listing page, and check the URL on the "Hello World" post's View link.

6.0.2 URL: http://localhost/wp60a/2022/10/17/hello-world/
6.1-RC1 URL: http://localhost/wp61a/?p=1

[SergeyBiryukov]

Replying to sabernhardt:

The Permalink Settings page had several changes for the upcoming release, but I was able to get the same results without visiting that page. The default schema.php setting has been blank for years, so the installation process set "Day and Name" pretty permalinks somewhere else in earlier sites (and now that doesn't work).

Right, pretty permalinks are conditionally enabled in wp_install_maybe_enable_pretty_permalinks() if the server supports that.

[dlh]

wp_install_maybe_enable_pretty_permalinks() ​looks for the `X-Pingback` header to determine whether a post is accessible at a "pretty" URL. In [54250], the logic for sending the X-Pingback header was moved to WP::send_headers(), but that logic relies on $wp_query, which isn't globalized in send_headers() (unlike in WP::handle_404(), where the logic used to be). A global $wp_query looks like it'd be enough to address the issue.

[SergeyBiryukov]

Replying to dlh:

In [54250], the logic for sending the X-Pingback header was moved to WP::send_headers(), but that logic relies on $wp_query, which isn't globalized in send_headers() (unlike in WP::handle_404(), where the logic used to be). A global $wp_query looks like it'd be enough to address the issue.

Great catch, thanks!

[SergeyBiryukov]

56840.2.diff​ includes a unit test.

[davidbaumwald]

LGTM. Thanks for working on this Sergey!

[SergeyBiryukov]

In 54636:

Bootstrap/Load: Correct sending the X-Pingback header in WP::send_headers().

The logic for sending the X-Pingback header for single posts that allow pings was recently moved from WP::handle_404()​ to a more appropriate place in WP::send_headers().

To check whether pings are open for a particular post, that logic relies on the $wp_query global, which is declared in WP::handle_404(), but not in WP::send_headers()

This commit ensures that $wp_query is globalized in WP::send_headers() too, so that the check works as expected.

Follow-up to [54250].

Props strategio, sabernhardt, dlh, davidbaumwald, SergeyBiryukov.
Fixes #56840.