Jabali Cache

开发者	apunker
更新时间	2026年6月27日 10:56
PHP版本:	7.4 及以上
WordPress版本:	7.0
版权:	GPLv2 or later
版权网址:	版权信息

下载

1.0.0

详情介绍:

Jabali Cache makes WordPress fast by keeping its object cache in Redis instead of rebuilding it on every request. WordPress normally throws away its internal cache at the end of each request, so the same expensive database queries run again and again. This plugin makes that cache persistent — backed by the Redis instance the Jabali hosting panel already runs — so pages assemble from memory instead of hammering MySQL. It is purpose-built for shared hosting, where many sites share one Redis server. That shapes every design decision: strict per-site isolation, safe behaviour under memory pressure, and a hard rule that a caching layer must never take a site down. Why you might want it

Fewer database queries, faster pages. Options, post meta, terms, user data and transients come from Redis on repeat requests instead of MySQL.
Lighter database load. Especially noticeable on WooCommerce, membership, and query-heavy sites under traffic.
Drop-in. Activate it and WordPress's standard object-cache API (wp_cache_*, transients) starts using Redis. No theme or plugin changes.

Built for the way Jabali hosts sites

Zero-config on Jabali. Connects to the panel Redis over the unix socket /run/redis/redis.sock, logical database 1. Nothing to type — no host, port, or password.
Strict per-site isolation. Every install gets its own key prefix. Sites share one Redis database but can never read or flush each other's cache. A site's flush only clears that site's keys.
No phpredis required. If the redis PHP extension is present it is used automatically; if not (the Jabali default), the plugin falls back to a dependency-free, pure-PHP RESP client over the same socket. Either way it just works.
Safe under memory pressure. The panel Redis runs an allkeys-lru policy, so it may evict keys at any time. Every read is best-effort — an evicted or missing key simply falls through to the database. An eviction is never an error.
Fails safe, always. If Redis is unreachable for any reason, WordPress keeps running with its normal per-request cache. Nothing breaks; caching just stops accelerating until the connection is back. The admin screen tells you exactly what is wrong and how to fix it.
Multisite-aware. On a network, per-blog data is namespaced per site while genuinely global groups (network, site meta) are shared correctly.

Object cache vs. page cache The persistent object cache is the main event and is on as soon as you activate the plugin. A full page cache is also included, but it is off by default. Jabali already serves a faster page cache at the edge via nginx (FastCGI microcache), so turning on the WordPress page cache as well would just cache the same HTML twice. Enable the in-WordPress page cache only on hosts where the nginx one is not available. Privacy Jabali Cache stores WordPress's own cache data in your Redis server and nowhere else. It does not collect analytics, contact any external service, or send data off your server. Support Development happens on GitHub. Found a bug, or have a feature request? Please open an issue: https://github.com/shukiv/jabali-panel/issues

安装:

On the Jabali panel (recommended)

Install and activate Jabali Cache. Activation drops in object-cache.php automatically.
In the panel, enable caching for the site (Applications → cache toggle). This provisions the site's Redis socket access.
Visit Settings → Jabali Cache and confirm Redis connection: Connected.

On any other host

Upload the jabali-cache folder to wp-content/plugins/ (or install the zip from Plugins → Add New).
Activate Jabali Cache.
Point it at your Redis server with a few constants in wp-config.php (see the FAQ). Over a unix socket or TCP both work.
Check Settings → Jabali Cache for a green connection status.

If the status ever shows Not reachable, the screen prints the exact prerequisite to fix — and the site keeps working the whole time as a normal non-persistent cache.

升级注意事项:

1.0.0 Initial release.

常见问题:

The status says Redis is "Not reachable". What do I do?

On the Jabali panel, socket access is set up when you enable caching for the site (Applications → cache toggle). If the status still shows Not reachable, re-run that toggle. On a standalone host, the site's PHP-FPM user needs two things for a unix socket:

open_basedir must allow the socket's directory — add /run/redis (or wherever your socket lives) to the pool's open_basedir.
Read/write access to the socket for the PHP-FPM user.

Until that is in place the plugin runs as a normal per-request cache and the site is completely unaffected — caching just isn't persistent yet.

Does it need the phpredis (PECL redis) extension?

No. It auto-detects phpredis and uses it when available; otherwise it uses a built-in pure-PHP client. You get persistent caching either way.

How do I use it outside the Jabali panel?

Define overrides in wp-config.php. With none of these set, it defaults to the Jabali socket and a per-site prefix. define( 'JABALI_CACHE_SOCKET', '/path/to/redis.sock' ); — unix socket, or: define( 'JABALI_CACHE_HOST', '127.0.0.1' ); define( 'JABALI_CACHE_PORT', 6379 ); Optional: define( 'JABALI_CACHE_DB', 1 ); — logical database number define( 'JABALI_CACHE_PASSWORD', '...' ); — Redis AUTH password define( 'JABALI_CACHE_PREFIX', 'mysite' ); — key prefix (auto-derived per site if unset) define( 'JABALI_CACHE_DISABLED', true ); — force off without deactivating

Will it isolate my cache from other sites on the same server?

Yes. Each install uses a unique key prefix, so reads, writes, and flushes are scoped to your site only. One site cannot see or clear another's cache, even though they may share the same Redis database.

Is it safe if Redis runs out of memory?

Yes. The expected policy is allkeys-lru — Redis evicts least-recently-used keys when full. Every read in this plugin is best-effort, so an evicted key just rebuilds from the database. There is no error path that can break the site under memory pressure.

Does it work on WordPress Multisite?

Yes. Per-site cache data is namespaced per blog, while truly global cache groups are shared across the network as WordPress expects.

Should I also turn on the page cache?

Only if your host does not already have one. On Jabali, nginx serves a FastCGI microcache at the edge, which is faster than caching in PHP — so the WordPress page cache stays off by default to avoid double-caching. Off Jabali, you can enable it from the settings screen.

How do I manage it from WP-CLI?

wp jabali-cache status # connection, driver, prefix, key count, page-cache state wp jabali-cache flush # flush this site's object cache wp jabali-cache flush --pages # also purge page-cache entries wp jabali-cache enable # enable caching wp jabali-cache disable # disable caching wp jabali-cache update-dropins # (re)install the wp-content drop-ins wp jabali-cache remove-dropins # remove the drop-ins wp jabali-cache diagnose # full connectivity + environment report

What happens when I uninstall it?

Deactivating removes the object-cache.php drop-in cleanly, so WordPress reverts to its built-in non-persistent cache. Uninstalling removes the plugin's options. Your Redis data is just a cache and is safe to discard.

更新日志: