Redis Cache By Xon 2.18.11

[philmckrackon]

XF v2.3.11

 

[frpsucre]

XF v2.3.11

View attachment 340581

View attachment 340580

Fatal error: Declaration of SV\RedisCache\XF\Pub\Controller\Forum::applyDateLimitFilters(XF\Entity\Forum $forum, XF\Finder\Thread $threadFinder, array $filters) must be compatible with XF\Pub\Controller\ForumController::applyDateLimitFilters(XF\Entity\Forum $forum, XF\Finder\ThreadFinder $threadFinder, array $filters) in /home//public_html/src/addons/SV/RedisCache/XF/Pub/Controller/Forum.php on line 11

 

[philmckrackon]

What version of Redis are you using? I just upgraded another forum to XF v2.3.11 and a very old Redis version with no errors.

 

[Enes3078]

Fatal error: Declaration of SV\RedisCache\XF\Pub\Controller\Forum::applyDateLimitFilters(XF\Entity\Forum $forum, XF\Finder\Thread $threadFinder, array $filters) must be compatible with XF\Pub\Controller\ForumController::applyDateLimitFilters(XF\Entity\Forum $forum, XF\Finder\ThreadFinder $threadFinder, array $filters) in /home//public_html/src/addons/SV/RedisCache/XF/Pub/Controller/Forum.php on line 11

Have you tried rebuilding the add-on?

 

[Xon]

I'm hoping XF2.3.11 hasn't broken the backwards compatibility layer (\XF\Finder\Thread gets automatically aliased to \XF\Finder\ThreadFinder), but I haven't had time to download it and test yet.

 

[philmckrackon]

I'm hoping XF2.3.11 hasn't broken the backwards compatibility layer (\XF\Finder\Thread gets automatically aliased to \XF\Finder\ThreadFinder), but I haven't had time to download it and test yet.

,@Xon Just info that might help, I just upgraded from Redis 8.4.4 to 8.6.4 and have no issues with the addon v2.18.9 XF 2.3.11

 

[Xon]

Xon updated Redis Cache By Xon with a new update entry:

2.18.10 - Maintenance & Bugfix update

• Fix $config['cache']['config']['compress_threshold'] setting was limited to the values of 0 or 1
• Fix compressed data would be cached even if it was larger than the non-compressed data
• Remove the use of implementing LoggerAwareInterface as this neither this add-on or XF actually use that functionality, and it just throw an exception anyway
• On uninstall & upgrade of the add-on, ensure the css cache is pruned to avoid stale cached data
• Support...

Read the rest of this update entry...

 

[benFF]

An interesting issue that I was troubleshooting recently. I can't say it's a "bug" precisely, but it doesn't behave the way the internal Redis plugin does.

This config using the native connector worked fine.

$config['cache']['provider'] = 'Redis';
$config['cache']['config'] = [
    'host' => '/var/run/redis/redis-cache.sock'
];

This config didn't work - it seemed to run okay for a minute or so:

$config['cache']['provider'] = 'SV\RedisCache\Redis';
$config['cache']['config'] = [
    'server' => 'unix:///var/run/redis/redis-cache.sock'
];

But then something blows up the site rendering:
View attachment 335818

With tons of errors in the log:
View attachment 335817

Troubleshooting uncovered that I had moved to server-based job triggers, and I was nonspecific about the php version in the crontab. /usr/bin/php was calling PHP 8.5, which would hang on executing the jobs, presumably because php-redis was not installed for that version (php -m | grep redis shows that it's not installed).

When using the stock Redis module, this simply causes the jobs to stop executing successfully - the jobs back up, you get an error in the admin panel about jobs not executing successfully, but the site continues to operate normally.

When using this plugin, the next time the crontab runs, you get the above behavior that breaks the site. This was clearly a misconfiguration on my part, I'm just reporting it A) in case someone else experiences this, and B) if this is unexpected and it should behave more like the built-in Redis plugin.

edit: FWIW, I have this plugin, flood checking, and views counter all installed.

Ah this looks a bit familiar to my issue, did you need to rebuild the master data to get it working again, or just reset the cache?

I'm not running an external cron though...

 

[Ridemonkey]

Ah this looks a bit familiar to my issue, did you need to rebuild the master data to get it working again, or just reset the cache?

I had to rebuild master data to fix it. My issue was definitely the incorrectly aligned PHP versions, which wouldn't happen if you weren't calling PHP in some way that's outside of the website (e.g. the server cron job). But yep, rebuilding master data fixed it each time.

 

[benFF]

I had to rebuild master data to fix it. My issue was definitely the incorrectly aligned PHP versions, which wouldn't happen if you weren't calling PHP in some way that's outside of the website (e.g. the server cron job). But yep, rebuilding master data fixed it each time.

Interesting, because I wasn't running a different version (I totally swapped them), but this does point towards a cache issue then ...

Edit: I've just discovered, my old php version had igbinary installed, the replacement didn't!

 

[Xon]

Having the serializer match is required!

It probably should handle deserializing failure better.

 

[Xon]

Xon updated Redis Cache By Xon with a new update entry:

2.18.11 - Maintenance & bugfix update

• Replace use of serialize() with json_encode() when computing hash for cached thread list totals
• Fix changing the serializer would cause site to unexpectedly fail until the cache was manually cleared.
  This causes the code to attempt to use php unserialize() or igbinary_unserialize() if the other fails. Only works if igbinary extension is installed

Read the rest of this update entry...