[WordPress] 外掛分享： Pantheon Advanced Page Cache

內容目錄

1 前言介紹
2 外掛協作開發者
3 外掛標籤
4 內容簡介
5 原文外掛簡介
- 5.1 Other Filters
6 各版本下載點
7 延伸相關外掛（你可能也想知道）

前言介紹

這款 WordPress 外掛「Pantheon Advanced Page Cache」是 2016-11-08 上架。
目前有 10000 個安裝啟用數。
上一次更新是 2025-02-25，距離現在已有 67 天。
外掛最低要求 WordPress 6.4 以上版本才可以安裝。
有 1 人給過評分。
還沒有人在論壇上發問，可能目前使用數不多，還沒有什麼大問題。

外掛協作開發者

外掛標籤

cdn | cache | pantheon |

內容簡介

對於希望對其頁面緩存作出細粒度控制的網站，Pantheon Advanced Page Cache 是實現這一目的的黃金工具。以下是該外掛程式運作的概述：

當響應產生時，該外掛程式會基於 WordPress 的主要WP_Query對象使用代理鍵來為用於響應的數據標記該響應的標識符。鑒於“添加自定義鍵”部分，您可以包括自己的代理鍵。
當 WordPress 數據被修改時，該外掛程式會觸發一個與相應代理鍵關聯的刷新請求。

由於它的代理鍵技術，因此 Pantheon Advanced Page Cache 為 WordPress 網站提供了一個明顯更精確的緩存刷新機制，通常具有更高的緩存命中率。它甚至與 WordPress REST API 一起運作。

讓我們開始創造偉大的事物吧！一旦您創建了非常棒的東西，請向我們發送功能請求（或錯誤報告）。

其作用原理

Pantheon Advanced Page Cache 大量使用代理鍵，這使得響應能夠被標記為隨後可用於刷新請求的標示符。例如，主頁響應可能會包括這些鍵的Surrogate-Key標頭：

Surrogate-Key: front home post-43 user-4 post-41 post-9 post-7 post-1 user-1

同樣，對 / wp-json / wp / v2 / posts的GET請求可能會包括這些鍵的Surrogate-Key標頭：

Surrogate-Key: rest-post-collection rest-post-43 rest-post-43 rest-post-9 rest-post-7 rest-post-1

由於緩存響應包括描述其中數據的元數據，因此代理鍵使得刷新行為更靈活，例如：

當一篇文章被更新時，清除文章的 URL，首頁，文章出現的任何索引視圖以及文中存在的任何 REST API 端點的緩存。
當一位作者更改其名稱時，清除對應該作者的目錄和他們編寫的任何文章的緩存。

一個響應中的代理鍵數量有一定限制，因此我們已根據用戶對正常 WordPress 網站的期望進行了優化。有關包含哪些鍵的詳細信息，請參閱“發射鍵”部分。如需添加自定義代理鍵的信息，請參閱以下“添加自定義鍵”部分。

添加自定義代理鍵

Pantheon Advanced Page Cache 默認基於 WordPress 主要WP_Query查詢對象解釋生成代理鍵。由於 WordPress 在頁面呈現之前發送頭信息，因此您需要使用pantheon_wp_main_query_surrogate_keys過濾器來包括頁面上出現的任何數據的其他代理鍵。

例如，為在主頁上呈現的側邊欄包括代理鍵，您可以使用is_home()模板標記來過濾鍵：

/**
* 為主頁面呈現的特色內容側邊欄添加代理鍵。
*/
add_filter（'pantheon_wp_main_query_surrogate_keys'，function（$keys）{
if ( is_home() ) {
$keys[] = 'sidebar-home-featured';
}
return $keys;
});

接下來，當側邊欄被更新時，您可以使用pantheon_wp_clear_edge_keys（）輔助函數發射特定於代理鍵的刷新事件：

原文外掛簡介

For sites wanting fine-grained control over how their responses are represented in their edge cache, Pantheon Advanced Page Cache is the golden ticket. Here’s a high-level overview of how the plugin works:

When a response is generated, the plugin uses surrogate keys based on WordPress’ main WP_Query object to “tag” the response with identifers for the data used in the response. See the “Adding Custom Keys” section for including your own surrogate keys.
When WordPress data is modified, the plugin triggers a purge request for the data’s corresponding surrogate keys.

Because of its surrogate key technology, Pantheon Advanced Page Cache empowers WordPress sites with a significantly more accurate cache purge mechanism, and generally higher cache hit rate. It even works with the WordPress REST API.
Go forth and make awesome! And, once you’ve built something great, send us feature requests (or bug reports).
How It Works
Pantheon Advanced Page Cache makes heavy use of surrogate keys, which enable responses to be “tagged” with identifiers that can then later be used in purge requests. For instance, a home page response might include the Surrogate-Key header with these keys:
Surrogate-Key: front home post-43 user-4 post-41 post-9 post-7 post-1 user-1

Similarly, a GET requests to /wp-json/wp/v2/posts might include the Surrogate-Key header with these keys:
Surrogate-Key: rest-post-collection rest-post-43 rest-post-43 rest-post-9 rest-post-7 rest-post-1

Because cached responses include metadata describing the data therein, surrogate keys enable more flexible purging behavior like:

When a post is updated, clear the cache for the post’s URL, the homepage, any index view the post appears on, and any REST API endpoints the post is present in.
When an author changes their name, clear the cache for the author’s archive and any post they’ve authored.

There is a limit to the number of surrogate keys in a response, so we’ve optimized them based on a user’s expectation of a normal WordPress site. See the “Emitted Keys” section for full details on which keys are included, and the “Adding Custom Keys” section following for information on how to add your own.
Adding Custom Keys
By default, Pantheon Advanced Page Cache generates surrogate keys based on an interpretation of the main WP_Query query object. Because WordPress sends headers before the page is rendered, you need to use the pantheon_wp_main_query_surrogate_keys filter to include additional surrogate keys for any data present on the page.
For example, to include surrogate keys for a sidebar rendered on the homepage, you can filter the keys using the is_home() template tag:
/**
* Add surrogate key for the featured content sidebar rendered on the homepage.
*/
add_filter( 'pantheon_wp_main_query_surrogate_keys', function( $keys ){
if ( is_home() ) {
$keys[] = 'sidebar-home-featured';
}
return $keys;
});

Then, when sidebars are updated, you can use the pantheon_wp_clear_edge_keys() helper function to emit a purge event specific to the surrogate key:
/**
* Trigger a purge event for the featured content sidebar when widgets are updated.
*/
add_action( 'update_option_sidebars_widgets', function() {
pantheon_wp_clear_edge_keys( array( 'sidebar-home-featured' ) );
});

Similarly, to include surrogate keys for posts queried on the homepage, you can pre-fetch the posts before the page is rendered:
/**
* An example of pre-fetching a WP_Query to tag the
* response with queried data. You'd use `papcx_wp_query()`
* a second time within your template to use the data.
*/
add_filter( 'pantheon_wp_main_query_surrogate_keys', function( $keys ) {
if ( is_home() ) {
$query = papcx_wp_query( array(
'post_type' => 'page',
) );
foreach( $query->posts as $post ) {
$keys[] = 'post-' . $post->ID;
}
}
return $keys;
});

/**
* Register a 'papc-non-persistent' cache group to cache data
* in a non-persistent manner. We only want data in this group
* to be cached within the page request.
*/
add_action( 'init', function(){
wp_cache_add_non_persistent_groups( array( 'papc-non-persistent' ) );
});

/**
* Helper function to instantiate a WP_Query object only
* once per page request.
*
* @param array $args Arguments to pass to WP_Query.
* @return WP_Query
*/
function papcx_wp_query( $args = array() ) {
$cache_key = md5( serialize( $args ) );
// WP_Query object will be in cache the second time we use the function.
$cache_value = wp_cache_get( $cache_key, 'papc-non-persistent' );
if ( false !== $cache_value ) {
return $cache_value;
}
$query = new WP_Query( $args );
wp_cache_set( $cache_key, $query, 'papc-non-persistent' );
return $query;
}

