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

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

• Clone the repository
• Run the any wp-cli command with PHP >= 7.4.0

$ 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

It would be useful if users could verify that their sitemap is valid.

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.

'info' would denote there is something to note about the check, but it's not yet a 'warning'

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.

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.

We should have a check to see if the installed languages are out of date.

• Add purchase details to installation instructions
• Pull the support details from a central source

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

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.

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.

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.

It would be helpful to be able to check that expected <head> metadata is present (e.g. FB OG tags)

From #120

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

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 | +------------------------+------------------+------------+-----------+----------------+

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:^2
  

• 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
  

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

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```

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.

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:

• 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 the 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

Drupal Site Audit is:

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?

wp_cache_flush() shouldn't be used on production sites because it can cause performance problems when repopulating.

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 will be more efficient to just iterate the filesystem once.

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.
• Debug Bar doesn't exist.
• W3 Total Cache doesn't exist, nor does WP Super Cache.
• More than 100 plugins active.
• More than 1000 autoloaded options.
• Excessive duplicate cron jobs scheduled.
• $_SERVER['SERVER_NAME'] isn't used in wp-config.php.
• File exploits via eval.
• Use of sessions.

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.)

If a user provides '*', then we should support checking every file, regardless of extension.

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 JPEG masquerading as a PNG, as an example.

• P3 Profiler

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

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

PHP code in the uploads directory could be a sign of nefarious code added to the system.

Bug Report

• [ x] Yes, I reviewed the contribution guidelines.
• [x ] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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.

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

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

This will enable checks to have more advanced description rendering logic if needed.

Greater than ~900kb or so should exhibit a warning.

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.

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

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?

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.

Couldn't install either package on my vagrant box. Same error for each:

[08:44 PM]-[vagrant@local]-[/vagrant]
$ wp package install wp-cli/doctor
Installing package wp-cli/doctor (dev-master)
Updating /home/vagrant/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...

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

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).

This plugin is listed with a broken link on the wp-cli package index.

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.

When unknown files exist in wp-admin/ or wp-includes/, Doctor should throw a warning.

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:

• Define which checks should be available.
• For the ones that permit variable behavior (e.g. autoloaded options threshold), be able to define the check values in the config file.

Production sites probably need to make sure Google Analytics is present.