Make WordPress Core

Opened 9 years ago

Last modified 7 years ago

#36188 new defect (bug)

After WordPress installation, the default category archive page is showing a 404 page

Reported by: strategio's profile strategio Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.2
Component: Rewrite Rules Keywords: has-patch 2nd-opinion
Focuses: Cc:

Description

Steps to reproduce the issue:

  1. Install WordPress
  2. Log to the back-end
  3. Go to Post -> Categories and click on the "view" link of the default category.

=> You get a 404 page

Now, if you visit Settings -> Permalinks, the default category archive page is showing correctly.

This issue might be related to #20171

Attachments (4)

upgrade.diff (392 bytes) - added by seancjones 9 years ago.
My first patch attempt. I hope it is correct.
36188.diff (887 bytes) - added by seancjones 8 years ago.
36188.2.diff (934 bytes) - added by seancjones 8 years ago.
Added duplicate hook comment
36188.3.diff (2.0 KB) - added by dlh 8 years ago.

Download all attachments as: .zip

Change History (24)

#1 @strategio
9 years ago

  • Version changed from trunk to 4.4.2

#2 @seancjones
9 years ago

I can verify that this happens for all new installs until a theme is switched or permalinks are manually updated. It is on the front- and back-end using a standard installation.

This occurs on both Nginx and Apache2.

As with #20171 the rules are being flushed. However, categories are not being impacted.

#3 @seancjones
9 years ago

  • Version changed from 4.4.2 to 4.2

@seancjones
9 years ago

My first patch attempt. I hope it is correct.

#4 @seancjones
9 years ago

  • Keywords has-patch needs-testing added

I submitted a patch. Hopefully I got it right, otherwise I can resubmit. Basically it looks like "theme_switched" triggers the flushes correctly. I have not tested this on multisite yet but on single-site it does not break anything and uses existing mechanisms to switch from "no" theme to the default theme for the first time.

#5 @seancjones
8 years ago

First off, thanks @boonebgorges for the tips on patches.

Second, to recap this bug:

This bug has been in existence ever since WordPress 4.2, when pretty permalinks were installed by default. After further digging, the reason this bug cropped up is because extra permastructs are not registered until the init hook, which is never called during installation. This looks like it's by design, to avoid conflicts. The only permastruct which is necessary at install is the category. So, we have a few options, including running the function on the next page load (seems like overkill), or manually registering categories (doesn't scale without effort).

My preferred option is to run the init action after the wp_install action (please see attached patch). I have tested this on single site and multi-site and have not seen any issues. This only happens after the install has concluded and, given that no plugins are activated on a new site install, should be equivalent to a page refresh on the home page. I also moved flush_rewrite_rules to run after init.

Hope to get some feedback. Thanks in advance!

@seancjones
8 years ago

@seancjones
8 years ago

Added duplicate hook comment

#7 @seancjones
8 years ago

Thanks @SergeyBiryukov, I have updated the patch with a duplicate hook comment.

This ticket was mentioned in Slack in #core by seancjones. View the logs.


8 years ago

This ticket was mentioned in Slack in #core by seancjones. View the logs.


8 years ago

#10 @swissspidy
8 years ago

  • Milestone changed from Awaiting Review to Future Release

#11 @jorbin
8 years ago

Looks like it could be related to #6481 [31089]. @ericlewis - since you worked on that, would you be willing to look into this?

#12 @seancjones
8 years ago

Giving this a nudge @jorbin @ericlewis @boonebgorges

#13 @seancjones
8 years ago

  • Keywords 2nd-opinion added; needs-testing removed

#14 @dlh
8 years ago

@seancjones: I found your patch after encountering this bug recently, and it works as expected.

However, I'm not sure it's true that init is not fired during installation. I called did_action( 'init' ) just before flush_rewrite_rules() in wp_install() and got back 1.

If I'm reading correctly, the taxonomies are registered on init during installation, but permastructs are skipped in WP_Taxonomy::add_rewrite_rules() because

is_admin() || '' != get_option( 'permalink_structure' ) )

is false (a permalink structure is usually set in wp_install_maybe_enable_pretty_permalinks(), though).

Also, I think there's still a chance that third-party code will run during installation. For example, if WP_DEFAULT_THEME registers taxonomies, it would be subject to the same bug. Firing init fixes the bug, but it seems like it will also cause whatever is hooked to init to run twice, which callbacks might not expect.

#15 @dlh
8 years ago

On second thought, firing init doesn't seem to fix the bug in the example of taxonomies in the default theme.

But, at least for the taxonomies that are available during install, I wonder whether adding a loop along the lines of the one below would address the bug without the overhead of init:

wp_install_maybe_enable_pretty_permalinks();

foreach ( get_taxonomies() as $taxonomy ) {
        get_taxonomy( $taxonomy )->add_rewrite_rules();
}

flush_rewrite_rules();

#16 @seancjones
8 years ago

@dlh I just tested this again on VVV. At first I thought I was replicating, because I applied the patch and local.wordpress-develop.dev was not updating the categories. Then, I realized I was in the wrong location. I ran again, under src.wordpress-develop.dev, and it uploaded fine. I also checked did_action('init') in upgrade.php prior to my patched line of "do_action( 'init' )" and it returned 0.

Can you tell me what OS you're using? What version of WordPress? I want to get to the point where I'm replicating what you're seeing (or vice versa :) ). That said, I definitely see your point in all this. It makes a lot of sense to do it manually. However, my concern is that a manual addition of those lines, while it would certainly work well, would violate DRY. Any time a new permastruct were added in the future, it would be highly likely to introduce the same bug without an additional few lines of code to cover it. If we went that route, it would probably make sense to build a function that goes through almost the same process as the extra_permastructs.

One note is that the action, when it happens within install, will only be affected by WordPress hooks on init, of which there are few. Plugins, mu-plugins, and themes are not loaded on the install script.

Last edited 8 years ago by seancjones (previous) (diff)

#17 @dlh
8 years ago

@seancjones I'm running trunk on Ubuntu 16.04.1.

I agree with you that calling WP_Taxonomy::add_rewrite_rules() isn't DRY, but I wonder whether we'd face that objection with almost anything shoehorned into wp_install().

For example, is firing init any more DRY? Suppose a new permastruct was subject to this bug but normally added somewhere other than init. If I'm following correctly, wouldn't the other hook have to fire in wp_install(), too?

But, continuing with our theme of different install experiences, in my testing I find that mu-plugins do run during wp_install(). Are you able to DM me on the core Slack? Maybe we can chat there to figure out what's happening.

@dlh
8 years ago

#18 @dlh
8 years ago

@seancjones and I have been kicking around different approaches to fixing this bug, including 36188.3.diff, which basically uses the same fix as in #18040 and #19794, but with wp_installing() instead of is_admin().

This ticket was mentioned in Slack in #core by dlh. View the logs.


8 years ago

This ticket was mentioned in Slack in #core by dlh. View the logs.


7 years ago

Note: See TracTickets for help on using tickets.