smyx

<h4>优化</h4>
<ol>
<li>
上传遇到中文名称时自动改名 [v1.1] 
命名方式: 时间戳+随机数字
</li>
<li>
新用户注册时禁止通知管理员 [v1.1] 
默认情况下，新用户注册时会发送一封邮件通知管理员，如果不需要通知请开启。
</li>
<li>
登录后跳转到首页 [v1.1] 
如果在wp-login.php登录，默认是进入后台(仪表盘)，开启后会进入首页。只有在redirect_to没有值时生效。
</li>
<li>
关闭升级 
开启后，将禁用WordPress升级、主题升级、插件升级，后台速度将大大提升。建议在想升级时开启，升级后关闭。
</li>
<li>
去掉头部多余代码
</li>
<li>
关闭 Trackbacks 
Trackbacks会带来一些垃圾评论
</li>
<li>
移除顶部工具栏
</li>
<li>
禁止修订日志及自动保存
</li>
<li>
文章ID连续 
发布文章时会对文章ID连续性做一些优化。需要开启【禁止修订日志及自动保存】，同时数据清理的[自动保存的文章]、[无效的菜单]的清理将自动失效。
</li>
<li>
禁用 XML-RPC 接口 
如果你使用离线工具发布文章，请勿关闭。
</li>
<li>
修改头像服务器 
如果您的用户主要在国内，建议选择一个。
</li>
<li>
替换Google字体库 
这是导致后台慢的原因之一。
</li>
<li>
替换Google前端公共库为360 CDN
</li>
</ol>
14.移除后台首页模块
<ol>
<li>移除文章发布页面模块 
评论（推荐，没那么神经跑到文章编辑页面查看评论吧） 
作者（推荐，不需要修改文章作者吧） 
自定义栏目（仅仅隐藏，功能并不影响） 
无论何时，管理员仍然可以使用自定义栏目。</li>
</ol>
<h4>增强</h4>
Sitemap(站点地图，支持自定义文章类型)（百度和Google通用,支持百度移动Sitemap）[v1.1]
使用CDN加速 [v1.1]
使用SMTP发邮件（整站通用，包括注册，找回密码等）[v1.1]
自定义:
<ol>
<li>
首页不显示某些分类 
填写分类数字ID，多个用英文逗号,分开，为方便查看ID，可以在下面开启【文章、评论、用户等列表显示ID】
</li>
<li>
首页不显示某些文章 
填写文章数字ID，多个用英文逗号,分开，为方便查看ID，可以在下面开启【文章、评论、用户等列表显示ID】
</li>
<li>
网站头部添加Meta代码 
提示：可以用于各种Meta验证
</li>
<li>
网站底部添加额外代码 
比如：可以添加统计代码等
</li>
</ol>
其他：
<ol>
<li>
记录用户上次登录时间 
开启后会在用户登录时记录时间，并在用户列表中显示。
</li>
<li>
文章、评论、用户等列表显示ID 
包括文章、页面、评论、用户、分类、标签列表，其中，页面列表还会显示模板文件名，用户列表还会显示注册时间。
</li>
<li>
禁止编辑主题或者插件 
关闭后，不能在后台不能直接编辑主题或者插件文件。
</li>
<li>
首页文章按修改时间排序
</li>
<li>
首页文章多种排序方式 
在首页链接后添加参数sort，可以排序文章，比如https://wptao.com/?sort=modified 表示按修改时间排序，当值为 date 表示按时间排序，当值为 comment_count 表示按评论数从多到少排序；当值为 rand 表示按随机排序；当值为 views 表示按访问数排序(需要安装相关插件)
</li>
<li>
文章链接可以改为站外链接开启后，无论对外显示外链还是内链，打开链接都将跳转到外链。 
文章使用站外链接的字段名，在文章发布页面，添加自定义栏目，输入新栏目_links_to 值为具体外链。
</li>
</ol>
<h4>数据库清理</h4>
定时清理 
开启后，会定时清理以下数据库信息。如需只定时清理部分冗余数据，可以勾选后【保存设置】
<ol>
<li>
文章修订版本
</li>
<li>
自动保存的文章
</li>
<li>
无效的菜单
</li>
<li>
无效的postmeta记录(文章已删除)
</li>
<li>
垃圾评论(包括回收站)
</li>
<li>
Trackback评论
</li>
<li>
无效的commentmeta记录(评论已删除)
</li>
<li>
空标签
</li>
<li>
冗余的feed
</li>
<li>
没用的用户资料(包括aim,yim,jabber)
</li>
</ol>
<h4>常用设置</h4>
省略
<h4>常见问题</h4>
1、对服务器有什么要求? 
需要安装zend组件，目前仅支持安装了PHP5.2.x、PHP5.3.x和PHP5.4.x系列的服务器环境，购买前，请打开 http://pan.baidu.com/s/1pJluHjt 下载后上传到网站根目录，通过 http://您的网站网址/test.php 打开，检查您的服务器是否支持！
2、是一次性收费还是每年收费？我能免费升级吗?
是一次性收费，下载的插件可以永久使用，免费升级一年，第二年起每年收取20%升级费用，不升级不收费。
3、我能退货吗?
该插件是互联网产品，具有可复制性，一旦购买，不能退款。
4、我用了一段时间后，能更换域名吗？
插件是绑定域名的，一旦购买后不能修改。
5、提供技术支持吗?
支持的，请联系插件作者即可。(联系方式见插件页面)
6、我应该选择单域名/多域名/WPMU中的哪一类型? 
比如您的网址是 http://www.yoururl.com/blog/ 
如果您购买了单域名，只能在这个www.yoururl.com域名下的网站使用，不能用于二级域名，但是你可以直接为二级域名购买插件。提示：加www和不加www视为同一个单域名，都能使用。 
如果您购买了根域名，支持该域名下的所有网站，所有的二级域名下的网站也能使用。 
如果您购买了WPMU，在根域名的基础上，还能使用WordPress MU Domain Mapping插件绑定其他域名。

