wp-cli / doctor-command Goto Github PK
View Code? Open in Web Editor NEWDiagnose problems within WordPress by running a series of checks for symptoms
License: MIT License
Diagnose problems within WordPress by running a series of checks for symptoms
License: MIT License
We have a new PHPCS standard for WP-CLI called WPCliCS. 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:
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
Yertle is a backdoor that is part of the WPForce suite and that can be injected into a WordPress site so that it can be remotely controlled for various nefarious purposes.
Here's the source code: https://github.com/n00py/WPForce
Describe the current, buggy behavior
wp doctor check --all --spotlight
Complains about duplicate cron-jobs.
The duplicate cronjobs is "publish_future_post"
Which is WP Core generating those "single-events" to publish post in the future.
If a site is using this functionality, and have more than 10 post set to the future, WP Doctor command will give an error.
Even through its expected behavior.
it could be argued that WP Core, should have the post_id as part of the single-cronjob naming, but thats not the case.
Example of WP Core registrering cronjobs using a non-unique key https://github.com/WordPress/WordPress/blob/87cdca8cd61887cd6685c0e11a06e913415524a7/wp-includes/post.php#L4514
maybe a simple solution could be to check if the saved parameter, is the same on multiple jobs.
If a user provides '*'
, then we should support checking every file, regardless of extension.
It should be possible to register one or more check names to a group.
Then you could wp doctor diagnose --group=db
to only run the database checks.
For instance, {DB_NAME}.sql
in the web root or wp-content
directory can be easily guessed.
However, we shouldn't flag SQL files generated by backup plugins and similar that either live in obscured directories (some hash appended) or are protected by .htaccess
files.
A JPEG masquerading as a PNG, as an example.
Use of eval()
is discouraged because it can lead to arbitrary code execution. We should scan all PHP files in ABSPATH
for use of eval()
.
And, on the note of scanning files, it would be cool to have a pattern of abstraction such that the file scan check is run once for all checks that implement some form of file check.
PHP code in the uploads directory could be a sign of nefarious code added to the system.
I have not been successful with this yet but I'm looking for a way to do conditional logic to run certain checks.
A good example (psudocode):
If define "multisite" exists
Do additional checks
If not
Skip additional checks
Is there a creative way to accomplish this within the doctor cli system
On sites with large uploads directories, iterating the directory can take a very long time.
We should make sure to only iterate the uploads directory once, instead of once per check.
Describe the current, buggy behavior
wp doctor check autoload-options-size
- 650 kB
SELECT 'Autoload kiB' as name, ROUND(SUM(LENGTH(option_value)) / 1024) as value FROM wp_options WHERE autoload='yes'
- 2.4 MB
Difference is in counting _transient_*
options.
https://codex.wordpress.org/Function_Reference/set_transient#Notes points out "NB: transients that never expire are autoloaded, whereas transients with an expiration time are not autoloaded. Consider this when adding transients that may not be needed on every page, and thus do not need to be autoloaded, impacting page performance."
Describe what you would expect as the correct outcome
wp doctor check autoload-options-size
should count unexpirable transients.
Let us know what environment you are running this on
convers@pill2 ~/www/institute]# wp cli info
OS: Linux 2.6.32-754.17.1.el6.x86_64 #1 SMP Tue Jul 2 12:42:48 UTC 2019 x86_64
Shell: /bin/bash
PHP binary: /opt/cpanel/ea-php73/root/usr/bin/php
PHP version: 7.3.15
php.ini used: /opt/cpanel/ea-php73/root/etc/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/convers/public_html/institute
WP-CLI packages dir: /home/convers/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.4.0
Reading https://github.com/wp-cli/doctor-command/pull/15/files by @danielbachhuber I'm now thinking this may be an issue for wp option
command instead. Your thoughts?
This will enable checks to have more advanced description rendering logic if needed.
In order to hit feature parity with WP Launch Check, we need to support:
WP_DEBUG
is true or false.SAVEQUERIES
is true or false.WP_CACHE
is true or false.$_SERVER['SERVER_NAME']
isn't used in wp-config.php
.All formats work except count format:
wp --allow-root doctor check --all --format=count
Error: Parameter errors:
Invalid value specified for 'format' (Render results in a particular format.)
It would be helpful to be able to check that expected <head>
metadata is present (e.g. FB OG tags)
Hello,
I was attempting to test this out using an up to date version of wp-cli (1.1.0) but on two separate servers, I get the same error:
PHP Fatal error: Uncaught Error: Class 'Mustangostang\Spyc' not found in ~/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-checks.php:32
I attempted to add this dependency to the "composer.json" file:
"mustangostang/spyc": "*"
I then ran an update but it would not work still. Would you have an idea as to how to get this missing dependency added, or what to modify to make this work? Thanks so much!
-Adam
Full Stack Trace:
PHP Fatal error: Uncaught Error: Class 'Mustangostang\Spyc' not found in ~/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-checks.php:32
Stack trace:
#0 ~/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-command.php(75): runcommand\Doctor\Checks::register_config('/root/.wp-cli/p...')
#1 [internal function]: runcommand\Doctor\Command->check(Array, Array)
#2 phar:///usr/bin/wp/php/WP_CLI/Dispatcher/CommandFactory.php(67): call_user_func(Array, Array, Array)
#3 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher{closure}(Array, Array)
#4 phar:///usr/bin/wp/php/WP_CLI/Dispatcher/Subcommand.php(390): call_user_func(Object(Closure), Array, Array)
#5 phar:///usr/bin/wp/php/WP_CLI/Runner.php(316): WP_CLI\Dispatcher\Subcommand->invoke(Array, Array, Array)
#6 phar:///usr/bin/wp/php/WP_CLI/Runner.php(323): WP_CLI\Runner->run_command(Array, Array)
#7 phar:///usr/bin/wp/php/WP_CLI/Runner.php(62): WP_CLI\Runner->_run_command()
#8 phar:///usr/bin/wp/php/WP_CLI/Runner.php(885): WP_CLI\Runner->do_e in ~/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-checks.php on line 32
The following changes need to be made to move the command over to the v2 structure:
composer require wp-cli/wp-cli:^2
composer require --dev wp-cli/wp-cli-tests:^2
.travis.yml
file from wp-cli/wp-cli
:
wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/.travis.yml
"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"
]
},
git rm bin/install-package-tests.sh
git rm bin/test.sh
git rm features/bootstrap/*
git rm features/extra/*
git rm features/steps/*
git rm utils/behat-tags.php
--dev
dependencies.cli *
config *
core *
eval
eval-file
help
composer update
wget https://raw.githubusercontent.com/wp-cli/wp-cli/master/phpcs.xml.dist
composer test
I noticed when a folder in wp-content is permission denied, doctor exits out.
chris@steak:~/sites/domain.com$ wp doctor check --all
Running checks 7 % [========> ]0:00 / 0:00
Error: RecursiveDirectoryIterator::__construct(/home/chris/sites/domain.com/wp-
content/galleryzip-cache): failed to open dir: Permission denied
chris@steak:~/sites/domain.com$
wp db check
To help alert to problem errors, it would be cool if the doctor checked the PHP error log for warnings, fatals, and other problem symptoms.
It seems that this repo is not available through Packagist.
I'm adding
"wp-cli/doctor-command": "^2.0"
and the resulting error is the following
Problem 1 - The requested package wp-cli/doctor-command could not be found in any version, there may be a typo in the package name.
The current behaviour is to exit with a non-zero status when there are some warnings or errors with the examined WordPress installation, like checksum errors.
This is a matter of semantics, but I believe the command should exit with error only if it failed to execute correctly, i.e. wrong flags were given or permission was denied or something else got wrong and the check did not complete. That it's purpose is to find errors and it did, doesn't mean it encountered an error itself.
I plan to use this package in an automated environment and I need to determine when the command completed successfully and when not. The report itself can be seen from the output, if and only if the command completed successfully.
Doctor core-verify-checksums says it is succesful
but when I run wp core verify-checksums it finds File should not exist: wp-admin/.php
Also Sucuri alerts for this extra file.
Greater than ~900kb or so should exhibit a warning.
Production sites probably need to make sure Google Analytics is present.
When a check has a warning or an error, we should offer a corrective recommendation on what they should do to try to address the issue.
We should have a check to see if the installed languages are out of date.
wp_cache_flush()
shouldn't be used on production sites because it can cause performance problems when repopulating.
This plugin is listed with a broken link on the wp-cli package index.
What I was looking for originally was a way to get more information on certain failed checks, particularly the ones where the extra detail (like which PHP files were found in uploads) won't fit nicely in a shorter-style summary "message".
Oh right. I was thinking these could go in a data field (or something better named). I think it needs to be in a separate field though, because it could be a huge amount of data and probably wouldn't be something you want to try to parse out of a message.
Can you give an example of what would be in the data field for the php-in-upload check? Would it be the file paths separated by newlines?
It would be the file path relative to WordPress root in JSON format. In --format=table, the JSON would be rendered within the table. In --format=json, it would be true JSON.
From discussion in #131
Site Audit is a Drupal static site analysis platform that generates reports with actionable best practice recommendations.
Every Drupal site is unique, with its own individual configuration, content, audience, and so forth. With that said, they all have the same core infrastructure and configuration; Drupal! Therefore, it's possible to perform performance and behavior gathering to inspect any site.
Site Audit uses a technique known as static program analysis. This mechanism does not actually perform requests on the target site, and in doing so avoids the observer effect. It's non-intrusive, so no installation into the target site or configuration is required.
The end result is a fast, repeatable report that can help detect common problems and provide introspection into Drupal sites. Reports can be generated in multiple formats, including plain text, HTML, and JSON.
wp doctor
currently provides output like this:
wp doctor diagnose core-update
+-------------+--------+----------------------------------------------------------------------+
| name | status | message |
+-------------+--------+----------------------------------------------------------------------+
| core-update | error | Updating to WordPress' newest minor version is strongly recommended. |
+-------------+--------+----------------------------------------------------------------------+
Can we reach some form of common ground with Drupal Site Audit, such that a standalone application can more easily handle return data from wp doctor
and Drupal Site Audit?
It would be helpful if you could write a check that would perform some arbitrary code execution to determine success or failure (e.g. truly assess whether Akismet is active or inactive).
It will be more efficient to just iterate the filesystem once.
Describe the current, buggy behavior
Since the version 7.4.0 passing the glue after the pieces on the implode
function has been deprecated. It forces to use the parameter order as the documentation.
Describe how other contributors can replicate this bug
$ vendor/bin/wp cli version
Describe what you would expect as the correct outcome
No deprecated warnings for newer PHP versions.
Let us know what environment you are running this on
OS: Darwin 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar 4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64
Shell:
PHP binary: /usr/local/bin/php
PHP version: 7.4.5
php.ini used: /usr/local/etc/php/7.4/php.ini
MySQL binary: /usr/local/bin/mysql
MySQL version: mysql Ver 15.1 Distrib 10.4.12-MariaDB, for osx10.15 (x86_64) using readline 5.1
SQL modes:
WP-CLI root dir: ~/Sites/wp-cli-dev/wp-cli
WP-CLI vendor dir: ~/Sites/wp-cli-dev/wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir: /var/folders/qp/h_rczc6x5yn705vvhb3pt4t00000gn/T/wp-cli-home/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config: ~/Sites/wp-cli-dev/doctor-command/wp-cli.yml
WP-CLI version: 2.5.0-alpha
Provide a possible solution
Inverting the parameters of the implode function would work for all versions since PHP 5.6.
Provide additional context/Screenshots
$ wp-cli/bin/wp cli version
PHP Deprecated: implode(): Passing glue string after array is deprecated. Swap the parameters in /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php on line 20
PHP Stack trace:
PHP 1. {main}() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/boot-fs.php:0
PHP 2. require_once() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/boot-fs.php:17
PHP 3. WP_CLI\bootstrap() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/wp-cli.php:27
PHP 4. WP_CLI\Bootstrap\LoadRequiredCommand->process() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/bootstrap.php:74
PHP 5. WP_CLI\Utils\load_file() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/WP_CLI/Bootstrap/LoadRequiredCommand.php:56
PHP 6. require_once() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/utils.php:108
PHP 7. ComposerAutoloaderInit6760afce2558b22ef4f36a2c1bfedb45::getLoader() /Users/eduardopittol/Sites/wp-cli-dev/vendor/autoload.php:7
PHP 8. composerRequire6760afce2558b22ef4f36a2c1bfedb45() /Users/eduardopittol/Sites/wp-cli-dev/vendor/composer/autoload_real.php:59
PHP 9. require() /Users/eduardopittol/Sites/wp-cli-dev/vendor/composer/autoload_real.php:69
PHP 10. WP_CLI::add_command() /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:27
PHP 11. class_exists() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
PHP 12. spl_autoload_call() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
PHP 13. {closure:/Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:8-24}() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
PHP 14. implode() /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:20
Deprecated: implode(): Passing glue string after array is deprecated. Swap the parameters in /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php on line 20
Call Stack:
0.0082 396480 1. {main}() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/boot-fs.php:0
0.0103 407088 2. require_once('/Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/wp-cli.php') /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/boot-fs.php:17
0.0143 428176 3. WP_CLI\bootstrap() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/wp-cli.php:27
0.0942 1701096 4. WP_CLI\Bootstrap\LoadRequiredCommand->process() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/bootstrap.php:74
0.0943 1701136 5. WP_CLI\Utils\load_file() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/WP_CLI/Bootstrap/LoadRequiredCommand.php:56
0.0959 1702240 6. require_once('/Users/eduardopittol/Sites/wp-cli-dev/vendor/autoload.php') /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/utils.php:108
0.0984 1715632 7. ComposerAutoloaderInit6760afce2558b22ef4f36a2c1bfedb45::getLoader() /Users/eduardopittol/Sites/wp-cli-dev/vendor/autoload.php:7
0.6853 7768336 8. composerRequire6760afce2558b22ef4f36a2c1bfedb45() /Users/eduardopittol/Sites/wp-cli-dev/vendor/composer/autoload_real.php:59
0.6867 7773352 9. require('/Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php') /Users/eduardopittol/Sites/wp-cli-dev/vendor/composer/autoload_real.php:69
0.6868 7773768 10. WP_CLI::add_command() /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:27
0.6868 7773768 11. class_exists() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
0.6868 7773824 12. spl_autoload_call() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
0.6878 7774256 13. {closure:/Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:8-24}() /Users/eduardopittol/Sites/wp-cli-dev/wp-cli/php/class-wp-cli.php:450
0.6878 7774808 14. implode() /Users/eduardopittol/Sites/wp-cli-dev/doctor-command/command.php:20
WP-CLI 2.5.0-alpha
To make it easier to customize the Doctor on an environment by environment basis, it would be nice to be able configure checks by a Yaml file.
More specifically:
'info' would denote there is something to note about the check, but it's not yet a 'warning'
While installing wp doctor
I am having with following error:
PHP Fatal error: require(): Failed opening required '/home/seocliff/.wp-cli/packages/vendor/composer/../wp-cli/entity-command/entity-command.php' (include_path='.:/usr/share/pear:/usr/share/php') in /home/seocliff/.wp-cli/packages/vendor/composer/autoload_real.php on line 66
Now, wp
command is also unusable. Please help
All checks work except validate-mime. I use PHP 7.0. I have googled around and apparently the function mime_content_type was deprecated and now it´s rescued in PHP 7.x. Maybe to make doctor work in all PHP versions?
These are the errors:
wp --allow-root doctor check validate-mime
Fatal error: Uncaught Error: Call to undefined function runcommand\Doctor\Checks\mime_content_type() in /root/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/checks/class-validate-mime.php:33
Stack trace:
#0 /root/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-command.php(99): runcommand\Doctor\Checks\Validate_Mime->run()
#1 phar:///usr/local/bin/wp/php/class-wp-cli.php(271): runcommand\Doctor\Command->runcommand\Doctor{closure}()
#2 phar:///usr/local/bin/wp/php/WP_CLI/Runner.php(1060): WP_CLI::do_hook('after_wp_load')
#3 /root/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-command.php(277): WP_CLI\Runner->load_wordpress()
#4 /root/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/class-command.php(156): runcommand\Doctor\Command->load_wordpress_with_template()
#5 [internal function]: runcommand\Doctor\Command->check(Array, Array)
#6 phar:///usr/local/bin/wp/php/WP_CLI/Dispatcher/CommandFactory.php(81): call_user_func(Array, Array, Array)
#7 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CL in /root/.wp-cli/packages/vendor/wp-cli/doctor-command/inc/checks/class-validate-mime.php on line 33
It has an error on Travis CI.
Fatal error: Uncaught Error: Call to undefined method cli\Table::setAsciiPreColorized() in vendor/wp-cli/wp-cli/php/WP_CLI/Formatter.php:285
Stack trace:
#0 vendor/wp-cli/wp-cli/php/WP_CLI/Formatter.php(138): WP_CLI\Formatter::show_table(Array, Array, false)
#1 vendor/wp-cli/wp-cli/php/WP_CLI/Formatter.php(89): WP_CLI\Formatter->format(Array, false)
#2 vendor/wp-cli/wp-cli/php/utils.php(288): WP_CLI\Formatter->display_items(Array)
#3 inc/class-command.php(261): WP_CLI\Utils\format_items('table', Array, Array)
#4 [internal function]: runcommand\Doctor\Command->list_(Array, Array)
#5 vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(81): call_user_func(Array, Array, Array)
#6 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}(Array, Array) in vendor/wp-cli/wp-cli/php/WP_CLI/Formatter.php on line 285
See https://travis-ci.org/wp-cli/doctor-command/jobs/261470000.
When unknown files exist in wp-admin/
or wp-includes/
, Doctor should throw a warning.
Couldn't install either package on my vagrant box. Same error for each:
Loading composer repositories with package information
Updating dependencies
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126
PHP Stack trace:
PHP 1. {main}() /usr/share/wp-cli/php/boot-fs.php:0
PHP 2. include() /usr/share/wp-cli/php/boot-fs.php:17
PHP 3. WP_CLI\Runner->start() /usr/share/wp-cli/php/wp-cli.php:21
PHP 4. WP_CLI\Runner->_run_command() /usr/share/wp-cli/php/WP_CLI/Runner.php:803
PHP 5. WP_CLI\Runner->run_command() /usr/share/wp-cli/php/WP_CLI/Runner.php:323
PHP 6. WP_CLI\Dispatcher\Subcommand->invoke() /usr/share/wp-cli/php/WP_CLI/Runner.php:316
PHP 7. call_user_func:{/usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388
PHP 8. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher{closure}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388
PHP 9. call_user_func:{/usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
PHP 10. Package_Command->install() /usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
PHP 11. Composer\Installer->run() /usr/share/wp-cli/php/commands/package.php:303
PHP 12. Composer\Installer->doInstall() /usr/share/wp-cli/vendor/composer/composer/src/Composer/Installer.php:216
PHP 13. Composer\DependencyResolver\Solver->solve() /usr/share/wp-cli/vendor/composer/composer/src/Composer/Installer.php:461
PHP 14. Composer\DependencyResolver\RuleSetGenerator->getRulesFor() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Solver.php:214
PHP 15. Composer\DependencyResolver\RuleSetGenerator->addRulesForJobs() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:333
PHP 16. Composer\DependencyResolver\RuleSetGenerator->addRulesForPackage() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:293
PHP 17. Composer\DependencyResolver\RuleSetGenerator->createConflictRule() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:246
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126
Call Stack:
0.0002 353944 1. {main}() /usr/share/wp-cli/php/boot-fs.php:0
0.0014 359568 2. include('/usr/share/wp-cli/php/wp-cli.php') /usr/share/wp-cli/php/boot-fs.php:17
0.0227 1357992 3. WP_CLI\Runner->start() /usr/share/wp-cli/php/wp-cli.php:21
0.0284 1450000 4. WP_CLI\Runner->_run_command() /usr/share/wp-cli/php/WP_CLI/Runner.php:803
0.0284 1450000 5. WP_CLI\Runner->run_command() /usr/share/wp-cli/php/WP_CLI/Runner.php:323
0.0370 1745776 6. WP_CLI\Dispatcher\Subcommand->invoke() /usr/share/wp-cli/php/WP_CLI/Runner.php:316
0.0512 2209344 7. call_user_func:{/usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388
0.0512 2209344 8. WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher{closure}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php:388
0.0512 2210152 9. call_user_func:{/usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67}() /usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
0.0512 2210152 10. Package_Command->install() /usr/share/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php:67
0.6635 7964344 11. Composer\Installer->run() /usr/share/wp-cli/php/commands/package.php:303
0.6673 8029576 12. Composer\Installer->doInstall() /usr/share/wp-cli/vendor/composer/composer/src/Composer/Installer.php:216
1.6855 10540952 13. Composer\DependencyResolver\Solver->solve() /usr/share/wp-cli/vendor/composer/composer/src/Composer/Installer.php:461
1.6856 10543568 14. Composer\DependencyResolver\RuleSetGenerator->getRulesFor() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/Solver.php:214
6.9760 116738920 15. Composer\DependencyResolver\RuleSetGenerator->addRulesForJobs() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:333
6.9761 116739336 16. Composer\DependencyResolver\RuleSetGenerator->addRulesForPackage() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:293
7.2341 129665480 17. Composer\DependencyResolver\RuleSetGenerator->createConflictRule() /usr/share/wp-cli/vendor/composer/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:246
Here is the return.
Noticable runcommand/profile
Sites wp package install wp-cli/doctor-command
Installing package wp-cli/doctor-command (dev-master)
Updating /Users/ralfhortt/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Updating dependencies
Resolving dependencies through SAT
Dependency resolution completed in 0.348 seconds
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package runcommand/profile could not be found in any version, there may be a typo in the package name.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting
see https://getcomposer.org/doc/04-schema.md#minimum-stability for more details.
Read https://getcomposer.org/doc/articles/troubleshooting.md for further common problems.
---
Error: Package installation failed (Composer return code 2). Reverted composer.json```
Rather than each check iterate the filesystem on its own, it would be better to have a general purpose filesystem iterator check that called all of its subchecks.
It would be useful if users could verify that their sitemap is valid.
We run a fairly custom build of this, so it's totally possible this is an issue on our end. But I'm totally unaware of how to find it.
Severity: Medium
Expected results: It works
Actual results: Getting this error when running doctor. Just updated to the latest release of doctor and profile.
Fatal error: Class 'Spyc' not found in phar:///usr/local/bin/wp/vendor/wp-cli/mustangostang-spyc/includes/functions.php on line 31
We have the modules loaded to a custom location, can recreate with:
export WP_CLI_PACKAGES_DIR=/opt/wp-cli-plugins ; /usr/local/bin/wp --allow-root --path=/home3/REDACTED/public_html doctor check --all
WP-CLI Version: 1.4.1
Kernel:
3.10.0-693.11.6.1.ELK.el6.x86_64
PHP:
PHP 5.4.45 (cli) (built: Oct 5 2015 15:35:12) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies with the ionCube PHP Loader (enabled) + Intrusion Protection from ioncube24.com (unconfigured) v10.1.1, Copyright (c) 2002-2017, by ionCube Ltd. with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies
No suhosin.
WP Version:
$wp_version = '4.8.5';
WP-cli stat:
File:
/usr/local/bin/wp'
Size: 4409743 Blocks: 8624 IO Block: 4096 regular file
Device: 97dh/2429d Inode: 997743 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-02-23 10:58:46.537376401 -0600
Modify: 2018-02-23 10:42:21.000000000 -0600
Change: 2018-02-23 10:58:44.807543311 -0600`
Packages:
+------------------------+------------------+------------+-----------+----------------+ | name | authors | version | update | update_version | +------------------------+------------------+------------+-----------+----------------+ | wp-cli/doctor-command | Daniel Bachhuber | v0.1.0 | available | dev-master | | wp-cli/profile-command | | dev-master | available | dev-master | +------------------------+------------------+------------+-----------+----------------+
To make the PHP 5.4 tests work, we have to limit them to the latest version before the 5.2 update (which bumps the PHP minimum version to PHP 5.6).
This is done by WP_VERSION=5.1
, but that unfortunately does not include the latest stable patch version. This should be fixed through wp-cli/wp-cli-tests#51
In the mean-time, we bumped the version to WP_VERSION=5.1.1
to make the doctor tests pass that rely on checking for the latest stable version. This should be reverted back to WP_VERSION=5.1
once the above issue has been fixed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.