Coder Social home page Coder Social logo

config-command's Introduction

WP-CLI

WP-CLI is the command-line interface for WordPress. You can update plugins, configure multisite installations and much more, without using a web browser.

Ongoing maintenance is made possible by:

The current stable release is version 2.10.0. For announcements, follow @wpcli on Twitter or sign up for email updates. Check out the roadmap for an overview of what's planned for upcoming releases.

Testing Average time to resolve an issue Percentage of issues still open

Quick links: Using | Installing | Support | Extending | Contributing | Credits

Using

WP-CLI provides a command-line interface for many actions you might perform in the WordPress admin. For instance, wp plugin install --activate (doc) lets you install and activate a WordPress plugin:

$ wp plugin install user-switching --activate
Installing User Switching (1.0.9)
Downloading installation package from https://downloads.wordpress.org/plugin/user-switching.1.0.9.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'user-switching'...
Plugin 'user-switching' activated.
Success: Installed 1 of 1 plugins.

WP-CLI also includes commands for many things you can't do in the WordPress admin. For example, wp transient delete --all (doc) lets you delete one or all transients:

$ wp transient delete --all
Success: 34 transients deleted from the database.

For a more complete introduction to using WP-CLI, read the Quick Start guide. Or, catch up with shell friends to learn about helpful command line utilities.

Already feel comfortable with the basics? Jump into the complete list of commands for detailed information on managing themes and plugins, importing and exporting data, performing database search-replace operations and more.

Installing

Downloading the Phar file is our recommended installation method for most users. Should you need, see also our documentation on alternative installation methods (Composer, Homebrew, Docker).

Before installing WP-CLI, please make sure your environment meets the minimum requirements:

  • UNIX-like environment (OS X, Linux, FreeBSD, Cygwin); limited support in Windows environment
  • PHP 5.6 or later
  • WordPress 3.7 or later. Versions older than the latest WordPress release may have degraded functionality

Once you've verified requirements, download the wp-cli.phar file using wget or curl:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Next, check the Phar file to verify that it's working:

php wp-cli.phar --info

To use WP-CLI from the command line by typing wp, make the file executable and move it to somewhere in your PATH. For example:

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

If WP-CLI was installed successfully, you should see something like this when you run wp --info:

$ wp --info
OS:     Linux 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64
Shell:  /usr/bin/zsh
PHP binary:     /usr/bin/php8.1
PHP version:    8.1.0
php.ini used:   /etc/php/8.1/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
SQL modes:
WP-CLI root dir:        /home/wp-cli/
WP-CLI vendor dir:      /home/wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir:    /home/wp-cli/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:  /home/wp-cli/wp-cli.yml
WP-CLI version: 2.10.0

Updating

You can update WP-CLI with wp cli update (doc), or by repeating the installation steps.

If WP-CLI is owned by root or another system user, you'll need to run sudo wp cli update.

Want to live life on the edge? Run wp cli update --nightly to use the latest nightly build of WP-CLI. The nightly build is more or less stable enough for you to use in your development environment, and always includes the latest and greatest WP-CLI features.

Tab completions

WP-CLI also comes with a tab completion script for Bash and ZSH. Just download wp-completion.bash and source it from ~/.bash_profile:

source /FULL/PATH/TO/wp-completion.bash

Don't forget to run source ~/.bash_profile afterwards.

If using zsh for your shell, you may need to load and start bashcompinit before sourcing. Put the following in your .zshrc:

autoload bashcompinit
bashcompinit
source /FULL/PATH/TO/wp-completion.bash

Support

WP-CLI's maintainers and contributors have limited availability to address general support questions. The current version of WP-CLI is the only officially supported version.

When looking for support, please first search for your question in these venues:

If you didn't find an answer in one of the venues above, you can:

  • Join the #cli channel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
  • Post a new thread in the WordPress.org support forum and tag it 'WP-CLI' so it's seen by the community.

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Before submitting a bug report, please review our best practices to help ensure your issue is addressed in a timely manner.

Please do not ask support questions on Twitter. Twitter isn't an acceptable venue for support because: 1) it's hard to hold conversations in under 280 characters, and 2) Twitter isn't a place where someone with your same question can search for an answer in a prior conversation.

Remember, libre != gratis; the open source license grants you the freedom to use and modify, but not commitments of other people's time. Please be respectful, and set your expectations accordingly.

Extending

A command is the atomic unit of WP-CLI functionality. wp plugin install (doc) is one command. wp plugin activate (doc) is another.

WP-CLI supports registering any callable class, function, or closure as a command. It reads usage details from the callback's PHPdoc. WP_CLI::add_command() (doc) is used for both internal and third-party command registration.

