关于最近博客建设的经验教训就是：别TM瞎搞优化！

故事从我想解决流量大，打算搞个图床来缓解访问压力开始，搜索了一下关于Wordpress迁移图床，排名第一的是雪糕这篇《 用 Cloudflare R2 作图床，迁移 WordPress 》。我的域名在Cloudflare，它家很多免费的服务都不错，之前还想用 Cloudflare Pages 搭个Hugo博客，R2是S3兼容，免费大容量足够用，于是很快的选定了把媒体文件都搬去R2存储桶。

创建存储桶

要使用R2存储桶，首先需要有个Cloudflare账号，然后绑定支付方式，我用的Paypal，之后就可以进入R2界面进行设置，选择创建一个存储桶，位置选择自动即可。

创建之后切换到存储桶设置，需要配置桶可以公开访问，自定义一个域名，把它和桶绑在一起，这样传到桶里的东西就可以通过这个地址访问。

创建API令牌

再去R2存储桶的页面创建API令牌，不仅Wordpress和存储桶连接需要API令牌，配置其他管理软件也需要。需要注意，令牌是可以长期使用的，但是令牌的这个页面关掉，就再也打不开。如果调试过程找不到秘钥或者不小心在配置软件中删掉，这个令牌就等于废了。我看网上说只能把桶删掉，那倒也不用，删掉令牌重新生成就好，一个桶可以有很多个令牌，起名的时候最好就区隔下，免得之后不知道哪个令牌对应哪个使用场景。

题外话，R2的网页端管理做的一塌糊涂，上传很卡经常半路失败，一次删除只能删25个文件，最窒息是文件夹无法删除，体验很差。懂技术用CLI来管理比较方便，如果像我一样小白，也可以用兼容AWS S3的图形软件来搞，配置方式都是通过API的密钥ID啥的。

Windows下面有WinSCP，或者S3Browser，前者用类似FTP的方式管理，但批量删除很卡，后者上传批量文件不方便，但清空全桶速度飞快（实践的眼泪），Mac下面暂时没找到同类软件， FileZilla 的S3连接功能付费，试了下Cyberduck总是SSL验证失败，懒得调试，就这样吧。

安装Media Cloud插件

因为想偷懒不修改Wordpress数据库文件，于是选了Media Cloud插件。设置非常友好，还有视频教程，只要把申请的API令牌信息填到对应的位置就可以，最后点一下Test Settings测试看看是否配置成功。

配置好之后，新上传到媒体库的图片会自动上传到存储桶，如果想把Wordpress上所有旧媒体文件搬到存储桶，在Task manage下面有个Migrate to Storage，不过这个功能是收费的。

EWWW Image Optimization的悲剧

我的第一次悲剧，是看到Media Cloud的设置有一条“Media Cloud will output URLs for webp images, if a webp image has been generated for an attachment via the EWWW Image Optimization plugin”，心动了。

EWWW Image Optimization是可以把所有博客图片优化成webp的插件，免费，即使已经在媒体库的图片也可以批量处理。

我是在激活了Media Cloud的时候开始进行的批量优化，所有被优化的图片都被识别成新上传的图片，传到桶里去了……我还没开同步媒体库的旧文件，所以整个桶里就2024/05一个文件夹，里面几千张图片，这我强迫症哪里受的了，顺手就用 S3Browser 把这个文件夹删掉，于是更悲剧，整个媒体库的文件都打不开了，缩略图也看不见。

尝试一些方法都没修复这个问题，去EWWW Image Optimization官网也找不到任何解决方法，强迫症的我无奈之下，只好用UpdraftPlus Backups插件恢复备份，中间伴随着服务器插件崩溃、页面504抽风、MySql启动不起来等多个莫名其妙的问题，几经周折好不容易恢复到头一天的备份。

第二次，我学乖了，先含泪充值1个月付费使用，不到5美元还可以接受。把博客内容全部重新配置之后，选择开始迁移，1000张图片（加上缩略图等多个版本可能有五六千张）大概花了3小时，不知道算快还是慢？好在不用在电脑前等着，点开始过一阵子再来看就行。

迁移好之后，再次打开EWWW Image Optimization优化……好家伙，这次不知道为什么，所有图片地址都乱套，博客文章里面的图片都访问不了……痛定思痛无解之下，只好再次用UpdraftPlus Backups插件恢复备份，悲剧升级是不知道为什么UpdraftPlus Backups出现错误，恢复了三四次，不是插件error，就是Uploads验证不通过，我只好再选择了更前一天的备份，竟然成功了……

问题就是，中间这一天我发了一篇博客，还有几个留言，就这么丢了也是有点不开心，只能又打开数据库，把备份的数据单独一条条导进去，完全违背了我不想修改数据库的初衷，这两天如果用RSS订阅我的话说不定能看到RSS莫名其妙更新了几次同样的内容，真是不好意思。

这次恢复好备份之后，再也不敢装什么优化插件，就老老实实的这么用吧。

播客搬迁到存储桶

除了博客的图片之外，我还有一个播客，虽然是自娱自乐的产物，但是占服务器的空间不小，搬到R2存储的话能节省不少资源，因为播客一共就50多期节目，且都在同一个文件夹里，处理起来反而非常简单。新建了一个专门放播客源文件的存储桶，用Winscp上传所有文件到存储桶。

播客这个也不想用Media Cloud的迁移功能了，直接打开Wordpress数据库修改下跑一下MySql代码。

UPDATE wp_podcast_postmeta
SET meta_value = REPLACE(meta_value, '源地址', '新地址')
WHERE meta_key IN ('enclosure', 'audio_file');

非常迅速的替换好，从前台和小宇宙测试了一下播放没什么问题，存储桶里面的文件也井然有序，本强迫症一本满足。