这篇文章的目的是做个测试。之前我看过，Obsidian 第三方插件市场有 WordPress 插件，可以实现发布到 WordPress 站点的功能。我很高兴的安装了它。
可惜的是，它会把我本地写的 Markdown 格式的文章转换成 HTML 后，传进 WordPress。WordPress 也是怪，这么多年一直没有官方支持 Markdown 格式，插件市场上把 Markdown 格式的内容保存在数据库里，显示的时候实时渲染的插件，只有凤毛麟角的两个，其他插件都是保存渲染好的 HTML 在数据库里，对日后的修改十分不便。
一时间，这个插件让我感受到了大起到大落的感觉。也没找到适合的插件，何况我感觉从现有功能上删掉本地渲染的 feature 功能应该也不难，于是就去仓库里提了 issue。一位名为 bugparty 的网友回复说不难，可以做一个。结果半个月后，竟然真的做了出来。这篇文章就是为乐对它进行测试的。
从前天开始进行测试，到今天上午完成了配置，我的网站完成了后台调整，从过去的 LNMP 切换到了 Docker 服务，也把 URL 的配置格式从目录切换到了子域名。
上个月我写了《或许我应该切换到子域名》这篇文章，讲了一些关于网站部署的想法。这次是把这篇文章中的想法进行了实践，并且也使用了 Docker。起因是我偶然间读到了这篇文章，里面对使用 Docker 来部署一个 WordPress 讲的非常清晰，特别是里面使用了 Nginx Proxy Manager (NPM) 这个工具，之前我从来没听说过它，让 Nginx 配置的一切都图形化了，而且支持自动申请 Let’s Encrypt SSL 证书，解决了我过去尝试中遇到的难题。我通读了下来，心想这并不复杂呀，于是也萌生了尝试的念头。
因为我之前还有 credit 没用完，所以我在 Linode 上面下单了一个最小的 VPS 实例，并把一个二级域名解析到上面。一开始我安装 Docker 这一步就遇到点问题，我开始的时候为了通用性，尽量避免兼容问题，选择了 Ubuntu 24.04 操作系统，结果遇到些挺奇怪的错误。软件仓库里有好几个版本的 Docker，我是新手也完全不确定该用哪一个。后来我按照网上的说明选了一个安装上去，在执行 docker compose 命令的时候也发生了 Python 的异常，在新的服务器上不大应该。于是我第二次选择了 Debian 12，也是我目前在用的 OS。这次我直接看 Docker 的官方网站上的说明，添加了 Docker 官方源，安装的里面的 stable 版本，之后比较正常了。
这次我遇到了一些问题，到最后基本都解决了。很多问题是我自己粗心导致的，比如在 NPM 中配置代理后访问时的 500 错误。现在看来是当时自己粗心，之前每怎么用过 Docker，看到一个内部 IP 就凭直觉往里填 127.0.0.1，后来才知道应该填 172.17.0.1。还有就是博客的 URL，怎么让他不带端口号，也不要自己跳转到无法访问的形式也让我想了半天。后来我发现应该配置好了代理和SSL之后，再访问 WordPress 完成安装，在后台设置中一切就正确了。我在测试服务器上把 WordPress 当前的配置都迁移过去，包括 Markdown 解析、主题字体设置，而且我发现现在 WordPress 导入支持把原本的媒体文件也导入进当前的服务器，文章里面的链接 URL 也被升级过了，省了很大的功夫。之后我还在申请通配符 SSL 证书那里遇到了麻烦，DNS 验证通不过，之后我发现我提交的是 DNSPod 后台的腾讯云 API，改成 token 之后问题也解决了。
得知 Jetpack 有一两年时间了，安装卸载尝试了几次，总算在前两天调整了博客的 Markdown 插件之后，又一次把 Jetpack 装上了，写一下使用微体验。
之所以叫“微”体验，是因为我感觉我用到的功能不过百分之一，Jetpack 作为 Automatic 官方发布的插件，我感觉似乎也担了一些给公司营收的任务，因此有些功能是需要付费使用的。而它的功能又确实多，我自觉用不到这么多高级的功能，所以也没舍得付费，到目前为止都是使用的免费版本，用的功能也只是少少的。
今天早上，抱着再试一次的想法，在知乎上又搜索了一遍“WordPress Markdown”，有幸看到了这篇回答，然后去搜索了一下回答中提到的 wp-gruber-markdown 这个插件。结果这个插件没找到，看到了一个名为 Parsedown for WordPress 这个插件。看了一下更新的时间还是 8 年前，详情页面里面也说没有与我目前的 WordPress 版本进行兼容性测试，不过我还是打开试了一试，结果访问页面，发现页面已经神奇的都正常了。我简单看了一下，目前没发现有踩雷的地方，于是就把 WordPress 切换了回来。
这两天因为 Markdown 插件的事可折腾了不少，前因后果在上一篇文章中写的比较细了，我的空余时间基本上都在捣鼓这个。未来路线也一直定不下来，所以就在几种方案中反复横跳。一是继续搜索合适的 WordPress 插件，看看能不能满足我解析 Markdown 的需求；二是看看能不能把 Movable Type 安装好，它原生支持 Markdown，目前网上还留存的一些 Movable Type 搭建的中文博客都让我比较眼馋；三是配置好 Hugo 的评论，文章发布功能很简单，但是评论功能我一直弄不好。
说到方案三，我也在想对我来说评论是否就那么重要，目前单说中文博客，就有很多是不加评论功能的。早年看蔡志浩的博客都关闭了评论功能，他还写了一篇文章专门分析了这件事。当时看了感觉有些超前激进，现在也多少释怀了。不过我对于信息的掌控形成了一种执念，我感觉虽然现在写博客、读博客的人少了，给博客评论的人也少了，但缺少了评论这个途径，不是连这一点点的交流可能性也给剥夺了吗？现在有多少人会去我的网页上找到我的邮箱，给我发一封邮件来讨论我的某篇文章呢？我不认为我的文章可以激发人们如此高涨的表达欲。退一万步说，就算真的有人愿意给我发邮件讨论，那这些讨论与我的博客文章也是剥离的状态，将来既无法与我的文章形成关联，讨论的内容也无法被将来的读者看到。关于博客文章与评论的关系，不同人有不同的观点，我是认为评论其实也算是博客文章的一部分，跟别人的讨论可以丰富文章的观点，对内容进行更多的补充，我认为是有价值的。所以，我也不希望我的博客上的评论丢失，评论放在第三方平台，比如 Disqus，对于部署静态博客是更容易的做法，但我出于这个目的，只能选择本地部署。上一篇文章也解释了，我最终选择的是 Remark42。
昨天晚上，Remark42 的部署有了一点进展。原先我的博客虽然可以显示评论框，但点击登录按钮，只能出来一个小小的白色的弹窗，没有任何内容。可以看出来是有些东西没有显示。我这几天反复看文档，也尝试了不少次，猜测是我选择部署在子目录下这种方式导致的 URL 连接缺失的问题，不过我也看到有别人成功部署了，最终也没确定问题所在。不过昨晚我修改了 Remark42 提供的前台代码，这一改让 github 登录的按钮能显示了，显然进步了一大截。不过最后我还是没搞定 OAuth 的配置，一直没有成功。思来想去，我感觉这一个方案或许有点困难，再次尝试了配置 Movable Type，Nginx + PSGI 也老是 502，只好全都放弃。
MarsEdit 是不得不提的另一个因素。记得网上有使用 MarsEdit 编写完发布到静态生成的博客上，但很麻烦，有很多中间步骤。要是能顺畅使用，还是得 WordPress 或 Movable Type。今天，WordPress 的这个 Markdown 插件如果可以正常使用，我就可以放下这段时间的心结，继续使用到下一次出问题了吧。
这两天，我又一次尝试了博客生成器。查了一下之前的博客记录，我在 2019 年的时候尝试过一次，当时选择了 Hugo，几个月后重新回到了 WordPress。当时的我文章里写的理由，没想到放在今天仍然成为了我这次尝试的动机。
前几天把博客服务器的操作系统进行了升级，我当时没有意识到，后来才发现 Debian 12 Bookworm 已经正式推出。虽说我的桌面电脑上使用的 Sid，但 Linode 服务器上还在使用 Bullseye 稳定版，也没有升级一些服务器软件，虽说 WordPress 一直提示我说 PHP 版本低。这次一升级了操作系统，把 Nginx、PHP 的版本都升级了好几个版本。印象里 PHP 升到了 8.2，导致我的 WordPress 在用的 Markdown 插件不兼容了。
我的 Markdown 插件是比较古老的 Markdown for WordPress and bbPress。这是我在 2007 年 3 月份刚开始用 WordPress 的时候就开始用的 Markdown 插件。我本来没感觉会有什么问题，因为 Markdown 相对简单，我没觉得会有多么复杂。这个插件的运作也很符合我的预期，把 Markdown 原文件保存到正文，在访问网页的时候现把 Markdown 渲染成 HTML，简便直观。结果我升级 PHP 后导致了语法不兼容，因为我不懂 PHP 所以也不好描述，我自己根据错误提示，把插件里的一些大括号改成方括号，结果没有错误提示了，但插件也不灵了。去插件网站上看看作者有没有升级，结果看到最后一次维护是十好几年前了，也就是说我只能放弃这个插件了。
之后就是上网搜索合适的新插件，找到几个看描述就不大符合我的需求，多数情况下会把 Markdown 翻译成 HTML 后再存进数据库，这让写作成了一锤子买卖，将来修改会很麻烦。后来我根据标星数量和评论，选择了排名最高、评价最高的 WP Githuber MD，我想评价这么高的插件，一定有它的可取之处。结果开始时我用的不错，但是后来我发现它也是变更了数据库的保存方式。最直观的反映是，我之前已经发布的文章都不好用了，Markdown 标签直接被显示了出来，而没有被正常转译。而我进入这篇文章的编辑界面，什么也不动，保存一下，问题就得到解决。说明在保存的时候，插件往数据库里面写了写什么。这是我不希望的，因此最终又重新回到了最初的插件。
我还忘了从哪个网页上看到了一个说法，说现在 Markdown 插件都是这么个思路，说是为了提升转译效率云云。我对此嗤之以鼻，我十多年前用的这个插件就可以在浏览的同时进行转译，没有明显效率拖后。而且，要是这么关注页面打开的时间，那干嘛还用 WordPress？不如早用静态发布的系统算了。
几天下来，我依旧没有找到合适的 WordPress 插件，在绝望下又萌生了迁移博客系统的想法。然后就开始调查尝试各种对 Markdown 支持更好的博客系统。首先静态生成器都没问题，他们天生支持 Markdown。然后 Movable Type，官方支持 Markdown。还有一些我之前没用过的博客系统，他们的网站也宣称官方支持 Markdown，比如 Typecho。
今天下午在 #archlinux-cn 组里 CSSlayer 的帮助下，解决了 Emacs 无法使用 Fcitx 5 输入中文的问题。刚安装好后配置过一次，那次好了，但之后又莫名其妙的不行了，让我很苦恼。今天在 CSSlayer 的指导下，安装了 xorg-fonts-misc 包，就又恢复了。果然和之前网上看的一样，Emacs 无法输入中文和字体设置有关。
于是今天晚上有了心思看看怎么在 Emacs 里面直接发布博客。之前我也是在 Emacs 里面写的，因为新系统里我只安装了 Emacs 和 Vim 两个编辑器，其他的编辑器都不是很吸引我。我之前是在 OneDrive 同步的一个子目录里，用 Emacs 保存成 Markdown 格式的，然后再复制粘贴进 WordPress 后台。比较麻烦的是需要把标题格式调整一下，而且 Emacs 和 Firefox 切换来回也有些烦人。今天看了一下文档，抱着试试的态度，竟然成功了。目前尚需要解决的问题是配置好密码保存，还有启始模版，不过目前已经可以比较好的写博客了，当然那样子会更舒服。
我在 MacBook Pro 上用 Day One 写日记，总是感觉效率很低，或许是有太多干扰，随便一下 cmd+tab 就切换到别打应用看一看。我很多日记，都是用 iPad 来写的。在 iPadOS 的平台下，至少应用是全屏的。屏幕不会太大，给人浪费空间的感觉。这样更容易产生一种沉浸式的体验。
我想，如果可以用 iPad 来写博客，或许也可以拯救我的注意力。但目前用 iPad 来写博客有几个问题：
输入体验不高。排除 Smart Keyboard Folio 手感这种可以忍受的问题，主要让我难受的是在外接键盘情况中，不支持第三方输入法。苹果的键盘现在有了双拼，支持小鹤了，这不错，但重码率还是有一些的。特别是需要翻页的时候，只能通过上下方向键来执行，太影响效率。如果能通过逗号、句号，哪怕是减号、等号来翻页，我也能接受，当然最好是支持第三方输入法，可以用鹤形。
没有专门客户端。我在电脑上用的是 MarsEdit，不支持 iPadOS。我目前在用 WordPress 的客户端，比较难用，速度也很慢。当然也可以用 Ulysses，但用作写博客会有各种问题，而且他对 Markdown 的支持也很怪异，比如加个链接就需要手指点几下，不能用标准的 Markdown 语法让我觉得难受。
最后，这篇文章在 WordPress 客户端发布失败。圆圈进度条一直在转，没法停止。我只好杀后台，心里担心会不会草稿也丢失。好在最后没有。复制粘贴到 Ulysses 里发布吧。
我曾经是 MarsEdit 3 的用户，在国外读大学期间用它写过一段时间的博客。当时遇到过使用上的问题，根据这篇文章的记录，当时我用的版本还不支持手动设定 slug，对于中文用户来说，中文标题会被忽略，生成很奇怪的文章网址。后来我开发者通过信，最终升级后解决了。
后来有了 Ulysses，它支持发布功能，所以我就开始用它来写博客。现在冷静分析，不是 MarsEdit 不好，当然它的界面太传统是一方面，但功能上是没啥缺陷的。之所以换到 Ulysses，我想是因为我花钱买了它。一份许可不算便宜，我不能买来放那里不用吧？写博客是个比较不错的用途。
回国后，虽然我写博客的时间少了，但我主要还是用 Ulysses。Ulysses 有它自身的好处，它跨设备，可以在 Mac、iPad、iPhone 上运行，并良好同步。工作时遇到需要现场发言的场景，我可以在 iPad 上打开 Ulysses 进行编辑，然后用一个字号比较大的发布模版，在 iPad 上显示，作为提纲。还有几次我需要上台演讲，我就用手机上的 Ulysses 打开在 iPad 上编写好的发言稿，还是用发布的功能，选一个看上去清晰的格式，作为提示。
我在 Ulysses 里有一个文件夹，名字叫“博客文章”，目前有 124 篇文章。我在里面写完后，通过发布功能，直接发布到我这个博客上。我感觉挺好的，特别是加上同步功能，我可以随时随地写博客。很多时候我拿出 iPad 来就可以写了，有时候躺在床上睡前也可以写。Ulysses 有即时保存功能，不想写了直接关闭即可，不怕丢失内容。
近期看到了 MarsEdit 4 发布的消息。其实早就听说了，不过当时没有兴趣。这次之所以又调查了一次，是因为又看的 John Gruber 的文章，然后还看了他在 XOXO 关于 Darring Fireball 的演讲。看到他的网站上写的他用来写作的工具，里面还是有 MarsEdit。我也不知道目前还是这样，还是他仅是没时间调整网页，不过不影响我再去看一眼 MarsEdit。
看着看着，我想还是下载一份试用版来用一用。这篇文章往前数两篇，都算是我用 MarsEdit 的尝试。给我的感觉是，和 MarsEdit 3 相比看不出很大改进。我是个怕麻烦的人，很多博客系统上有的功能，我其实懒得用，感觉对我这一个个人的博客也没啥大用，我用到的其实是最基础的功能。我看了版本 4 要收费，一度想着是不是可以用版本 3？结果版本 3 在当前的系统已经不再支持，下载下来的程序无法执行。想来想去，目前我打算在试用期结束后，花钱买一份许可。
为什么我不再继续用 Ulysses 了呢？我感觉在写博客方面，Ulysses 有些“专业不对口”。虽然它的功能足够丰富，也可以满足发布一篇博客的需求，但在管理博客方面是有些不足的。从 Ulysses 的角度上，一篇文章发布前可以做种种修改，但发布后就和我无关了。如果要修改什么东西，就只好重新发布。在结合 WordPress 来用的时候，如果我想改个错别字，就需要重新发布一次。或者我想加一个标签，也带来过发布了两篇文章的情况。而 MarsEdit，版本 3 我记不清了，版本 4 里可以把我博客里所有的文章都拉到本地，随时修改、调整，就想是一个博客的客户端一样，特别方便，这是吸引我的地方。
今天，把WordPress的Markdown插件换回了我最早使用的Markdown for WordPress and bbPress。
当年我学会了Markdown语法后，就立刻想在写博客的时候使用。当时也是有缘，我第一个找到的就是这个插件，用着感觉很不错，一直用了好几年。后来之所以把它换掉，原因已经记不清了，似乎是和WordPress新加入的谷腾堡编辑器有关，或许和JetPack插件有关系，似乎官方已经支持Markdown语法，我就没有必要安装这个插件了。还有一个可能的原因，也是谷腾堡的锅，我用Ulysses写完博客后，直接发布会发生语法问题。
之后我又换了插件，大概是因为JetPack的速度太慢了，于是就禁用了它。找了一个WP Githuber MD插件。当时为什么没有用回Markdown for WordPress and bbPress插件我已经忘记了，是否是仍然存在问题也记不清，反正WP Githuber MD感觉挺好用的，提供的双栏编辑器界面，左边写Markdown，右边实时生成结果，很直观。不过我用不到，一方面我使用的Markdown语法非常简单，很少有写错需要看看结果的时候，再者我使用Ulysses来写，在线编辑器用的很少。
今天发现了WP Githuber MD插件的缺陷。我发现我过去文章里的Markdown语法全都失效了，开始以为是配置的原因，今天仔细看了看，没有这方面的配置。我试着从后台进入文章编辑，什么也不做，只点一下更新，再刷新页面就恢复了。我去数据库里看看，原来在进行文章编辑之后，数据库里保存的Markdown格式全部被转换成了HTML标记。看来WP Githuber MD插件的编辑器能够识别HTML标记，并转换成Markdown格式，在保存的时候再以HTML保存，但这造成了我之前文章里的Markdown失效了，因为它们没有被转换。
上网查找一下解决方案，发现现在的Markdown插件基本上都是一个原理，没有找到能够在生成页面时动态转换语法的插件，似乎功能都往即时转译去了，也就是在编辑时是Markdown，保存时会转换成HTML再保存。我好几年前用的插件就能做到在生成页面时转换，现在的主机效率应该不至于做不到吧。还看到有极端的说法是在Typora里编写，然后导出HTML后再粘到WordPress里，我实在是不知道是怎么想的。
没办法，最终还是启用了最早的Markdown for WordPress and bbPress插件。是否会出问题我还需要继续观察。
之前我换 Hugo 的原因之一就是对 WordPress 的编辑器的开发路线非常不满。一个简单的博客，弄那么复杂的古腾堡干什么？这东西，我感觉就是初学者用这简单把，还有真正在浏览器里打字的人用着输入一些。像我们这种在外部把文章写好了再发布的，非常不爽。我猜和 WordPress 要往 CMS 工具发展有关。
过去古腾堡是个插件，我不用它的话禁用即可，但随着版本升级，古腾堡成了默认的了，我也找不到可以把它关闭的开关。切换到 HTML 编辑模式，把 Markdown 复制进去，切换回来还是乱了，再换到 HTML 模式，被加上了 HTML 的标签，不是我想要的。更别提通过 Ulysses 发布了，之前的文章里的列表全没了，一团糟。
我很奇怪 WordPress 没有跟上潮流，默认加上解析 Markdown 的功能。Moveable Type 在很早的版本就默认支持 Markdown，而 WordPress 还是需要插件支持。我刚学会 Markdown 后，给 WordPress 装了一个名为 Markdown for WordPress and bbPress 的插件，这几年一直这么用着。直到出了古腾堡的妖蛾子。我尝试着打开 Jetpack 里面的 Markdown 功能，也没起到作用。无奈还是换一个插件吧。
根据评价，我选择了 WP Githuber MD，尝试了一下不得了。首先之前的格式恢复正常了，再者编辑器也有了更加强大的功能，实现了左右两栏的设计，左边是 Markdown 文本，右边是实时预览。虽然我目前用不到实时预览的功能，不过还没有把它关闭，新鲜两天再说。
这样我的博客系统又可以安稳的用一段时间了。我觉得 WordPress 这样破坏生态，从使用者的角度来说真看不出有什么太大的必要。Firefox 给插件系统动了大手术，换来了开发者和用户的长时间阵痛，到现在还让我心有余悸，真不希望 WordPress 走 Firefox 的后尘。毕竟，博客在今天已经式微，强大又稳定还能保持更新的博客系统也没多少了。