Add site generator command

[i-am-chitti]

Description

Add site generator command

wp site generate

Options

• slug
• count
• email
• network_id
• private
• progress

Issues

Fixes #231
Related wp-cli/wp-cli#5935

[swissspidy]

Neat!

With this being a new command, let's add it to this list here:

entity-command/composer.json

Lines 125 to 130 in 8b19b7d

	"site activate",
	"site archive",
	"site create",
	"site deactivate",
	"site delete",
	"site empty",

That will make sure the readme can be updated properly. The readme will be updated automatically via a cron workflow, but you can also update it manually in this PR using wp scaffold package-readme if you'd like to see the changes.

[i-am-chitti]

@swissspidy Addressed the feedback. Please have a re-review.
Also, the Behat tests are failing for the newly added site-generate.feature . It's passing on my local -

In CI -

[swissspidy]

I don't see that test failing on CI, I only see this error:

PHP Fatal error:  Call to undefined function get_subdirectory_reserved_names() in src/Site_Command.php on line 555

That's because of my suggestion to use get_subdirectory_reserved_names(). Turns out this was only added in WP 4.4, but we still run tests against 3.7+.

To address this, we can add a new private method to the class like this:

/**
 * Retrieves a list of reserved site on a sub-directory Multisite installation.
 *
 * Works on older WordPress versions where get_subdirectory_reserved_names() does not exist.
 *
 * @return string[] Array of reserved names.
 */
private function get_subdirectory_reserved_names() {
	if ( function_exists( 'get_subdirectory_reserved_names' ) ) {
		return get_subdirectory_reserved_names();
	}

	$names = array(
		'page',
		'comments',
		'blog',
		'files',
		'feed',
		'wp-admin',
		'wp-content',
		'wp-includes',
		'wp-json',
		'embed',
	);

	// phpcs:ignore WordPress.NamingConventions.PrefixAllGlobals.NonPrefixedHooknameFound -- Calling WordPress native hook.
	return apply_filters( 'subdirectory_reserved_names', $names );
}

[swissspidy]

Ah, now I see the failing test correctly, again only on older WP versions. https://github.com/wp-cli/entity-command/actions/runs/8852432605/job/24311451054?pr=498#step:11:86

Unfortunately I don't have a local 3.7 test site (or an old PHP version) right now to manually test this.

I wonder if it has to do with the URL scheme (https vs http). Some tests do

    And I run `wp site list --site__in={SITE_ID} --field=url | sed -e's,^\(.*\)://.*,\1,g'`
    And save STDOUT as {SCHEME}

And then use e.g. {SCHEME}://example.com/site1/ in the test.

If it's not that, then maybe someone else has an idea.

---

Aside: any idea why this one other unrelated test could be failing only on this PR?

https://github.com/wp-cli/entity-command/actions/runs/8852432605/job/24311451385?pr=498#step:11:84

[ernilambar]

@swissspidy #499

[swissspidy]

@wp-cli/committers Does anyone have thoughts here on how to debug the WP 3.7 failure? I don't have a working local setup to test it myself.

[ernilambar]

Looks like we faced same issue and fixed using {SCHEME} few years ago. e0a00c5 May be we should use same approach here also.

[i-am-chitti]

Thanks @ernilambar. This is fixing the failing tests on local. Hoping to get the same results in CI.

[ernilambar]

@swissspidy Any idea why regenerate-readme was not triggered after this PR?