install.php failed to create permanent link rewrite rules on percona cluster

[mmpower]

When wordpress is installed on a multi-master galera cluster ( like percona xtradb cluster), the post id in wp_posts table may not start from 1.

but wp-admin/install.php has the following code logic when trying to generate rewrite rules for permanent links in function wp_install_maybe_enable_pretty_permalinks():

<?php
...
                $test_url = get_permalink( 1 );
   
                if ( ! $test_url ) {
                        $test_url = home_url( '/wordpress-check-for-rewrites/' );
                }
   
                /*
                 * Send a request to the site, and check whether
                 * the 'x-pingback' header is returned as expected.
                 *
                 * Uses wp_remote_get() instead of wp_remote_head() because web servers
                 * can block head requests.
                 */
                $response          = wp_remote_get( $test_url, array( 'timeout' => 5 ) );
   
                $x_pingback_header = wp_remote_retrieve_header( $response, 'x-pingback' );
                $pretty_permalinks = $x_pingback_header && $x_pingback_header === get_bloginfo( 'pingback_url' );
...

basically it assumes there is a post id "1" and used that to test the permanent link. if no such post if then use a non-existed page to test; and then compare the x-pingback response header.

however, since there is no such post id "1" in this case, it 's using a non-existed url "/wordpress-check-for-rewrites/" for the etsting and current versions of wordpress does not return a "x-pingback" header for 404 pages. thus it failed the permanent link tests and empty the empty the rewrite rules, and generates a empty htaccess file like the following:

# BEGIN WordPress

# END WordPress

please fix it so that it uses the smallest post id available in wp_posts table instead of hardcoding " $test_url = get_permalink( 1 );"

[mmpower]

Replying to mmpower:

the mentioned function "wp_install_maybe_enable_pretty_permalinks()" above is in file wp-admin/includes/upgrade.php.

[swissspidy]

I assume post ID 1 was used in wp_install_maybe_enable_pretty_permalinks() as that would be the sample post created in wp_install_defaults().

Seems like a check for a specific ID can be avoided if we can use something else than the pingback header

current version of wordpress does not return a "x-pingback" header for 404 pages

This change in particular was introduced in 4.4 / #20226.

[SergeyBiryukov]

36628.patch​ uses get_page_by_path() instead of a hardcoded ID and removes the "test against a random 404 page" part, as it appears to no longer be relevant after [34442], as noted in comment:20:ticket:20226.

[mmpower]

Thanks @SergeyBiryukov @swissspidy . will use the patch for now.

[SergeyBiryukov]

In 38109:

Permalinks: In wp_install_maybe_enable_pretty_permalinks():

• Use get_page_by_path() instead of a hardcoded ID, which may not always exist.
• Remove the "test against a random 404 page" part, which is no longer relevant after [34442].

Fixes #36628.