Because Pantheon Advanced Page Cache already handles WordPress post purge events, there’s no additional call to pantheon_wp_clear_edge_keys().
Lastly, the pantheon_wp_rest_api_surrogate_keys filter lets you filter surrogate keys present in a REST API response.
Additional purging by path
When a post is published for the first time, the permalink’s path is also purged even if it has no matching keys. This can be further filtered with the pantheon_clear_post_path filter.
add_action('pantheon_clear_post_path', function($paths) {
// Add or remove paths from $paths
return $paths
}, 10, 3);

Need a bit more power? In addition to pantheon_wp_clear_edge_keys(), there are two additional helper functions you can use:

pantheon_wp_clear_edge_paths( $paths = array() ) – Purge cache for one or more paths.
pantheon_wp_clear_edge_all() – Warning! With great power comes great responsibility. Purge the entire cache, but do so wisely.

Ignoring Specific Post Types
By default, Pantheon Advanced Page Cache is pretty aggressive in how it clears its surrogate keys. Specifically, any time wp_insert_post is called (which can include any time a post of any type is added or updated, even private post types), it will purge a variety of keys including home, front, 404 and feed. To bypass or override this behavior, since 1.5.0 we have a filter allowing an array of post types to ignore to be passed before those caches are purged. By default, the revision post type is ignored, but others can be added:
/**
* Add a custom post type to the ignored post types.
*
* @param array $ignored_post_types The array of ignored post types.
* @return array
*/
function filter_ignored_posts( $ignored_post_types ) {
$ignored_post_types[] = 'my-post-type'; // Ignore my-post-type from cache purges.
return $ignored_post_types;
}

add_filter( 'pantheon_purge_post_type_ignored', 'filter_ignored_posts' );

This will prevent the cache from being purged if the given post type is updated.
Setting the Cache Max Age with a filter
The cache max age setting is controlled by the Pantheon Page Cache admin page. As of 2.0.0, there are three cache age options by default — 1 week, 1 month, 1 year. Pantheon Advanced Page Cache automatically purges the cache of updated and related posts and pages, but you might want to override the cache max age value and set it programmatically. In this case, you can use the pantheon_cache_default_max_age filter added in Pantheon MU plugin 1.4.0+. For example:
add_filter( 'pantheon_cache_default_max_age', function() {
return 10 * DAY_IN_SECONDS;
} );

When the cache max age is filtered in this way, the admin option is disabled and a notice is displayed.
Updating the cache max age based on nonces
Nonces created on the front-end, often used to secure forms and other data, have a lifetime, and if the cache max age is longer than the nonce lifetime, the nonce may expire before the cache does. To avoid this, you can use the pantheon_cache_nonce_lifetime action to set the pantheon_cache_default_max_age to less than the nonce lifetime. For example:
do_action( 'pantheon_cache_nonce_lifetime' );

It’s important to wrap your do_action in the appropriate conditionals to ensure that the action is only called when necessary and not filtering the cache max age in cases when it’s not necessary. This might mean only running on certain pages or in certain contexts in your code.
WP-CLI Commands
This plugin implements a variety of WP-CLI commands. All commands are grouped into the wp pantheon cache namespace.
$ wp help pantheon cache

NAME

wp pantheon cache

DESCRIPTION

Manage the Pantheon Advanced Page Cache.

SYNOPSIS

wp pantheon cache

SUBCOMMANDS

purge-all Purge the entire page cache.
purge-key Purge one or more surrogate keys from cache.
purge-path Purge one or more paths from cache.

