wp theme status <theme-name> throws: Error: Couldn't find theme-status.mustache about wp-cli

[danielbachhuber]

@porg The latest stable seems to work fine for me...

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6831k  100 6831k    0     0  34.6M      0 --:--:-- --:--:-- --:--:-- 34.7M
$ php wp-cli.phar theme status "twentytwentythree"
Theme twentytwentythree details:
    Name: Twenty Twenty-Three
    Status: Active
    Version: 1.0 (Update available)
    Author: the WordPress team

Can you share wp --info? Maybe you have some odd PHP configuration?

[porg]

This is what I get on my shared webhosting service:

$ wp --info
OS:	Linux 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php8.0
PHP version:	8.0.28
php.ini used:	/etc/php/8.0/cli/php.ini
MySQL binary:	/usr/bin/mysql
MySQL version:	mysql  Ver 14.14 Distrib 5.7.40-43, for debian-linux-gnu (x86_64) using  7.0
SQL modes:	
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:	/data/web/customer-id
WP-CLI packages dir:	/data/web/customer-id/.wp-cli/packages/
WP-CLI cache dir:	/data/web/customer-id/.wp-cli/cache
WP-CLI global config:	/data/web/customer-id/.wp-cli/config.yml
WP-CLI project config:	
WP-CLI version:	2.10.0

[danielbachhuber]

My guess is that phar_safe_path() is failing:

https://github.com/wp-cli/extension-command/blob/80713703e090fbc74926af6f75bf963619f76fdb/src/Theme_Command.php#L886-L898

wp-cli/php/utils.php

Lines 1462 to 1473 in e516414

	function phar_safe_path( $path ) {
	if ( ! inside_phar() ) {
	return $path;
	}
	return str_replace(
	PHAR_STREAM_PREFIX . rtrim( WP_CLI_PHAR_PATH, '/' ) . '/',
	PHAR_STREAM_PREFIX,
	$path
	);
	}

Can you launch wp shell and share the return value of WP_CLI\Utils\inside_phar()?

[porg]

=> bool(true)

[danielbachhuber]

Huh!

Can you try re-downloading WP-CLI? What does md5 <wp-cli-path> give you?

[porg]

md5 not available in the shell of the webhost.

In the European evening I will download the binary via SFTP and then md5 on my computer.

[porg]

FYI: The current wp-cli binary has been installed via its own update mechanism wp cli update .

[porg]

$ wp cli version
WP-CLI 2.10.0
$ wp cli check-update
Success: WP-CLI is at the latest version.

md5 = 6710e90c3ed173925acd35ce5fe5aaf9

[porg]

$ wp cli update
Success: WP-CLI is at the latest version.

• There is no possibility to run wp cli update with a --force flag to re-download and re-install.
• I could run the curl oneliner to re-install. Shall I?
• Or shall I try the nightly?
• Could I downgrade again later?
  • Is wp-cli shipped "all in one file"? (Seems so at first glance at the curl oneliner)
  • So install is effectively only the download of a single file .phar file and making it executable (via shebang) or else run invoke it with php before it. But when running the first time, is it installing libraries or config files elsewhere?
  • If not, then I assume downgrading to the stable should be possible.

[danielbachhuber]

Is wp-cli shipped "all in one file"? (Seems so at first glance at the curl oneliner)

Yes, as a Phar file ("PHP Archive").

I could run the curl oneliner to re-install. Shall I?
Or shall I try the nightly?

Based on your md5 results, it seems you have the correct file for WP-CLI v2.10.0.

But, wp-cli/core-command#160 looks like a similar report where the user saw different results based on which URL they downloaded the Phar from.

Can you try downloading a new copy of WP-CLI using curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar and seeing if the problem reproduces with the new copy?

[porg]

Generally I believe in computing to be a deterministic discipline

• … though in over 3 decades of experience I had some occasions where after all debugging was exhausted it may shortly felt as if voodoo was involved 😂.
• Your forementioned issue where a file with the same MD5 checksum produces a different outcome depending from where it was downloaded, again seems too much voodoo to me! I don't believe this to be the true cause.
• Eventually in a deterministic machine, there is always some kind of real difference, which makes the difference, which we oversee. Be it a filesystem timestamp (which strangely is involved in whatever logic), or faulty permissions which the re-download somehow corrects, or be it even an odd bug like an xattr, which kept the download URL, which as far etched as it may seem nevertheless makes a difference for some very very odd reason. Whatever insignificant bit of data or metadata it ever may be, I've experienced it all 😉

But in our case here, it is rather some PHP env/runtime difference (e.g. Object Cache which I have ON) or some faulty PHP files in WordPress Core (although I never touched them), with which wp-cli interfaces, I assume.

My conducted testing which lead to no difference yet

1. In my ~/bin I noticed file wp-completion.bash.

• Deleted it.
• Ran wp theme status "twentytwentythree" again.
• Same error as before.

2. Logged out and into my shell again, my bash complained about a missing wp-completion.bash which is sourced in ~/.bashrc.

• So in this state wp-completion.bash was definitely not in action.
• Ran wp theme status "twentytwentythree" again.
• Same error as before.

3. Downloaded via the curl-oneliner, removed the old phar file, renamed the downloaded to just wp.

• Ran wp theme status "twentytwentythree" again.
• Same error as before.

4. Due to having no possibility to run shebang executables in the SSH environment of my shared webhosting, in my .bashrc I have had alias wp="php ~/bin/wp" for a while now.

• Ran explicitly php ~/bin/wp theme status "twentytwentythree".
• Same error as before.

Any more ideas?

[porg]

Please note: Personally I don't care for this bug.

• I just spotted it by coincidence in a use case which I may use only once every year or so.
• Instead of wp theme status <specificTheme> I can just run wp theme status get the whole report and then look at my <specificTheme> of interest.
• But some people who may rely on that function for automation, may get a problem with it.
• Hence I took it to heart to report and take part in debugging it. But from my side my curiosity in this is done, and from myself I would not further look into this, but just accept it as is.
• If you deem this as worthy to further investigate, please tell me what I should be looking for.

[danielbachhuber]

Oh, it's definitely a bug, I don't deny that. I don't have any ideas what it might be.

If I was able to reproduce the issue, I'd open the Phar file in vim and add some debugging checkpoints around the code in question.

@wp-cli/committers Any ideas what the issue might be?