![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 8 years ago
#44804 new defect (bug)
pretty_permalinks capability may not be detected correctly during a fresh install on a server without mod_rewrite
| Reported by: | ccprog | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Upgrade/Install | Version: | 4.9.8 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
I have a lighttpd server that has a pretty standard setup: no active mod_rewrite rules, but a index-file rule that names index.php as a index file (thus a sort of one-off rewrite). I don't know about other servers, but this may be not that uncommon as a default setup.
Now look at wp_install_maybe_enable_pretty_permalinks() in wp-admin/includes.upgrade.php. If you look closely, the routine to test for active mod_rewrite functionality will ping for get_permalink( $first_post->ID ), if it already exists. During a fresh install, it doesn't, and an empty string is used for testing.
This leads to a false positive, since the empty path is rerouted despite the absence of true rewrite rules. Option permalink_structure is set to /%year%/%monthnum%/%day%/%postname%/, without the leading file name. If you go to the settings page later and change the permalink settings, the error is corrected and the file name inserted - now the $first_post exists.
For almost all practical purposes, this poses no problems, but came to the fore in the most obscure of all places: while testing Gutenberg on a fresh install, the editor crashed - see https://github.com/WordPress/gutenberg/issues/8899.
