subcommands use underscores when using wp-cli + php 5.5

[boreal321]

All the subcommands on a machine with php 5.5 are listed with underscores instead of the usual dashes. Some subcommands are being cutoff so only part of the subcommand is shown and the cutoff string is what needs to be typed to get the subcommand to execute. I'm seeing this behaviour on a debian 7.5 system running PHP 5.5.13-1~dotdeb.1 (cli) (built: Jun 14 2014 22:10:33) and both wp-cli version 0.15 and 0.15.1

Here's the output of the command wp core

# wp core
usage: wp core config 
   or: wp core download 
   or: wp core install 
   or: wp core is_installed 
   or: wp core multisite_convert 
   or: wp core multisite_install 
   or: wp core update 
   or: wp core update_db 
   or: wp core version

Here's wp user:

# wp user
usage: wp user add_cap 
   or: wp user add_role 
   or: wp user create 
   or: wp user delete 
   or: wp user generate 
   or: wp user get 
   or: wp user import_csv 
   or: wp user list_ 
   or: wp user list_caps 
   or: wp user meta <command>
   or: wp user remove_cap 
   or: wp user remove_role 
   or: wp user set_role 
   or: wp user update 

To get a list of users I actually need to type

wp user list_

On systems running php 5.4 and 5.3 the output looks like this:

# wp core
usage: wp core config --dbname=<dbname> --dbuser=<dbuser> [--dbpass=<dbpass>] [--dbhost=<dbhost>] [--dbprefix=<dbprefix>] [--dbcharset=<dbcharset>] [--dbcollate=<dbcollate>] [--locale=<locale>] [--extra-php] [--skip-salts] [--skip-check]
   or: wp core download [--path=<path>] [--locale=<locale>] [--version=<version>] [--force]
   or: wp core install --url=<url> --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core is-installed [--network]
   or: wp core multisite-convert [--title=<network-title>] [--base=<url-path>] [--subdomains]
   or: wp core multisite-install [--url=<url>] [--base=<url-path>] [--subdomains] --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core update [<zip>] [--version=<version>] [--force] [--locale=<locale>]
   or: wp core update-db 
   or: wp core version [--extra]

Anyone know what's going on?

[jmslbam]

Hi @boreal, quite the scooby doo mystery, because the CI tests here on GitHub do use 5.5 to test against.

Do you have some possible already to use vagrant boxes / files to test on?

[boreal321]

Hi @jmslbam!

Yes, I can install a vagrant based VM. Do you have a vagrantfile I can use?

BTW, I've tested this on 2 different VMs. One on Digital Ocean and the other on some private hardware running Xen. Exactly the same results. Odd eh. Or as Scoob would say, "Ruh roh, Raggy!"

Could I be missing a PHP module? Are the full requirements for wp-cli available anywhere?

[QWp6t]

It works as expected for me in PHP 5.5.13 on CentOS x86-64

[05:53 PM]-[vagrant@localhost]-[~] 
$ wp core
usage: wp core config --dbname=<dbname> --dbuser=<dbuser> [--dbpass=<dbpass>] [--dbhost=<dbhost>] [--dbprefix=<dbprefix>] [--dbcharset=<dbcharset>] [--dbcollate=<dbcollate>] [--locale=<locale>] [--extra-php] [--skip-salts] [--skip-check]
   or: wp core download [--path=<path>] [--locale=<locale>] [--version=<version>] [--force]
   or: wp core install --url=<url> --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core is-installed [--network]
   or: wp core multisite-convert [--title=<network-title>] [--base=<url-path>] [--subdomains]
   or: wp core multisite-install [--url=<url>] [--base=<url-path>] [--subdomains] --title=<site-title> --admin_user=<username> --admin_password=<password> --admin_email=<email>
   or: wp core update [<zip>] [--version=<version>] [--force] [--locale=<locale>]
   or: wp core update-db 
   or: wp core version [--extra]

See 'wp help core <command>' for more information on a specific command.

[05:54 AM]-[vagrant@localhost]-[~] 
$ php -v
PHP 5.5.13 (cli) (built: Jun  5 2014 16:44:19) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

@boreal, if you don't mind doing php -i in your console and pasting it into pastebin or gist or something and linking it here, I can compare it with my own output and see if there are any differences between the two. (note: php -i dumps your environment variables as well, so be sure to scan it for any sensitive text)

[jmslbam]

Hi,

Victor, I phrased my question not so optimal. I hoped you would have a vagrant box. You can create a vagrant file with the online tool https://puphpet.com/ Because I don't know if you have Apache or nginx etc.

And what @QWp6t said would be a good one indeed.

Anyway the php functions are with underscore and the @subcommand set-role are shown in the help. It's something with the synopsis parser. Still looking into it where it exactly parses the @subcommand in the code. :)

[jmslbam]

So maybe you can try this one also : http://getprotobox.com/

[danielbachhuber]

WP-CLI uses Reflection to read the PHPdoc (ref 1, ref 2). What's happening is that WP-CLI is reading all of the class methods, but missing the PHPdoc for each. That's why the aliases are incorrect, arguments are missing, etc.

@boreal I don't have ready access to 5.5.13 at the moment. Mind doing a bit of debugging around this diagnosis?

[boreal321]

@danielbachhuber, you bet. Let me know what I can do.

[boreal321]

Here's the php -i output

https://gist.github.com/boreal/b5b1f9055d1e2c1d3bfe

[boreal321]

@danielbachhuber I'm not sure what I need to do to debug further. Reflection is built into PHP and there's no config associated so it would seem I have the required parts.

[danielbachhuber]

I think we need to do some one-on-one debugging. Ping me in IRC tomorrow or Thursday. We're #wordpress-cli

[boreal321]

@danielbachhuber, will do. Thanks!

[boreal321]

I spun up a new VM and ran my ansbile playbook on it task by task which helped me discover the culprit. Turns out it was the opcache.ini config that caused the issue. The default install of php includes an empty (or disabled) opcache.ini but my playbook copies a custom opcache config for the PHP-FPM service. The /etc/php5/cli/conf.d directory contains symlinks to the same mods-available directory as the fpm config so php on the command line loads the opcache module and config. After I deleted the symlink to the opcache.ini wp-cli started to produce the expected output.

[danielbachhuber]

@boreal glad you tracked it down! What specifically about the config was the culprit?

[boreal321]

Good question. I will re-enable the opcache for the cli and go through it line by line.

[boreal321]

opcache.save_comments = 0

Makes sense, eh. Setting it to 1 also fixes the issue. Here's my working config:

zend_extension=opcache.so opcache.memory_consumption=1024 opcache.interned_strings_buffer=16 opcache.max_accelerated_files=50000 opcache.save_comments=1 opcache.load_comments=0 opcache.fast_shutdown=1 opcache.revalidate_freq=60 opcache.enable_cli=1 opcache.error_log="/var/log/php-opcache-errors.log"

[boreal321]

Oops, forgot to mention... scooby dooby doo!

Guys, thanks for responding and not leaving me out to dry. This project is just so freakin great.

[danielbachhuber]

Happy to help :)

[jmslbam]

No problem and thanks Daniel!