Skip to content

Allow getting from global groups by force#39

Closed
trepmal wants to merge 7469 commits intowp-cli:masterfrom
trepmal:global-groups
Closed

Allow getting from global groups by force#39
trepmal wants to merge 7469 commits intowp-cli:masterfrom
trepmal:global-groups

Conversation

@trepmal
Copy link
Copy Markdown
Contributor

@trepmal trepmal commented Oct 5, 2018

This could be a weirdish edge case, I'll do my best to explain...

I have batcache's advanced-cache.php installed.

Batcache puts its group, batcache, in the global groups (line 139).

However, WP-CLI doesn't load advanced-cache.php.

So given a cached page with key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx and group batcache, I can't fetch with WP-CLI:

$ wp cache get xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx batcache 
Error: Object with key 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' and group 'batcache' not found.

With this patch, I can force WPCLI to put the given group in the global groups before fetching (manually truncated results):

$ wp cache get xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx batcache --global
array (
  'output' => '...',
  'time' => 1538761873,
  'timer' => '0.357',
  'headers' => 
  array (
    'Vary' => 
    array (
      0 => 'Cookie',
    ),
    'Content-Type' => 
    array (
      0 => 'text/html; charset=UTF-8',
    ),
    'Link' => 
    array (
      0 => '...',
      1 => '...',
    ),
  ),
  'status_header' => 'HTTP/1.1 200 OK',
  'redirect_status' => false,
  'redirect_location' => false,
  'version' => 0,
  'max_age' => 300,
)

schlessera and others added 30 commits March 17, 2017 12:42
Abstract `wp server` back to wp-cli/server-command
…equirements to PHP 5.4+.

The PR to lower the PHP requirements for the original was rejected: pyrech/composer-changelogs#44
Abstract `wp shell` to wp-cli/shell-command
This should always be 'latest'. Also include 'nightly' for testing.
* Explicitly identify each job in the build matrix
* Run tests against PHP 7.1 and 7.0
* Only run `phpcs` once, instead of with every job
* Run multisite tests on each job
Update support policy to mention WordPress.org forums
Abstract `wp eval` to wp-cli/eval-command
Warn user when managing rewrite rules while skipping plugins/themes
Variety of improvements to scaffolded `.travis.yml` and `circle.yml`
Permit `dev-master` for required WP-CLI packages
…output.

Pipe `wc` output through `tr` to delete the indentation, so that the output is consistent across all platforms and the tests all behave in the same way.

Fixes #3925
Fix broken tests by removing platform-specific indentation from `wc` output.
Permit WP-CLI to be built as a phar when dependency of another project
Instead of using the PHP 5.3+ fork from my personal account ([`schlessera/composer-changelogs`](https://github.com/schlessera/composer-changelogs)), use the one from the `wp-cli` organization instead: [`wpcli/composer-changelogs`](https://github.com/wp-cli/composer-changelogs).
@schlessera
Copy link
Copy Markdown
Member

@trepmal Still up for writing the tests for this?

@schlessera
Copy link
Copy Markdown
Member

@trepmal Gentle ping to find out whether you're still interested in completing this PR.

wojsmol and others added 19 commits April 6, 2019 04:21
Move PHP 5.4 tests from `WP_VERSION` `latest` to `5.1`
Enhancement: Add PHP 7.3 to Travis CI build matrix
Use prefix `wpcli_` instead of `wp_cli_`
... as that version contains the new WPCliCS PHPCS standard.
* `.distignore`: no need to distribute the phpcs/phpunit config files.
* `.gitignore`: Allow devs to overwrite config files for PHPUnit and PHPCS
    - The `.dist` files should be committed. However, for their personal use, devs can overrule those files with versions without `.dist`.
        Those personal versions should never be committed.

As a side-note: for PHPCS, having a personal version while still using the original `.dist` file is made very easy, as you can just import the `.dist` file as a starting point, like so:
```xml
<?xml version="1.0"?>
<ruleset name="WP-CLI">
    <rule ref="./phpcs.xml.dist"/>
</ruleset>
```
The file is completely documented in-line.
Only minimal changes needed.
Implement CS checking based on the WPCliCS ruleset
Add preliminary PHP 7.4 testing
@trepmal trepmal requested a review from a team as a code owner March 14, 2020 17:24
@trepmal
Copy link
Copy Markdown
Contributor Author

trepmal commented Mar 18, 2020

Working on this again... finally...

My manual tests are okay, but I'm having trouble getting behat tests to give the expected results. Example:

$ git diff features/cache.feature
diff --git a/features/cache.feature b/features/cache.feature
index 472f28d1..5a311200 100644
--- a/features/cache.feature
+++ b/features/cache.feature
@@ -7,6 +7,7 @@ Feature: Managed the WordPress object cache
       <?php
       $set_foo = function(){
         wp_cache_set( 'foo', 'bar' );
+        wp_cache_set( 'pie', 'cherry', 'dessert' );
       };
       $set_foo_value = function() {
         wp_cache_set( 'foo', 2 );
@@ -132,3 +133,9 @@ Feature: Managed the WordPress object cache
       """
       Error: Could not replace object 'bar' in group 'foo'. Does it not exist?
       """
+
+    When I try `wp cache get pie dessert --global`
+    Then STDERR should be:
+      """
+      Error: Object with key 'pie' and group 'dessert' not found.
+      """
(::) failed steps (::)

01. $ wp cache get pie dessert --global
    cherry

Whereas, if I run the mu-plugin in a regular WP environment (no object-cache.php):

$ wp cache get pie dessert --global
Error: Object with key 'pie' and group 'dessert' not found.

@jenkoian
Copy link
Copy Markdown

Hi @trepmal - been looking into this as we have a need for this to support --global - thanks for your work on it!

I'm getting same result as you with the behat tests. If I change it to a multisite test though (by changing Given a WP install to Given a WP multisite install) the tests pass.

Looking through https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-object-cache.php it seems the only place global_groups are referenced is when multisite is active.

Does this match up with what you're seeing?

@schlessera
Copy link
Copy Markdown
Member

@trepmal I'm sorry, it seems a push I did to the master branch rewrote that one so badly that this PR is pointing into the void and was therefore automatically closed.

Are you able to rebase it from your fork onto the new master branch to recreate a PR?

If not, let me know, and I'll assemble the standalone commits you've made into a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

command:cache-get Related to 'cache get' command

Projects

None yet

Development

Successfully merging this pull request may close these issues.