/**
 * Delete an option from the database.
 *
 * Returns an error if the option didn't exist.
 *
 * ## OPTIONS
 *
 * <key>
 * : Key for the option.
 *
 * ## EXAMPLES
 *
 *     $ wp option delete my_option
 *     Success: Deleted 'my_option' option.
 */
$delete_option_cmd = function( $args ) {
	list( $key ) = $args;

	if ( ! delete_option( $key ) ) {
		WP_CLI::error( "Could not delete '$key' option. Does it exist?" );
	} else {
		WP_CLI::success( "Deleted '$key' option." );
	}
};
WP_CLI::add_command( 'option delete', $delete_option_cmd );

WP-CLI comes with dozens of commands. It's easier than it looks to create a custom WP-CLI command. Read the commands cookbook to learn more. Browse the internal API docs to discover a variety of helpful functions you can use in your custom WP-CLI command.

Contributing

We appreciate you taking the initiative to contribute to WP-CLI. It’s because of you, and the community around you, that WP-CLI is such a great project.

Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Read through our contributing guidelines in the handbook for a thorough introduction to how you can get involved. Following these guidelines helps to communicate that you respect the time of other contributors on the project. In turn, they’ll do their best to reciprocate that respect when working with you, across timezones and around the world.

Leadership

WP-CLI has one project maintainer: schlessera.

On occasion, we grant write access to contributors who have demonstrated, over a period of time, that they are capable and invested in moving the project forward.

Read the governance document in the handbook for more operational details about the project.

Credits

Besides the libraries defined in composer.json, we have used code or ideas from the following projects:

config-command's People

Contributors

ancocodet avatar clemens-tolboom avatar codeprokid avatar danielbachhuber avatar ernilambar avatar fjarrett avatar francescolaffi avatar gitlost avatar jmslbam avatar lalaithan avatar lkwdwrd avatar lucatume avatar miya0001 avatar mpeshev avatar mwilliamson avatar natewr avatar nyordanov avatar pmbaldha avatar rahul3883 avatar rodrigoprimo avatar schlessera avatar scribu avatar sidsector9 avatar swissspidy avatar szepeviktor avatar thrijith avatar tomjn avatar wesm87 avatar wojsmol avatar wojtekn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

config-command's Issues

wildcard for alias (dynamic aliases)

#58 is a case for dynamically generated ~/.wp-cli/config.yml

Going further with WP instance mass-management, I'd like to know what do you think about the idea that alias support globbing string patterns and be provided as a variable to alias's directives.

For example:

'@ae-*':
  ssh: docker:phpfpm-projectone-{alias}/var/www

would support wp @ae-us-master bound to docker:phpfpm-projectone-ae-us-master/var/www
as well as wp @ae-in-develop bound to docker:phpfpm-projectone-ae-in-develop/var/www
etc...

wp config create - Too many positional arguments

Ubuntu 14
CLI 1.5
PHP 5.5.9

This might be my lack of knowledge in the command line.

But

wp config create --dbname=db_name --dbuser=username --dbpass=password --dbhost='127.0.0.1'

will result in Too many positional arguments

wp config create --dbname=db_name --dbuser='username' --dbpass='password' --dbhost='127.0.0.1'

Placing DB user, password, and host in single quotes worked. The same goes for the core install command.

I didn't see this in any of the docs or the CLI help text.

https://developer.wordpress.org/cli/commands/config/create/
https://developer.wordpress.org/cli/commands/core/install/

WP-CLI detecting wp-config.php in parent folder could cause command to fail

The case:

Let's say I'm having a WordPress installation which is not working for some reason or WordPress installation leftovers in public_html/. Meanwhile I want to install and configure WordPress in public_html/some-random-subfolder using WP-CLI. I download and place the files in the subfolder, prepare DB and try to

wp config create

The action fails with:

wp config create --dbname=test --dbuser=test --dbpass=test --dbhost=127.0.0.1
Error: The 'wp-config.php' file already exists.

Here is what I have in the wp-config.php in the parent folder:

cat ../wp-config.php 
<?php

echo "some broken or custom wp-config.php file";
require_once(__DIR__.'/wp-config-CUSTOM.php');

Additionally, all other WP-CLI commands except wp --info are also failing:

wp core
Error: Strange wp-config.php file: wp-settings.php is not loaded directly.

If there's no wp-config.php in the parent dir - it works:

ll ../wp-config*
ls: cannot access '../wp-config*': No such file or directory

wp config create --dbname=test --dbuser=test --dbpass=test --dbhost=127.0.0.1
ERROR 1045 (28000): Access denied for user 'test'@'localhost' (using password: YES)

