Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to Create an Advanced Cache Plugin #5

Open
6 tasks
raamdev opened this issue Dec 28, 2014 · 1 comment
Open
6 tasks

How to Create an Advanced Cache Plugin #5

raamdev opened this issue Dec 28, 2014 · 1 comment

Comments

@raamdev
Copy link
Contributor

raamdev commented Dec 28, 2014


KB Article Creation Checklist
  • Write initial draft for this KB Article; label this issue draft and either questions or tutorials
  • Add required YAML configuration
  • Add Tags for this KB Article to the YAML config (see YAML Keys (Explained))
  • Edit and finalize draft for publishing (remove draft label, add draft-finalized label)
  • Assign Issue to yourself and create Markdown file (remove draft-finalized label, add pending)
  • Project Lead: Review and Publish KB Article (remove pending label, add published label)
title: 
categories: 
tags: 
author: 
github-issue: https://github.com/websharks/zencache-kb/issues/5

This KB article should explain how to create an Advanced Cache Plugin, and provide a few scenarios where one might use one.

@jaswsinc writes...


When a plugin developer adds hooks using an AC plugin file, they are going to be adding hooks with Quick Cache itself, using methods provided by the advanced_cache class. Thus, the name "AC plugins".

So if I were writing an AC plugin file, I would not do something like this:

add_filter('quick_cache_xxx_xxx_xxx', function());

Instead, I'd need to use the family of hook-related methods provided by the advanced_cache class, which inherits methods from the share class.

$ac = $GLOBALS['quick_cache__advanced_cache'];
$ac->add_filter(get_class($ac).'__version_salt', function(){ return 'my salt'; });

See also, the example here: https://github.com/websharks/quick-cache/blob/000000-dev/quick-cache/includes/ac-plugin.example.php


@raamdev writes to a customer

The Version Salt can be configured inside the Quick Cache UI (see Quick Cache ⥱ Plugin Options ⥱ Dynamic Version Salt) or for more advanced implementations you can supply the version salt via an AC Plugin (see example, specifically the my_ac_version_salt_shaker() function example.

Regarding getting information for the version salt after the WordPress "init": You are correct that Quick Cache loads everything before the WordPress "init" fires. This is necessary, as it's what makes Quick Cache a caching plugin (it allows Quick Cache to serve pages without loading all of WordPress and slowing things down). The Advanced Cache (advanced-cache.php) system that WordPress provides for caching plugins to hook into is loaded before most of WordPress (this is where Quick Cache is loaded in WordPress).

However, you do have Cookies, PHP Environment Variables, and any constants defined in wp-config.php available to you when building your Version Salt.

For your scenario, I would recommend using the cookie approach:

Your plugin would set a cookie whenever the visitor selects a specific currency: setcookie("MyCurrencyPlugin", $currency)

In your Quick Cache AC Plugin, you would then check if $_COOKIE['MyCurrencyPlugin'] is set. If it is set, then you would use the value of that cookie to create the Version Salt. For example, if the value of the cookie was EUR then that would be used to create a version of the cache specifically for all pages that are showing the EUR currency.

For this example, an AC Plugin wouldn't even be necessary. If you know that your plugin is setting a cookie called "MyCurrencyPlugin" whenever the currency changes, you could simply add $_COOKIE['MyCurrencyPlugin'] to the Dynamic Version Salt options panel (see screenshot).


@raamdev writes...

@jaswsinc: Quick question regarding the AC Plugin system: I'm looking over how it works in the code and from what I can tell, AC Plugins would not have access to any post-Init WordPress stuff, correct? For example, if someone wanted to write a plugin that generated a Version Salt for Quick Cache based on the state of WordPress plugin (let's say, a WP plugin that shows content in various currencies based on the currently selected currency), that wouldn't be possible, correct? Anything that an AC-Plugin uses must be pre-Init (e.g., something inside wp-config.php) or something in the PHP environment itself (server variables, etc.).

@jaswsinc writes...

That's right. It's in that particular phase that we can avoid loading most parts of WordPress and instead serve a cache file, which will be much faster and easier on the server. So it also means that we have much less to work with. Things in the /wp-config.php file will be available, and the PHP environment (as you mentioned). There is also a very small amount of WordPress loaded, like the core constants. This is where QC runs, so everything above this line will be available. Everything below it will not be. https://github.com/WordPress/WordPress/blob/master/wp-settings.php#L64

There is one exception to this however. QC has a postload phase that runs a few things also; but only if the cache cannot be served for some reason. See: https://github.com/WordPress/WordPress/blob/master/wp-settings.php#L227

@raamdev writes...

In the case of a plugin where the user (the person browsing the site) changes the state (for example, selecting a dropdown menu to change the currency shown on the site, or a language plugin changing the language shown on the site), a cookie would be the only way to go, correct? (An environment variable wouldn't work because how would you set and save the environment variable based on a visitor's preference...).

On the other hand, if we were talking about a state that was changed based on plugin options, then we could do something like write a value to a constant in wp-config.php which our AC Plugin would then read.

Am I following this correctly?

@jaswsinc writes...

On the other hand, if we were talking about a state that was changed based on plugin options, then we could do something like write a value to a constant in wp-config.php which our AC Plugin would then read.

Correct. This would make it easy to build an AC plugin of your own that would then read that config value and create the salt that considers it.

a cookie would be the only way to go, correct? (An environment variable wouldn't work because how would you set and save the environment variable based on a visitor's preference...).

Well, an environment variable can be set by the web server itself using things like Mod Rewrite, where it picks apart the URL. The thing to keep in mind, is that each of these are tools that could be used in concert. If a cookie works, then that's probably easier. However, you could also add something like a WordPress Endpoint http://codex.wordpress.org/Rewrite_API/add_rewrite_endpoint and then look for this in the URL. Either with PHP, or with Mod Rewrite. At times, using an environment variable might make sense. At other times, it might be easier just to detect subtle changes in the structure of a URL (or of a query string variable); and then base your salt on this.

@jaswrks
Copy link

jaswrks commented Feb 3, 2015

Nice article! :-) Wow, those two guys really know their stuff! 😮

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants