标签归档：WordPress

使用腾讯云云迁移服务将 R2 存储中的文件迁移到腾讯云 COS 中

发表评论

最近把这个域名重新备案了一下，就可以利用起我在腾讯云上的闲置服务器。既然要迁移服务器，不妨将图床一并迁移，这样后续使用起来也方便，国内的读者加载起来速度也快。

不过，这些年大量使用，我的文件还是挺多的….足足有 13GB 的文件，手动一个个搬迁可就累死了；于是乎，我决定试试腾讯云的迁移服务，来帮助我把 R2 上的文件迁移过来。

image

获取配置信息

想要使用腾讯云提供的云迁移（CMG）服务，则需要获取一些配置信息，具体包括：

  • Cloudflare R2 的 Access ID 和 Secret Key
  • 腾讯云的 Access ID 和 Access Key，创建好的 Bucket（要迁移的目标）

R2 的相关配置可以在 CloudFlare R2的配置页面找到；如果没有的话，你就创建一个新的。

image

腾讯云的则可以在腾讯云密钥管理中获取，建议创建一个新的用户，并授予 QcloudMSPFullAccess 及 QcloudCOSAccessForMSPRole 策略，点击子账号可以看到如下图的两个权限。

image

配置云迁移

完成账号的确认后，接下来就是配置云迁移。打开云迁移中的「对象存储迁移」，或者直接打开这个链接，就直接进入云迁移的页面。

image

源站配置

接下来配置云迁移的具体配置，点击新建人数，在新的页面中，输入你的 CloudFlare 配置信息，具体可以参考下面的截图:

image
  • AK/SK： 你从 Cloudflare 获取的相关参数；
  • 桶名称：你的 R2 Bucket 的名称；
  • 空间域名：你的 R2 的域名，是 uid.r2.cloudflarestoage.com，比如我的是 https://24071135c3ad9d9196e7e45e33948d28.r2.cloudflarestorage.com。
  • 桶的所在地：比如我的是亚洲，就选 apac。

源站中的其他选项可以根据需要选择，如果你是完整迁移，和我保持一致即可。

目标站点配置

接下来是配置迁移目标，这里指标支持迁移到腾讯云自家的 COS 上；填入你的 Secret ID 和 Secret Key，然后可以直接在下面输入具体的 Bucket 名称，或者填完后点击下拉框右侧的刷新按钮后，选择合适的。

image

其他的选项，如果你和我一样是整个 Bucket 迁移，则可以保持相同的配置，直接整个迁移。

配置完成后，点击最下方的新建并启动，就会启动搬迁。接下来就回到任务列表等刷新即可，等待他自己搬迁完即可。实测搬迁速度很快，13G 的文件，8 分钟就搬迁完成了（还是我限制了搬迁的带宽），如果是不限制，估计 2 分钟就能搬迁完成。

image

如果你需要和我一样，从外部的 S3 将文件搬迁到腾讯云的 COS 上，不妨试试看这个方法~

silver mercedes benz emblem on blue surface

解决因为 SSL 导致的 WordPress 后台无限 Redirect 的问题

2条回复

在使用 CapRover 并配置域名为 HTTPs 域名时，在你访问管理后台时，可能会导致触发Chrome 自己的无限 Redirect 的问题。

之所以出现这个问题，是因为 CapRover 的架构导致的：CapRover 在最外层是一个 Nginx，SSL 证书也是在这一层完成的。而 CapRover 的默认配置，在将请求向后转发时，透传的域名会是不含 HTTPs 的协议标识的，导致 WordPress 认为发来的请求是非加密的。

d2b5ca33bd970f64a6301fa75ae2eb22 18

而 WordPress 识别到你的请求未加密，就会返回 302 让你进入 HTTPS的链接。但新的请求并不会带上 HTTPs 的标识，导致进入无限循环。

解决这个问题的一个简单处理的方式是 — 在你的 wp-config.php 中加入如下代码，来告诉 WordPress，这个请求已经是 HTTPs 保护的了，你直接处理就好。

/* for ssl in docker */

define('FORCE_SSL_LOGIN',true);

define('FORCE_SSL_ADMIN',true);

$_SERVER['HTTPS'] = 'on';
Code language: PHP (php)

docker

在 WordPress 的 Docker 镜像上加装 Redis 拓展，以支持 Redis 缓存

4条回复

在 从 LAMP 到 Docker based PaaS 工具 当中，我提到我现在使用的是 Docker Based PaaS 产品来托管站点。本站目前其实就是跑在 Docker 上的。

使用默认的 WordPress 镜像时，我发现一个问题：没有支持 Redis 拓展！我使用 Redis 来缓存 Query，提升访问的性能。如果缺失了 Redis 拓展，就会减少一部分缓存的能力。于是开始研究如何在官方的 WordPress 镜像上加入 Redis 拓展。

根据 WordPress 镜像的官方说明，我们可以 docker-php-ext-* 命令来配置镜像，安装必要的拓展，来满足我们日常使用的需求，并给出了官方的参考。

不过，我在验证 Redis 拓展时，使用 docker-php-ext-* 命令没有配置成功，好在可以使用 pecl 来安装。于是，我便将 Dockerfile 修改成如下内容，来完成对于 Redis 拓展的安装。

FROM wordpress:latest
RUN pecl install -o -f redis && rm -rf /tmp/pear && docker-php-ext-enable redis

修改好 Dockerfile ，然后重新启动，一切都好了～

d2b5ca33bd970f64a6301fa75ae2eb22 4
turned-on monitor

插件多次加载导致的 WordPres 后台加载缓慢

发表评论

在 WordPress Jetpack 的一个陈年 Bug – 在 wp-Options 中生成大量的数据 中，我提到，问题的根源并不是数据库，虽然在数据库中产生了大量的数据，但并没有真正意义上拖慢系统的进程， 那到底是什么拖慢了进程？

1fp2qm

随着对系统的深入排查，我发现一个异常的事情，在进入管理后台时，出现了插件更新插件列表的情况。这个并不多见。因为管理后台的进入不应该涉及到对于插件列表的更新。此外，我发现这个查询的 SQL 巨长，且包含了大量的查询。

d2b5ca33bd970f64a6301fa75ae2eb22 32

于是评估，这个可能才是导致系统缓慢的真正原因。熟悉 WordPress 的读者一定知道， WordPress 对于插件的加载，是通过在数据库中存储了一组插件路径，每次启动时通过这组插件路径来加载插件。这样对于 WordPress 来说，可以快速加载插件。

但在这次的异常场景中，同一个内容的插件被加载了多次，就算这个插件比较小，可能依然会导致计算时间。此外，WordPress 引入插件后，会加载对应的 Hook 、 Filter 和 Action，则可能导致同一个 Action 被频繁触发，造成额外的计算量。从而使得虽然数据库查询时间不长，但整体耗时却巨长无比。

而这个问题的处理倒是也比较简单：

  1. 对 active_plugins 进行备份，避免修改跪了。
  2. 对于 active_plugins 进行清空，此时 WordPress 会彻底不加载任何插件。
  3. 仿照之前的列表，启用所有的插件。

通过对于active_plugins的清理，将启动速度成功降低至 2 秒左右，将系统性能提升了 80 %。

d2b5ca33bd970f64a6301fa75ae2eb22 36
silver mercedes benz emblem on blue surface

WordPress Jetpack 的一个陈年 Bug – 在 wp-Options 中生成大量的数据

4条回复

最近在处理一个 WordPress 系统访问下降的问题时，发现了一个奇怪的现象：一个只有很少的页面的网站，数据库备份竟然足足有 9.5 GB。我当时的第一反应是：数据库性能极差导致的站点性能不好。

d2b5ca33bd970f64a6301fa75ae2eb22 29

不过，到数据库打开后发现， 虽然有大量的条目生成，但因为no autoload，所以其实并不会被自动加载到缓存中，从而也不会让网站的性能有太多的下降。

d2b5ca33bd970f64a6301fa75ae2eb22 31

想想也合理,数据库中包含了数十万条记录，如果都加载到内存里，可能 PHP 默认的 1024MB 的运行内存直接被打爆了，所以问题不在此。

不过，虽然问题的核心不是它，但如此海量的脏数据对于系统依然是无价值和无意义的，于是乎我便将这些脏数据删除，数据库的大小从 9.52 GB 骤降至 34.8 MB，进入到一个正常的数据库大小区间了。

删除脏数据的命令如下：

DELETE FROM wp_options WHERE option_name LIKE '%jpsq_sync-%'
Code language: JavaScript (javascript)

相关链接

  • https://wordpress.org/support/topic/wordpress-database-error-commands-out-of-syn/
  • https://wordpress.org/support/topic/jpsq_sync-table-constantly-generated-to-the-db/
  • https://gist.github.com/bhubbard/894040fec6421f891f1f88f2c6428ef0
a computer screen with a bunch of text on it

WordPress 出现 RedisException: OOM command not allowed when used memory > maxmemory 的报错怎么处理？

发表评论

早晨起来，想登录博客，记录下自己的灵感，突然发现死活登录不上 WordPress 后台。

登录到 VPS 后台，发现没有出现我之前常出的问题 — 硬盘满了。于是再次回到网页端登录，仔细研究后发现，我的登录应该是成功的，但登录完成后，又重新跳转回来，根据这个情况，我猜测可能是登录态出现了问题。

于是尝试切换到 Safari 、Chrome 的无痕模式登录，依然没有解决问题。因此可以排除掉客户端的问题导致的。

找到问题

接下来就是查看服务端问题。登录到服务器上，找到 WordPress 的日志，查看最近的几条日志，突然在众多 Notice 当中，看到了一个 Exception:

RedisException: OOM command not allowed when used memory > 'maxmemory'
Code language: JavaScript (javascript)

看到这个报错，突然明白了问题在哪了。

我的 WordPress 使用 Redis 作为缓存，而我过去一直配置的缓存空间是 128M，看报错，显然是因为 Redis 使用的内存空间大于 128M，而我过去没有配置逐出机制(默认是 noeviction)，导致直接 OOM 爆掉了。

而我的登录态也使用了 Redis，没办法在缓存当中塞入新的 Key，自然登录也就失败了。

解决问题

找到问题之后，下一步便是解决问题。

解决问题并不复杂，为 Redis 调整内存空间大小，并配置逐出机制，就可以解决这个问题。

maxmemory 221000000
maxmemory-policy allkeys-lru

将 Redis 逐出机制设置为 allkeys-lru ，并将内存设置为 200M 后，重启 Redis ，果然我的 WordPress 可以正常登录了。

参考

allkeys-lru 表示对移除最近使用最少的 （least recently used）Key。

更多算法可以参考 Key Evicution

person typing on laptop computer

写博客， 工具重要么？

发表评论

我写了快 10 年的博客，近 1000 篇，勉强算得上是个老人了，今天看到 Pin 的文章提到《只要用得習慣的都是好工具？》，刚好聊聊我自己的看法。

我从一开始使用 WordPress 写博客，再到后面折腾 Ghost、Typecho、EMlog、B3log、Hexo、Hugo 等一系列博客程序，一直到后来坚持在 WordPress 这个平台上持续写作。确实是有我自己的考量的。

对于我来说，确实不太需要工具来帮助我更好的产生一篇博客 —— 因为我满脑子都是灵感。但另一方面，我也认可工具是非常重要的 —— 就像我为什么现在坚持使用 WordPress 。

WordPress 作为动态程序，可以让我无时无刻的在任何一台电脑上写作 —— 我不只在 macOS 上写博客，还会在手机上写。而这些是 Hexo、Hugo 之类的产品无法做到的。

动态博客的 WordPress 释放了我写作的生产力，让我可以源源不断的产生灵感、记下灵感，并转变成文章。

另一方面，WordPress 的丰富的插件系统，也让我能够更好的写作：如果你细心，可能会注意到，今年我的博客几乎都有了题图 —— 主要得益于一个 WordPress 插件 Instant Images，让我可以直接在 WordPress 中搜索无版权图片作为头图。再配合上 USS Upyun 这个插件，来将我的图片放在对象存储上。

d2b5ca33bd970f64a6301fa75ae2eb22 6

当贴图变得简单了以后，自然也就愿意在文章当中给我的读者以更加丰富的形式。

你说工具不重要么？我不这么觉得。

当你不知道你想要什么的时候，工具或许是不重要，因为反正你没明确方向，效率并不重要。但当你明确了你想要什么的时候，工具就变得十分重要了。

telegram

为你的 WordPress 站点配置 Telegram Instant View

发表评论

Telegram 内置了一个非常好用的阅读功能 —— Instant View。Instant View 可以实现在 Telegram 内部重新对网站内容进行排版，从而为读者提供更好的阅读体验。

作为一个网站主，如果你希望对你的网站提供相应的支持，则可以自行在 Instant View 的网站添加你自己的网站进行适配。

为 WordPress 添加 Instant View 适配

访问 Instant View 官网，并使用你自己的 Telegram 账号登录

d2b5ca33bd970f64a6301fa75ae2eb22 8
Instant View 官网

登录成功后，点击右侧的 My Templates，进入到 Templates 管理页面。

d2b5ca33bd970f64a6301fa75ae2eb22 9

并在 Templates 管理页面中间的输入框中输入你网站任一文章的地址，并回车，你会自动进入到规则的适配页面。

d2b5ca33bd970f64a6301fa75ae2eb22 10
规则适配页面

随后，在页面中输入你的站点的规则，这里我们可以使用其他开发者写好的规则。将规则粘贴在页面中

# Use Instant View version 2.0
~version: "2.0"

# Use this template only blog article pages
?exists: /html/head/meta[@property="article:published_time"]

# Get article text in <article> 
body:     //article

# Get title from <h1>

title:    $body//h1[1]
subtitle: $title/next-sibling::h2
author_url: //span[has-class("author")]//@href

# Get article cover image
cover: //img[has-class("wp-post-image")]

# Convert all iframe elements to inline element
@inline: $body//iframe[starts-with(@src, "/media/")]

# Remote header and footer
@remove: //article/header
@remove: //article/footer

# Replace p to figure
@replace_tag(<figure>): $body//p[.//img]

# Youtube Embedded Fix
@replace_tag(<figure>): $body//p[.//iframe]
Code language: PHP (php)

粘贴并保存后，会自动在最右侧页面生成预览的效果。

d2b5ca33bd970f64a6301fa75ae2eb22 11
加入规则适配后的效果

当你的规则适配效果无误后，接下来只需要点击右上叫的 Mark as Checked ，来标记该页面已经检查完车。

d2b5ca33bd970f64a6301fa75ae2eb22 12
标记为检查成功

测试完成第一个后， 接下来你只需要在你的博客当中挑选出 10 篇文章，进行文章的验证即可。

d2b5ca33bd970f64a6301fa75ae2eb22 4
验证至少 10 个页面才行

根据 Telegram Instant View 的规则，你需要验证满 10 篇文章，才能提交你的模板给官方人员审核。

d2b5ca33bd970f64a6301fa75ae2eb22 5

提交后，你会见到这样的提示，接下来只需要等待你的模板通过测试即可。

d2b5ca33bd970f64a6301fa75ae2eb22 6
提交成功

预览效果

在审核期间，你可以在编辑器页面右上角点击「View in Telegram」来查看预览的效果。包括你也可以复制里面的 rhash 的值，使用这个值来生成 Instant View 的链接分享给别人。不过，最方便的当然还是等官方审核通过以后再用。

d2b5ca33bd970f64a6301fa75ae2eb22 13
预览效果。

总结

Telegram Instant View 的开发不困难，掌握了一定的 HTML 、XPath 的基础，就可以开发完成，简单的几步，就可以让你的网站在 Telegram 当中拥有一个不错的预览效果，这个时间值得去花。

silver mercedes benz emblem on blue surface

从企业视角，为什么要选择 WordPress？

2条回复

WordPress 在国内日渐式微，从过去的全民博客用 WordPress， 到后来的很少人会使用 WordPress 做博客，再到现在只有一小撮人还在使用 WordPress，伴随着 PHP 的衰落和 Golang 等新语言的兴起，WordPress 不再是国人的选择。过去曾经有一段时间，大家很喜欢用 WordPress 做电子商城，不过随着时间的流逝和国内外电商贸易环境差异的变化，使用 WordPress 开发电子商城也不再是一个选择。如今的企业，不再愿意选择 WordPress 来完成自己的业务。

不过，从我自己的视角来看，我们看待任何一个工具的时候，不能看他是否还流行，而是要看他是否还能解决我们所面临的问题。

WordPress 的优势是什么？

WordPress 最大的优势主要是三点：

  1. 插件市场足够丰富带来的更少的开发工作量：但凡提到 WordPress ，你就不能不提 WordPress 的插件市场。WordPress 海量的插件市场可以帮助你更好的完成你的工作。对于一些传统模式下需要自己开发的功能，你可以选择直接安装 WordPress 来完成工作。
  2. 服务端渲染带来的 SEO 友好：现代 SPA 也有服务端渲染的能力，不过对于开发者来说，则需要单独假设一套服务端渲染的服务来完成这部分工作。或者提前预生成所有的页面。对于页面较小的站点，预生成比较靠谱。但对于数据量极大的站点，预生成也是一个较为痛苦的过程。WordPress 因为更加的传统，所以一直采用的是服务端渲染的模式。服务端渲染在针对 SEO 进行优化时，可以获得更好的优化能力（毕竟有些时候 Spider 不一定会等你的页面在前端渲染完成）。
  3. 极强的编辑性带来的人力释放：WordPress 不仅仅是我们看到的给用户的这一套 UI，还包含了一个强大的用户后台。强大体现在 Editor (Gutenberg)、全站编辑（WordPress 5.9 开始提供的新能力）。这些能力可以让 WordPress 从一个只能用固定模板的网站，变成了提供了一定的自由度，可以通过拖拽来生成一个页面的能力。对于一些比较极致追求拖拽的人，还会使用 Elementor （不过不太好做性能优化，如非必要，不上 Elementor）。这个能力带来的时候可以释放开发团队的人力，在构建好最基础的 Block 之后，交由运营人员来完成后续的管理和维护。

WordPress 的劣势是什么？

但同样的，没有什么东西是只有好处没有坏处的， WordPress 的坏处同样明显。

  1. 使用 PHP 编写，国内维护人员难招：WordPress 所依赖的 PHP 生态式微，则相应的，从事 WordPress 开发的人也渐渐变得更少。对于企业来说，难以找到合适的人是一个很大的问题。
  2. 目标太大，容易被安全攻击：WordPress 作为全球使用量排行第一的 CMS（内容管理系统），盯着它的黑客也多。虽然对于 WordPress 本体的安全攻击很快就会被修复。但针对普通插件的攻击则不那么容易防范。如果选择不当，很有可能把自己变成黑客的肉鸡。

总结

技术领域没有银弹。WordPress 同样也不是那个银弹。在合适的场景下， WordPress 便能放大自己的价值。而如果不合适，同样也无法放大 WordPress 的存在价值。

programming language

在 WordPress 中实现同一个 CSS 类在不同页面展示不同的效果

2条回复

在使用 WordPress 开发时，某些时候你会遇到在同一个类在不同页面的时候，希望有不同表现的诉求。在这种情况下，一个比较简单 or 比较 Tricky 的技巧是通过 Body 层的类选择器来实现。

在 WordPress 进行渲染时，会自动在页面的 <body> 上加入 postid-[id] 的类，对比本文就是 postid-5888。

d2b5ca33bd970f64a6301fa75ae2eb22 29
比如本文的 class

类似的，如果是一个 Page，也会生成 page-id-[id] 的类。

d2b5ca33bd970f64a6301fa75ae2eb22 30
页面生成的类是 page-id-[id]，和 post 规则不完全相同

因此，如果你需要某个页面的元素样式和其他页面元素样式不同，但页面结构保持一致，一个比较好的方式是通过这些页面类选择器来实现。以你要自定义 btn 样式为例。则可以这样实现：

// 标准页面的样式
.btn{
   // your styles
}

// 在文章 ID 为 5888 的文章上的样式
.postid-5888 .btn{
  // your styles
}
// 在页面 ID 为 84 的文章上的样式
.page-id-84 .btn{
  // your styles
}

Code language: JavaScript (javascript)

总结

借助上面的方式可以实现同一个类在不同的页面展示不同的样式。但我个人觉得，这样的实现方式可能对于 Debug 不太方便，尽可能少用。但如果你需要用的话，那一定要注意好组织代码，避免后续维护成本提升。

此外，除了通过修改 style.css 来实现，你可以考虑将 Page 单独的样式梳理在一个 page.css 中进行维护，从而降低维护难度和成本。
WordPress 当中也有一些插件来实现某个页面自定义的 CSS 能力，将这些样式放在插件中来实现也是一个不错的选择：Post/Page specific custom CSS

Reference