wp-cli / cache-command Goto Github PK

We have a new PHPCS standard for WP-CLI called WPCliCS (props @jrfnl). 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 thre 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

Feature Request

• [ x ] Yes, I reviewed the contribution guidelines.

If I'm understanding right the --url flag is ignored when doing a wp cache flush. but no notice is given saying the flag is being ignored.

Is it feasible to update cache-command to clear caches for only subsite
e.g. when below command is run
wp cache flush --url=www.multisite.com/subsite
only flush www.multisite.com/subsite but don't affect caches on www.multisite.com/ or www.multisite.com/other-subsite

If not, maybe a notice that the flag is being ignored would be helpful.

It would be great to have patch and pluck commands for wp cache and wp transient.

Prior art: wp-cli/entity-command#65

When using an external object cache, transients are stored in the object cache and not in the database.

wp transient get ... will still work correctly, as it wraps the get_transient() or get_site_transient() functions.

However, wp transient list will always return an empty table, as the handler for the WP-CLI command generates some SQL to explicitly look in the options or sitemeta tables, which will be empty of transients.

Could we have an early guard clause for the list() method that reminds users that transients are stored in the object cache and so can't be displayed, if the object cache is being used?

(At least until WP core has get_transients() function that can be wrapped.)

I recently had the need to delete a long list of transients all at once. It would be great if the wp [cache|transient] delete command accepted multiple keys via multiple positional parameters.

Site transients are used on single sites as well as multisites so the name of the --network option and its description are a bit misleading.

The description of the --network option should be clarified.

One could also add --site as a synonym maybe. Edit: in this case deprecate --network by not mentioning it (although honour it for BC).

After wp-cli/wp-cli#4001 lands, we should revert 5a0b583

WP CLI v2.1.0 transient command is non-existent. Errors with 'transient' is not a registered wp command.

edit: I had to run "wp package install [email protected]:wp-cli/cache-command.git" and it installed the package and then everything was working. Documentation says this is supposed to be included already. And I know packages are depreciated.

The following changes need to be made:

1. In the .travis.yml file, the - composer behat line in the script: section needs to be changed into the following:

- composer behat || composer behat-rerun

2. In the composer-json file, the requirement on wp-cli/wp-cli-tests needs to be adapted to require at least v2.0.7:

"wp-cli/wp-cli-tests": "^2.0.7"

3. In the composer-json file, the "scripts" section needs to be extended. Immediately after the line "behat": "run-behat-tests",, the following line needs to be inserted:

"behat-rerun": "rerun-behat-tests",

Here's an example of how this should look like:

Improve command description text:

https://github.com/wp-cli/cache-command/blob/master/src/Transient_Command.php

Current description: Manage transients.

Proposed description:
Manage WordPress transient and standardized way of storing cached data in the database temporarily base.

Example: See the WordPress Transients_API reference.

It appears that if you want to delete all transients, it assumes wp_options ($wpdb->options) and not wp_sitemeta (Due to a early return). This needs refactoring.

Thanks.

When I manually run the tests locally with SQLite, the following scenarios are failing:

001 Scenario: Deleting all transients on single site # features/transient.feature:58
      Then STDOUT should be:                         # features/transient.feature:76
        $ wp transient delete --all
        Success: No transients found.

002 Scenario: Deleting expired transients on single site # features/transient.feature:123
      Then STDOUT should be:                             # features/transient.feature:134
        $ wp transient delete --expired
        Success: No expired transients found.

003 Scenario: Deleting all transients on multisite # features/transient.feature:194
      Then STDOUT should be:                       # features/transient.feature:215
        $ wp transient delete --all
        Success: No transients found.

004 Scenario: Deleting expired transients on multisite # features/transient.feature:286
      Then STDOUT should be:                           # features/transient.feature:301
        $ wp transient delete --expired
        Success: No expired transients found.

005 Scenario: List transients on single site # features/transient.feature:386
      Then STDOUT should contain:            # features/transient.feature:400
        $ wp transient list --format=csv
        name,value,expiration

006 Scenario: List transients on multisite # features/transient.feature:431
      Then STDOUT should contain:          # features/transient.feature:445
        $ wp transient list --format=csv
        name,value,expiration

007 Scenario: List transients with search and exclude pattern # features/transient.feature:476
      Then STDOUT should be:                                  # features/transient.feature:485
        $ wp transient list --format=csv --fields=name --search="foo"
        name

The transient command uses lots of custom MySQL queries. The SQLite integration plugin is supposed to make those SQLite-compatible, but perhaps something is not working there.

Or, since deletion and listing are failing, maybe the issue is that the insertion using set_transient() is failing in the first place.

Let's figure it out together. This could involve changes to the command, the tests, core, or the SQLite plugin.

Improve command short and long description in
https://github.com/wp-cli/cache-command/src/Cache_Command.php

wp cache | Manage the object cache.

Proposed short description:
Manipulates the WP Object Cache.

Proposed long description:
Use a persistent object cache drop-in to persist cache values between requests.
WP Object Cache

cc:@hearvox

Greetings.

I just looked around the wp cache type command after seeing it returns "Unknown" in our WP instances running WP Stash. I think it would be pretty useful if we could see that a site is indeed running WP-Stash - and possibly which driver is in use.

I see that determining the cache type is a "manual" process that checks for the specifics of several implementations. So would you be supportive of adding WP Stash to the list of implementations to check against?

The most basic check would probably be class_exists('Inpsyde\WpStash\WpStash') and it could return get_class( WpStash::instance()->driver() ). This would yield the FQCN of the StashPHP driver that is currently being used.

