Download the PHP package chesio/bc-cache without Composer

On this page you can find all versions of the php package chesio/bc-cache. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of chesio/bc-cache

Informations about the package bc-cache

BC Cache

GitHub Actions Packagist

Modern and simple full page cache plugin for WordPress inspired by Cachify.

BC Cache has no settings page - it is intended for webmasters who are familiar with .htaccess files and WordPress actions and filters.

BC Cache can cache not only HTML pages, but core XML sitemaps as well. Technically, any content type generated by WordPress for front-end requests routed via root index.php file can be handled provided that output generation triggers send_headers hook.

Requirements

Limitations

Installation

BC Cache is not available at WordPress Plugins Directory, but there are several other ways you can get it.

Using WP-CLI

If you have WP-CLI installed, you can install (and optionally activate) BC Cache with a single command:

Using Composer

Composer is a great tool for managing PHP project dependencies. Although WordPress itself does not make it easy to use Composer to manage WordPress installation as a whole, there are multiple ways how to do it.

BC Cache is available at Packagist, so just run composer require chesio/bc-cache as usual.

Using Git

Master branch always contains latest stable version, so you can install BC Cache by cloning it from within your plugins directory:

Updating is as easy as:

Using Git Updater plugin

Once installed, BC Cache can be kept up to date via Git Updater plugin. To install it either use the Git Updater Pro.

Direct download

This method is the least recommended, but it works without any other tool. You can download BC Cache directly from GitHub. Make sure to unpack the plugin into correct directory and drop the version number from folder name.

Setup

You have to configure your Apache webserver to serve cached files. Most common way to do it is to add the lines below to the root .htaccess file. This is the same file to which WordPress automatically writes pretty permalinks configuration - you must put the lines below before the pretty permalinks configuration.

Note: the configuration below assumes that you have WordPress installed in wordpress subdirectory - if it is not your case, simply drop the /wordpress part from the following rule: RewriteRule .* - [E=BC_CACHE_ROOT:%{DOCUMENT_ROOT}/wordpress]. In general, you may need to make some tweaks to the example configuration below to fit your server environment.

Configuration

BC Cache has no settings. You can modify plugin behavior with PHP constants, WordPress filters and theme features.

Constants

Two advanced features of the plugin can be optionally disabled with a constant.

The cache warm up feature can be disabled by setting BC_CACHE_WARM_UP_ENABLED constant with a false value:

File locking is used to ensure atomicity of operations that manipulate the cache. If your webserver has issues with flock() you may want to disable use of file locking by setting BC_CACHE_FILE_LOCKING_ENABLED constant with a false value:

Both constant must be defined at the time the plugin boots - typically the best place to define them is wp-config.php file. It is recommended to set the constants before activating the plugin.

Filters

If there was a settings page, following filters would likely become plugin settings as they alter basic functionality:

Filters for advanced functions

Following filters can be used to tweak automatic cache flushing:

Following filters can be used to extend list of cache exclusions or whitelist some query string parameters:

Following filters are necessary to set up request variants:

Following filters can be used to tweak warming up of cache:

Following filters are only useful if your theme declares support for caching for front-end users:

Theme features

Some advanced features must be supported by your theme and are active only if the theme explicitly declares its support for particular feature:

Automatic cache flushing

The cache is flushed automatically on core actions listed below. The list of actions can be filtered with bc-cache/filter:flush-hooks filter.

Special handling of posts and terms

In WordPress, posts can be used to hold various types of data - including data that is not presented on frontend in any way. To make cache flushing as sensible as possible, when a post is published or trashed the cache is flushed only when post type is public. You may use bc-cache/filter:is-public-post-type filter to override whether a particular post type is deemed as public for cache flushing purposes or not.

Note: Changing post status to draft, future or pending always triggers cache flush (regardless of the post type).

Terms (taxonomies) are handled in a similar manner - cache is automatically flushed when a term is created, deleted or edited, but only in case of terms from a public taxonomy. You may use bc-cache/filter:is-public-taxonomy filter to override whether a particular taxonomy should be deemed as public or not.

Flushing the cache programmatically

If you want to flush BC Cache cache from within your code, just call do_action('bc-cache/action:flush-cache'). Note that the action is available after the init hook with priority 10 is executed.

Scheduled cache flushing

Flushing of BC Cache cache on given schedule can be easily achieved with WP-Cron - you only have to hook the bc-cache/action:flush-cache action to a scheduled event. Following WP-CLI command sets WP-Cron event that triggers cache flush every midnight:

Cache exclusions

A response to HTTP(S) request is not cached by BC Cache if any of the conditions below evaluates as true:

  1. Request is a POST request.
  2. Request is a GET request with one or more query string fields that are not whitelisted. By default, the whitelist consists of Google click IDs, Facebook Click Identifier, Microsoft Click ID and standard UTM parameters, but it can be filtered.
  3. Request is not for a front-end page (ie. wp_using_themes returns false). Output of AJAX, WP-CLI or WP-Cron calls is never cached.
  4. Request comes from a non-anonymous user (ie. user that is logged in, left a comment or accessed password protected page/post). The rule can be tweaked to ignore front-end users if your theme supports it.
  5. Request/response type is one of the following: search, 404, feed, trackback, robots.txt, preview or password protected post.
  6. Fatal error recovery mode is active.
  7. DONOTCACHEPAGE constant is set and evaluates to true. This constant is for example automatically set by WooCommerce on certain pages.
  8. Return value of bc-cache/filter:skip-cache filter evaluates to true.

