Bug Report

• 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

When doing any command in wp shell when SSH'd into a remote server, I get a path to the WP-CLI REPL file returned to me before the correct output.

Describe how other contributors can replicate this bug

wp> wp_revisions_to_keep( get_post( 3451690 ) );
=> phar:///root/roles/docker-container-web/usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php:52:
int(50)

Describe what you would expect as the correct outcome

That this path should not appear when using the simplistic REPL.

wp> wp_revisions_to_keep( get_post( 3451690 ) );
int(50)

Let us know what environment you are running this on

OS:	Linux 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64
Shell:	/bin/bash
PHP binary:	/root/roles/nginx-php/usr/local/php7.3/bin.stretch/php
PHP version:	7.3.16
php.ini used:	/usr/local/php7.3/conf/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/vipdev
WP-CLI packages dir:	/home/{redacted}/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.4.0

Provide a possible solution

Maybe remove or fix this var_dump()?

Steps to reproduce:

1. Execute these commands:

wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "100"
wp> update_post_meta( 139, '_price', 200 )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
bool(true)
wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "200"

2. Leave the wp shell running in background, and in a different session run this DB query:

mysql> update wp_postmeta set meta_value = '123' where post_id = 139 and meta_key = '_price';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

3. Go back to the wp shell, and run this:

wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "200"
wp> 

If you close and open wp shell again, it will return the correct value:

boro@bor0:~/dev/www/wordpress$ wp shell
wp> get_post_meta( 139, '_price', true )
=> phar:///Users/boro/bin/wp/php/WP_CLI/REPL.php:43:
string(3) "123"
wp> 

Feature Request

• Yes, I reviewed the contribution guidelines.

When dealing with complex queries, WP Shell often dumps large volumes of data on to my screen.

For example, running a query with 'posts_per_page'=> 200, will result in hundreds of blog posts being printed. But I only want, say, the GUID.

Describe the solution you'd like

I'd like a command-line option so that wp shell --no-output will only display what I explicitly echo.

Current version:

wp shell
wp> $a = "hello";
=> string(5) "hello"

Proposed version:

wp shell --no-output
wp> $a = "hello";
wp>

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
  

Feature Request

Add support for default shell on OpenBSD (ksh).

Describe your use case and the problem you are facing

Trying to use wp shell cmd under OpenBSD results in errors and exits prematurely.

$ wp shell
/bin/ksh: fc: history functions not available
/bin/ksh: read: -e: unknown option
$ echo $?
0

$ wp cli info
OS:     OpenBSD 6.6 GENERIC.MP#584 amd64
Shell:  /bin/ksh
PHP binary:     /usr/local/bin/php-7.3
PHP version:    7.3.13
php.ini used:   /etc/php-7.3.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/htdocs
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.4.0
$ env | grep WP_CLI_CUSTOM_SHELL
WP_CLI_CUSTOM_SHELL=/bin/ksh

Describe the solution you'd like

Quick win:

Add some more detection at shell instantiation to detect shell and platform to enable running in ksh on OpenBSD.

Nice to have:

Test in a few different shell/OS environments and modify to run across more - else, fail gracefully when unsupported.

Happy to work on this

Right now, using PsySH as the alternative shell implementation requires a rather technical change to the internals of WP-CLI:

• Either completely install WP-CLI through Composer, instead of using the Phar
• Or directly edit the ~/.wp-cli/packages/composer.json file

I'd like to create a new package wp-cli/shell-psysh that you can just install through the WP-CLI package manager to replace the default shell instead (naming of the package up for discussion of course).

In the documentation on WordPress.org, the flag --basic is described as follows:

[--basic]
Start in fail-safe mode, even if Boris is available.

What is Boris?

Originally reported by @hiobama in #34:

If exit wp-shell by ctrl + c, some processes will always running there, never give up, slow down your computer.

wp> namespace dustinpaluch { }
PHP Parse error:  syntax error, unexpected 'dustinpaluch' (T_STRING), expecting \\ (T_NS_SEPARATOR) in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/REPL.php(37) : eval()'d code on line 1

I'm trying to reproduce a bug involving namespaces, wp actions, and anonymous functions, and was hoping I'd be able to use the wp shell to make a minimal test case.

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

Making typos/etc often results in a fatal error, and the session crashes and has to be restarted. After restarting, I have to recreate any variables, includes, etc from scratch, without making any fatal errors. That often makes it just too frustrating to use.

> wp shell
wp> require 'foo.txt';
Warning: require(foo.txt): Failed to open stream: No such file or directory in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code on line 1
Fatal error: Uncaught Error: Failed opening required 'foo.txt' (include_path='.:/usr/local/Cellar/php/8.0.0_1/share/php/pear') in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code:1
Stack trace:
#0 phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32): eval()
#1 phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/Shell_Command.php(51): WP_CLI\Shell\REPL->start()
#2 [internal function]: Shell_Command->__invoke(Array, Array)
#3 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(98): call_user_func(Array, Array, Array)
#4 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array)
#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(451): call_user_func(Object(Closure), Array, Array)
#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(371): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#7 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(394): WP_CLI\Runner->run_command(Array, Array)
#8 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1160): WP_CLI\Runner->run_command_and_exit()
#9 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#10 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(74): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#11 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(27): WP_CLI\bootstrap()
#12 phar:///usr/local/bin/wp/php/boot-phar.php(11): include('phar:///usr/loc...')
#13 /usr/local/bin/wp(4): include('phar:///usr/loc...')
#14 {main}
  thrown in phar:///usr/local/bin/wp/vendor/wp-cli/shell-command/src/WP_CLI/Shell/REPL.php(32) : eval()'d code on line 1
Error: There has been a critical error on this website.Learn more about debugging in WordPress. There has been a critical error on this website.

Describe the solution you'd like

PHP's REPL is able to catch fatals and continue running:

php > $foo = 'stuff';
php > echo $foo;
stuff
php > require 'foo.txt';

Warning: require(foo.txt): Failed to open stream: No such file or directory in php shell code on line 1

Warning: Uncaught Error: Failed opening required 'foo.txt' (include_path='.:/usr/local/Cellar/php/8.0.0_1/share/php/pear') in php shell code:1
Stack trace:
#0 {main}
  thrown in php shell code on line 1
php > echo $foo;
stuff

Is that possible for wp shell ?

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:

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

Hi
When i try, to use 'use statement', shell exited with not message error.
I'm use themosis framework to develop a plugin. I'm try to prototype very basic code;

Thanks

I haven't had the chance to dig into this further, but just wanted to log this somewhere to prevent forgetting about it.

Assigning a value to $line in wp shell gives very unexpected results, causing some pretty confusing behavior and bugs.

Behavior:

wp shell

wp> $line = 'this wont work';
=> string(14) 'this wont work'
wp> $line;
=> string(13) "return $line;"

wp> $linetest = 'this will';
=> string(9) "this will"
wp> $linetest;
=> string(9) "this will"