I hope you consider this a worthwhile addition - which I'd happily PR your way.

As a side note: Wouldn't it make sense to provide a generic way for implementations to TELL wp-cli what's being used? The ideal solution would be of course if WP-Core had such a thing on offer, but in the absence of this: is there an inherent problem with checking for the existence of $wp_object_cache->type - or maybe even calling wp_cache_type() if it exists?

In addition, maybe you could return 'Unknown: ' . get_class( $wp_object_cache ), so users with entirely custom solutions would at least get some result.

"Transients are saved to the wp_options table." is only partially true if running the wp transient type command against a multisite. See #41 for background. There are two ways to solve this:

Transients are saved to the wp_options table, site transients to the wp_sitemeta table.

Transients are saved to the database.

For simplicity's sake I'd choose the second option.

wp_using_ext_object_cache() was introduced in 3.7 so should be safe to use. I already switched a few occurrences in #42.

Feature Request

• Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing

In WordPress 6.1, a new function function was added called wp_cache_supports. This function takes a string parameter and returns a Boolean. This function is used to determine if the current object cache supports a feature, like multiple get.

Describe the solution you'd like

A new command.

WP cache supports <feature>

This would return a bool as it's output.

Feature Request

In WordPress 6.1, wp_cache_flush_group was added to core. See blog post.

This function, allows for developers to clear all keys in a cache group, instead of one key at a time.

Describe the solution you'd like

Create a new command that allows for the wp_cache_flush_group function to be called, like so

wp cache clear group <group>

Before calling this function, if should check if the object cache support this functionality, by calling wp_cache_supports and fail fast if the current object cache doesn't support this functionality.

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

https://core.trac.wordpress.org/changeset/58025 was merged last week, which added a new transient.

That now causes some tests to fail, see https://github.com/wp-cli/cache-command/actions/runs/8845496490/job/24289764622?pr=89#step:11:88

Describe how other contributors can replicate this bug

Run Behat tests with WP_VERSION=trunk

Describe what you would expect as the correct outcome

Passing tests :)

Let us know what environment you are running this on

Any environment

Provide a possible solution

We could force-delete wp_theme_files_patterns in the tests, or add some new tests specifically targeting 6.6+, and only run the existing ones on <= 6.5. We could also modify the tests a little bit to be less strict (e.g. use "contain" vs "be")

Provide additional context/Screenshots

See link above

Example is showing && instead of &&:
$ wp transient delete --all --network && wp site list --field=url | xargs -n1 -I % wp --url=% transient delete --all

Should be:
$ wp transient delete --all --network && wp site list --field=url | xargs -n1 -I % wp --url=% transient delete --all

I had an issue with two sites living on same server under separate virtual hosts. I once accidentally muddled the other vhost resulting in both WP installations getting the same domain name into siteurl. I did all required fixes and it almost started working, until I noticed that accessing wp-admin on the previously muddled vhost kept redirecting to the other vhost.

I followed and found a call to auth_redirect() in wp-admin/admin.php which triggered this. It fetches the current siteurl option in some places. While the proper value was in the database options table, still the function attempts to redirect to the wrong vhost domain.

Then I saw that the old domain was in the alloptions cache while the database value was correct.

I tried wp cache flush and wp cache flush --network, but still alloptions contained the old and wrong domain in siteurl. The only thing that worked was redis-cli flushall.

The two sites are staging and production versions of a WP multisite application.

Is this a problem in the cache command or in the Redis cache backend? I can't see any code relating to alloptions in the Redis module (object-cache.php).

WP version is 4.9.1, WP-CLI version is 1.2.1. The server is a pretty regular Ubuntu 16.04 web server. We use a Redis3 installation (local) for object caching.

To better understand the issue please take a look at core's delete_expired_transients().

There are three cases:

1. _transient_ in $wpdb->options for regular transients
2. _site_transient_ in $wpdb->options for site transients when not multisite
3. _site_transient_ in $wpdb->sitemeta for site transients when multisite

delete_expired() only handles case 1, delete_all() only case 1 and 2. Both should be updated to support all three cases by default as I don't think we should bother the user with the --network flag in this case.

Site transients are for example used for plugin/theme/available translations checks.

Feature Request

In WordPress 6.0 wp_cache_flush_runtime function. This function can be used to clear cache keys stored in php memory to free up that memory. Not all object cache support this. For that reason, wp_cache_supports( 'flush_runtime' ) should be called before using this function / command.

A clear and concise description of what you are actually trying to do, and in what way the current version of WP-CLI is not up to the task.

Describe the solution you'd like

Add a new command, like this.

wp cache flush runtime to would call wp_cache_flush_runtime. This is functionality is not supported, then it should fail fast.

wp cache flush can fail when the cache holds a stale domain lookup value and DOMAIN_CURRENT_SITE is properly set to the new domain (previously wp-cli/search-replace-command#12):

$ wp cache flush
Error: Site 'mstest.org/' not found. Verify DOMAIN_CURRENT_SITE matches an existing site or use `--url=<url>` to override.
$ wp config get --constant=DOMAIN_CURRENT_SITE
mstest.org
$ wp db query "SELECT domain FROM wp_blogs"
+------------+
| domain     |
+------------+
| mstest.org |
| mstest.org |
+------------+

It shouldn't need to be this way! wp_cache_flush() has no dependency on the site context. It should be possible to call it before multisite context has been bootstrapped. However, there's no pragmatic way to do so currently:

Once we sort this out and the problem is solved, we should remove the message in wp search-replace too.

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

• 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
  

For debugging transients stored in the database a wp transient list command would be helpful. Related plugins are Debug Bar Transients or Transients Manager.