As mentioned here https://github.com/rhubarbgroup/redis-cache/issues/369 when I implemented the new enhanced implementation for testing, I removed the code related to PHPStan.

This PR should add PHPStan back while also provide the ability to auto run it using Github actions.

cc @szepeviktor your feedback is appreciate it before I make it as ready for review.

From: https://wordpress.org/support/topic/redis-plugin-causes-maximum-function-nesting-level-error/

[07-Sep-2020 02:20:58 UTC] PHP Fatal error:  Uncaught Error: Maximum function nesting level of '256' reached, aborting! in /var/www/html/wp-content/object-cache.php:1798
Stack trace:
#0 /var/www/html/wp-content/object-cache.php(1798): str_replace(':', '-', 'posts')
#1 /var/www/html/wp-content/object-cache.php(1818): WP_Object_Cache->sanitize_key_part('posts')
#2 /var/www/html/wp-content/object-cache.php(1781): WP_Object_Cache->is_global_group('posts')
#3 /var/www/html/wp-content/object-cache.php(1332): WP_Object_Cache->build_key(141935, 'posts')
#4 /var/www/html/wp-content/object-cache.php(114): WP_Object_Cache->get(141935, 'posts', false, NULL)
#5 /var/www/html/wp-includes/class-wp-post.php(239): wp_cache_get(141935, 'posts')
#6 /var/www/html/wp-includes/post.php(780): WP_Post::get_instance(141935)
#7 /var/www/html/wp-content/plugins/pods/classes/PodsMeta.php(2950): get_post(141935)
#8 /var/www/html/wp-content/plugins/pods/classes/PodsMeta.php(3043): PodsMeta->get_object('post_type', 141935)
#9 /var/www/html/wp-content/plugins/pods/classes/PodsMeta.php in /var/www/html/wp-content/object-cache.php on line 1798
[07-Sep-2020 02:20:58 UTC] PHP Fatal error:  Uncaught Error: Maximum function nesting level of '256' reached, aborting! in /var/www/html/wp-includes/plugin.php:923
Stack trace:
#0 /var/www/html/wp-includes/plugin.php(923): spl_object_hash(Object(Tribe\Events\Views\V2\Hooks))
#1 /var/www/html/wp-includes/class-wp-hook.php(172): _wp_filter_build_unique_id('tribe_get_optio...', Array, 10)
#2 /var/www/html/wp-includes/plugin.php(281): WP_Hook->remove_filter('tribe_get_optio...', Array, 10)
#3 /var/www/html/wp-content/plugins/the-events-calendar/src/Tribe/Views/V2/Hooks.php(739): remove_filter('tribe_get_optio...', Array, 10)
#4 /var/www/html/wp-includes/class-wp-hook.php(289): Tribe\Events\Views\V2\Hooks->filter_get_stylesheet_option(false, 'tribe_zoom_refr...')
#5 /var/www/html/wp-includes/plugin.php(206): WP_Hook->apply_filters(false, Array)
#6 /var/www/html/wp-content/plugins/the-events-calendar/common/src/functions/template-tags/general.php(29): apply_filters('tribe_get_optio...', false, 'tribe_zoom_refr...', false)
#7 /var/www/html/wp-content/plugins/e in /var/www/html/wp-includes/plugin.php on line 923

'schedule_details'       => ( new Lazy_String(
					static function () use ( $post_id ) {
						return tribe_events_event_schedule_details( $post_id );
					},
					false
				) )->on_resolve( $cache_this ),

Hi, my Metric in admin not showing data.

I install WordPress 5.7.2 on: CentOS: 7.9 Nginx: 1.20.1 PHP: 8.0.8 MariaDB: 10.5 Redis Server: 6.2.4 Php Redis: 5.3.4

This is my Diagnostics:

Status: Connected
Client: PhpRedis (v5.3.4)
Drop-in: Valid
Disabled: No
Ping: 1
Errors: []
PhpRedis: 5.3.4
Predis: Not loaded
Credis: Not loaded
PHP Version: 8.0.8
Plugin Version: 2.0.20
Redis Version: 6.2.4
Multisite: No
Filesystem: Working
Global Prefix: "wp_b052ee7_"
Blog Prefix: "wp_b052ee7_"
WP_REDIS_PREFIX: "my-domain.com"
WP_CACHE_KEY_SALT: "my-domain.com"
Global Groups: [
    "blog-details",
    "blog-id-cache",
    "blog-lookup",
    "global-posts",
    "networks",
    "rss",
    "sites",
    "site-details",
    "site-lookup",
    "site-options",
    "site-transient",
    "users",
    "useremail",
    "userlogins",
    "usermeta",
    "user_meta",
    "userslugs",
    "redis-cache",
    "blog_meta"
]
Ignored Groups: [
    "counts",
    "plugins",
    "themes"
]
Unflushable Groups: []
Drop-ins: [
    "Redis Object Cache Drop-In v2.0.20 by Till Krüss"
]

My # redis-cli => info

[root@localhost ~]# redis-cli
127.0.0.1:6379> info
# Server
redis_version:6.2.4
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:6b9ff9cb3b70c87a
redis_mode:standalone
os:Linux 3.10.0-1160.25.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:c11-builtin
gcc_version:8.3.1
process_id:22230
process_supervised:systemd
run_id:dade95dcdcacc28109fd5678a0721275af8e4e48
tcp_port:6379
server_time_usec:1625905042096988
uptime_in_seconds:225019
uptime_in_days:2
hz:10
configured_hz:10
lru_clock:15292306
executable:/usr/bin/redis-server
config_file:/etc/redis/redis.conf
io_threads_active:0

# Clients
connected_clients:1
cluster_connections:0
maxclients:10000
client_recent_max_input_buffer:16
client_recent_max_output_buffer:0
blocked_clients:0
tracking_clients:0
clients_in_timeout_table:0

# Memory
used_memory:1008688
used_memory_human:985.05K
used_memory_rss:8028160
used_memory_rss_human:7.66M
used_memory_peak:63864608
used_memory_peak_human:60.91M
used_memory_peak_perc:1.58%
used_memory_overhead:834328
used_memory_startup:811840
used_memory_dataset:174360
used_memory_dataset_perc:88.58%
allocator_allocated:1965824
allocator_active:2625536
allocator_resident:5836800
total_system_memory:8201482240
total_system_memory_human:7.64G
used_memory_lua:37888
used_memory_lua_human:37.00K
used_memory_scripts:0
used_memory_scripts_human:0B
number_of_cached_scripts:0
maxmemory:2147483648
maxmemory_human:2.00G
maxmemory_policy:allkeys-lru
allocator_frag_ratio:1.34
allocator_frag_bytes:659712
allocator_rss_ratio:2.22
allocator_rss_bytes:3211264
rss_overhead_ratio:1.38
rss_overhead_bytes:2191360
mem_fragmentation_ratio:8.31
mem_fragmentation_bytes:7062240
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:20496
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

# Persistence
loading:0
current_cow_size:0
current_cow_size_age:0
current_fork_perc:0.00
current_save_keys_processed:0
current_save_keys_total:0
rdb_changes_since_last_save:4301
rdb_bgsave_in_progress:0
rdb_last_save_time:1625904842
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:602112
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0
module_fork_in_progress:0
module_fork_last_cow_size:0

# Stats
total_connections_received:45548
total_commands_processed:7107463
instantaneous_ops_per_sec:0
total_net_input_bytes:21676817203
total_net_output_bytes:15877612932
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
expired_stale_perc:0.00
expired_time_cap_reached_count:0
expire_cycle_cpu_milliseconds:11424
evicted_keys:0
keyspace_hits:1025237
keyspace_misses:3336701
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:524
total_forks:756
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0
tracking_total_keys:0
tracking_total_items:0
tracking_total_prefixes:0
unexpected_error_replies:0
total_error_replies:2
dump_payload_sanitizations:0
total_reads_processed:8198280
total_writes_processed:7108590
io_threaded_reads_processed:0
io_threaded_writes_processed:0