(DB error above is normal, there's no such DB but the point is that I don't receive the wp-config.php related error)

If there is a valid WordPress application with a proper wp-config.php - it works as well.

So, the issue is if there is invalid wp-config/leftovers in the parent directory - this prevents me to configure a new, separate, independent WordPress app using WP-CLI in a sub-folder.

I've tested that on different 2 different stacks - LAMP and LEMP - the behaviour is the same.

Maybe it would be a good idea commands like "config", "core", etc. which could be related to installing and configuring separate application to be independent from the anything else than the files in the current folder?

@-prefixed hash' key (aliases): valid YAML?

I try to dynamically generate/edit ~/.wp-cli/config.yml and need to parse this file.
I expect it to be valid YAML but it seems it's not:

$ cat ~/.wp-cli/config.yml

disabled_commands:
  - db drop
@ae:
  path: /web/wp

$ python3 -c "import os,yaml; x = yaml.load(open(os.path.expanduser('~/.wp-cli/config.yml'), 'r').read());"

yaml.scanner.ScannerError: while scanning for the next token
found character '@' that cannot start any token
  in "<unicode string>", line 3, column 1:
    @ae:
    ^

Where would YAML specifically allow the "@" character as a dictionary key?
Any documentation/clarification on this?

`shuffle-salts` doesn't regenerate `WP_CACHE_KEY_SALT`

Hi guys

Describe the current, buggy behavior
Running wp config shuffle-salts regenerates all salts except WP_CACHE_KEY_SALT

Describe what you would expect as the correct outcome
All salts should be regenerated by the shuffle-salts command.

Possible solution
Check if WP_CACHE_KEY_SALT is present, and if true then regenerate key

Context
I'm using a custom wp-config.php template with placeholders for deployment so I can't use wp config create. I'm using sed to replace database credential placeholders and and wp config shuffle-salts to add unique salts. This system works well except for the fact that WP_CACHE_KEY_SALT isn't shuffled. I realise WP_CACHE_KEY_SALT isn't in the standard wp-config.php file, however it is present in all wp-config.php files created with wp config create . Therefore I think it makes sense for wp config shuffle-salts to also handle its regeneration.

Cheers!

"Inherit" option does not appear to apply to nested folders below config file

Given a Trellis/Bedrock project with the following folder structure:

.
├── wp-cli.local.yml
├── site
│   ├── wp-cli.yml
│   └── web
│       ├── app
│       │   ├── themes
│       │   ├── upgrade
│       │   └── uploads
│       └── wp
│           ├── wp-admin
│           ├── wp-content
│           └── wp-includes
└── trellis
# wp-cli.local.yml
@dev:
  ssh: [email protected]/srv/www/example.com/current
  path: web/wp
# wp-cli.yml
path: web/wp

_:
  inherit: ../wp-cli.local.yml

I would expect the alias @dev to be available in any folder below /site

# ./site
$ wp cli alias
---
@all: Run command against every registered alias.
@otherdev:
  ssh: [email protected]/srv/www/otherexample.com/current
@dev:
  path: web/wp
  ssh: [email protected]/srv/www/example.com/current

$ wp --info
OS:	Darwin 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
Shell:	/usr/local/bin/zsh
PHP binary:	/usr/local/Cellar/php/7.2.10/bin/php
PHP version:	7.2.10
php.ini used:	/usr/local/etc/php/7.2/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/jeremy/Projects/example.com/site
WP-CLI packages dir:	/Users/jeremy/.wp-cli/packages/
WP-CLI global config:	/Users/jeremy/.wp-cli/config.yml
WP-CLI project config:	/Users/jeremy/Projects/example.com/site/wp-cli.yml
WP-CLI version:	2.0.1

# ./site/web/app/themes/mytheme/
$ wp cli alias
---
@all: Run command against every registered alias.
@otherdev:
  ssh: [email protected]/srv/www/otherexample.com/current

$ wp @dev --info
Error: Alias '@dev' not found.
Did you mean '@otherdev'?

$ wp --info
OS:	Darwin 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
Shell:	/usr/local/bin/zsh
PHP binary:	/usr/local/Cellar/php/7.2.10/bin/php
PHP version:	7.2.10
php.ini used:	/usr/local/etc/php/7.2/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/Users/jeremy/Projects/example.com/site/web/app/themes/mytheme
WP-CLI packages dir:	/Users/jeremy/.wp-cli/packages/
WP-CLI global config:	/Users/jeremy/.wp-cli/config.yml
WP-CLI project config:	/Users/jeremy/Projects/example.com/site/wp-cli.yml
WP-CLI version:	2.0.1

