Using a Redis Server

This is a community-contributed tutorial. This tutorial is over a year old and may not apply to your version of Concrete CMS.
Jun 16, 2023

By default, Concrete stores non-volatile cache items in the filesystem (in the /application/files/cache directory).

If you want to use a redis server instead, you have to manually edit the /application/config/concrete.php file, where you can define how the different persistent caches have to be stored.

Concrete caches

You can use Redis instead of the filesystem cache with these configuration keys:

  • concrete.cache.levels.overrides a cache used to store the resolved overrides
  • concrete.cache.levels.expensive a cache used to store data that should be kept across different web requests (it's the cache/expensive described here)
  • concrete.cache.levels.object this is usually a cache that's ephemeral, but you may want to use a persistent driver for it (it's the cache described here)

Concrete supports 2 different type of connection to a redis server:

  1. To define connection via TCP/IP, you can use an array like this:

    [
       'host' => '127.0.0.1', // The IP or the host name of the Redis server
       'port' => 6379, // The TCP port to be used, you can omit it if you use the default port (6379)
       'ttl' => 5, // The connection timeout (in seconds)
       'password' => null, // The password to be used to connect to the Redis server, omit or set to null if none
    ]
    
  2. To define connection via Unix socket, you can use an array like this:

    [
       'socket' => '/run/redis/redis.sock',
       'password' => null, // The password to be used to connect to the Redis server, omit or set to null if none
    ]
    

Concrete supports connecting to multiple Redis servers, and the definition of all the server connections must be stored in a servers configuration key. In addition, if your Redis server serves multiple applications or websites, you may also want to specify which database to be used (via a database configuration key), as well as a prefix for the keys of the cached items (via a prefix configuration key). You finally have to set the preferred_driver configuration key to redis in order to instruct Concrete to use the Redis servers instead of the filesystem.

To summarize, here's an extract from a sample /application/config/concrete.php file that configure Redis for the Concrete caches:

<?php

return [
    'cache' => [
        'levels' => [
            'overrides' => [
                'preferred_driver' => 'redis',
                'drivers' => [
                    'redis' => [
                        'options' => [
                            'database' => 0,
                            'prefix' => 'myapp:overrides',
                            'servers' => [
                                [
                                    'host' => '127.0.0.1',
                                    'port' => 6379,
                                    'ttl' => 5,
                                    'password' => null,
                                ],
                            ],
                        ],
                    ],
                ],
            ],
            'expensive' => [
                'preferred_driver' => 'redis',
                'drivers' => [
                    'redis' => [
                        'options' => [
                            'database' => 0,
                            'prefix' => 'myapp:expensive',
                            'servers' => [
                                [
                                    'host' => '127.0.0.1',
                                    'port' => 6379,
                                    'ttl' => 5,
                                    'password' => null,
                                ],
                            ],
                        ],
                    ],
                ],
            ],
            'object' => [
                'preferred_driver' => 'redis',
                'drivers' => [
                    'redis' => [
                        'options' => [
                            'database' => 0,
                            'prefix' => 'myapp:object',
                            'servers' => [
                                [
                                    'host' => '127.0.0.1',
                                    'port' => 6379,
                                    'ttl' => 5,
                                    'password' => null,
                                ],
                            ],
                        ],
                    ],
                ],
            ],
        ],
    ],
];

Session storage

You can use Redis instead of the filesystem to store the data of your visitor sessions. The definition of the Redis server(s) to be used must be done using the concrete.session.redis configuration key (its definition is the same as above), and you have to set the concrete.session.handler to redis.

Here's an extract from a sample /application/config/concrete.php file that configure Redis for the session data:

<?php

return [
    'session' => [
        'handler' => 'redis',
        'redis' => [
            'database' => 0,
            'prefix' => 'myapp:session',
            'servers' => [
                [
                    'host' => '127.0.0.1',
                    'port' => 6379,
                    'ttl' => 5,
                    'password' => null,
                ],
            ],
        ],
    ],
];

Page cache

In order to instruct Concrete to use Redis to store the cached pages, you can configure the concrete.cache.page.redis configuration key as described above, and set the concrete.cache.page.adapter configuration key to redis. You can configure the prefix with the prefix key,

Here's an extract from a sample /application/config/concrete.php file that configure Redis for the page cache:

<?php

return [
    'cache' => [
        'page' => [
            'adapter' => 'redis',
            'redis' => [
                'prefix' => 'myapp:page-cache',
                'database' => 0,
                'servers' => [
                    [
                        'host' => '127.0.0.1',
                        'port' => 6379,
                        'ttl' => 5,
                        'password' => null,
                    ],
                ],
            ],
        ],
    ],
];
Recent Tutorials
Customize locale icons
Oct 29, 2024
By myq.

How to customize locale (language region) flags

Concrete CMS Caching Guide
Oct 16, 2024

An overview of types of caching in Concrete and considerations when using them.

Redirect all requests to HTTPS
Oct 9, 2024
By myq.

How to follow best practices for a secure web

Upgrade Concrete versions 9.3.1 and 9.3.2
Sep 10, 2024
By myq.

How to get past a bug in versions 9.3.1 and 9.3.2 that prevents upgrading the Concrete core through the Dashboard

How to use Composer with Marketplace extensions
Aug 22, 2024

Composer can be used to manage third-party extensions from the marketplace

Controlling Google Tag Manager Tags Based on Concrete CMS Edit Toolbar Visibility
Aug 13, 2024

This document provides a step-by-step guide on how to control the firing of Google Tag Manager (GTM) tags based on the visibility of the Concrete CMS edit toolbar. It explains how to create a custom JavaScript variable in GTM to detect whether the edit toolbar is present on a page and how to set up a trigger that ensures GTM tags only fire when the toolbar is not visible. This setup is particularly useful for developers and marketers who want to ensure that tracking and analytics tags are not activated during content editing sessions, thereby preserving the accuracy of data collected.

Improvements?

Let us know by posting here.