Use wp help pantheon cache to learn more about each command.
Debugging
By default, Pantheon’s infrastructure strips out the Surrogate-Key response header before responses are served to clients. The contents of this header can be viewed as Surrogate-Key-Raw by adding on a debugging header to the request.
A direct way of inspecting headers is with curl -I. This command will make a request and show just the response headers. Adding -H "Pantheon-Debug:1" will result in Surrogate-Key-Raw being included in the response headers. The complete command looks like this:
curl -IH "Pantheon-Debug:1" https://scalewp.io/

Piping to grep will filter the output down to just the Surrogate-Key-Raw header:
curl -IH "Pantheon-Debug:1" https://scalewp.io/ | grep -i Surrogate-Key-Raw

Tada!
Emitted Keys and Purge Events
Emitted Keys on Traditional Views
Home /

Emits surrogate keys: home, front, post- (all posts in main query)

Single post /2016/10/14/surrogate-keys/

Emits surrogate keys: single, post-, post-user-, post-term- (all terms assigned to post)

Author archive /author/pantheon/

Emits surrogate keys: archive, user-, post- (all posts in main query)

Term archive /tag/cdn/

Emits surrogate keys: archive, term-, post- (all posts in main query)

Day archive /2016/10/14/

Emits surrogate keys: archive, date, post- (all posts in main query)

Month archive /2016/10/

Emits surrogate keys: archive, date, post- (all posts in main query)

Year archive /2016/

Emits surrogate keys: archive, date, post- (all posts in main query)

Search /?s=

Emits surrogate keys: search, either search-results or search-no-results, post- (all posts in main query)

Not found (404)

Emits surrogate keys: 404

Emitted Keys on REST API Endpoints
Posts

/wp-json/wp/v2/posts emits surrogate keys: rest-post-collection, rest-post-
/wp-json/wp/v2/posts/ emits surrogate keys: rest-post-

Pages

/wp-json/wp/v2/pages emits surrogate keys: rest-page-collection, rest-post-
/wp-json/wp/v2/pages/ emits surrogate keys: rest-post-

Other Filters

pantheon_apc_disable_admin_notices
Since 2.0.0, Pantheon Advanced Page Cache displays a number of admin notices about your current cache max age value. You can disable these notices with the pantheon_apc_disable_admin_notices filter.
add_filter( 'pantheon_apc_disable_admin_notices', '__return_true' );

Alternately, the function callback is passed into the pantheon_apc_disable_admin_notices filter, allowing you to specify precisely which notice to disable, for example:
add_filter( 'pantheon_apc_disable_admin_notices', function( $disable_notices, $callback ) {
if ( $callback === '\\Pantheon_Advanced_Page_Cache\\Admin_Interface\\admin_notice_maybe_recommend_higher_max_age' ) {
return true;
}
return $disable_notices;
}, 10, 2 );

The above example would disable only the admin notice recommending a higher cache max age.
Plugin Integrations
Pantheon Advanced Page Cache integrates with WordPress plugins, including:

WPGraphQL

Contributing
See CONTRIBUTING.md for information on contributing.

各版本下載點

方法一：點下方版本號的連結下載 ZIP 檔案後，登入網站後台左側選單「外掛」的「安裝外掛」，然後選擇上方的「上傳外掛」，把下載回去的 ZIP 外掛打包檔案上傳上去安裝與啟用。
方法二：透過「安裝外掛」的畫面右方搜尋功能，搜尋外掛名稱「Pantheon Advanced Page Cache」來進行安裝。

（建議使用方法二，確保安裝的版本符合當前運作的 WordPress 環境。

0.1.0 | 0.1.1 | 0.1.2 | 0.1.3 | 0.1.4 | 0.1.5 | 0.2.0 | 0.2.1 | 0.3.0 | 0.3.1 | 1.0.0 | 1.1.0 | 1.1.1 | 1.2.0 | 1.2.1 | 1.2.2 | 1.2.3 | 1.2.4 | 1.3.0 | 1.4.0 | 1.4.1 | 1.4.2 | 1.5.0 | 2.0.0 | 2.1.0 | 2.1.1 | trunk |

