Setting up the object cache with Redis or Memcached
First: what can your PHP do?
The object cache talks to Redis or Memcached, and for that PHP needs the matching extension. Kakapo checks this at runtime by looking whether the class Redis or Memcached is really loaded. A running Redis service alone is not enough: without the extension PHP cannot talk to it. If it is missing, the entry in the selection list is disabled, and next to it you see which package is missing (for example “pecl install redis” or the distribution package php<version>-redis, then restart PHP). If Kakapo only finds the older extension “memcache” without the d, it says so explicitly — it is not used, because it lacks the getMulti batch query and binary transfer. If neither of the two extensions is there, you cannot get any further here; that is a matter for your host, not for the plugin.
Entering the connection details
Host is usually 127.0.0.1. A scheme such as “http://” is rejected, because only a hostname or an IP belongs here. For a Unix socket you enter its path (e.g. /var/run/redis/redis.sock) and set the port to 0. The port is usually 6379 with Redis and 11211 with Memcached; 0 to 65535 is allowed. If you switch the connection, Kakapo brings the default port along automatically, as long as the old one was still the default. The database number (0 to 255) only exists with Redis and separates this site from other applications on the same server. You only need a user name and password if your Redis works with ACL (from Redis 6) or Memcached requires SASL. The key prefix separates two WordPress installations on the same cache server from one another — if the field stays empty, a prefix is derived from your site address (kwpp plus eight characters). Letters, digits and _ . : - are allowed, at most 40 characters. The lifetime per entry is preset to 86400 seconds; 0 to 2592000 is allowed. 0 means “never expires” — that has consequences for clearing, see below.
Test the connection before you write anything
The “Test connection” button really does open a connection, writes a test key (valid for 30 seconds), reads it back, compares it character by character with the value written and deletes it again. Only when the value comes back unchanged does the test count as passed — a mere “connect() did not return false” would be too thin: Redis can be connected and still be write-protected (a replica), and Memcached accepts connections before it has memory. A time limit of one second applies to the whole cycle. The measured time and a few server details (version, memory used, number of entries, duration) are then shown in the card. If the test fails, the specific reason is given there: not reachable, authentication rejected, database cannot be selected. The test runs exclusively in the admin area or via cron — a test connection is never opened while a visitor's page is being built.
Writing the drop-in — and what happens in the process
The object cache lives in the file wp-content/object-cache.php. WordPress loads it very early, before any plugin. Before writing, Kakapo shows a preview: which file will be created, which access data it will contain, what will then be stored on the cache server and what the way back looks like. If something is in the way — a missing extension, someone else's drop-in at that spot, wp-content not writable, a missing template — the button is disabled and the reason is shown above it; the check is repeated on the server side when writing. To confirm, you type INSTALLIEREN. It is then written first to a neighbouring file, which PHP itself checks for syntax (provided exec() is allowed and a PHP binary is reachable), and only afterwards renamed into its place and set to 0644. The reason for the detour: a half-written object-cache.php would be an error before every plugin — the site would be blank, including the admin page from which you wanted to undo it. Every write also gets its own generation, so that entries from the time before a removal do not suddenly become valid again (otherwise the old blog name would come back, for instance, and logged-in administrators would be thrown out of their session). If someone else's drop-in is already at that spot, it is neither overwritten nor deleted.
In operation: reading the numbers, clearing, removing
Under “Live operation” you find the numbers for this one page view: connection setup in milliseconds, hits and misses, how many of them came from the cache server, how many requests went there and how long they took. There are deliberately no statistics over time — keeping them would cost more on every request than they measure. “Clear object cache” switches the key salt instead of sending FLUSHDB or flush_all: this means no old key points to a valid entry any more, while data belonging to other applications on the same server stays untouched. The orphaned entries expire via the configured lifetime — if that is set to 0, they never expire and pile up until Redis or Memcached cleans up by itself. If you change settings, what is in the file still applies; Kakapo reports the discrepancy and offers “Update drop-in”. “Remove drop-in” deletes exactly one file, without leaving behind a database row or a schedule; it also disappears when the plugin is deactivated. If you do not want the password in plain text in the file, you define it as KWPP_OC_AUTH in wp-config.php and leave the field empty — the constant takes precedence. The same works for host, port, user, database and prefix (KWPP_OC_HOST, KWPP_OC_PORT, KWPP_OC_USER, KWPP_OC_DB, KWPP_OC_PREFIX); a server change then needs no rewriting of the drop-in.