Given WP-CLI shows the same project config, and the alias works in the folder the config is in, it seems the "inherit" option is not read/discovered from above the current working directory.

This is an atypical use case, and obviously not a standard WP install, so let me know if there's a "default" local dev setup you'd like me to try.

Make clear that --dbname and --dbuser are mandatory when using wp config create

When using:

wp core download --locale=en_GB && wp config create

it returns an error:

Error: Parameter errors:
 missing --dbname parameter (Set the database name.)
 missing --dbuser parameter (Set the database user.)

The documentation and/or the error message should make clear that those missing parameters are mandatory.

Even when we use --skip-check it returns the same error:

wp core download --locale=en_GB && wp config create --skip-check

Error: Parameter errors:
 missing --dbname parameter (Set the database name.)
 missing --dbuser parameter (Set the database user.)

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
  1. 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"
  1. 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:

DB-Check fails if Database requires SSL

Bug Report

Describe the current, buggy behavior
Executing any config-command, that checks the database, e.g. wp config create will result in the following error, if the database requires SSL:
ERROR 9002 (28000): SSL connection is required. Please specify SSL options and retry.

Even if you specify:

--extra-php <<PHP
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
PHP

...because the check is not using PHP, but rather:

// Check DB connection.
		if ( ! Utils\get_flag_value( $assoc_args, 'skip-check' ) ) {
			Utils\run_mysql_command( '/usr/bin/env mysql --no-defaults', $mysql_db_connection_args );
		}

(where mysql_db_connection_args is hardcoded)
and there is currently no way to specify/inject an addition parameter like --ssl!

Describe how other contributors can replicate this bug

Create a MySQL-DB that requires SSL (for Azure-MySQL there is button "Enforce SSL connection")
And then try wp config create with valid credentials.

Describe what you would expect as the correct outcome
Working MySQL-Connection.

Let us know what environment you are running this on
environment independent.

Provide a possible solution

Either respect the addition PHP define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL); or provide a parameter to enable SSL!
wp db export seems to have such an option: wp-cli/db-command#126 (comment)

wp config has - Does not return response

Using wp-cli 1.5.0 on a multisite instance from a root user with flag --allow-root and full path to wp install specified - I do not receive any response from calling this command either for settings known not to exist in wp-config.php or for those known to exist.

Missing values in `wp config get`

There are some missing values in wp config get in my composer WordPress setup.

  • WP_CONTENT_URL
  • WP_HOME
  • WP_SITEURL

These constants seem to be broken, maybe through my composer setup or multi enviroment configs.

wp-config.txt
wp-config.default.txt

