Open eyalroth opened 5 years ago
I cannot replicate this on my system.
WP-CLI basically just calls the WordPress wp_install()
function, it doesn't generate any of the rewrites itself.
I'd guess that your cli/server environment is set up in such a way the WordPress' guess_url()
function messes up.
Can you provide more information about your server environment?
Darn it, I feared this is something environment specific. I'm running on Windows WSL, Ubuntu 16.04.
I tried setting the WP_SITEURL
variable in my wp-config.php
, and still each method is generating a different result, so I would assume wp_guess_url()
is not the culprit. Any other ideas?
@eyalroth See wp rewrite flush documentation regarding needed entries in WP-CLI config files and check what is returned by echo $_SERVER['SERVER_SOFTWARE'];
.
@wojsmol mod_rewrite
is included in the configuration, otherwise the rewrite wouldn't have worked.
I'm getting Undefined index: SOFTWARE
messages when trying to echo
the value in my wp-config.php
.
@eyalroth This shoud be echo $_SERVER['SERVER_SOFTWARE];.
- fixed in my previous reply.
@wojsmol Apache/2.4.38 (Unix) OpenSSL/1.0.2q PHP/7.3.2 mod_perl/2.0.8-dev Perl/v5.16.3
.
Installation is done via composer:
{
"type" : "project",
"repositories": [
{
"type": "composer",
"url": "https://wpackagist.org"
}
],
"require": {
"php": ">=7.0",
"composer/installers": "1.*",
"johnpbloch/wordpress": "5.1.*"
},
"extra": {
"wordpress-install-dir": "public/wp",
"installer-paths": {
"public/wp-content/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
"public/wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
"public/wp-content/themes/{$name}/": ["type:wordpress-theme"]
}
}
}
I did a bit of digging. The rewrite rules are built with this index.php
prefix because WordPress (not WP-CLI) came to the conclusion that your server environment does not support true rewrite, so it wants to route everything through the index.php
file to fake it.
@eyalroth This page might help diagnose the actual issue: https://docs.bolt.cm/3.6/howto/making-sure-htaccess-works
@schlessera Most of the page is concerned with an existing .htaccess
file, which is not expected to exist in the first place for this issue. I tried the htaccess_tester.php
script posted there and it worked. My site is indeed not at the top level of the server, but I don't see why this should be a problem.
Summary
Installing WP via
wp core install
creates rewrite rules withindex.php
as prefix, which then causes the.htaccess
file never to be written, even not bywp rewrite flush --hard
. The installation process viawp-admin
produces a different set of rules which does not cause this problem.Here's the output of
wp rewrite list
after an installation withwp core install
: cli-rewrite.txtAnd here's the output for the same command after an installation via
wp-admin
: manual-rewrite.txtWorkaround
Set a custom rewrite structure, such as
wp rewrite structure '/%category%/%postname%/' --hard
to (a) correct the rewrite rules and (b) force the writing of the.htaccess
file.