延伸相關外掛（你可能也想知道）

W3 Total Cache 》W3 Total Cache (W3TC) 透過整合內容傳遞網絡 (CDN) 和最新最佳實踐等功能，提高網站性能、減少加載時間，增進 SEO、核心 Web 主要指標和整體用戶體驗。W3TC ...。
SpeedyCache – Cache, Optimization, Performance 》SpeedyCache 是一款 WordPress 外掛，能透過網頁快取、最小化檔案和檔案壓縮的方式，幫助您減少網站載入時間。, 您可以在 https://speedycache.com/docs 找到...。
Breeze – WordPress Cache Plugin 》Breeze是由Cloudways團隊開發的一款免費、簡單（卻功能強大）且使用者友好的WordPress快取外掛。它提供不同層級的WordPress效能優化選項，在WordPress、搭配W...。
Use Google Libraries 》e's content distribution network (CDN) URLs for the supported libraries., This hook is used to replace the default WordPress registered script sour...。
CDN Enabler 》CDN Enabler 是一個簡單易用的 WordPress 外掛，可以將 CSS、JavaScript 和圖像等 URL 重寫為經由內容傳遞網路 (CDN) 提供，以提升網站效能、可靠性和擴展性...。
bunny.net – WordPress CDN Plugin 》使用bunny.net內容分發網絡可以加快您的網站速度。此外掛可讓您輕鬆在WordPress上啟用Bunny CDN，並享受全球得到極大改善的頁面加載速度。更好的是，只需一分...。
Swift Performance Lite 》——WordPress外掛介紹——, , 需要速度。WordPress的緩存和性能外掛！, 您創建了它，而我們讓它保持快速！您知道嗎……, 您只有3秒鐘的時間來給來訪者留下印象。不...。
Jetpack VideoPress 》WordPress 最佳的精美影片主機, VideoPress 具有沉浸式的設計，非常適合想要輕鬆上傳高質量影片的攝影師、創作者、電影製作人、教育工作者和部落客。, 專為 W...。
Flying Images: Optimize and Lazy Load Images for Faster Page Speed 》優化圖片的完整解決方案, 功能特點, , 免費無限CDN – Flying Images 使用Statically提供免費的CDN。Statically由Cloudflare（高級網絡）、BunnyCDN、Fa...。
WP-Stateless – Google Cloud Storage 》使用 WP-Stateless 外掛，您可以將 WordPress 媒體從 Google Cloud Storage (GCS) 上傳和提供服務。只需兩分鐘，您就可以從 Google Cloud 的分佈式伺服器中受...。
GoCache 》透過這個 WordPress 外掛，您可以將您的 WordPress 網站連接至 GoCache。GoCache 擁有智慧型加速技術，能夠加速網站的靜態網頁和檔案，同時減少網頁伺服器和...。
C3 Cloudfront Cache Controller 》3>這是一個簡單的外掛，如果您發布文章，它就會清除所有 Cloudfront 緩存。, 您可以輕鬆地在 WordPress 中使用 CloudFront。, Fixture (固定項), , , wp_is_m...。
Microsoft Azure Storage for WordPress 》這個 WordPress 外掛允許您使用 Microsoft Azure 儲存服務來托管您的 WordPress 網站媒體和上傳檔案。Microsoft Azure 儲存是一種有效的方式，可以無限擴展您...。
SmartVideo – Video Player and CDN 》這是一個為 WordPress 使用者提供無限制影片儲存和播放的外掛。, 為什麼要使用這個影片播放器外掛？, 這個外掛可以：, , 在幾秒鐘內在您的網站上添加影片, 優...。
BerqWP – Automated All-In-One PageSpeed Optimization for Core Web Vitals, Cache, CDN, Images, CSS, and JavaScript 》SearchPro 可以透過 WordPress Rest API，讓使用者輕鬆地找到相關內容。它可以從 WordPress 文章、頁面、WooCommerce 產品，甚至是自訂文章類型中的標題和內...。

文章

文章