Theme files are reported as 'File should not exist' on Windows
ericgopak opened this issue · 10 comments
After running wp core verify-checksums
on my WordPress 4.9.4 installation, the tool reports some files under my theme folder as 'Warning: File should not exist: wp-content/themes/MyTheme/includes/wp_booster/wp-admin/deeper/folder/some/file
'
I think that all theme files should be ignored when verifying core checksums. And the problem here seems to be the /wp-admin/
folder inside my theme.
Hi @ericgopak,
Thanks for the report. This should already be accommodated for with https://github.com/wp-cli/wp-cli/pull/3268/files. Is there additional detail you can provide that might explain how your configuration is different?
Hi @danielbachhuber ,
The fix looks good by the look of it :) It seems to take care of both wp-admin/
and wp-includes/
, which was exactly the problem.
I don't currently have a setup to check out WP-CLI from Git, so I can't actually test it. But I think it's fine.
Thanks! I think you can close this issue for now.
@ericgopak To clarify, that change was implemented in v0.25.0. WP-CLI is currently at v1.5.0.
If the issue still manifests itself for you locally, then we'll need more detail on how to reproduce in order to help resolve. Our bug reporting guidelines offer a template you can follow.
@danielbachhuber Sorry for taking so long to respond. A quick peek into the issue has shown that the issue might be Windows-specific (my current working OS), and is still present in the latest WP-CLI version (v1.5.0). I want to help you out on this. I guess I should write a more detailed bug report and then I could fix it myself and submit a pull request.
I'm new to WP-CLI codebase, but I'm happy to submit my first pull request in the upcoming days.
If you agree, then we can re-open the issue and I'll proceed as described above.
I have the same problem (does not work via CMD, but works with the Windows Subsystem for Linux). I think the problem is that in the filter_file()
method (https://github.com/wp-cli/checksum-command/blob/master/src/Checksum_Core_Command.php#L140) there is a check for /
, but Windows has \
(so for example, $filepath
could be wp-content\index.php
), so the ^wp-(?!config\.php)([^\/]*)$
regex matches everything with wp-
at the beginning on Windows.
Unfortunately, I have no idea how to check if another regex would work, because I cannot edit the content of wp-cli.phar
in PhpStorm… Btw: would be great if there would be some post on how to develop for the WP-CLI (how to open the .phar
for debugging/testing (if that is the right way to do it), …) :)
Thanks for the additional detail, @florianbrinkmann. It makes sense that this is a bug specific to Windows.
Btw: would be great if there would be some post on how to develop for the WP-CLI
Thanks @danielbachhuber, found it – I already was aware of the handbook and searched there, but not in the Pull Requests chapter…
Thank you, @danielbachhuber and @florianbrinkmann, I've followed the guidelines for setting up WP-CLI for development locally.
Indeed, the issue was with the regex, which assumed only regular (*nix-style) slashes. Adding the backslash (escaped as \\\\
) solved the problem for me.
And to make it all a somewhat better bug report, here are steps to reproduce the issue:
- Have a fresh WordPress installation
- Create a new file under
/wp-content/
so that the path to the file includes either /wp-admin/
or/wp-includes/
, e.g.wordpress/wp-content/themes/MyTheme/wp-includes/some_file.php
- Run
wp core verify-checksums
from the root of this WordPress installation
Notes on the tested environment:
$ wp --info
OS: Windows NT 6.3 build 9600 (Windows 8.1 Professional Edition) AMD64
Shell: /bin/bash
PHP binary: /XXX/WAMP/bin/php/php7.0.10/php
PHP version: 7.0.10
php.ini used: X:\XXX\WAMP\bin\php\php7.0.10\php.ini
WP-CLI root dir: X:\XXX\wp-cli
WP-CLI vendor dir: X:\XXX\wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir: X:\XXX\home\XXX/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.0.0-alpha
Update: actually, it seems that the issue was more generic - with that bug in the regex expression any paths in any wp-*\
folders were reported as File should not exist
. With the changes from the pull request above this is no longer happening.