wp-cli / wp-cli-bundle

📦 WP-CLI package that bundles the framework with a set of common commands

wp-cli/wp-cli-bundle

Combines the most common commands into the standard, installable version of WP-CLI.

Generally, bundled commands either relate directly to a WordPress API or offer some common developer convenience. New commands are included in the WP-CLI bundle when the project governance decides they should be. There isn't much of a formal process to it, so feel free to ask if you ever have a question.

The handbook documents the various ways you can install the bundle. The Phar is built on every merge and pushed to wp-cli/builds repository. A stable version is tagged a few times each year. Both wp-cli/wp-cli and wp-cli/wp-cli-bundle use milestones to indicate the next stable release. For wp-cli/wp-cli, the milestone represents the version of the WP-CLI framework. For wp-cli/wp-cli-bundle, the milestone represents the WP-CLI Phar version. We keep these in sync for backwards compatibility reasons, and to avoid causing confusion with third party commands. Each of the command repositories are versioned independently according to semantic versioning principles as needed.

wp-cli-bundle's Issues

Missing 2.4.1 release

Although wp-cli/wp-cli has released 2.4.1, there has been no tagged release of wp-cli/wp-cli-bundle with an updated lock file. Once wp-cli/wp-cli#5359 has been fixed to account for the outdated version reporting, the composer.lock file should be updated, and a new release tagged to match wp-cli/wp-cli.

Allow composer ^2.0

Hi,

Would it be possible to support composer ^2.0 instead of ^2.0.0? Thus allowing versions >=2.0 and <3.0.

Thanks

Tagged commit for 2.1.0 composer.lock file points to commit before VERSION update

Greetings,

After building a phar for version 2.1.0, using the tagged version in this repo, I noticed that the version output was 2.1.0-alpha instead of the expected 2.1.0.

It looks like the current master branch builds correctly against 2.1.0 and has the correct version in the --version output, so re-tagging the 2.1.0 tag should fix it.

P.S. The link in the issue template for this repo 404's (http://wp-cli.org/docs/bug-reports/)

Automatically rerun failed scenarios

The following changes need to be made:

1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:

- composer behat || composer behat-rerun

2. In the composer-json file, the requirement on wp-cli/wp-cli-tests needs to be adapted to require at least v2.0.7:

"wp-cli/wp-cli-tests": "^2.0.7"

3. In the composer-json file, the "scripts" section needs to be extended. Immediately after the line "behat": "run-behat-tests",, the following line needs to be inserted:

"behat-rerun": "rerun-behat-tests",

---

Here's an example of how this should look like:

php7.2-mysql in Ubuntu

Should php7.2-mysql be in this list? Or php7-mysql? I don't know much about this, but I've got an Ubuntu 16.04 container with PHP 7.2 (and php7.2-mysql) and it feels like I'm having to work around this dependency list to get wp-cli installed:
https://github.com/wp-cli/wp-cli-bundle/blob/master/utils/wp-cli-updatedeb.sh#L34

Unpacking php-wpcli (2.1.0) ...
dpkg: dependency problems prevent configuration of php-wpcli:
 php-wpcli depends on php5-mysql | php5-mysqlnd | php7.0-mysql | php7.1-mysql; however:
  Package php5-mysql is not installed.
  Package php5-mysqlnd is not installed.
  Package php7.0-mysql is not installed.
  Package php7.1-mysql is not installed.

