core-command CLI install creates wrong rewrite rules which prevent the `.htaccess` from being created

Summary

Installing WP via wp core install creates rewrite rules with index.php as prefix, which then causes the .htaccess file never to be written, even not by wp rewrite flush --hard. The installation process via wp-admin produces a different set of rules which does not cause this problem.

Here's the output of wp rewrite list after an installation with wp core install: cli-rewrite.txt

And here's the output for the same command after an installation via wp-admin: manual-rewrite.txt

Workaround

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.

Mar 07 '19 19:03 eyalroth

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?

Mar 09 '19 13:03 schlessera

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?

Mar 10 '19 11:03 eyalroth

@eyalroth See wp rewrite flush documentation regarding needed entries in WP-CLI config files and check what is returned by echo $_SERVER['SERVER_SOFTWARE'];.

Mar 12 '19 12:03 wojsmol

@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.

Mar 12 '19 12:03 eyalroth

@eyalroth This shoud be echo $_SERVER['SERVER_SOFTWARE];. - fixed in my previous reply.

Mar 12 '19 12:03 wojsmol

@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"]
        }
    }
}

Mar 12 '19 13:03 eyalroth

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.

Mar 14 '19 10:03 schlessera

@eyalroth This page might help diagnose the actual issue: https://docs.bolt.cm/3.6/howto/making-sure-htaccess-works

Mar 14 '19 10:03 schlessera

@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.

Mar 20 '19 14:03 eyalroth