| key              | value                                                            | type     |
+------------------+------------------------------------------------------------------+----------+
| table_prefix     | prefix_                                                          | variable |
| WP_ENV           | development                                                      | constant |
| DB_CHARSET       | utf8mb4                                                          | constant |
| DB_COLLATE       |                                                                  | constant |
| AUTH_KEY         | xxx                                                              | constant |
| SECURE_AUTH_KEY  | xxx                                                              | constant |
| NONCE_KEY        | xxx                                                              | constant |
| AUTH_SALT        | xxx                                                              | constant |
| SECURE_AUTH_SALT | xxx                                                              | constant |
| LOGGED_IN_SALT   | xxx                                                              | constant |
| NONCE_SALT       | xxx                                                              | constant |
| WP_CONTENT_DIR   | /Users/ralfhortt/Sites/xxx/public/wp-content                     | constant |
| WP_CONTENT_URL   | http:///wp-content                                               | constant |
| WP_HOME          | http://                                                          | constant |
| WP_SITEURL       | http:///wp                                                       | constant |
| FS_METHOD        | direct                                                           | constant |
| DB_NAME          | Test Database                                                    | constant |
| DB_USER          | xxxx                                                             | constant |
| DB_PASSWORD      | xxx                                                              | constant |
| DB_HOST          | localhost                                                        | constant |
| WP_DEBUG         | 1                                                                | constant |
+------------------+------------------------------------------------------------------+----------+```

`wp config create`: passwords with single quotes breaks wp-config.php

Bug Report

Describe the current, buggy behavior

When creating a new wp-config.php file with a password containing single quotes, the resulting wp-config.php file is invalid and produces a PHP syntax error.

Describe how other contributors can replicate this bug

  • Create a new Database and a new Database User (e.g.: wpdb / wpuser)
  • Create a new directory (wordpress)
  • Download WordPress (wp core download ...)
  • Create config file with a password containing single quotes: wp config create --dbname=wpdb --dbuser=wpuser --dbpass=".bWWd}6B3X E-gv9BYEjpH9 w+'Pq5" --dbhost=127.0.0.1

Success: Generated 'wp-config.php' file.

Content of the wp-config.php:

...
define( 'DB_PASSWORD', '.bWWd}6B3X E-gv9BYEjpH9 w+'Pq5' );
...
$ php -l wp-config.php
PHP Parse error:  syntax error, unexpected 'Pq5' (T_STRING), expecting ')' in wp-config.php on line 29
Errors parsing wp-config.php

Describe what you would expect as the correct outcome

The value of the DB_PASSWORD constant should be escaped:

define( 'DB_PASSWORD', '.bWWd}6B3X E-gv9BYEjpH9 w+\'Pq5' );

Let us know what environment you are running this on

wp cli info
OS:	Linux 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php7.3
PHP version:	7.3.7-1+ubuntu18.04.1+deb.sury.org+1
php.ini used:	/etc/php/7.3/cli/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/home/site1/sites/wpapp/public
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.2.0

Provide a possible solution

A possible solution would be to escape the single quote character in the wp-config.php file.

Default `--type=<type>` to 'constant'

Given the majority use-case for the wp-config.php file is to act as a store of constants, it would be helpful to default --type=<type> to 'constant'.

Missing documentation: special flag `--anchor=EOF`

In wp-cli/wp-config-transformer#23 we added special behavior for the anchor selection to allow the user to specify the end of file.

This can be use by passing the special EOF value to the flag: --anchor=EOF.

We forgot to add documentation to the config command in all the places where an --anchor flag is accepted. This special case handling should be added to all the corresponding docblocks.

Config parser does not include dependencies

One of my wp-config.php files makes a (legitimate) add_filter() call, however wp-cli can't handle it:

➜  PhpstormProjects wp --ssh=hakre config get --format=json | jq .
PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /home/hakre/.config/composer/vendor/wp-cli/config-command/src/Config_Command.php(250) : eval()'d code:93
Stack trace:
#0 /home/hakre/.config/composer/vendor/wp-cli/config-command/src/Config_Command.php(250): eval()
#1 [internal function]: Config_Command->get(Array, Array)
#2 /home/hakre/.config/composer/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(87): call_user_func(Array, Array, Array)
#3 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#4 /home/hakre/.config/composer/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(421): call_user_func(Object(Closure), Array, Array)
#5 /home/hakre/.config/composer/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(336): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#6 /home/hakre/.config/composer/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(343): WP_CLI\Runner->run_command(Array, Array)
#7 /home/hakre/.config/composer/vendor/wp-cli/wp-cli/php/WP_C in /home/hakre/.config/composer/vendor/wp-cli/config-command/src/Config_Command.php(250) : eval()'d code on line 93

Add --format=env option to config get command

Feature Request

Describe the solution you'd like

Currently the --format options are var_export, json, and yaml. It would be nice to have an env option here as well, which would print something like this:

DB_NAME=wp_site
DB_USER=wp_user
DB_PASSWORD=123123

deleting a constant with concatenated function deletes much more

Bug Report

Describe the current, buggy behavior

Deleting a constant with concatenated function from wp-config.php with wp config delete deletes more than just that constant.

Describe how other contributors can replicate this bug

  • A wp-config.php file with a constant definition concatenating a function, like in my example
  • Run wp config delete USER_PATH
<?php

define( 'WP_DEBUG', false );

define( 'USER_PATH', '/var/www/' . get_current_user() );

define( 'THIS_AND', md5( 'that' ) );

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

define( 'DISABLE_WP_CRON', true );

/* That's all, stop editing! Happy publishing. */

Describe what you would expect as the correct outcome

wp-config.php with just USER_PATH constant definition removed.

Let us know what environment you are running this on

OS:	Linux 4.9.184-linuxkit #1 SMP Tue Jul 2 22:58:16 UTC 2019 x86_64
Shell:
PHP binary:	/usr/local/bin/php
PHP version:	7.3.11
php.ini used:	/usr/local/etc/php/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/var/www/html
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.4.0

env: mysql: No such file or directory

Getting this error env: mysql: No such file or directory when I attempt wp config create . I am using MAMP and otherwise everything seems to be working fine. The plan was to wp core download , wp config create , wp core install .

Allow using own template for `wp-config.php`

I use env variables where storing secret data (example DB_NAME, DB_USER, AUTH_KEY and etc) and want to use define( 'DB_NAME', getenv('DB_NAME') );.

It will be great if i can to use own template for wp-config.php.

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

Handle old `config get` syntax gracefully

The wp config get syntax has changed, breaking BC.

Although the command is rather recent and might not have been used much in scripting, we should look into providing graceful handling of the old syntax.

wp config get --global=<global> => wp config get <key> --type=variable
wp config get --constant=<constant> => wp config get <key> --type=constant
wp config get => wp config list

Refactor config command to always validate in config transformer library

Right now we have two separate code paths that deal with setting values in the wp-config.php file. While we created a new library wp-cli/wp-config-transformer to deal with config file manipulations, we still have old commands like wp config create that use their own logic to set the config values.

This means that for any validation logic we want to provide, we'd need to include it into both code paths.

To improve this situation, I'd like to refactor the old wp config create command to just render the mustache template with default values, and then pass all provided arguments through wp-cli/wp-config-transformer to set the config entries to the requested values. This way, we can concentrate all actual validation logic in wp-cli/wp-config-transformer, and the commands are all just shallow wrappings around that library.

cc @fjarrett

Indicate files included from wp-config.php

Similar to variables and constants, it would be neat to indicate which files are included from wp-config.php

We can use get_included_files(), and compare the results from before to after, similar to the existing logic from #9

Get the value of a specific constant or global

As a WP-CLI user, it would be helpful if I could get the value of a specific constant or global out of wp-config.php.

The syntax could be wp config get --constant=DB_NAME and wp config get --global=table_prefix

If I use either --constant=<constant> or --global=<global>, WP-CLI should simply print the value.

From #14 (comment)

Doesn't work if comment in line above

Bug Report

Describe the current, buggy behavior

File contains:

// Enable test
define( 'WP_DEBUG', true );

I run:
wp config set WP_DEBUG false --raw --type=constant

Then it won't change to false.
When I remove the comment in the line above it works fine.

Describe what you would expect as the correct outcome

That cli changes the define "true" to "false"

Let us know what environment you are running this on

OS: Centos7
Shell:  bash
PHP version:    7.0.x
php.ini used:
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       /some/path
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.0.1

WordPress become blank page after setting WP_MEMORY_LIMIT

After I tried
wp config set WP_MEMORY_LIMIT 100M --raw --path=/path/to/wp/root --quiet --allow-root
I found wp-cli will add one line like this below
define( 'WP_MEMORY_LIMIT', 100M );

But the wrong is that, 「100M」should be quoted like this:
define( 'WP_MEMORY_LIMIT', '100M' );
or WordPress could not figure out what we want to do, and then lead to error, even blank page.

Test environment: Ubuntu 18.04.2 LTS, WordPress 5.1, php 7.3, wp-cli 2

errors updating shuffle-salts

I run several wordpress sites and after a Wordpress meetup someone mentioned that it might be worth for security reasons to update salts in wp-config. I am running a script to run wp-cli config shuffle-salts. When most times is working I am finding out that sometimes there are lines that get parse errors similar to this one:

define( 'LOGGED_IN_SALT', 'BLABLABLA');'BLABLABLA');

so inserting some code right after ; and breaking website.

It has happened to me in several sites so maybe If I have to take into account something when issueing this command

Abstract `config set --add` to `config add`

config set --add is a deviation from our standard syntax. Typically, set and add are two separate operations (e.g. option set vs. option add, and cache set vs. cache add).

It'd be better to abstract config set --add to config add.

We may also consider a config update, which would add the constant if it didn't exist, or update it if it did.

Issue writing change when previous line ends with a //comment

Not sure if this belongs here or with wp-config-transformer, but I've encountered an issue when trying to modify a line that comes directly after a line ending with a //comment with no newline in between.

Example configuration block:

<?php

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('WP_CACHE', true); //Added by WP-Cache Manager
define( 'WPCACHEHOME', '/var/www/html/ex/example.com/wp-content/plugins/wp-super-cache/' ); //Added by WP-Cache Manager
wp config get WPCACHEHOME
/var/www/html/ex/example.com/wp-content/plugins/wp-super-cache/

wp config set WPCACHEHOME test
Success: Updated the constant 'WPCACHEHOME' in the 'wp-config.php' file with the value 'test'.

wp config get WPCACHEHOME
/var/www/html/ex/example.com/wp-content/plugins/wp-super-cache/

If I either:

  • Remove the //Added by WP-Cache Manager comment
  • Put a newline between the WP_CACHE and WPCACHEHOME line

Then it works as expected. This happens with anything that modifies (such as delete) and not just with the set command. Some further testing shows that the file is never opened for writing when this happens, despite being returned as successfully changed:

strace -e open,close wp config delete WPCACHEHOME 2>&1 |grep wp-config.php

open("/var/www/html/ex/example.com/test/wp-config.php", O_RDONLY|O_LARGEFILE) = 4
open("/var/www/html/ex/example.com/test/wp-config.php", O_RDONLY|O_LARGEFILE) = 4
open("/var/www/html/ex/example.com/test/wp-config.php", O_RDONLY|O_LARGEFILE) = 4
Success: Deleted the constant 'WPCACHEHOME' from the 'wp-config.php' file.

wp config get WPCACHEHOME
/var/www/html/ex/example.com/wp-content/plugins/wp-super-cache/

Using PHP 7.0.29 and WP CLI 1.5.0

Misconfiguration composer.json (no php version)

Bug Report

Describe the current, buggy behavior

This command doesn't have any PHP requirement, so I expect that PHP version is the same as in wp-cli/wp-cli (for example).

WP-CLI declares that it is supported php: ^5.4 || ^7.0.

The current version of the command contains code that only works with PHP 5.6, so I can install an incompatible version on PHP 5.4 via composer.

Describe how other contributors can replicate this bug

  • Obtain config-command v2.0.7+ and wp-cli v2+
  • Try to run any subcommand of config command on php 5.4 or 5.5

Fatal error: Arrays are not allowed in class constants in ...

Describe what you would expect as the correct outcome

I expect that composer.json contains php requirement (for composer to install a compatible version of the package) or this command works on wp-cli requirements.

Let us know what environment you are running this on

php 5.5 or 5.4

Provide a possible solution

I have no idea because older versions are affected too.

Provide additional context/Screenshots

70dbaa2#diff-8c43ee4439224cdb788f81713eb643ad21b61840572cec8399362df9f2ec1795

https://packagist.org/packages/wp-cli/wp-cli#v2.4.1
https://packagist.org/packages/wp-cli/config-command#v2.0.7

wp config create results in broken wp-config.php

The command wp config create --dbname=testwpcli --dbuser=root --dbpass=root results in a broken wp-config.php as the word Array in inserted above /* That's all, stop editing! Happy blogging. */. (See wp-config.php.txt, line 67. – Had to upload file as txt-file to attach it.)

Opening the website in the browser brings a white screen of death. wp core install with parameters doesn't get executed.

Looking at the file templates/wp-config.mustache I assume the variable {{extra-php}} isn't used correctly.

Tested on local webserver (MAMP on MacOS, PHP 7.2.1), using WP-CLI 1.5.1.

wp config [any command] puts a newline between each line in my wp-config.php files

wp config [any command] puts a newline between each line in my wp-config.php files

I install WP-CLI as follows because all WordPress folders are owned by www-data:

sudo wget -qO /usr/local/bin/wp-cli https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
sudo chmod +x /usr/local/bin/wp-cli
sudo tee /usr/local/bin/wp >/dev/null <<'EOF'
sudo runuser -u www-data -- wp-cli $@
EOF
sudo chmod +x /usr/local/bin/wp

Both wrapper commands sudo runuser -u www-data -- wp-cli $@ and sudo -u www-data -- wp-cli $@ do this.
sudo -u www-data -i -- wp-cli $@ gives me this output: This account is currently not available.

The commands I ran so far that put a newline between each line in wp-config.php are:

wp --path=/var/www/$domain/htdocs config shuffle-salts
wp --path=/var/www/$domain/htdocs config set CLOUDFLARE_HTTP2_SERVER_PUSH_ACTIVE true

I think it is a bug? Any help will be appreciated! Thanks in advance!

Create `wp config get` to list configuration defined in parsed wp-config.php

As a WordPress developer, it would be helpful to have a wp config get command to list configuration defined in parsed wp-config.php

This command could contain both constants and PHP global variables defined in wp-config.php. We can take a similar approach to WP_CLI\Runner in identifying this data:

// Load wp-config.php code, in the global scope
$wp_cli_original_defined_vars = get_defined_vars();
eval( $this->get_wp_config_code() );
foreach( get_defined_vars() as $key => $var ) {
	if ( array_key_exists( $key, $wp_cli_original_defined_vars ) || 'wp_cli_original_defined_vars' === $key ) {
		continue;
	}
	global $$key;
	$$key = $var;
}

Previously wp-cli/wp-cli#3831

Move command over to new v2 structure

The following changes need to be made to move the command over to the v2 structure:

  • Make sure the correct framework is required:
    composer require wp-cli/wp-cli:^2
    
  • Require the testing framework as a dev dependency:
    composer require --dev wp-cli/wp-cli-tests:^0
    
  • Use the .travis.yml file from wp-cli/wp-cli:
    wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
    
  • Add the default script configuration to Composer file:
      "scripts": {
          "lint": "run-linter-tests",
          "phpcs": "run-phpcs-tests",
          "phpunit": "run-php-unit-tests",
          "behat": "run-behat-tests",
          "prepare-tests": "install-package-tests",
          "test": [
              "@lint",
              "@phpcs",
              "@phpunit",
              "@behat"
          ]
      },
    
  • Remove scaffolded binary files:
    git rm bin/install-package-tests.sh
    git rm bin/test.sh
    
  • Remove scaffolded Behat setup:
    git rm features/bootstrap/*
    git rm features/extra/*
    git rm features/steps/*
    
  • Remove scaffolded Behat tags util script:
    git rm utils/behat-tags.php
    
  • Add command packages that are needed for Behat tests as --dev dependencies.
    The following commands are already available, anything else needs to be explicitly required:
    • cli *
    • config *
    • core *
    • eval
    • eval-file
    • help
  • Update all dependencies:
    composer update
    
  • Optional - Add PHPCS rule set to enable CS & compatibility sniffing:
    wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
    
  • Run and adapt tests to make sure they all pass:
    composer test
    

Error: Could not create new 'wp-config.php' file.

Hello!

I have strange problem. I can't create new wp-config.php file. I'm getting error which is probably related to code:

$bytes_written = file_put_contents( ABSPATH . 'wp-config.php', $out );
		if ( ! $bytes_written ) {
			WP_CLI::error( "Could not create new 'wp-config.php' file." );
		} else {
			WP_CLI::success( "Generated 'wp-config.php' file." );
		}

Error:

[06:09:35] [root@a1 tcwp]# ./wp-cli --allow-root config create --dbname=test --dbuser=test--force --skip-check --debug
Debug (bootstrap): No readable global config found (0.097s)
Debug (bootstrap): No project config found (0.098s)
Debug (bootstrap): argv: ./wp-cli --allow-root config create --dbname=test --dbuser=test --force --skip-check --debug (0.098s)
Debug (bootstrap): ABSPATH defined: /var/www/tcwp/ (0.099s)
Debug (bootstrap): Running command: config create (0.1s)
Error: Could not create new 'wp-config.php' file.

In error_log I have found:

PHP Warning:  file_get_contents(phar://wp-cli.phar/templates/phar://wp-cli/vendor/wp-cli/config-command/templates/wp-config.mustache): failed to open stream: phar error: "templates/phar:/wp-cli/vendor/wp-cli/config-command/templates/wp-config.mustache" is not a file in phar "wp-cli.phar" in phar:///home/mateuszdemo/public_html/wp-cli/php/utils.php on line 457

wp-cli is generating empty file. I don't know why it is not working. I have tested this on:

System: CentOS release 6.9 (Final)

PHP (without suhosin):

PHP 7.1.9 (cli) (built: Sep 11 2017 16:59:11) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.1.9, Copyright (c) 1999-2017, by Zend Technologies

WordPress: 4.8.2

`wp config create` would benefit from clear path to defer all parameter initialization.

It would seem to me that the optional/required parameters for wp config create are a little overbearing, especially considering the capabilities of wp config set. I don't see a strong reason why all of the parameters shouldn't be optional.

Verification is important, but given the wide variety of environments out there, the host/user only requirement seems very over/under in regards to actually having all the info to verify a connection (I'm assuming the purpose of them being required is to conduct that test).

Given the kitchen sink list of parameters possibly required, and the comparative ease of use of wp config set. It would be nice if there was an official, clearly indicated way to jump over to the for-each usage style.

I would prefer a flag that indicates this intention and skips the checks, but the command documentation could more clearly steer users to this possibility, as well.

I'm sure many users, like myself, are also interested in simplifying the injection of these parameters from the environment variables already present in their Docker container. At that point, you are already for-eaching in a bunch of (possibly missing) parameters, so why not include the other two.

To illustrate my process/point:


If setting up an environment like this:

$ docker run -it --rm wordpress:cli bash

bash-5.1$ wp core download --skip-content

Downloading WordPress 5.7 (en_US)...
md5 hash verified: b3033cdce55dd8c9af9eaed9233475d4
Success: WordPress downloaded.

This use case should have a shorthand flag, i.e. wp config create --template.

bash-5.1$ wp --skip-check config create --dbname= --dbuser=

Success: Generated 'wp-config.php' file.

To support setting all parameters in a for-each style like this (unrolled for clarity):

bash-5.1$ wp config set DB_NAME wordpress
Success: Updated the constant 'DB_NAME' in the 'wp-config.php' file with the value 'wordpress'.
bash-5.1$ wp config set DB_USER root
Success: Updated the constant 'DB_USER' in the 'wp-config.php' file with the value 'root'.
bash-5.1$ wp config set DB_PASSWORD example
Success: Updated the constant 'DB_PASSWORD' in the 'wp-config.php' file with the value 'example'.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.