手动升级到了 WordPress 3.7，感觉貌似不错。唯一不满意的就是 BAE 的多灾多难，安全与方便就如同鱼和熊掌，两者不可兼得。
升级也没有像 BAE 官方的 WordPress For BAE 3.0 教程那样容易，不知是不是我的问题。还要费心去跟，看看升级升级了什么。
Twenty Twelve 也升级了，跟进官方版本。
有时间会写写教程，目前暂定：
刚刚在 V2EX 看到有人问为什么 BAE 免费 Redis 没人用来做缓存，不免费 Cache，大家却都想用。
这不仅仅是因为 Cache 方便移植，而是 BAE 干了一件好事：
目前每条 redis 命令的有效长度最大为2048个字节。
2048 字节是什么情况？2K，这缓存，如果确实要用，必须分片写入、分片读写，那样的话，查询量也少不了多少，效率我个人感觉和直接不用缓存差不多。
知道这种情况，我也有心查了一下 Cache：
Key 最大长度：180Bytes
Value 最大长度：1MB
所以性能自然不如自己弄的 Memcached，但是架不住 BAE 的服务器好，所以还是比我们自己的快！
由此，我突然产生了一个新想法：利用 BCS 云存储也是 Key->Value 的特性，换存到云存储。目前我已经在尝试了。。
因为近期 Gravatar 头像加载速度又慢如蜗牛，所以需要缓存一下。百度了一下，没有 BAE 版的，于是参照 SAE 版的，自己写了个。
Gravatar 是 Globally Recognized Avatar 的缩写，是 Gravatar 推出的一项服务，意为“全球通用头像”。如果在 Gravatar 的服务器上放置了你自己的头像，那么在任何支持 Gravatar 的站点上留言时，只要提供你与这个头像关联的 E-Mail 地址，就能够显示出你的Gravatar头像来。
因为 Gravatar 的服务器在国外，在国内访问使用该功能的网站或博客，可能因为载入速度过慢而导致页面一直在载入中甚至头像无法显示，这是一个非常糟糕的用户体验。将头像缓存下来，定时更新，而头像图片的文件一般不会很大，不需要暂用很大的服务器空间，因此缓存 Gravatar 头像是一个加快网站访问速度的高性价比选择。
很简单，在你的主题的 Function.php 文件中加入以下代码：
<?php
function nikbobo_get_avatar_cache ( $avatar ) {
if( $_SERVER['PHP_SELF'] == '/wp-admin/options-discussion.php' )
return $avatar;
$bucket = '这里更改为你的Bucket名称';
$cache_dir = '/avatar/';
$baidu_bcs = new BaiduBCS();
$tmp = strpos( $avatar, 'avatar/' ) + 7;
$avatar_id = substr( $avatar, $tmp, strpos( $avatar, '?' ) - $tmp );
$tmp = strpos( $avatar, 'avatar/' ) + 7;
$pattern = "/(<img.* src=\')([^\']*)(\'.*)/";
$avatar_url = preg_replace( $pattern, "$2", $avatar );
$avatar_url = str_replace( "&", "&", $avatar_url );
$avatar_file = $cache_dir . $avatar_id . '.png';
if( ! $baidu_bcs->is_object_exist( $bucket, $avatar_file ) ) {
$content = @file_get_contents( $avatar_url );
if( ! $content )
return $avatar;
$opt['acl'] = "public-read";
$opt['headers']['Expires'] = 'access plus 15 days';
$opt['headers']['Content-Type'] = 'image/png';
$result = $baidu_bcs->create_object_by_content( $bucket, $avatar_file, $content, $opt );
}
$avatar_cache_url = 'http://bcs.duapp.com/' . $bucket . $avatar_file;
$avatar = preg_replace( $pattern, "$1" . $avatar_cache_url . "$3", $avatar );
return $avatar;
}
add_filter('get_avatar', 'nikbobo_get_avatar_cache');
?>
以上代码在 BAE 环境中测试通过，无法确定能否用于非 BAE 环境。
大功告成！
大家有无发现？旧版移植的 Cache 已无法使用？现在，我就把新版的发布出来。
嘘！你们有所不知，目前 BAE 3.0 所有服务都是免费的。所以 2.0 木有钱钱用 Cache 的童鞋有福了。
首先需要开通 Cache，放一张我开通后的图：
然后下载我修改好的文件（包含 WordPress Object Cache 模块和 BAE Cache SDK），放在 wp-content 目录下。
切记，不是 plugins 目录！
然后修改约 377 行，填入相关信息：
$this->mc[$bucket] = new BaeMemcache( ‘资源名称’, ‘连接地址:端口’, ‘API Key’, ‘Secret Key’ );
哈哈，大功告成！你就可以学别人用 Memcached 那样使用了。
文件下载：百度网盘
大家可能有疑问，为什么要加入 SDK？
因为 BAE 官方说
目前各语言服务的SDK需要开发者自己安装到环境中
今天，无意间看到了一堆喷 BAE、SAE 的言论，看不过眼，所以写一下。
大家的焦点主要在“不支持写本地目录”这个问题上。那么我就说以下为什么要这么做。
其实这么做，目的只有一个——安全。
为什么动静分离会安全呢？
我们做一个假设：
WordPress 爆出了一个任意上传的漏洞。
如果动态和静态放在一起，上传成功，立刻挂马。
如果动静分离，上传成功，上传到专门的静态服务器，没有动态语言解析器，结果——无法执行！上传成功，也是废品！
就说这么多。
话说，BAE 3.0 发布了，是不是应该写一下 3.0 的 WordPress 教程，来体验一下 BAE 3.0 呢？BAE 官方说的是
WordPress 3.6 完全兼容
那么？情况究竟如何？真的是这样么？
对，你没猜错！核心程序代码一行都不用改！
甚至你直接上传上去安装都可以，但是，我不推荐这种做法。
因为，BAE 官方说了：
BAE 3.0 更新代码时会将执行单元中存在而 SVN 中不存在的文件或目录删除。因此如果代码在运行过程中写了本地文件，那么再下次更新代码时本地文件就会本删掉。
那么应该怎么做呢？
是不是一行代码都不用改？
终于搞定 BCS 云存储的问题了，查来查去，查了半天，居然是因为我用了自动远程下载图片，然后把 BCS 的当远程图片了。。。
我今天拿到了 BAE 3.0 的测试资格，第一时间搬迁到 3.0，但由于犯了经验主义，所以竟然连网站 500 了都不知道。。。
现在简要记录一下升级的注意事项：
因为某些原因，再次搬迁到 BAE，不过由于搬迁过程中操作失误，图片全部丢失了。所以抱歉，看不到图。
不知大家有无注意到，在 BAE 上运行的 WordPress，获取到的评论 IP 都是 BAE 的内网 IP，而不是真正的访客 IP。
那么真正的访客 IP 在哪里呢？根据 BAE 官方的解答，真正的访客 IP 在 HTTP_X_FORWARDED_FOR 中，但是由于 BAE 的特殊性，所以代码与安全宝获取真实 IP 的代码略有不同，但依旧是放在主题的 Functions.php 中。
代码如下：
<?php
add_action('init', 'GetIP');
function GetIP() {
$IP = str_replace(", ", "", str_replace(getenv('REMOTE_ADDR'), "", getenv('HTTP_X_FORWARDED_FOR')));
if (false === getenv('HTTP_X_FORWARDED_FOR')) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR'];
} else {
$_SERVER['REMOTE_ADDR'] = $IP;
}
}
?>