日志
- 2023-06-06：优化m2w 2.5的教程。
- 2023-06-05：m2w 2.5正式发布，支持REST API！更新相关教程。
- 2023-04-23：新增目录/格式不敏感的提示；新增更改已存在文章题目的相关技巧。
- 2023-02-07：教程维护。无重要更新。
- 2022-12-14：更新了一些使用细节。比如，建议运行脚本不要使用和m2w包同名（我改为了
myblog.py），否则会出来一些bug。 - 2022-12-11：将
m2w 2上传至PyPi (v2.2.10)，让大家可以通过pip安装m2w。具体用法去Github文档看吧，也蛮简单的。当然，像原来那样用也是可以的。 - 2022-12-08：教程中增加
post_metadata不可以为空值的提醒；更新了m2w v2.2.4，在上传新文件前先检查其是否已经存在于WordPress后台，避免重复上传。 - 2022-12-06：升级至
m2w 2.2。优化了user.json的参数结构使其更加灵活。至少在v2.2.1版本或以上。更新若干教程。 - 2022-12-03：创建船新版本m2w 2.0！
前言
m2w 1.0的教程可见《Docker系列 WordPress系列 WordPress上传或更新Markdown的最佳实践》。
之前我一直使用m2w来管理自己的博客文章。某次和小伙伴liange交流时，我意识到大家管理本地文件夹的习惯不太一样。比如，我虽然会将某文件放在一个具有特定结构的文件目录里，但我定位文件的时候习惯使用Everything之类的软件搭配正则表达式，因此只是记文件大致名字而不怎么记文件位置。
但是，有相当一部分人定位文件的时候依赖对文件位置的记忆。基于这种现实，旧版本的m2w对于某些小伙伴来说是不友好的。其一，旧m2w需要用户指定legacy和new文件夹，因此用户无法根据自己的喜好将待同步/更新的文件放到任意目录。其二，随着博客文章的数量与日俱增，这会带来管理上的困难。其三，将新文件“强行转移”至legacy里，这种操作也不太自然。其四，对于有多个站点/帐户的小伙伴来说，旧版本m2w的实现不够简洁。
因此，趁着周末休息，我设计了m2w的Plus版本——即所谓的m2w 2 ！m2w 2有以下特性：
- 与
m2w 1.0相比，使用 和config/user.json略微不同的方式维护用户信息。 - 用户可以开心地保留原有的文件结构 (～￣▽￣)～ 。
- 通过多个
legacy_*.json同时管理多个网站/帐户。 - 只需要使用1个 python 脚本
myblog.py而不是两个（m2w 1.0中的update.py和upload.py）。 - 像m2w 1.0 稳定且好用！
- 即时更新，而不像基于Github Page的更新策略一样有一定延时。
项目地址和原来是一样的：
欢迎使用喔！用法比m2w 1.0要更简单一些。对于m2w v2.2.4或以上的版本在上传新文件前会对WordPress后台已存在的Post进行检测（基于文件名），所以不会导致重复上传，大家可以放心升级啦！
最后，所有的m2w版本均依赖xmlrcp.php，所以你的WordPress站点不要关闭其API（默认情况下是开放的）。在WordPress 6.0时代，配合Wordfence等安全插件，其实不需要太担心安全问题。建议WordPress站点有https的情况下再使用m2w，否则可能会造成帐号/密码泄露（如果博客仅有http，建议上https；可参考此教程）。
基本原理
无论是更新文章还是上传文章，不再分开，完全由myblog.py控制。大致的规则是这样的：
- 如果
legacy*.json不存在，则所有的文件都是新文件，需要全部上传。 - 如果
legacy*.json存在，如果某些key不存在，表明为新文件，需要上传这些key对应的md。 - 如果
legacy*.json存在，如果key存在但value不同，表明为旧文件有新的改动，需要更新这些key对应的md。
我觉得这种逻辑对于普通用户来说是挺友好的，但是对进阶选手来说就不一定了。不过，进阶选手操作能力强，在我的基础上魔改，应该问题不大 (～￣▽￣)～
判断文件改动的基本原理是md5算法。根据chatGPT的介绍，MD5是一种散列算法，用于确保信息传输完整一致。它通过对数据进行摘要来产生一个结果，该结果称为散列值。MD5被广泛用于生成文件或消息的指纹，以确保它们在传输过程中没有被篡改。在m2w中，md5算法主要用于快速并敏感地判断某个markdown文件是否有改动。
user.json
该文件包含账户名及密码，请妥善保管。
新的user.json与旧版本略有不同，具体结构如下：
"web01": {
"domain": "https://domain-01.com",
"username": "username-01",
"password": "password-01",
"path_markdown": [
"E:/Github/m2w/@test/main",
"E:/Github/m2w/@test/main2"
],
"post_metadata": {
"category": ["test"],
"tag": ["test"],
"status": "publish"
},
"path_legacy_json": "/config/legacy"
}
其中web01可以随便取名，它与legacy_*.json文件的命名和一些message有关，一但指定后不建议更改。可以添加多个类似于web01的对象，这对于多网站/帐户的用户来说是挺友好的。post_metadata指定了默认上传的类、标签和状态，不可以为空值。
值得一提的是，path_legacy_json表征了legacy_*.json类文件的位置，它一般不需要调整，保留默认的/config/legacy取值即可。
目录结构
m2w 2不会破坏用户的文件结构，它完全是通过legacy*.json文件来判断是否有文件需要上传/更新。需要提醒的是，尽管m2w 2将文件的绝对路径当成Key，但你尽量不要对不同的文件使用相同的文件名——如果你这样做，其实也会给看博客文章的人造成疑惑（尽管这不会报错，因为WordPress会自动分配不同的数字ID）。
m2w 2的目录结构进行了优化。在user.json文件中，依然由path_markdown变量控制：
"path_markdown": [
"E:/Github/m2w/@test/main",
"E:/Github/m2w/@test/main2"
],
这里你可以加任意数量的顶级目录。如果该目录里有子文件夹和.md文件，也可以正确识别。由于代码里具有去重机制，所以并不需要担心路径重复。如果这些目录里有非.md格式的文件，它们将会被m2w 2忽略。
网站/帐户
如下所示：
"domain": "https://domain-01.com",
"username": "username-01",
"password": "password-01"
domain、username、password则和m2w 1.0是一样的，即分别代表WordPress站点的域名、用户名、密码。
项目展示
为了演示多站点/帐号的功能，我使用了重复的站点/帐号。
基本使用
如下图，一条python myblog.py命令即可：
目录/格式不敏感
m2w 2对于markdown所在文件夹的位置是不敏感的。一般来说，你只需要指定一个最上层的目录即可（下图示例中，只要指定new02即可）：
此外，如果目标目录有其它格式的非markdown文件（比如jpg/gif），m2w 2会自动忽略它们——因为它们不太可能是博客文章。
其它提示
yaml头
和1.0版本一样，m2w 2支持在markdown文件添加yaml头。如下所示：
---
category: [docker]
tag: [wordpress, docker]
status: publish
---
其中category代表分类（一般是1个，但也可以多个），它在某些情况下参与文章默认链接的构成。tag代表标签（可有多个），status代表文章状态（publish发布/draft草稿/private隐私）。
逻辑判断
在myblog.py中，首先进行网站连接，只有成功连接时才会进行md5 sum判断。该特点对于连接网络不稳定站点是必要的，因为由于q的原因这些站点偶尔会无法连接。如果事先进行了md5 sum判断且连接错误/超时，尽管下一次成功连接网站，也无法同步上次更新（因为md5值已经更新过了），这会给用户带来不必要的困扰。该特性在m2w v1.0.7已经添加，但较早的m2w版本里我并未考虑到这种可能性（踩坑成长ing）。
用VSCode来运行myblog.py的小伙伴建议加个代理。打开VSCode，按F1可调出设置文件settings.json。下图示范v2ray的ip和端口：
根据自己本地代理所使用类型、ip和端口进行更改即可。
信息级别
如果你觉得代码运行时的提示信息太“多”、太“杂”，可以在myblog.py中设置verbose=False。如下图：
message report一般是对应myblog.py或up.py脚本中的print命令，如果不喜欢，自己注释或删除就行。这没啥好说的，挺简单 (～￣▽￣)～
更改题目
一般建议题目在上传前就确定好。如果你真的需要更改一篇文章的题目，建议遵循以下步骤：
- 去WordPress后台更改为新题目
- 在本地Markdown里将文件名改为
新题目.md - 运行m2w。由于
force_upload=False（默认值），所以该文章并不会上传；但是在legacy*.json中却留下了记录 新题目.md有更改内容时，会自动更新内容
听上去挺复杂。自己实践一下吧！总的来说，最好就是一开始就可以定型题目——这完全是可以做到的。在我博客有145篇博文的时候，印象中我只改过2次题目。
m2w 2.5
从2.5版本开始，m2w支持REST API喽 (ฅ´ω`ฅ) REST API 利用的是WordPress Application Password，它是一个具有某种用途的临时密码，而不是博客的登陆密码。 因此，这种方式天然地比传统的登陆密码模式更加安全；就算不小心泄露了，也没关系，直接删除换个新的就行。我和小伙伴@FoxSuzuran共同完成了m2w的REST API兼容和开发工作。由于最近我的毕业答辩及工作等事宜已经稳定，所以有空完成了相关测试。
我测试的Python版本包括3.7.6、3.8.1、3.10.10，都可以正常工作。一般都是建议使用conda啦！大家直接使用pip install m2w即可下载最新版。用法和m2w 2.0几乎是一样的，只是user.json多了一个application_password参数。
m2w 2.5的实际使用效果如图所示：
某些情况下，REST API模式的效率会比Password模式低。如果你用不惯REST API模式，也可以直接使用Password模式，用https我觉得问题也不大！
启用REST API
为了启用REST API模式，WordPress后台需要做一些准备工作。具体如下：
- 如果使用了wordfence之类的安全插件，请启用WordPress应用程序密码:
- 创建一个新的REST API:
- 安全地保管该API。如果有必要，可以重新生成或删除:
myblog.py
一些比较重要的参数定义在myblog.py里。实际上，m2w只提供基础函数；正式工作时是通过类似myblog.py的脚本来完成的。下面是一些比较重要的参数：
- path_m2w：字符型。指定元数据（即config文件夹）的路径，它通常包含1个user.json和系列legacy_*.json。
- force_upload：布尔型。如果WordPress已经存在一个名为a的文章，是否强制上传本地一个名为a的markdown文件。默认
force_upload = False，这样则不会为同题目的文章分配多个ID，因为它们往往是同一个文件。 - verbose：布尔型。是否显示工作报告。默认
verbose = True。不喜欢关注工作细节的小伙伴可以设置verbose = False。 - last_update_time_change：布尔型。仅适用于REST API模式。是否在更新文章时强制更新文章的发布日期。默认值为
False。如果你希望更新文章后会排在最前列（时间倒序），你应该设置为True。 - max_retries：正整型。如果由于网络波动等原因导致上传/更新失败，重新尝试的最大次数。默认值为
10。
从这些参数可以看出，m2w 2.5相比m2w 2有更多细致的考虑。这也是该项目逐渐成熟的标志啦 (ฅ´ω`ฅ)
user.json
如果你要使用REST API模式，可以类似这样配置user.json：
{
"web01": {
"domain": "https://blognas.hwb0307.com",
"username": "your_username",
"application_password": "your_rest_api",
"path_markdown": [
"E:/Github/m2w/@test/main",
"E:/Github/m2w/@test/main2"
],
"post_metadata": {
"category": ["test"],
"tag": ["test"],
"status": "publish"
},
"path_legacy_json": "/config/legacy"
}
}
如果你要使用旧的Password模式，可以类似这样配置user.json（application_password也可以删除）：
{
"web01": {
"domain": "https://blognas.hwb0307.com",
"password": "your_password",
"application_password": "",
"path_markdown": [
"E:/Github/m2w/@test/main",
"E:/Github/m2w/@test/main2"
],
"post_metadata": {
"category": ["test"],
"tag": ["test"],
"status": "publish"
},
"path_legacy_json": "/config/legacy"
}
}
小结
个人感觉m2w还是不错的。大家使用时有啥问题可以多多反馈，评论区留言或提issue都可以的！
扩展阅读
- WordPress XML-RPC
- A Complete Guide on xmlrpc.php in WordPress (What It Is, Security Risks, How to Disable It)
- The Complete Guide to WordPress REST API Basics
- How to Use the WordPress REST API with Python
- 10分钟教你用YAPF让Python代码瞬间从丑陋变漂亮 – 腾讯云开发者社区-腾讯云
---------------
完结，撒花！如果您点一下广告，可以养活苯苯😍😍😍
貌似修改tag跟catagory不会跟着更新|´・ω・)ノ
是的。如果你要改tag，自己在后台修改就行。 一般我文章的tag都是固定的，文章完成时就已经确定了。
这个我测试了一下，很不错！非常实用！不过我用argon主题测试发现，上传上去之后，图片如果比较小的话（外链），是居左显示的，这个argon主题应该可以通过修改css让文章里的图片全部居中显示的吧，不知道你折腾过没
详见《特效》。具体方法是添加一个额外CSS:
我记得你用的不是halo？
啊哈，我是用halo，昨天正好有时间就折腾了一下你的m2w?
我个人觉得m2w还不错的，写作和修改博文比较方便 ୧(๑•̀⌄•́๑)૭
请问博主这个错误是为啥 xmlrpc.client.Fault: <Fault 500: ‘项目需要一个名字。’>
啊这，我还没遇到过哎。可以贴一下你的user.json内容吗（请将安全信息隐藏）
我看了一下能自动获取到md文件的名字，但是还是会报错，下面是我的userjson
早上起来debug了一下，发现是tag为空的问题，加上一个tag就可以正常推送了
tag确实不可以是空的。另外，你这markdown的路径是不是也有点问题？这不是我默认的路径嘛，你的应该也不一样
我的markdown路径就是按照博文自己建立的，测试好了之后我再改成自己的，现在发现是可以正常推送和更新的。但是我觉得一篇博文不需要tag也是可以的，所以昨天死活没有找到问题，去对应位置print一下，发现也能出现md的文件名，所以我猜可能是配置的问题，今天早上改了tag就可以了
加tag好一些，这样文章系统会比较有条理。如果没有特别倾向，可以设定默认tag为common、general之类的词。一般我写博文的时候，该博文都会对应某个主题。就算是吐槽，也有一个关于“吐槽”的tag或category ヾ(≧∇≦*)ゝ
你这个user.json文件感觉问题很大? 可以远程连线看一下。你有telegram的话可以加群： https://t.me/benszhub 。没有就加QQ吧
好的，加油！ (๑•̀ㅁ•́ฅ)