博客优化

WordPress优化、功能增强、使用SMTP发邮件、CDN加速、站点地图(sitemap，包括移动sitemap)、数据库清理等。

Daniel Bachhuber

Chris Reynolds

John Spellman

Pantheon Systems

pwtyler

ryanshoover

rwagner00

kporras07

<a href="https://circleci.com/gh/pantheon-systems/pantheon-advanced-page-cache" rel="nofollow ugc"></a>
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:
<ol>
<li>When a response is generated, the plugin uses surrogate keys based on WordPress’ main <code>WP_Query</code> 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.</li>
<li>When WordPress data is modified, the plugin triggers a purge request for the data’s corresponding surrogate keys.</li>
</ol>
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, <a href="https://github.com/pantheon-systems/pantheon-advanced-page-cache/issues" rel="nofollow ugc">send us feature requests (or bug reports)</a>.
<h3>How It Works</h3>
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 <code>Surrogate-Key</code> header with these keys:
<pre><code>Surrogate-Key: front home post-43 user-4 post-41 post-9 post-7 post-1 user-1
</code></pre>
Similarly, a <code>GET</code> requests to <code>/wp-json/wp/v2/posts</code> might include the <code>Surrogate-Key</code> header with these keys:
<pre><code>Surrogate-Key: rest-post-collection rest-post-43 rest-post-43 rest-post-9 rest-post-7 rest-post-1
</code></pre>
Because cached responses include metadata describing the data therein, surrogate keys enable more flexible purging behavior like:
<ul>
<li>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.</li>
<li>When an author changes their name, clear the cache for the author’s archive and any post they’ve authored.</li>
</ul>
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.
<h4>Adding Custom Keys</h4>
By default, Pantheon Advanced Page Cache generates surrogate keys based on an interpretation of the main <code>WP_Query</code> query object. Because WordPress sends headers before the page is rendered, you need to use the <code>pantheon_wp_main_query_surrogate_keys</code> 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 <code>is_home()</code> template tag:
<pre><code>/**
 * 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;
});
</code></pre>
Then, when sidebars are updated, you can use the <code>pantheon_wp_clear_edge_keys()</code> helper function to emit a purge event specific to the surrogate key:
<pre><code>/**
 * 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' ) );
});
</code></pre>
Similarly, to include surrogate keys for posts queried on the homepage, you can pre-fetch the posts before the page is rendered:
<pre><code>/**
 * 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;
}
</code></pre>
Because Pantheon Advanced Page Cache already handles WordPress post purge events, there’s no additional call to <code>pantheon_wp_clear_edge_keys()</code>.
Lastly, the <code>pantheon_wp_rest_api_surrogate_keys</code> filter lets you filter surrogate keys present in a REST API response.
<h4>Additional purging by path</h4>
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 <code>pantheon_clear_post_path</code> filter.
<pre><code> add_action('pantheon_clear_post_path', function($paths) {
 // Add or remove paths from $paths
 return $paths
 }, 10, 3);
</code></pre>
Need a bit more power? In addition to <code>pantheon_wp_clear_edge_keys()</code>, there are two additional helper functions you can use:
<ul>
<li><code>pantheon_wp_clear_edge_paths( $paths = array() )</code> – Purge cache for one or more paths.</li>
<li><code>pantheon_wp_clear_edge_all()</code> – Warning! With great power comes great responsibility. Purge the entire cache, but do so wisely.</li>
</ul>
<h4>Ignoring Specific Post Types</h4>
By default, Pantheon Advanced Page Cache is pretty aggressive in how it clears its surrogate keys. Specifically, any time <code>wp_insert_post</code> 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 <code>home</code>, <code>front</code>, <code>404</code> and <code>feed</code>. 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 <code>revision</code> post type is ignored, but others can be added:
<pre><code>/**
* 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' );
</code></pre>
This will prevent the cache from being purged if the given post type is updated.
<h4>Setting the Cache Max Age with a filter</h4>
The cache max age setting is controlled by the <a href="https://docs.pantheon.io/guides/wordpress-configurations/wordpress-cache-plugin" rel="nofollow ugc">Pantheon Page Cache</a> 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 <code>pantheon_cache_default_max_age</code> filter added in <a href="https://docs.pantheon.io/guides/wordpress-configurations/wordpress-cache-plugin#override-the-default-max-age" rel="nofollow ugc">Pantheon MU plugin 1.4.0+</a>. For example:
<pre><code>add_filter( 'pantheon_cache_default_max_age', function() {
 return 10 * DAY_IN_SECONDS;
} );
</code></pre>
When the cache max age is filtered in this way, the admin option is disabled and a notice is displayed.
<h4>Updating the cache max age based on nonces</h4>
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 <code>pantheon_cache_nonce_lifetime</code> action to set the <code>pantheon_cache_default_max_age</code> to less than the nonce lifetime. For example:
<pre><code>do_action( 'pantheon_cache_nonce_lifetime' );
</code></pre>
It’s important to wrap your <code>do_action</code> 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.
<h3>WP-CLI Commands</h3>
This plugin implements a variety of <a href="https://wp-cli.org" rel="nofollow ugc">WP-CLI</a> commands. All commands are grouped into the <code>wp pantheon cache</code> namespace.
<pre><code>$ wp help pantheon cache

NAME

 wp pantheon cache

DESCRIPTION

 Manage the Pantheon Advanced Page Cache.

SYNOPSIS

 wp pantheon cache <command>

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.
</code></pre>
Use <code>wp help pantheon cache <command></code> to learn more about each command.
<h3>Debugging</h3>
By default, Pantheon’s infrastructure strips out the <code>Surrogate-Key</code> response header before responses are served to clients. The contents of this header can be viewed as <code>Surrogate-Key-Raw</code> by adding on a debugging header to the request.
A direct way of inspecting headers is with <code>curl -I</code>. This command will make a request and show just the response headers. Adding <code>-H "Pantheon-Debug:1"</code> will result in <code>Surrogate-Key-Raw</code> being included in the response headers. The complete command looks like this:
<pre><code>curl -IH "Pantheon-Debug:1" https://scalewp.io/
</code></pre>
Piping to <code>grep</code> will filter the output down to just the <code>Surrogate-Key-Raw</code> header:
<pre><code>curl -IH "Pantheon-Debug:1" https://scalewp.io/ | grep -i Surrogate-Key-Raw
</code></pre>
Tada!
<h3>Emitted Keys and Purge Events</h3>
<h4>Emitted Keys on Traditional Views</h4>
Home <code>/</code>
<ul>
<li>Emits surrogate keys: <code>home</code>, <code>front</code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Single post <code>/2016/10/14/surrogate-keys/</code>
<ul>
<li>Emits surrogate keys: <code>single</code>, <code>post-<id></code>, <code>post-user-<id></code>, <code>post-term-<id></code> (all terms assigned to post)</li>
</ul>
Author archive <code>/author/pantheon/</code>
<ul>
<li>Emits surrogate keys: <code>archive</code>, <code>user-<id></code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Term archive <code>/tag/cdn/</code>
<ul>
<li>Emits surrogate keys: <code>archive</code>, <code>term-<id></code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Day archive <code>/2016/10/14/</code>
<ul>
<li>Emits surrogate keys: <code>archive</code>, <code>date</code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Month archive <code>/2016/10/</code>
<ul>
<li>Emits surrogate keys: <code>archive</code>, <code>date</code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Year archive <code>/2016/</code>
<ul>
<li>Emits surrogate keys: <code>archive</code>, <code>date</code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Search <code>/?s=<search></code>
<ul>
<li>Emits surrogate keys: <code>search</code>, either <code>search-results</code> or <code>search-no-results</code>, <code>post-<id></code> (all posts in main query)</li>
</ul>
Not found (404)
<ul>
<li>Emits surrogate keys: <code>404</code></li>
</ul>
<h4>Emitted Keys on REST API Endpoints</h4>
Posts
<ul>
<li><code>/wp-json/wp/v2/posts</code> emits surrogate keys: <code>rest-post-collection</code>, <code>rest-post-<id></code></li>
<li><code>/wp-json/wp/v2/posts/<id></code> emits surrogate keys: <code>rest-post-<id></code></li>
</ul>
Pages
<ul>
<li><code>/wp-json/wp/v2/pages</code> emits surrogate keys: <code>rest-page-collection</code>, <code>rest-post-<id></code></li>
<li><code>/wp-json/wp/v2/pages/<id></code> emits surrogate keys: <code>rest-post-<id></code></li>
</ul>
Categories
<ul>
<li><code>/wp-json/wp/v2/categories</code> emits surrogate keys: <code>rest-category-collection</code>, <code>rest-term-<id></code></li>
<li><code>/wp-json/wp/v2/categories/<id></code> emits surrogate keys: <code>rest-term-<id></code></li>
</ul>
Tags
<ul>
<li><code>/wp-json/wp/v2/tags</code> emits surrogate keys: <code>rest-post_tag-collection</code>, <code>rest-term-<id></code></li>
<li><code>/wp-json/wp/v2/tags/<id></code> emits surrogate keys: <code>rest-term-<id></code></li>
</ul>
Comments
<ul>
<li><code>/wp-json/wp/v2/comments</code> emits surrogate keys: <code>rest-comment-collection</code>, <code>rest-comment-post-<post-id></code>, <code>rest-comment-<id></code></li>
<li><code>/wp-json/wp/v2/comments/<id></code> emits surrogate keys: <code>rest-comment-post-<post-id></code>, <code>rest-comment-<id></code></li>
</ul>
Users
<ul>
<li><code>/wp-json/wp/v2/users</code> emits surrogate keys: <code>rest-user-collection</code>, <code>rest-user-<id></code></li>
<li><code>/wp-json/wp/v2/users/<id></code> emits surrogate keys: <code>rest-user-<id></code></li>
</ul>
Settings
<ul>
<li><code>/wp-json/wp/v2/settings</code> emits surrogate keys: <code>rest-setting-<name></code></li>
</ul>
<h4>Purge Events</h4>
Different WordPress actions cause different surrogate keys to be purged, documented here.
wp_insert_post / transition_post_status / before_delete_post / delete_attachment
<ul>
<li>Purges surrogate keys: <code>home</code>, <code>front</code>, <code>404</code>, <code>post-<id></code>, <code>user-<id></code>, <code>term-<id></code>, <code>rest-<type>-collection</code>, <code>rest-comment-post-<id></code></li>
<li>Affected views: homepage, single post, any page with 404 header, any archive where post displays, author archive, term archive, REST API collection and resource endpoints</li>
</ul>
clean_post_cache
<ul>
<li>Purges surrogate keys: <code>post-<id></code>, <code>rest-post-<id></code></li>
<li>Affected views: single post, REST API resource endpoint</li>
</ul>
created_term / edited_term / delete_term
<ul>
<li>Purges surrogate keys: <code>term-<id></code>, <code>post-term-<id></code>, <code>rest-<taxonomy>-collection</code></li>
<li>Affected views: term archive, any post where the term is assigned, REST API collection and resource endpoints</li>
</ul>
clean_term_cache
<ul>
<li>Purges surrogate keys: <code>term-<id></code>, <code>rest-term-<id></code></li>
<li>Affected views: term archive, REST API resource endpoint</li>
</ul>
wp_insert_comment / transition_comment_status
<ul>
<li>Purges surrogate keys: <code>rest-comment-collection</code>, <code>rest-comment-<id></code></li>
<li>Affected views: REST API collection and resource endpoints</li>
</ul>
clean_comment_cache
<ul>
<li>Purges surrogate keys: <code>rest-comment-<id></code></li>
<li>Affected views: REST API resource endpoint</li>
</ul>
clean_user_cache
<ul>
<li>Purges surrogate keys: <code>user-<id></code>, <code>rest-user-<id></code></li>
<li>Affected views: author archive, any post where the user is the author</li>
</ul>
updated_option
<ul>
<li>Purges surrogate keys: <code>rest-setting-<name></code></li>
<li>Affected views: REST API resource endpoint</li>
</ul>
<h3>Surrogate Keys for taxonomy terms</h3>
Setting surrogate keys for posts with large numbers of taxonomies (such as WooCommerce products with a large number of global attributes) can suffer from slower queries. Surrogate keys can be skipped for ‘product’ post types’ taxonomy terms (or any other criteria you see fit) with the following filter:
<pre><code>function custom_should_add_terms($should_add_terms, $wp_query) {
 if ( $wp_query->is_singular( 'product' ) ) {
 return false;
 }
 return $should_add_terms;
}
add_filter('pantheon_should_add_terms', 'custom_should_add_terms', 10, 2);<h3>Other Filters</h3>
</code></pre>
<h4>pantheon_apc_disable_admin_notices</h4>
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 <code>pantheon_apc_disable_admin_notices</code> filter.
<pre><code>add_filter( 'pantheon_apc_disable_admin_notices', '__return_true' );
</code></pre>
Alternately, the function callback is passed into the <code>pantheon_apc_disable_admin_notices</code> filter, allowing you to specify precisely which notice to disable, for example:
<pre><code>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 );
</code></pre>
The above example would disable only the admin notice recommending a higher cache max age.
<h3>Plugin Integrations</h3>
Pantheon Advanced Page Cache integrates with WordPress plugins, including:
<ul>
<li><a href="https://wordpress.org/plugins/wp-graphql/" rel="ugc">WPGraphQL</a></li>
</ul>
<h3>Contributing</h3>
See <a href="https://github.com/pantheon-systems/wp-saml-auth/blob/master/CONTRIBUTING.md" rel="nofollow ugc">CONTRIBUTING.md</a> for information on contributing.

Pantheon Advanced Page Cache

Automatically clear related pages from Pantheon's Edge when you update content. High TTL. Fresh content. Visitors never wait.

博客优化 vs Pantheon Advanced Page Cache