首先是周报的频率后面改成每五天一次，无节假日（比如今天是12月1日，下次是12月5日），另外称呼由周报更改为项目发展报告。帖子命名格式：项目发展报告-2021-12-1。
上周新的应用市场爬虫机制还没完全开发完，主要原因是应用市场应对插件和主题 Slug 重复问题的处理机制计划按老赵头的新方案重构一下，而新的机制牵扯到了爬虫的数据录入模块的录入逻辑，所以需要等处理 Slug 重复问题的机制重构完后才能继续应用市场爬虫的开发。
之所以会 Slug 重复，是因为 wordpress.org 在架构上插件目录和主题目录是两个互相独立的站点，数据库也是分开的，但 litepress.cn 将二者都塞到了一个 Woo 商城里，所以二者的 Slug 就会产生冲突。
之前为了解决这个问题，是装了 Permalink Manager 插件，然后为有冲突的插件和主题维护一套映射关系。老实说，机制复杂容易出错，而且也多装了一个在本平台应用场景有限却很庞大的插件，应用市场已经启用了将近 40 个插件了，实在是不堪重负，能省则省。于是基于以上两点原因，计划对此重构。
新的方案打算默认在爬虫录入数据时就对 Slug 附加前缀，比如说：plugin-xxx、theme-xxx。然后在数据输出时再去掉前缀输出原始 Slug。理论上应该是可行的，但仍不十分肯定，所以需要先将这个功能重构完确定路线完全可行，之后再对应用市场爬虫机制应用新的数据录入机制。
最后，原计划应用市场爬虫的数据采集录入模块使用 WordPress 的 Cron 驱动，但现在有了更棒的方案：我使用 WordPress 开发了一个常驻后台的守护进程，其监控一个 Redis Steam 队列，一旦 Slug 更新监控模块发现某个插件、主题更新，就会将 Slug 压入队列，当 Redis Stream 中存在数据时该进程就会结束阻塞状态，而开始他的工作流程。
这样做的好处是省掉了 Cron 每次启动时加载 WordPress 框架的成本开支，因为新的守护进程只在进程启动时才会加载一次 WordPress 框架，之后一直在后台运行，只在需要的时候运行所需代码即可。这就好像 Java 的 SpringBoot 一样，既节省硬件资源又速度快。
后续翻译平台的爬虫也会重构为这种常驻后台的守护进程。