# Replication
role:master
connected_slaves:0
master_failover_state:no-failover
master_replid:cb6e8609c009a05eb14a39f69da27ac2fd4ec591
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:402.985964
used_cpu_user:340.727196
used_cpu_sys_children:3.257474
used_cpu_user_children:4.672545
used_cpu_sys_main_thread:400.433787
used_cpu_user_main_thread:339.582664

# Modules

# Errorstats
errorstat_ERR:count=2

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=35,expires=2,avg_ttl=1339182748

My # redis-cli => KEYS metrics

127.0.0.1:6379> KEYS *metrics*
1) "my-domain-1.comwp_1a43c2f:redis-cache:metrics"
2) "my-domain-2.comwp_e2cb081:redis-cache:metrics"
3) "my-domain-3.comwp_648a5bd:redis-cache:metrics"
4) "my-domain-4.comwp_b962ee3:redis-cache:metrics"

My /etc/redis/redis.conf

bind 127.0.0.1
protected-mode yes
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize no
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile /var/log/redis/redis.log
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir /var/lib/redis
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
maxmemory 2048mb
maxmemory-policy allkeys-lru
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 128mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes

Thanks :D

A warning is generated when using a RedisCluster as the datasource for object cache with PECL Redis:

PHP Warning:  RedisCluster::ping() expects exactly 1 parameter, 0 given in /var/www/sportshub/releases/20180402235221/web/app/object-cache.php on line 494

This PR updates object-cache.php to ping with a host when in cluster mode. This avoids continuous PHP warnings in logs. I chose WP_REDIS_HOST as the constant to use since it's required in single node implementations and makes sense if you're using a hosting provider that only requires you know the endpoint to a single server to make use of an entire Redis Cluster, like AWS: https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Endpoints.html#Endpoints.Find.RedisCluster

Of course we could use a different constant, or a random entry from the seed nodes passed in as well, since it's just checking to see if the connection is alive.

Hi,

Currently we're running redis-cache in production. It appears there is sometimes an edge-case once our redis store has many keys ( 7mill+ ) where once a key is set, eg user_meta the key even when updated via update_user_meta, it is never updated in the redis-cache. This is no bueno as even when the user_meta is changed in DB... the redis-cache continues serving stale values.

It's only when we forcefully DELETE the key where everything works fine. However this only happens when the redis DB has been operational for a while, and we slam it with requests to get & update_user_meta.

It seems there is some logic when updating user_meta where, if the value isn't updated in the database ( values are the same ), the redis cache is not invalidated, or updated.

Thanks for your work on this. I've had it working but when I recently disabled & re-enabled the cache, I'm left with the following:

URI: /wp-admin/upgrade.php?_wp_http_referer=%2Fwp%2Fwp-admin%2Ftools.php%3Fpage%3Dredis-cache%26message%3Dcache-enabled

Wherever I navigate in the admin, I'm redirected to the above. This doesn't affect the front-end of the site which continues to work as normal.

WordPress: 4.2.1 Redis Object Cache: 1.1.1

The cause could be another plugin but it's worth opening an issue here because this might be a common problem.

Redis Object Cache provides a Flush Cache button, however, it clears the entire DB. We have a multisite WordPress with thousands of blogs, and to flush all cache may lead performance problem to us. So I make some changes to flush per site cache. This feature is only available for network sites. A Flush Cache link will be added in each site line in Network Sites menu.

Hello. I have read that many users have faced issues with the upgrade. My issue is that upgrade haven’t caused just functionality issues but also data loss. When I’ve upgraded and was prompted to replace the object-cache.php, then everything seem normal. Though all the new orders on the website, plus the products data that were running via API import were wrong. Orders are blank (only a few custom meta fields were saved) but lost total billing/shipping data. Like we lost the WC_Order, WC_product properties etc

Even reverting back, I cannot find these data, also checked DB and they were erased as well, even wc_mail logs have empty orders etc.