dpkg: error processing package php-wpcli (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 php-wpcli

Thanks in advance!

Increase PHP version

wp-cli-bundle/composer.json

Lines 47 to 50 in 398a1d8

	"config": {
	"platform": {
	"php": "5.6"
	},

Set the PHP version to at least PHP 7.2.

I get that WP has support that goes back to PHP 5.6, however I am certain that people apt enough to use wp cli will not be on a version that old, that has potential security issues.

The reason why wp-cli should upgrade, since there are some bugs in tools used by wp-cli (e.g. gettext) that have been fixed in newer versions of these tools - which however require at least PHP 7.2.

Support composer/composer 2.3+

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Currently this package locks itself to composer/composer 2.2 which only supports symfony/console ^5.0. To support eg. roots/acorn v3 (illuminate v9) symfony/console ^6.0 is required but currently having wp-cli-bundle as a dependency prevents that.

Note that previous versions of WP-CLI did have this unlocked so I am able to update some packages however with older WP-CLI throws PHP 8.2 notices.

Describe the solution you'd like

Unlock composer/composer to at least v2.3 but ideally support up to latest version.

Remove/replace README.md

It seems README.md is a copy of wp-cli/wp-cli. It'll be problematic to have duplicated documentation. What should this README.md contain?

Adopt and enforce new `WP_CLI_CS` standard

We have a new PHPCS standard for WP-CLI called WPCliCS (props @jrfnl). It is part of the wp-cli/wp-cli-tests package starting with version v2.1.0.

To adopt & enforce this new standard, the following actions need to be taken for this repository:

• Create a PR that adds a custom ruleset phpcs.xml.dist to the repository

  • Add phpcs.xml.dist file
  • Adapt .distignore to ignore phpcs.xml.dist & phpunit.xml.dist
  • Adapt .gitignore to ignore phpunit.xml, phpcs.xml & .phpcs.xml
  • Require version ^2.1 of the wp-cli/wp-cli-tests as a dev dependency

• Make any required changes to the code that fail the checks from the above ruleset in separate PRs

• Merge thre ruleset once all required changes have been processed and merged

A sample PR for a simple repository can be seen here: https://github.com/wp-cli/maintenance-mode-command/pull/3/files

Related wp-cli/wp-cli#5179

Release 2.9.1, to allow having composer 2.6 on board

I just checked my install, and it seems that I still have composer 2.2.22 installed, despite being on version 2.9.0 of this package

web@website:/var/www/website (main)$ composer depends composer/composer
wp-cli/package-command v2.5.0 requires composer/composer (^1.10.23 || ^2.2.17)
wp-cli/wp-cli-bundle   v2.9.0 requires composer/composer (^1.10.23 || ~2.2.17)

This prevents me from installing any package depending on sf/console 6.x (as composer/composer 2.2.x does not allow it. Otoh composer 2.6 does)...

Would it make sense to release the current head version as 2.9.1?

Thanks!

Release 2.5.0 checklist

• Revert wp-cli/wp-cli dependency in wp-cli/config-command back to a stable tag [config-command#106]
• Revert wp-cli/wp-cli dependency in wp-cli/package-command back to a stable tag [package-command#118]
• Plugin and theme commands break on custom folder structures [extension-command#247]
• Revert wp-cli/wp-cli dependency in wp-cli/search-replace-command back to a stable tag [search-replace-command#149
• Revert wp-cli/wp-cli dependency in wp-cli/db-command back to a stable tag [db-command#181
• Revert wp-cli/wp-cli dependency in wp-cli/entity-command back to a stable tag [entity-command#303

Ambiguous class resolution WP_CLI\Inflector

$ composer require --prefer-dist wp-cli/wp-cli-bundle --optimize-autoloader
Using version ^2.0 for wp-cli/wp-cli-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating optimized autoload files
Warning: Ambiguous class resolution, "WP_CLI\Inflector" was found in both "/home/instahu/website/tmp/vendor/wp-cli/wp-cli/php/WP_CLI/Inflector.php" and "/home/instahu/website/tmp/vendor/wp-cli/scaffold-command/src/WP_CLI/Inflector.php", the first will be used.

It seem scaffold-command has a duplicated class.
Please advise.

Distribute a single PHAR file as composer package

Currently the phar file update is manual.

Could we create a Composer package that contains only the phar file?

Move over tests in `wp-cli/package-command` that generate a Phar

The following scenarios in the feature tests of wp-cli/package-command need to be moved over here, because they generate a Phar file using the make-phar.php tool:

• Install a package requiring a WP-CLI version that doesn't match [package-install.feature#L1044]
• Install a package requiring a WP-CLI version that does match [package-install.feature#L1090]
• Install a package requiring a WP-CLI alpha version that does match [package-install.feature#L1133]

Issue checklist for v2.1.0

Checklist of open issues we want to include for release v2.1.0:

wp-cli/db-command

• --size_format not working correct for DB size

wp-cli/entity-command

• wp post generate --post_content hangs if there's no STDIN (does not work within Behat)

wp-cli/extension-command

• plugin update does not fail on bad file permissions
• wp theme mod get --all produces malformed output for non-tabular formats (punted)

wp-cli/i18n-command

• Invalid MD5 hashes in make-json command (invalid)

wp-cli/language-command

• PHP notice on updating theme translations with no updates
• Allow to install language packs for all plugins

wp-cli/scaffold-command

• Block scaffold command produces a syntax error when used with --theme argument

wp-cli/wp-cli

• --prompt should skip flags that have been included in the command (to be discussed)
• WP-CLI does not use the same way as wordpress to locate the wp-config.php
• Packages cannot override bundled commands in Phar anymore
• WP CLI can no longer be installed on Windows
• Bump PHP version check in bootstrap code to v5.4+

---

Fixes #41

composer global require wp-cli/wp-cli-bundle

Hi There,

When running composer version 2+ I'm finding that the use of composer global require wp-cli/wp-cli-bundle causes composer 1.10.17 to be installed in my global vendor/bin, which due to being in my $PATH is causing composer 1.10 to be used rather than 2+

Thanks.

Bump PHP Compatibility Checker version minimum to 5.4

While we raised the required PHP minimum for WP-CLI to version 5.4+ with release v2.0.0, we are still checking for PHP 5.3 compatibility with the PHP Compatibility Checker sniffs.

Nightly builds with latest checkout of all commands instead of waiting for release for individual commands

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Currently, Nightly builds are built when something is merged to the bundle repo. Since the development of all the actions happens in separate repos, they get added to nightly only after a release is created on the individual repos.

Describe the solution you'd like

Can the nightly builds be made to include master branches of all the individual commands?

One way of doing this I am imagining is - Create a separate branch on this repo from which nightlies can be built, This branch will need will need two changes - 1. drop prefer-stable from composer.json and 2. remove composer.lock to allow downloading latest versions.

One drawback I can think of is - Creating a separate branch is a maintenance task to keep this branch up to date with all the latest changes from main branch.

Lintian reports php-wpcli_2.9.0_all.deb has two errors

user@ubuntu:~/wp-cli-bundle$ utils/wp-cli-updatedeb.sh
...
E: php-wpcli: depends-on-obsolete-package Depends: mysql-client => default-mysql-client
E: php-wpcli: php-script-but-no-php-cli-dep php (does not satisfy php-cli:any) [usr/bin/wp]
X: php-wpcli: bin-sbin-mismatch usr/bin/wp bin/wp -> usr/bin/wp
sign it:               dpkg-sig -k SIGNING-KEY -s builder "/home/user/wp-cli-bundle/php-wpcli_2.9.0_all.deb"
include in your repo:  pushd /var/www/REPO-DIR
                       reprepro includedeb jessie "/home/user/wp-cli-bundle/php-wpcli_2.9.0_all.deb" && popd

user@ubuntu:~/wp-cli-bundle$ lintian php-wpcli_2.9.0_all.deb 
E: php-wpcli: depends-on-obsolete-package Depends: mysql-client => default-mysql-client
E: php-wpcli: php-script-but-no-php-cli-dep php (does not satisfy php-cli:any) [usr/bin/wp]

Restore failing Phar deployments

Something is rotten in the state of Denmark:

https://github.com/wp-cli/wp-cli-bundle/actions/workflows/deployment.yml
https://github.com/wp-cli/wp-cli-bundle/actions/runs/3898207401/jobs/6656726095#step:13:49

It might be the GitHub action: ramsey/composer-install#240 (comment)

Originally discussed in https://wordpress.slack.com/archives/C02RP4T41/p1673537804932939

Done is:

• Deployments are working again.

composer require wp-cli/wp-cli-bundle:~2.3.0 installs 2.4.0-alpha?

Bug Report

Is your bug report directly related to a specific command?

No.

Are you unsure about what repository to post the bug report into?

I am sure.

--- ✅ If you are in the correct location now... --->

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

I was trying to get a wp executable of latest stable version 2.3.0.

$ composer require wp-cli/wp-cli-bundle:~2.3.0

But after installation:

$ [git:master+?{1}] public/vendor/bin/wp cli info
OS:     Linux 5.3.0-rc8-gentoo+ #101 SMP PREEMPT Tue Sep 10 18:09:37 EEST 2019 x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php
PHP version:    7.3.9
php.ini used:   /etc/php/cli-php7.3/php.ini
WP-CLI root dir:        /home/leho/Documents/cxl-wpstarter.git/public/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      /home/leho/Documents/cxl-wpstarter.git/public/vendor
WP_CLI phar path:
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:  /home/leho/Documents/cxl-wpstarter.git/wp-cli.yml
WP-CLI version: 2.4.0-alpha

Describe how other contributors can replicate this bug

See above.

Describe what you would expect as the correct outcome

I expected to get "WP-CLI version: 2.3.0"

Let us know what environment you are running this on

See above.

Provide a possible solution

I am unclear on whether I'm missing something about how composer works, or https://github.com/wp-cli/wp-cli-bundle/blob/v2.3.0/composer.json actually produces the expected result, because all dependencies are marked constrained via ^?

In which case I could create a documentation update PR.

Automatically submit pull requests for 'wp-cli/wp-cli' updates

Given so much of our development workflow is automated, it's easy to forget to submit updates like #467

Ideally, Dependabot (or something similar) would update the wp-cli/wp-cli dependency and automatically submit these pull request for us.

Done is:

• wp-cli/wp-cli dependency updates are submitted with some automated system.