CLI install creates wrong rewrite rules which prevent the .htaccess from being created

[eyalroth]

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.

[schlessera]

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?

[eyalroth]

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?

[wojsmol]

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

[eyalroth]

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

[wojsmol]

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

[eyalroth]

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

[schlessera]

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.

[schlessera]

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

[eyalroth]

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