Allow unique release version as part of key scheme #51

Open

khromov wants to merge 1 commit from khromov/add-release-var into master

khromov commented

2016-05-24 20:22:03 +01:00

(Migrated from github.com)

Flushing the entire cache in APC or Memcached is not ideal because multiple sites can reside on same server, and because it can also cause the Object Cache to be cleared if you use the same backend for both.

This pull request allows for the use of the variable $release in the "Key scheme" to allow invalidation of WP-FFPC page cache when a new version is deployed.

Use case: We want the page cache to be invalidated when a new version of the site is released without having to flush the entire cache backend.

With this PR, we can add the following to wp-config.php:

define("WP_RELEASE", '16bb26116228a6c6090214b091725070d894e5ed');

(In this example, 16bb26116228a6c6090214b091725070d894e5ed is the currently deployed Git hash)

Then we will set $release as part of the key scheme:

$release-$scheme://$host$request_uri

The raw cache keys will now be:

meta-16bb26116228a6c6090214b091725070d894e5ed-http://site.com
data-16bb26116228a6c6090214b091725070d894e5ed-http://site.com

If we define WP_RELEASE dynamically for each release ( using a deploy system like Deployer or Capistrano) we can gracefully invalidate old cache entries without having to flush the entire cache.

![2016-05-24 21_21_38-wp-ffpc options wp stable wordpress](https://cloud.githubusercontent.com/assets/1207507/15516966/86ca1626-21f5-11e6-9cea-cd3509cf4d50.png) Flushing the entire cache in APC or Memcached is not ideal because multiple sites can reside on same server, and because it can also cause the Object Cache to be cleared if you use the same backend for both. This pull request allows for the use of the variable `$release` in the "Key scheme" to allow invalidation of WP-FFPC page cache when a new version is deployed. **Use case**: We want the page cache to be invalidated when a new version of the site is released without having to flush the entire cache backend. With this PR, we can add the following to `wp-config.php`: ``` php define("WP_RELEASE", '16bb26116228a6c6090214b091725070d894e5ed'); ``` (In this example, `16bb26116228a6c6090214b091725070d894e5ed` is the currently deployed Git hash) Then we will set `$release` as part of the key scheme: ``` $release-$scheme://$host$request_uri ``` The raw cache keys will now be: ``` meta-16bb26116228a6c6090214b091725070d894e5ed-http://site.com data-16bb26116228a6c6090214b091725070d894e5ed-http://site.com ``` If we define `WP_RELEASE` dynamically for each release ( using a deploy system like Deployer or Capistrano) we can gracefully invalidate old cache entries without having to flush the entire cache.

khromov commented

2016-08-08 16:44:38 +01:00

(Migrated from github.com)

Bump!

khromov commented

2016-09-29 22:16:20 +01:00

(Migrated from github.com)

@petermolnar Could you please take a look at this? I'm open to any feedback you have and would love to see this merged!

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin khromov/add-release-var:khromov/add-release-var

git checkout khromov/add-release-var

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout master

git merge --no-ff khromov/add-release-var

git checkout khromov/add-release-var

git rebase master

git checkout master

git merge --ff-only khromov/add-release-var

git checkout khromov/add-release-var

git rebase master

git checkout master

git merge --no-ff khromov/add-release-var

git checkout master

git merge --squash khromov/add-release-var