Push Markdown重构
契机
自己在搭建网站Wordpress的时候，发现wordpress对markdown的支持并不是非常好，这让我非常难受啊，研究生期间我可是markdown的重度用户，毕竟Typora太好用了，比起word编辑不知道高到哪里去了。于是网上找来找去啊，找不到一个合适的，要么需要曲线救国，要么需要一些有限制的软件，所以就是没有一个完美的解决方案，但很快啊，我在知乎上看到《WordPress+PublishMarkdown快速构建个人博客》这篇文章，顿时就来劲了啊。文章是20年2月份写的，我赶紧去下载试了一下，发现果真能行，但是一开始我发现报错，有一些bug，我就看看他的源码，好家伙，应用程序居然用的Vue2，顿时我就来劲了，最近在学vue，但是缺少实战，本来想用vue搭个博客的，后来发现wordpress省事，vue练手的机会就搁置了，这不，机会一下子就来了。
在此机缘下，我就萌生打算用TypeScrip+Vue3+Electron13重构这个项目的想法，毕竟源代码编译运行都行不通。
在2021年7月14日，我已经实现了1.0版本的重构，去除了MathJax（因为实现不了，后续看情况实现），然后代码全都是用原来的，就是挪过来，毕竟Vue3和Vue2也差不多，js变成ts（anyScript😁）。不过也花了十天的时间，主要难点不在逻辑代码，因为直接复制粘贴，主要在有些库比较陈旧，还有一些莫名奇怪的BUG，最最蛋疼的是我用Electron的安全文档，没有内置Node，所以需要提前预加载，这就是通过复杂换取安全，说实话，我感觉也没有安全，非常蛋疼，早知道当初不走这一步了。现在唯一表面上不安全的就是去除了跨域限制，后续再看看怎么改吧，希望这个暑假能把这个软件完善一下，改改自己想要的逻辑。
过程
2021年9月1日
🎉✨🎉✨🎉今天发布了v1.1.0，算是里程碑的一个版本，主要是真正实现了原来软件最初的样子，就是重新加回MathJax。这个软件我自己已经使用了一个半月了，未来可能还是会有bug，但目前的使用体验来说，已经覆盖大部分的使用场景了，感觉还是很不错的。
2021年11月21日
昨天发布了v1.2.0，算是比较小的里程碑了，主要是修复了一些bug，更加完善了一些需求，并且在阿里前端训练营小组的帮助下，实现了一些文件列表、主题切换锦上添花的模式，还是可以的，越来越完善了。
2022年8月4日
即将发布v2.0.0，距离1.0版本更新已经过去一年多了，中间修修补补，小打小闹，现在终于完成了TypeScript和Vue3组件式写法了，也算是圆梦了。这其实是当初最终的想法，主要就是为了学习Vue3，现在一年过去了，发现我只有这个项目能够拿得出手。不过这次2.0.0版本在项目结构上变得还是比较大的，首先是动了之前的代码屎山，稍微理了理，把项目结构弄得清晰一点，没有那么难看了，还有一些变量名，实在是过于抽象和雷同，导致我在写1.x的时候就搞不清楚哪个是哪个。这次项目依赖也用pnpm，打包工具也从@vue/cli换成了vite3，这次的工具真的都焕然一新了。还加入了更新的功能，这虽然electron自带，但你实现了，就感觉贼tm炫酷。应该是没有3.x了，如果是有，那估计可能走得是MWeb那种路线，但是别人原生实现的，速度和体积应该能够吊打我的，也没有必要去实现那种了，本地端用typora够好用了。
实现原理
基本逻辑
基本是原来的逻辑，本地将markdown渲染成html格式，然后通过xmlrpc发送到wordpress。
MathJax
MathJax之前的版本是通过非常麻烦的方法，因为可能是写的比较早的原因，第三方的库不是很多，所以需要自己去写，但现在有比较成熟的第三方库了，我直接拿来使用，使用markdown-it插件库，直接在本地渲染成svg格式，然后上传到网页。之前是只在本地渲染查看，但是上传的话还是源代码，需要WordPress使用mathjax的插件来渲染。由于我使用了插件渲染不出来， 算是失败，但是本地渲染出来非常好，那我直接上传渲染后的，不仅能使WordPress少安装一个插件，还能减少渲染性能压力，直接展示，非常的amazing啊。
文章上传
对文章上传的逻辑和图片上传的逻辑进行了一定的优化，这就是我想要的效果。文章上传和图片上传是分开来的，毕竟markdown也不是内置图片，也是通过超链接的方式引用图片。
首先是对文章上传到Wordpress进行了逻辑优化，起因是开发软件的时候老是多次安装，甚至清缓存，或是多台设备试用这个软件，或者wordpress删除了文章，这就会导致原来的逻辑代码不能够适用。
目前的更新逻辑为下：
- 手动确认：先模式一；若指定ID为0，则模式二；若模式二失败，则模式三；若模式三失败，则模式四；
- 自动判断：先模式二；若模式二失败，则模式三；若模式三失败，则为模式四；
- 创建新文章：直接模式四；
- 模式一：更新指定文章ID
- 模式二：更新本地缓存获取的文章ID（相同的URL）
模式三：更新远程获得的文章ID（相同的标题，因为获取所有的文章，包括内容，比较费流量）- 模式四：创建新的文章
手动更新适用于第一次使用软件，或者是换了一台设备更新文章，那么就可以指定文章ID来使当前这次能够成功更新，并且在本地缓存了更新后的ID。
自动判断适用于就一台设备，而且有本地缓存的情况，当然没有也能够自动获取远程文章ID，除了费流量没啥硬伤。
图片上传
对图片上传的逻辑也进行了优化，也是因为多台设备和远程可能删除篡改图片的问题。
现在的逻辑是如果在手动模式下，选择了强制更新图片，那么就会强制覆盖原来有的图片，而且不会生成新的图片。自动覆盖的代码也需要修改wordpress的部分代码，因为wordpress的xmlrpc原本的逻辑是会生成-1,-2这样后缀的图片，而不会覆盖原来的图片，所以需要加一小段。
如果在手动模式下，选择了获取远程图片，那么就会把远程文章中的每一张图片的url赋给本地图片URL缓存，需要满足本地文章中的图片名称与网络文章的图片名称一致。这种应用场景是本地没有网络那篇文章，那么只需要输入ID并且勾选这个选项，本地图片URL缓存就会更新为远程图片URL，而不会再一次强制更新图片到远程的网络文章，这对于网络文章图片特别多的情况非常有用，节省很多时间。
强制更新图片和获取远程图片两个操作逻辑互斥，不能够同时选择，只能至多选择一个。
如果在手动模式下的不强制更新图片或者自动模式，那么就会检查本地缓有没有图片记录，如果勾选了“不检查远程图片”这个选项，那么就不会检查远程图片，如果勾选了那么还会再检查远程图片，如果都检查成功，那么就不会更新图片，即便图片已经经过了修改（只看文件名称）。如果没有，那么也会进行覆盖更新。
因此我的建议是，在远程删除了图片，或者本地修改了图片，那么就强制更新图片，自动模式不一定有效，因为有时候还有CDN的效果，即使删除了图片，CDN还有缓存，会有影响。
源码地址
gitee地址（主要）：https://gitee.com/xaotuman/push-markdown
github地址（备用）：https://github.com/szx741/push-markdown
使用教程：https://gitee.com/xaotuman/push-markdown/blob/master/docs/使用教程.md
push-markdown示例文档上传到WordPress的样式：https://szx.life/sample-docs-1/
其他链接
原代码链接：https://github.com/jzj1993/PublishMarkdown
写作助手：BlogHelper
博客园上传markdown文件：pycnblog
小彩蛋
图标自己画了一个，就取push-markdown的首字母，虽然细看画的不怎么样，但是随便瞥一眼有点内味了，并且我还加了自己的名字，不过只有这么大的图片才能看的到，在桌面上的图标就看不到了，也算是自嗨的一个小彩蛋吧。