Important! Cache exclusion rules are essentially defined in two places:

  1. In PHP code (including bc-cache/filter:skip-cache filter), the rules are used to determine whether current HTTP(S) request should be written to cache.
  2. In .htaccess file, the rules are used to determine whether current HTTP(S) request should be served from cache.

When you add new rule for cache writing via bc-cache/filter:skip-cache filter, you should always consider whether the rule should be also enforced for cache reading via .htaccess file. In general, if your rule has no relation to request URI (for example you check cookies or User-Agent string), you probably want to have the rule in both places. The same applies to bc-cache/filter:query-string-fields-whitelist filter - any extra whitelisted fields will not prevent cache writing anymore, but will still prevent cache reading unless they are integrated into respective rule in .htaccess file.

Cache viewer

Contents of cache can be inspected (by any user with manage_options capability) via Cache Viewer management page (under Tools). Users who can flush the cache are able to delete individual cache entries.

You may encounter a warning in Cache Viewer about total size of cache files being different from total size of files in cache folder - this usually means that you failed to correctly provide list of all available request variants via bc-cache/filter:request-variants filter.

Front-end users and caching

Note: front-end user is any user that has no business accessing /wp-admin area despite being able to log in via wp-login.php. Although the implementation details do not presume any particular plugin, following text is written with WooCommerce (and registered customers as front-end users) in mind.

Depending on your theme, the HTML served to front-end users can be identical to the HTML served to anonymous users. Such themes most often fetch any personalized content (like items added to cart) via a JavaScript call. In such case there is no reason to exclude front-end users from full page caching.

There is a catch though...

Unlike some other content management systems, WordPress does not distinguish between back-end and front-end users. The same authentication mechanism is used to authenticate back-end users (like shop managers) and front-end users (like shop customers). As a fact, you cannot use the same email address to create a test customer account as you had used for shop manager account.

BC Cache by default does not read from or write to cache when HTTP request comes from any logged-in user:

  1. When call to is_user_logged_in function returns true, response to HTTP request is not written to cache.
  2. When HTTP request has a cookie with wordpress_logged_in in its name, response to HTTP request is not read from cache - this check must be configured in .htaccess file.

When your theme declares support for front-end user caching:

The first check is relaxed automatically with some reasonable defaults: any user that has read and customer capabilities only is considered to be front-end user and any pages he/she visits are written to cache normally. You may filter the capabilities list or the output of the check if you wish so.

To make it possible to relax the second check, BC Cache sets an additional session cookie whenever front-end user logs in. The rule in .htaccess file that deals with login cookie has to be extended as follows:

This way cached pages can be served to front-end users too. Cookie name and content can be adjusted by designated filters - make sure to adapt respective .htaccess rule if you change them.

Request variants

Sometimes a different response body is served to request to the same URL, typically when particular cookie is set or request is made by particular browser/bot. In such cases, BC Cache allows to define request variants and cache/serve different response body based on configured conditions. A typical example is the situation in which privacy policy notice is displayed until site visitor accepts it. The state (cookie policy accepted or not) is often determined based on presence of particular cookie. Using request variants, BC Cache can serve visitors regardless if they have or have not accepted the cookie policy.

Request variant configuration example

A website has two variants: one with cookie notice (_cookie_noticeaccepted cookie is not set) and one without (_cookie_noticeaccepted cookie is already set).

Request variant name should be set whenever cookie notice is accepted (example uses API of Cookie Notice plugin):

The default configuration needs to be extended as well and set the new variant accordingly:

Important: Variant names are appended to basename part of cache file names, so index becomes index_cna and index.gz becomes index_cna.gz in the example above. To make sure your setup will work, use only letters from [a-z0-9_-] range as variant names.

Cache warm up

Since version 2, the plugin performs cache warm up, ie. stores all pages in cache automatically without the need of front-end users to visit them. The obvious advantage is that even the first visitors of particular pages are served from cache (= fast).

Internally, the warm up process is hooked to WP-Cron and the website is crawling itself in the background. This automatic crawling is kicked up every time cache is flushed (with a 10 minutes delay by default, but this can be configured).

Since version 2.2, cache warm up can be triggered immediately from Cache Viewer. Also, the cache can be warmed up from command line via following WP-CLI command: wp bc-cache warm-up

In order for the warm up to function properly:

Cache warm up configuration examples

Invoke cache warm up just 5 minutes after last cache flush:

Allow only single warm up HTTP request per WP-Cron invocation:

Modify arguments of HTTP request to get page variant with cookie notice accepted (see request variant configuration example for context):

WP-CLI commands

You might use WP-CLI to delete specific posts/pages form cache, flush entire cache, run cache warm up, get size information or even list all cache entries. BC Cache registers bc-cache command with following subcommands:

Integration with 3rd-party plugins and tools

Autoptimize

Autoptimize is a very popular plugin to optimize script and styles by aggregation, minification, caching etc. BC Cache automatically flushes its cache whenever Autoptimize cache is purged.

Cookie Notice

Cookie Notice is a popular plugin to display a simple, customizable website banner helpful achieving compliance with certain cookie consent requirements. BC Cache automatically flushes its cache whenever Cookie Notice banner configuration is changed.

7G firewall

If you happen to have 7G firewall by Jeff Starr installed on your website, you may have to alter the rule in 7G:[REQUEST URI] section that prevents access to .gz files (note that the code snippet below has been shortened with ... for better readability):

If you see 403 errors instead of cached pages, you have to either remove the |gz part from the RewriteCond line above or remove the line completely.

Credits

All versions of bc-cache with dependencies

PHP Build Version
Package Version
Requires php Version ^8.1
composer/installers Version ^1.0 || ^2.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package chesio/bc-cache contains the following files

Loading the files please wait ....