I had to rollback my website to an older backup

I guess those data are lost for ever.

https://github.com/tillkruss/redis-cache/pull/127

I've tried installing from the this git repo not the org repo, still won't flush.

Nothing in the Redis log.

Trying to flush by wp-cli doesn't work.

Last plugin to work is 1.4.3

Brand new clean site. very few plugins.

Status: Connected
Redis Version: 5.0.6
Client: PhpRedis (v5.0.2)
Drop-in: Valid
Ping: 1
Redis Extension: 5.0.2
Predis Client: 1.1.1
PHP Version: 7.2.24-1+ubuntu18.04.1+deb.sury.org+1
Multisite: No
Global Prefix: "wp_"
Blog Prefix: "wp_"
WP_REDIS_TIMEOUT: 0
WP_REDIS_READ_TIMEOUT: 0
WP_CACHE_KEY_SALT: "pheavuzeiYoex9ja-testbuild4.com"
Global Groups: {
    "0": "blog-details",
    "1": "blog-id-cache",
    "2": "blog-lookup",
    "3": "global-posts",
    "4": "networks",
    "5": "rss",
    "6": "sites",
    "7": "site-details",
    "8": "site-lookup",
    "9": "site-options",
    "10": "site-transient",
    "11": "users",
    "12": "useremail",
    "13": "userlogins",
    "14": "usermeta",
    "15": "user_meta",
    "16": "userslugs",
    "33": "blog_meta"
}
Ignored Groups: [
    "counts",
    "plugins"
]
Unflushable Groups: []
Dropins: 
 - Redis Object Cache Drop-In v1.5.2 by Till Krüss
Plugins: 
 - Akismet Anti-Spam v4.1.3 by Automattic (Inactive)
 - Hello Dolly v1.7.2 by Matt Mullenweg (Inactive)
 - Nginx Helper v2.1.0 by rtCamp (Active)
 - Redis Object Cache v1.5.2 by Till Krüss (Active)

I'm getting a PHP Fatal Error with 1.3.8. I'm not sure what I'm missing, but I've made sure to update the object-cache.php file. From what I can tell, seems that object-cache.php isn't being included? Any thoughts?

PHP Fatal error:  Uncaught Error: Call to undefined method WP_Object_Cache::redis_status() in /opt/local/apache/appdata/wp-content/plugins/redis-cache/redis-cache.php:171
Stack trace:
#0 /opt/local/apache/appdata/wp-content/plugins/redis-cache/redis-cache.php(153): RedisObjectCache->get_redis_status()
#1 /opt/local/apache/appdata/wp-content/plugins/redis-cache/includes/admin-page.php(14): RedisObjectCache->get_status()
#2 /opt/local/apache/appdata/wp-content/plugins/redis-cache/redis-cache.php(92): require_once('/opt/local/apac...')
#3 /opt/local/apache/appdata/wp-includes/class-wp-hook.php(286): RedisObjectCache->show_admin_page('')
#4 /opt/local/apache/appdata/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array)
#5 /opt/local/apache/appdata/wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#6 /opt/local/apache/appdata/wp-admin/admin.php(224): do_action('settings_page_r...')
#7 /opt/local/apache/appdata/wp-admin/options-general.php(10): require_once('/opt/local/apac...')
#8 {main}
  thrown in /opt/local/apache/appdata/wp-content/plugins/redis-cache/redis-cache.php on line 171

The proposal is simple, add a new hook that reports statistics (hits & misses) for every cache call.

This enables end users to implement fine grained metrics in order to better understand cache runtime behaviour, in order to optimize cache usage.

The proposed signature is as follows:

/**
    * Fires on every cache call.
    *
    * This hook is called on every cache request.
    * It reports statistics per key involved. @see WP_Object_Cache::TRACE_FLAG_READ and friends.
    *
    * @param  string             $command   The command that was executed.
    * @param  string             $group     Key group.
    * @param  array[string]array $keyValues Maps keys to the returned values (if any) and the resulting status.
    *  $keyValues = [
    *      "foo" => ["value" => "bar", "status" => TRACE_FLAG_READ | TRACE_FLAG_HIT],                       // hit on redis (implies internal miss)
    *      "baz" => ["value" => "quo", "status" => TRACE_FLAG_READ | TRACE_FLAG_HIT | TRACE_FLAG_INTERNAL], // hit on internal cache
    *      "eta" => ["value" => null,  "status" => TRACE_FLAG_READ],                                        // miss
    * ];
    * @param  float              $duration  Duration of the request in microseconds.
    * @return void
*/
do_action( 'redis_object_cache_trace', $command, $group, $keyValues, $duration );

This signature is able to accommodate for both batch and single key flows. For every key, we pass the value as well as the operation metadata to the user. The user is free to decide which metadata is relevant for their use case.

Flags are defined as follows:

/**
    * Operation pertains to internal cache, not Redis.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_INTERNAL = 1 << 0;
/**
    * Operation resulted in a cache hit.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_HIT = 1 << 1;
/**
    * Read operation.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_READ = 1 << 2;
/**
    * Write operation.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_WRITE = 1 << 3;
/**
    * Delete operation.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_DEL = 1 << 4;
/**
    * Operation bypassed internal cache.
    *
    * @since x.x.x
    * @var int
*/
const TRACE_FLAG_REFRESH = 1 << 5;

Intended usage is as follows:

add_action( 'redis_object_cache_trace', function($command, $group, $keyValues, $duration) {
    foreach ($keyValues as $key => $result) {
        $flags = $result['status'];
        $value = $result['value'];
       
        $isInternal = ($flags & WP_Object_Cache::TRACE_FLAG_INTERNAL) > 0;
        $isHit = ($flags & WP_Object_Cache::TRACE_FLAG_HIT) > 0;
        $isReadOp = ($flags & WP_Object_Cache::TRACE_FLAG_READ) > 0;
        $isWriteOp = ($flags & WP_Object_Cache::TRACE_FLAG_WRITE) > 0;
        $isDelOp = ($flags & WP_Object_Cache::TRACE_FLAG_DEL) > 0;
        $isRefresh = ($flags & WP_Object_Cache::TRACE_FLAG_REFRESH) > 0;

        
        // do stuff.
    }
}, 10, 4);

We decided to ignore writes to the internal cache, as we don't see any value in measuring it. If you feel like we should, even if it's for the sake of consistency alone, let us know.

I'm not a PHP developer, nor am I that familiar with WP, so please let me know if there's anything that can be improved.

https://github.com/WordPress/performance/pull/553 put a wrapper around object-cache.php and replace original. This is resulting in A foreign object cache drop-in was found. To use Redis for object caching, please enable the drop-in.

tried to connect over a unix socket file and it was continuing to default to 127.0.0.1 when I only defined WP_REDIS_PATH in wp-config.php. it worked fine once I also defined WP_REDIS_HOST (though only defining HOST and not PATH failed as well, had to have both).

version 2.2.2

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_HOST', '/home/whatever/redis/redis.sock' );
define( 'WP_REDIS_PATH', '/home/whatever/redis/redis.sock' );

I have one issue with WP_REDIS_GRACEFUL

WordPress makes several calls to wp_cache_delete() (especially wp-includes/meta.php ): if one of them ends up being a no-op, the relevant cache entry becomes stale. WordPress eventually will re-connect to Redis, and that will respond with a cache hit instead of a cache miss.

Note it is borderline impossible to replicate this behaviour unless the Redis server is hosted on a different machine rather than the one where WordPress runs (with php-fpm, in my case).

The "salt" as "prefix" is a misleading naming convention. I keep seeing prefixes that are ridiculously long and contain all the characters.

Let's nudge users towards a cleaner prefix setup with examples in the UI, if theirs is quite long and contains many special characters.

rIT<~s5f$+w]!s&HL5tlGw|gLe13*/rGo= |u3!izQCQyx|VBeB5hw&#ZD,6GtaI => mysite: