You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
@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
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.
The text was updated successfully, but these errors were encountered:
KB Article Creation Checklist
draft
and eitherquestions
ortutorials
draft
label, adddraft-finalized
label)draft-finalized
label, addpending
)pending
label, addpublished
label)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:
Instead, I'd need to use the family of hook-related methods provided by the
advanced_cache
class, which inherits methods from theshare
class.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 writes...
@raamdev writes...
@jaswsinc writes...
The text was updated successfully, but these errors were encountered: