众所周知，WordPress 是一个对 MySQL 强依赖的 CMS。MySQL 众所周知也可以用 MariaDB 代餐。不过不管是 MySQL 还是 MariaDB，保持在后台运行都要狂吃 200+ m 内存。这对于个人站点当然是特别浪费的。

但是官方给出了一个插件 SQLite Database Integration，据称是为了测试他们即将合并入主线的 SQLite 支持而提前放出的插件。而这个插件又是 fork 的 别人的 东西，因此按理来说应该是 battle-tested 了。于是脑子一热，就整了一些迁移。

迁移的过程就不提了，没什么技术含量，基本上就是安装插件，然后重新走一遍安装流程，导入备份的文章就行了。我怕手贱，还把插件丢到了 mu-plugins 里面，不过看着 db.php 上面写着的

 * This file is auto-generated and copied from the sqlite plugin.
 * Please don't edit this file directly.

我知道显然这不是建议的操作。于是又丢回 plugins 了。希望我的手安分一点。

在迁移的同时，将服务器上的所有服务放在了同一个 docker-compose.yaml 里面。或许这才是把我又耗到一点的根本原因：先是把 WordPress 换成 fpm 镜像和 caddy 合并跑，再因为不想看到跨镜像挂载换回 apache 镜像拿 caddy 接着做反向代理，又在把 volume mount 的内容转成 bind mount 的过程中 cp 不带 -p 没保留权限而暴毙，还忘记改 wp-config.php 的一众 secret key 而差点成为公网靶场。

12/1 10:38 更新，因为一些洁癖又换回了 fpm（不会真有人拿 Caddy 反代 Apache 吧！！！）。
btw，感谢 Caddy，有着全世界最好配置的 php_fastcgi。配置文件放在下面，用做记录。
另外记录一个很烦的一点：WordPress 不支持检测 Caddy 的 Rewrite。

version: "3"

services:
  wordpress:
    image: php:8.2-fpm-alpine
    restart: unless-stopped
    volumes:
      - $PWD/wordpress/html:/var/www/html
      - $PWD/wordpress/php.ini:/usr/local/etc/php/conf.d/wordpress.ini
  caddy:
    image: caddy:alpine
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - $PWD/caddy/Caddyfile:/etc/caddy/Caddyfile
      - $PWD/caddy/site:/srv
      - $PWD/wordpress/html:/srv/wordpress
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

hymint.space {
        root * /srv/wordpress
        php_fastcgi wordpress:9000 {
                root /var/www/html
        }
        file_server
}

总之暂时是安稳下来了。我是真的体会到 Docker 这东西和 Traditional PHP 就是八字不合。然而又有什么办法呢？总不能真用 Debian 12 给的 wordpress 包吧——诶，不过大概也不是不行，它可是 Debian 啊。就是版本应该会太老了点。

12/1 10:48 更新，续上面的配置文件，其实按照这样配置 Docker WordPress 也还不错。