对于一个希望在WordPress上撰写博客的人来说，在网页之外，一个方便的本地编辑器可能是很有必要的。十来年前，在Windows上曾有过多个WordPress客户端，但是目前很多都不再有人维护。WordPress网站上有一个有点长的客户端列表可供参考，现在的更新后的列表中的Windows客户端有以下几个：
- BlogDesk
- BlogJet
- Chrysanth WebStory
- WordPress.com Desktop App （需要Jetpack插件以访问未在WordPress上托管的博客）
这几个客户端里面。BlogDesk已经很久都没有更新了，网页上的更新记录到了2009年；BlogJet和Chrysanth Webstory都不是免费的。所以这次的测试对象只有免费的Open Live Writer（前身Windows Live Writer），WordPress官方的客户端，以及MS Office Word。
Open Live Writer是这三个里面，唯一严格意义上可以做到离线编辑的WordPress客户端。它是Windows Live Writer的开源分支，挂靠于.Net基金会旗下。尽管它的代码改动停在了2019年，但是目前仍能在WordPress 6.0站点上运行，且可以在Windows软件商店上下载安装。它的界面比较像Windows 8的风格。同时支持可视化编辑、HTML源代码编辑、预览。
值得注意的是它可以下载站点的主题，在预览时也可以查看在站点中的呈现效果。不过这个功能只能说是聊胜于无，因为它下载的主题可能并不完整。如果站点用了一些奇技淫巧，站点的还原度并不会太高。源代码功能的帮助也比较有限，因为没有语法高亮。
不过OLW支持插件且开源，提供了一点点改善的微小的可能性……
WordPress桌面客户端是WordPress官方的产品。它在GPLv2下开源，但本质上来说应该是又一个Electron应用/Chromium套壳。继承了WordPress的作风，它并不直接支持WordPress之外的站点。如果要用在WordPress之外，需要在自己的站点上配置Jetpack以连接WordPress账号。除此之外，如果你懂网页的JavaScript的一些常规操作的话，你可以开控制台暂时跳转到自己的网站。另外，这个客户端并不能算是严格的离线编辑器，它只是一个精简版的专门用来访问WordPress博客的浏览器而已，它的功能依赖于网页，可能还不如移动端版本。网页本身也是支持离线的，只要用户不刷新，不点按钮，缓存还能用……
至于Word，也可以算作一种WordPress离线编辑器。它对WordPress的支持比较隐蔽，需要在新建文档的时候选择「博客文章（Blog Post）」模板，之后会弹出设置博客的对话框。可以合理怀疑的是，Word对WordPress乃至博客的支持是Windows Live Writer被扫进历史垃圾堆的原因之一。但另一方面，Word又不是为写博客而设计的，它缺少一些OWL针对写博客做的一些细节。无论如何，使用Word来给WordPress网站撰写文章的体验是与用Word写普通文章的体验类似的，这意味着也会有类似的限制，比如代码块就需要Word之外的操作，而在OWL里面只要在源代码里加入一对<code>标签。
ARG use_cache=false
ARG node_version=16.17.0
ARG base_image=registry.a8c.com/calypso/base:latest
###################
FROM node:${node_version}-bullseye-slim as builder-cache-false
###################
# This image contains a directory /calypso/.cache which includes caches
# for yarn, terser, css-loader and babel.
FROM ${base_image} as builder-cache-true
ENV NPM_CONFIG_CACHE=/calypso/.cache
ENV PERSISTENT_CACHE=true
ENV READONLY_CACHE=true
###################
FROM builder-cache-${use_cache} as builder
# Information for Sentry Releases.
ARG manual_sentry_release=false
ARG is_default_branch=false
ARG sentry_auth_token=”
ENV MANUAL_SENTRY_RELEASE $manual_sentry_release
ENV IS_DEFAULT_BRANCH $is_default_branch
ENV SENTRY_AUTH_TOKEN $sentry_auth_token
ARG commit_sha=“(unknown)”
ARG workers=4
ARG node_memory=8192
ENV CONTAINER ‘docker’
ENV PROFILE=true
ENV COMMIT_SHA $commit_sha
ENV CALYPSO_ENV production
ENV WORKERS $workers
ENV BUILD_TRANSLATION_CHUNKS true
ENV PUPPETEER_SKIP_DOWNLOAD true
ENV PLAYWRIGHT_SKIP_DOWNLOAD true
ENV SKIP_TSC true
ENV NODE_OPTIONS –max-old-space-size=$node_memory
WORKDIR /calypso
# Build a “base” layer
#
# This layer should never change unless env-config.sh
# changes. For local development this should always
# be an empty file and therefore this layer should
# cache well.
#
# env-config.sh
# used by systems to overwrite some defaults
# such as the apt and npm mirrors
COPY ./env-config.sh /tmp/env-config.sh
RUN bash /tmp/env-config.sh
# Build a “source” layer
#
# This layer is populated with up-to-date files from
# Calypso development.
#
# We remove apps, tests and desktop because they are not needed to
# build or run calypso, but yarn will still install their
# dependencies which end up bloating the image.
# /apps/notifications is not removed because it is required by Calypso
COPY . /calypso/
RUN yarn install –immutable –check-cache
# Build the final layer
#
# This contains built environments of Calypso. It will
# change any time any of the Calypso source-code changes.
ENV NODE_ENV production
RUN yarn run build
# Delete any sourcemaps which may have been generated to avoid creating a large artifact.
RUN find /calypso/build /calypso/public -name “*.*.map” –exec rm {} \;
###################
FROM node:${node_version}-alpine as app
ARG commit_sha=“(unknown)”
ENV COMMIT_SHA $commit_sha
ENV NODE_ENV production
WORKDIR /calypso
RUN apk add —no-cache tini
COPY —from=builder –chown=nobody:nobody /calypso/build /calypso/build
COPY —from=builder –chown=nobody:nobody /calypso/public /calypso/public
COPY —from=builder –chown=nobody:nobody /calypso/config /calypso/config
COPY —from=builder –chown=nobody:nobody /calypso/package.json /calypso/package.json
USER nobody
ENTRYPOINT [“/sbin/tini”, “–“]
CMD [“node”, “–unhandled-rejections=warn”, “build/server.js”]
对于一般的不是特别注重排版的博文来说，撰写草稿可以直接用专门的MarkDown编辑器写，之后可以很方便地转成HTML。这样，没有特别要求的话只要在网站上复制粘贴即可。如果喜欢用API做事，可以搭配上OWL，还方便插入图片。把排版、页面设定工作放到站点上。这种流程对于插入代码也是比较友好的。MS Word则比较适合主要是文字且对文章内部排版有所追求的用户。至于WordPress那个官方客户端，适合只是懒得开浏览器的用户。至于公式这种东西，为了兼容性直接当作图片对待也不是不行？
关于MarkDown，在博文领域，我认为如果作者习惯使用MarkDown的话，大可以选用支持的编辑器。但是没必要让站点也支持MarkDown格式，HTML就足够了。转成HTML所用的时间在写一篇博文所用的时间面前，带来的边际成本并不高，至少不足以让我转投直接支持用MarkDown写作的博客程序。
很多这种第三方客户端的正常运行都依赖于WordPress的XML-RPC接口，最近这个接口被认为会对站点增添安全风险。而且WordPress在推区块式编辑器，第三方不是很容易达到站内所见即所得的效果，甚至在本地另外搭一个WordPress也能达到类似于离线编辑器的效果。至于是否有把WordPress的区块编辑器搞成独立版本的项目，目前还没有看到。
另外WordPress还支持使用电子邮件发文，这个方法的疑点主要是在排版。
关于Chrysanth Webstory，有一篇小有名气的作者的批评文章可以看看，标题叫Chrysanth WebStory Is Not Free。作者也遇到了和本人类似的对本地编辑器的使用场景，批判了一番欧美的小型商业软件不透明的付费模式。付费也不一定会得到更优质的服务，反而意味着被割了两茬韭菜。
（……待续？）