On Apache servers, RunCache can serve cached pages directly through Apache without starting PHP for each request. The PHP page cache creates and stores the cached page, while rewrite rules in .htaccess direct later requests to the stored file.

This guide explains the Apache modules required, how to configure the cache, when Apache serves a cached page, and how to verify that it is working.

Before you start

Make sure you have:

  • Terminal access with permission to enable Apache modules and restart Apache.
  • A writable .htaccess file in the WordPress root directory.
  • The RunCache Full Page Cache screen open in WordPress.

The Apache module setup only needs to be completed once. RunCache manages its own .htaccess rules after that.

The top of the RunCache dashboard as captured on the lab server. Cache Status reads Enabled with PHP Cache below it and a pink toggle on, then Pages Cached 84, Cache Size 9 MB and Compression Ratio 80.6%. A row of four tabs reads Full Page Cache, CDN Edge Cache, Assets CDN and Object Cache. Under it a blue callout headed NGINX Server Detected recommends NGINX FastCGI Cache for best performance and NGINX Page Cache for a simpler setup, above three switched-off cards for Nginx Page Cache, Nginx FastCGI Cache and Redis Page Cache. An amber pill on the right reads PHP Cache - Configuration Required, beside a Verify Cache link.

You can enable Apache Page Cache from the Full Page Cache tab in RunCache.

On an Apache server, RunCache displays an Apache Server Detected notice and provides Apache Page Cache and Redis Page Cache options.

Using Apache Page Cache on RunCloud

On a RunCloud-managed server, RunCache automatically detects the server environment and makes the supported server-level cache options available. RunCache then automatically generates the required configuration.

RunCache writes the required rewrite rules to .htaccess. Apache Page Cache requires the mod_rewrite and mod_headers modules, which are enabled on a standard RunCloud Apache stack.

Apache Requirements

  1. Make sure the .htaccess file in your WordPress root directory is writable by the web server. RunCache cannot install the rules otherwise.

  2. Enable the two modules that the rules depend on:a2enmod headers rewrite If either module is newly enabled, Apache may prompt you to restart the service. For example:Enabling module headers. Module rewrite already enabled To activate the new configuration, you need to run: service apache2 restart If Apache reports that a module is already enabled, no further action is required.If Apache reports that a module does not exist, make sure the required module is installed before continuing.RunCache uses mod_rewrite to process cache requests and mod_headers to add the X-RunCache-* response headers.

  3. Restart Apache:

    systemctl restart apache2

    After restarting Apache, confirm that both required modules are loaded:

    apachectl -M | grep -E "headers|rewrite"

    The command should return entries for both headers_module and rewrite_module.

    If only one module appears, enable the missing module before continuing.

     rewrite_module (shared)

How RunCache Updates .htaccess

RunCache adds its Apache rewrite rules to .htaccess between the following markers:

# BEGIN RunCache
...
# END RunCache

To confirm that RunCache added its rewrite block, check the beginning of .htaccess:

head -3 .htaccess

# BEGIN RunCache
# RunCache Plugin: Apache rewrite rules for serving cached pages.
# Bugs or questions? Email [email protected].

If the RunCache block does not appear, confirm that .htaccess is writable by the web server, then enable Apache Page Cache again.

RunCache writes its cache rules above the existing WordPress rewrite rules so Apache can check for a cached file before passing the request to WordPress.

When the settings are saved again, RunCache replaces its existing block rather than adding a duplicate.

Enabling Apache Page Cache also enables the PHP page cache component, which generates the cached HTML files that Apache serves.

When Apache Serves a Cached Page

Apache bypasses the cached page when any of the following conditions apply:

  • The method is not GET
  • The path starts with /.well-known, /wp-admin, /wp-login.php, /wp-cron.php, /wp-signup.php, /wp-activate.php, /wp-comments-post.php, /wp-json, /xmlrpc.php, a feed path, /cart, /checkout or /my-account
  • The URI matches *sitemap*.xml
  • The request carries wp-postpass, wordpress_logged_in, wordpress_sec_, comment_author or wp-settings-

For Apache to serve a cached page, the request must also have an empty query string and must not target an existing file on disk.

Cached files are stored at paths such as:

wp-content/cache/runcache/<host>/index.html
wp-content/cache/runcache/<host>/<path>/index.html

Requests containing a query string are handled by PHP rather than Apache Page Cache, even if RunCache is configured to ignore that query parameter.

If the PHP cache serves the request, the response reports:

X-RunCache-Type: PHP

Verify Apache Page Cache

Run the following request twice while logged out of WordPress:

curl -s -o /dev/null -D - https://example.com/ | grep -i x-runcache

On the second request, a successful Apache cache hit should return:

X-RunCache-Type: Apache
X-RunCache-Status: HIT

If the response contains:

X-RunCache-Type: PHP

the page was served from the PHP cache rather than Apache Page Cache. Check whether the request contains a query string and confirm that the RunCache rewrite block exists in .htaccess.

If no X-RunCache-* headers appear on a page that is being cached, confirm that mod_headers is enabled.

How RunCache Verification Works

When you verify Apache Page Cache, RunCache rewrites its .htaccess block before checking the home page response.

If verification continues to fail, check that:

  • .htaccess is writable.
  • mod_headers is enabled.
  • Another plugin has not added rewrite rules ahead of the RunCache block.

Disable Apache Page Cache

Disabling Apache Page Cache removes the RunCache rewrite block from .htaccess and removes the PHP page cache drop-in.

Your existing .htaccess rules remain unchanged.

Confirm the result by verifying the cache is working; if nothing is being served, work through “Nothing is being cached.”