WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#36628 closed defect (bug) (fixed)

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

Reported by: mmpower Owned by:
Milestone: 4.6 Priority: normal
Severity: normal Version: 4.4
Component: Rewrite Rules Keywords: has-patch
Focuses: Cc:

Description

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 );"

Attachments (1)

36628.patch (760 bytes) - added by SergeyBiryukov 4 years ago.

Download all attachments as: .zip

Change History (8)

#1 in reply to: ↑ description @mmpower
4 years ago

Replying to mmpower:

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

#2 @swissspidy
4 years ago

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.

#3 @SergeyBiryukov
4 years ago

  • Component changed from General to Rewrite Rules
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.6

#4 @SergeyBiryukov
4 years ago

  • Keywords has-patch added; needs-patch removed

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.

#5 @mmpower
4 years ago

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

Last edited 4 years ago by mmpower (previous) (diff)

#6 @ocean90
4 years ago

  • Version changed from trunk to 4.4

#7 @SergeyBiryukov
4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.