But I’ve got some problems with the settings file that this plugin generates: site/web/app/object-cache.php
The problem is that I don’t want this file to be checked in with git/version control because if I disable the plugin in local env and commit the file changes. The file will be considered to be deleted and then also be deleted on staging or production when I deploy.
So right now, after each deploy I have to check if the plugins is deactivated and also flush the redis cache each time. Because things like Product Attributes disappears when i deactivate redis cache.
I’m doing this wrong or do someone experienced the same issue?
@JulienMelissas and I use(d) https://wordpress.org/plugins/wp-redis/ . I don’t recall having that file change issue. Not sure how much that helps, I haven’t worked with wp-redis and an ecommerce site, so haven’t seen Product Attributes disappear, but nothing should break without using a cache. If you have to do something with each deploy, you should add some code into your trellis repo for it. For example, I have this for another obj cache plugin I used
then in group_vars/staging/wordpress_sites.yml in cache I would set wp_lcache: true if I wanted it. It looks like cache:
I just set up Trelis with Redis (using the trellis-redis role) and installed the WP Redis plugin:
Static pages already load very fast with Trellis, but dynamic pages (like shop pages/filters/complex admin areas) won’t enjoy the speed up of nginx microcaching.
Using the redis object cache resulted in a very significant speed up, both in development (docker) and production (Trellis on Ubuntu 20).
Yes, you have to set some parameters in the Bedrock config file.
The usage of configuration for that plugin makes it ideal for Bedrock sites.
Bedrock site file config/environments/production.php:
// Redis cache server (WP Redis plugin)
$_SERVER['CACHE_HOST'] = 'localhost';
$_SERVER['CACHE_PORT'] = 6379;
$_SERVER['CACHE_PASSWORD'] = '';
$_SERVER['WP_CACHE_KEY_SALT'] = 'my-site-1'; // salt to prevent collisions of cached data between different sites
$_SERVER['CACHE_DB'] = 2; // redis DB index, which can be used as additional means of separating cached site data
You can use different configuration for different environments of course, which is very useful:
For production I use the configuration above (locally running redis instance without a password (well, one could add one)), and for development I use a docker container setup with a redis container instead (no salt/DB index needed as there is one redis container per site), which also dramatically improves performance (noticeable even on native WSL 2 file system).
The plugin also offers wp CLI tool commands, which makes it futher useful for Bedrock app-style usage. You can use it to quickly check the cache status and stats and purge the cache.
Add trellis-redis role to Trellis. The current version of the marksabbath.trellis_redis repo seems incompatible with my version of Ansible. Someone has a PR for a fix but it’s not yet merged. Luckily you can use that version of your source though.
Many thanks for sharing your insights + setups @strarsis & @Simeon, much appreciated…!
I went ahead and got Redis to work, a few thoughts / additions regarding the setup:
The forked Ansible role https://github.com/im-mortal/trellis-redis was a great starting point for me but there were a few things I needed to add / tweak so I forked that one as https://github.com/E-VANCE/trellis-redis.
The version-specific PHP package is missing, thus I couldn’t get Redis to work. Added this to /tasks/main.yml
NOTE: Could / should use a version-placeholder for upwards compatibility…
The default Redis-config only assigned 128mb as redis_maxmemory (which might be sensible, not sure as of now) but also set redis_maxmemory_policy to noeviction which makes Redis return a write error once the memory limit has been reached… Thus:
# Max memory values
I’ve been using trellis-redis in combination with WP Redis for a WooCommerce webshop. Since there’s quite some products with a lot of variations WP Redis drastically improved performance on especially the product archive page. However a weird quirk popped up; a few times already the somehow the products aren’t found (‘No products are found’ - message is showing). Flushing the cache resolves this issue.
Has anyone had similar issues? Where do I even start debugging this?
Maybe this is not caused by the object cache but by nginx microcaching?
More rarely changing pages are held in cache for some requests, although they may need rerendering.
Pages that are individualized or often-changing (as WooCommerce cart, check-out, account pages) should be excluded from microcaching:
Do you have the same issue when you disable the object cache?
We’ve been utilizing microcaching for a while and this hasn’t caused any issues. This quirk first happened after setting up WP Redis.
To me it does seem like the Object Cache is failing somehow as there are no products found, this page should always show all products so there’s no reason nginx should render a page without any products in the first place.
It’s hard to find out what’s going on because it’s only happened 2 times now and I don’t know how to recreate this locally / on staging)