diff --git a/404.html b/404.html
index a2ed4f54..fab4e303 100644
--- a/404.html
+++ b/404.html
@@ -1 +1 @@
-
404: This page could not be found404
This page could not be found.
\ No newline at end of file
+404: This page could not be found404
This page could not be found.
\ No newline at end of file
diff --git a/_next/static/mIzbcNyiBonMiP55n0miY/_buildManifest.js b/_next/static/0T3BfSzrbYvxGf5Gk-Dy4/_buildManifest.js
similarity index 100%
rename from _next/static/mIzbcNyiBonMiP55n0miY/_buildManifest.js
rename to _next/static/0T3BfSzrbYvxGf5Gk-Dy4/_buildManifest.js
diff --git a/_next/static/mIzbcNyiBonMiP55n0miY/_ssgManifest.js b/_next/static/0T3BfSzrbYvxGf5Gk-Dy4/_ssgManifest.js
similarity index 100%
rename from _next/static/mIzbcNyiBonMiP55n0miY/_ssgManifest.js
rename to _next/static/0T3BfSzrbYvxGf5Gk-Dy4/_ssgManifest.js
diff --git a/_next/static/chunks/nextra-data-en-US.json b/_next/static/chunks/nextra-data-en-US.json
index 32e105c3..6cd961fd 100644
--- a/_next/static/chunks/nextra-data-en-US.json
+++ b/_next/static/chunks/nextra-data-en-US.json
@@ -1 +1 @@
-{"/about/faq":{"title":"常见问题","data":{"谁在维护-mog#谁在维护 Mog?":"Mog 是一个独立的社区驱动的项目。它是由 Wibus 在 2021 年作为其个人项目创建的,原身为 Golden Space / NEXT Space,极大的受到了 Mix Space 的影响。如今,Mog 由来自于全国各地的志愿者们维护。自 2021 年以来,Mog 的发展主要是通过爱 ❤️ 和热情来驱动的。如果您觉得 Mog 不错的话,请考虑赞助我们,以支持 Mog 的发展!\n赞助事项请发送邮件至 wibus@qq.com。","mog-v1-和-mog-v2-之间的区别是什么#Mog v1 和 Mog v2 之间的区别是什么?":"从 NEXT 到 Mog 是一个比较惨痛的过程,已经有一部分人知道此项目了,他们通常称之为 \"nx\",现在修改这个名字对宣传来说并不是一件好事,但为了以后的发展我们必须这样做。新的名字由两个单词组成:Module + Blog = Mog,这和我们在 v2 版本的构思有关。我们在 v2 突破地采用了微服务架构,对于不同的服务分离,我们仍在探索当中,相信出版的时候可以寻找到一个较好的方案。","1x-存在的严重问题#1.x 存在的严重问题":"1.x 版本由于更新仓促,导致了很多的问题,比如:\nAPI RESTFul 规范\nDTO 与 Model 不匹配,导致输出存在问题\n接口方法书写混乱\n注释不规范\n很难继续向上堆积功能,原架构会导致功能臃肿\n为了长久的发展,我们发布了最后的 v1.7.0,并立即开始了 v2 的重构","v2-新增的特性有#v2 新增的特性有:":"2.x 版本将会内置后台,无需额外部署,也不应额外部署,这会增加更多的在意料之外的维护成本\n2.x 使用微服务架构,扩展性对比单一服务高了很多,且一个微服务的异常不会导致其它微服务同时异常,增强稳定性\n评论模块、邮件模块、友链模块、渲染模块将会独立为一个单独服务\n我们对文档进行了重写,重新使用了 Vitepress,并且参照了许多优秀的开源项目编写相关文档\n评论模块将会考虑与其他博客系统相兼容,并且提供独立的控制台\n邮件模块将会寓于交流模块之内,交流模块将会负责一切与交流相关的功能\n友链模块我们会考虑将其可以作为一个独立的友链页面,并且支持主题定制\n渲染模块我们会提供一个 Tiny markdown Server,推动更多的自定义语法渲染处理","mog-使用什么开源协议#Mog 使用什么开源协议?":"Mog 是完全免费的开源项目,且基于 AGPLv3 License 发布。","mog-可靠吗#Mog 可靠吗?":"Mog 是一个完全开源的项目,我们不会收集任何用户的数据,也不会做任何不可逆的操作,我们会尽可能的保证用户的数据安全。如果您觉得代码中存在安全问题,欢迎您根据安全策略反馈于我们团队,我们会尽快修复。","mog-功能健壮吗#Mog 功能健壮吗?":"Mog 的目标是提供一个可靠、健全的博客系统,我们会尽可能的保证功能的健壮性,但是我们也不会过度的追求功能的完善,我们会在功能的完善与稳定性之间进行权衡。我们会将很多的功能进行拆分,使得 Mog 可以更加的灵活,比如评论模块、邮件模块、友链模块、渲染模块等等,这些模块都可以独立的使用,也可以与 Mog 一起使用。这样一来,既可以向上堆积功能,也可以向下拆分功能,使得 Mog 更加的灵活。","mog-体积小吗#Mog 体积小吗?":"很不幸,全套 Mog 的体积并不小,因为我们使用了很多的依赖,构建了很多服务,这导致功能越多,体积越大。我们只能尽最大可能减小体积,当然,我们会保证体积的稳定性,不会出现突然增大的情况。","mog-能胜任大规模场景吗#Mog 能胜任大规模场景吗?":"目前表现效果或许还不是很理想,Mog 的计划之一就是能够胜任大规模场景,不断挑战极限使用场景,优化相关代码,使得 Mog 能够胜任大规模场景。","我可以为-mog-做贡献吗#我可以为 Mog 做贡献吗?":"当然,欢迎你阅读 贡献指南 为 Mog 做出贡献。","图标设计#图标设计":"v0 版图标 - By wibus-wee.\nv1 版图标 - By wibus-wee.\nv2 版图标 :\nIcon: By Jinhwan Kim.\nFont name: GlacialIndifference-Regular\nFont link: https://hanken.co/product/hk-grotesk/\nFont author: Hanken Design Co.\nFont author site: https://hanken.co/"}},"/about/release":{"title":"版本发布","data":{"":"当前 Mog 的最新稳定版本是 。完整的过往发布记录可以在 GitHub 查阅。","发布周期#发布周期":"Mog 并没有固定的发布周期。\n补丁版本 (patch releases) 发布会及时按需进行。\n小版本 (minor releases) 发布总是会包含一些新特性,发布周期并不确定,并会经历 beta 预发布阶段。\n大版本 (major releases) 发布会提前知会,且经历早期讨论和 alpha、beta 等预发布阶段。","语义化版本控制的特殊情况#语义化版本控制的特殊情况":"Mog 的发布会遵循语义化版本控制,同时伴随一些特殊情况。","编译后的代码和旧版运行时之间的兼容性#编译后的代码和旧版运行时之间的兼容性":"较新小版本的 Mog 编译器可能会生成与较旧小版本的 Mog 运行时不兼容的代码。例如,由 Mog v2.1 生成的代码可能不完全兼容 Mog v.2.2 的运行时。","预发布版本#预发布版本":"小版本发布通常会经历不定量的 beta 版。而大版本发布则会经历 alpha 和 beta 阶段。预发布版本 (pre releases) 是为了进行集成/稳定性测试,并让早期用户为不稳定的功能提供反馈。请不要在生产中使用预发布版本。所有的预发布版本都被认为是不稳定的,并且可能会在两者之间产生不兼容变更,所以在使用预发布版本时,一定要精确锁定版本号。","废弃的特性#废弃的特性":"我们可能会定期废弃那些在新的小版本中拥有更新更好的替代品的功能。被废弃的功能仍将继续工作,但会在进入废弃状态后的下一个大版本中被删除。","rfc#RFC":"具有可观表层 API 的新特性和 Mog 的重大变更都将经历意见征集 (RFC) 流程。RFC 流程的目的是为新功能进入该框架提供一个一致且可控的路径,并给用户一个机会参与设计过程并提供反馈。该 RFC 流程会在 GitHub 上的 mogland/rfcs 仓库进行。","试验性特性#试验性特性":"有些特性在 Mog 的稳定版本中已经发布并被记录了,但被标记为试验性的。试验性特性通常与某些 RFC 讨论相关联,这些讨论中的大部分设计问题已经在理论上得到了解决,但仍缺乏来自真实实践的反馈。试验性特性的目的是允许用户通过在生产环境中测试它们来提供反馈,而不必使用不稳定的 Mog 版本。试验性特性本身是被认为不稳定的,只能以某种受控的方式使用,且该特性可预期地会在任何发布类型中发生变化。此页面参考自 Vue.js 的 版本发布 页面。"}},"/blog/core-updated-to-v1.7.0-alpha.0":{"title":"Mog 1.7.0-alpha.0 (Continuation) 预发布","data":{"":"好久不见!距离我们宣布 Core 正式可用已经有一个月了,这期间我们做出了不少的优化、修补,以及功能更新,让我来给你慢慢列举一些较为重要的更改:","-breaking-changes#🚨 Breaking Changes":"备份模块:\n支持使用 JSON 恢复部分服务数据- by Wibus\n主题模块:\nEJS 模板引擎解析器支持 - by Wibus (b0e57)\n支持从 GitHub 或 自定义地址下载主题 - by Wibus (2622d)","最为重要的-feature----主题模块#最为重要的 Feature -- 主题模块":"这个模块曾经出现于 Core v0.x 版本中,但重构后的版本都并没有怎么提及此功能,今天归来纯属希望可以更加方便地来编写前端主题。目前模块已初步成型,相关模块接口已经公开,但是依然存在有且已知的问题:\n传递数据似乎不足,或对开发对应页面并不适用\n反向代理后,样式等文件无法正常获取\n对辅助函数支持不足(因为有很多函数支持都仅适用于 Express 平台)现在仅支持 moment 方法\n相关数据字段尚未完全确定,具体情况等待第一个 Demo 发版后再作商讨","-bug-fixes#🐞 Bug Fixes":"评论模块:\n模型 与 Dto 的属性不匹配 - by wibus-wee (f1e7d)\n从暴露的全部字段检索垃圾评论 - by wibus-wee (e139e)","-performance#🏎 Performance":"聚合模块:\n对查找最新文章的服务返回 新增 text 字段 - by wibus-wee (24e2d)\nGitHub Release Page:https://github.com/mogland/core/releases"}},"/blog/mog-core-v1.5.1-release":{"title":"Mog 1.5.1 (Evolution) 发布 - 重构后的新起点","data":{"":"感谢 @MYXXTS @origami-tech @Truimo 等大佬的鼎力相助经过1年的摸索与将近1个月的从零重构,我们发版了新的 Mog Core 版本,这将是一个全新的起点。","新特性#新特性":"新的数据库驱动 MongoDB:MongoDB 是一个 NoSQL 数据库,它提供了一种非常简单的方式来存储和查询数据,而且它的性能非常高。\n新的缓存机制 Redis:Redis 是一个高性能的内存数据库,作为一个缓存,它可以提供高速的查询和存储,目前 Mog Core 使用于配置获取中\n新的插件系统,插件系统是一个非常特别的框架,它可以让你在空间中添加新的功能,比如 WebHook, Macros, 可以让你的空间更加灵活,更加强大。\n新的插件系统尚未稳定,仅完成了基本的插件注册,激活,应用插件\n全新的文章备份模块:文章备份可以让你将文章备份到本地,以备以后使用,同时支持导入/迁移\n改进后的文章备份,将遵循以下逻辑:\n单篇文章直接输出\n多篇文章打包输出\n改进后的数据库备份模块:将全部 Mog 数据保存至本地,数据比文章备份模块更加全面\n在文章或页面中自动记录图片相关元数据:比如图片的宽高、图片的类型、图片的 URL 等等,但也需要前端支持,这样可以让你的文章更加美观\n提供了更多的文章管理选项:比如文章的标签,文章的分类,文章的显示/隐藏,文章的发布时间,等等\n支持标签或分类合并:将多个分类或标签中的文章合并如一个分类或标签\n使用了装饰器来验证密钥以使用高阶操作\n全新的跨平台 Cookie 解析装饰器:支持多种浏览器,比如 Chrome、Firefox、Safari、IE、Edge 等等","如何迁移#如何迁移?":"v0 我们使用的是 MySQL 作为数据库,而 v1 我们使用的是 MongoDB,其中使用了很多 MongoDB 的特性,因此无法直接升级。目前只有一个可行的方案:\n将 v0 的文章页面数据导出,然后导入到 v1 中,v0 和 v1 在处理文章页面数据的方式是一致的,因此可以直接导入。\n由于 v0 是 Beta 版本,充满了不确定性,因此我们无法保证导出的数据能够完全正确导入到 v1 中,因此我们建议你在导入之前先备份好 v1 的数据库。"}},"/blog/mog-is-now-available":{"title":"Mog 1.6.0 (GoLive) 发布 - 从新起点开始","data":{"":"在不断持续开发了将近一年的Mog,我们收到了大量的评论,并且支持Mog的开发。非常感谢各位的支持!今天,随着 Mog 第一款官方前端主题 Tiny 成功发布,Mog已经可以真正部署使用了!感谢全部成员的贡献,以及大家的支持!","正式部署可用版本#正式部署可用版本":"Mog Core: v1.6.0\nMog Admin: v0.2.1\nMog Theme Tiny: v0.1.2\n立即阅读文档部署!\nMog Core 1.5.3 至 1.6.0 之间内容修改较多,期间包括了 漏洞修复、新增功能、逻辑优化。","preview#Preview":"[Mog Admin]\t[Mog Theme Tiny]"}},"/blog/mog-v2-refactor-1":{"title":"Mog 2.0 (Odyssey) 开始重构 - Stage 1 Issue","data":{"":"从 NEXT 到 Mog 是一个比较惨痛的过程,已经有一部分人知道此项目了,他们通常称之为 \"nx\",现在修改这个名字对宣传来说并不是一件好事,但为了以后的发展我们必须这样做。新的名字由两个单词组成:Module + Blog = Mog,这和我们在 v2 版本的构思有关。我们在 v2 突破地采用了微服务架构,对于不同的服务分离,我们仍在探索当中,相信出版的时候可以寻找到一个较好的方案。","为什么突然要重构#为什么突然要重构?":"1.x 版本由于更新仓促,导致了很多的问题,比如:\nAPI RESTFul 规范\nDTO 与 Model 不匹配,导致输出存在问题\n接口方法书写混乱\n注释不规范\n很难继续向上堆积功能,原架构会导致功能臃肿\n为了长久的发展,我们发布了最后的 v1.7.0,并立即开始了 v2 的重构","这次更新有什么新功能或者优势#这次更新有什么新功能或者优势?":"2.x 版本将会内置后台,无需额外部署,也不应额外部署,这会增加更多的在意料之外的维护成本\n2.x 使用微服务架构,扩展性对比单一服务高了很多,且一个微服务的异常不会导致其它微服务同时异常,增强稳定性\n评论模块、邮件模块、友链模块、渲染模块将会独立为一个单独服务\n我们对文档进行了重写,重新使用了 Vitepress,并且参照了许多优秀的开源项目编写相关文档\n评论模块将会考虑与其他博客系统相兼容,并且提供独立的控制台\n邮件模块将会寓于交流模块之内,交流模块将会负责一切与交流相关的功能\n友链模块我们会考虑将其可以作为一个独立的友链页面,并且支持主题定制\n渲染模块我们会提供一个 Tiny markdown Server,推动更多的自定义语法渲染处理","这次更新的问题是什么#这次更新的问题是什么?":"1.x --> 2.x 预计会出现较多接口不兼容的情况,因此除核心外的生态需要全部重写\n由于 2.x 使用微服务架构,因此文档部署需要全部重写,建议全部重新开始.\n该版本的制作时间会大大增长,有可能需要到下一个假期才可基本完成.\n此次的重构代号为:Odyssey."}},"/blog/mog-v2-refactor-2":{"title":"Mog Odyssey 2.0 重构基础服务 - Stage 2 Issue","data":{"":"第一阶段,我们居多是进行路径规划,后续阶段,我们会加紧进行基础服务的重构,在完成所有基础服务的时候我们将会发布一次 Alpha 文档。我们目前已完成重构的基础服务有:\n数据库模块 (mogland/core#309)\n授权模块 ( mogland/core#309 )\n配置模块 ( mogland/core#336 )\n用户服务模块 ( mogland/core#348 )\n文库模块 ( mogland/core#363 )\n数据聚合模块 ( mogland/core#396 )\n余下的服务模块我们将会在下一阶段继续加紧重构,在此之前,我们需要对某些模块撰写 RFC。","距离-20-还有多远#距离 2.0 还有多远?":"很接近,但也很遥远\n我们已经在全力开发,但是我们还需要一些时间来完成,我们将会在 2022 春节前完成 v2.0 的开发,但是我们不会在这个时间点发布,我们将会在 2022 春节后发布 v2.0,我们将会在发布前进行一些测试,以确保 v2.0 的稳定性。我们目前遇到的困难包括且不限于:人手不足、架构考虑、规划不足我们真的很希望有更多的人能够加入我们。"}},"/blog/mog-v2-refactor-3":{"title":"Mog Odyssey 2.0 重构生态服务 - Stage 3 Issue","data":{"核心所有服务已成功重写#核心所有服务已成功重写":"如果你有关注我们的开发进度,你能发现我们已经将所有的服务都重写完成了。至此,Mog v2 的核心部分已经基本完成,目前我们正在进行一些发布前的测试以及部分模块中的功能补充与优化。此次新增的模块有:\n分类 / 标签 + 文章 / 页面的服务模块 ( PR in mogland/core#363 )\n基本评论模块 ( PR in mogland/core#404, 于 mogland/core#558 已移除)\n评论服务模块 (PR in mogland/core#558 )\n数据聚合模块 ( PR in mogland/core#396 )\n友链服务模块 ( PR in mogland/core#565)\n基本友链模块 ( PR in mogland/core#511,于 mogland/core#565 已移除)\n通知模块 (PR in mogland/core#568)\n可能你会感到疑惑,为什么我们在后续的 PR 中移除了基本模块?\n目前的设计结构暂时对基础内置模块的支持并不是很友好,将会极大提高其编码时的复杂度,我们可能会在后续的版本中重新设计这部分的内容,这取决于用户是否需要基本模块。\n非常感谢 Mog 团队成员对这部分代码的贡献,我们将继续提高核心模块的代码质量与稳定性。","新的控制台-ui-已就绪#新的控制台 UI 已就绪!":"全新的 core,肯定要有全新的控制台 UI,我们在过去的时间里,对控制台 UI 进行了大量的重构,目前已经基本完成了。我们依然使用了 React 作为控制台 UI 的开发框架,以及在设计上依然保持了与原来的控制台 UI 的风格基本一致,但是我们对控制台 UI 的设计进行了部分的优化,使得控制台 UI 更加的简洁。","新文档首页#新文档首页":"我们又一次重写了文档首页,实际上是从 Vuejs Fork 的,我们对其中的一些内容做了一些修改,并且在添加了一些章节。你可以在这里看到新的首页:https://mog.js.org/","接下来我们要做的#接下来我们要做的":"我们需要将 v1 生态全部迭代至 v2,这依然是一个很长且困难的过程,我们将会在接下来的时间里继续努力。此外,我们需要重写全部评论模块,目前的评论数据设计已经可以支持在不同的站点中使用了~"}},"/blog/mog-v2-refactor-4":{"title":"Mog Odyssey 2.0 加入部分特性 - Stage 4 Issue","data":{"":"全部修改日志在 https://github.com/mogland/core/issues/605","主题系统-by-wibus-wee#主题系统 by @wibus-wee":"我们新增了一个主题系统服务 (themes-service),它将配有 Fastify + @fastify/point-of-view,目前我们支持了 .ejs 格式的模板引擎,在 Stage 5 我们可能会加入自定义渲染器功能。主题系统支持 i18n,配置十分方便,仅需要 i18n.yaml + _i() 即可使用:\n除此之外,还支持了自定义主题插件支持,它能让你在渲染前处理某些数据,不过目前它还有些缺陷,有待 Stage 5 中继续改进。","重新设计-core-readme-by-wibus-wee#重新设计 Core README by @wibus-wee":"总是认为之前的 README 太过花哨,而我们在第四阶段中,重新设计了 README。\n移除了 Motivation 动机 章节\n移除了 Table of Contents 目录章节\n重新设计了 Contributors 章节\n移除了 Activity 章节\n移除了 @allcontributors 机器人\n国际化 README\n将 # --> ##,以去除默认样式中过长的下划线\n与我们而言,这是一个小改进。","core-支持内置控制台-by-wibus-wee#[Core] 支持内置控制台 by @wibus-wee":"为了便捷性,我们将控制台移入了 Core Gateway 服务中,需要注意的是,它并不是由模板引擎制作的,控制台的仓库依然在 mogland/console,但 Core 将会把全部请求转接到后端中,把 Cookie 等注入请求返回中,请求远端 HTML 等文件,将内容返回。我们增加了关于后台的自定义配置,由于这项功能仍处于测试阶段,我们默认将会把它关闭,如果需要启动你需要在配置文件中启动它。相关文档已更新","全新的评论组件-mog-comments-wc-by-wibus-wee#全新的评论组件 mog-comments-wc by @wibus-wee":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。为了方便主题开发,我们使用 @jwcjs 开发了通用的评论组件。多亏于 Mog 评论服务的设计,它可以在任何地方使用,比如 Hexo。在后期我们将会实现对应的专属评论控制面板"}},"/blog/mog-v2-refactor-5":{"title":"Mog Odyssey 2.0 错误修复与项目重构 - Stage 5 Issue","data":{"":"GitHub · Mog Stage 5: https://github.com/mogland/core/issues/661","icon-全新的图标-by-jinhwan-kim#[Icon] 全新的图标 by @Jinhwan Kim":"有关这个图标的版权,你可以前往「常见问题」查看","core-自定义发布活动与返回接口-by-wibus-wee#[Core] 自定义发布活动与返回接口 by @wibus-wee":"通过定义配置文件,你将可以通过定义发布活动来调度你自己的服务,比如说:\n这样,你就可以通过 GET /events 来获取全部活动,通过 GET /events/{id} 来获取指定活动,通过 POST /events 来发布活动。","core-自定义定时任务支持-by-wibus-wee#[Core] 自定义定时任务支持 by @wibus-wee":"定时任务是一个非常重要的功能,它可以让你在指定的时间执行指定的任务,比如说,你可以在每天的 00:00:00 发送一封访客信息邮件给自己,或者在每天的 00:00:00 清理一次数据库。于是我们做了一个较为简单的定时任务系统,它具有以下功能\n不同的任务类型(访问 URL,广播事件)\n及其自由的任务操作参数\n支持任务执行进行后续操作\n收集任务错误日志\n暂时来说较为简陋,在后续阶段我们会继续完善它。","core-其他新增功能-by-wibus-wee#[Core] 其他新增功能 by @wibus-wee":"数据备份恢复支持\n静态资源管理服务支持\n友链服务支持获取全部状态的友链数据\n在无密码注册用户的情况下自动生成临时密码\n你可以看到,我们本次的功能增强都是围绕着自定义进行的,我们希望用户可以通过自定义来实现更多的功能,而不是依赖于我们的功能。","console-使用-vercelswr-请求后端数据-by-wibus-wee#[Console] 使用 @vercel/swr 请求后端数据 by @wibus-wee":"重构几乎所有触发的请求\n重构几乎所有的 Hooks,减少明面上的 useEffect 狂魔\n重构几乎所有页面的请求钩子\n将重复组件抽象为 ActionButton 组件\n另外,我们还使用新的 Toast 组件以替换原有有缺陷的通知组件","console-控制台支持刷新版本缓存-by-wibus-wee#[Console] 控制台支持刷新版本缓存 by @wibus-wee":"我们内置控制台的资源获取策略是:优先使用缓存,如果缓存不存在则请求远端资源,这样做的好处是可以减少请求次数,但是也会导致一些问题,比如:缓存所储存的版本过期,但是我们的控制台并不会主动刷新缓存,这就导致了用户无法获取到最新的控制台。为了解决这个问题,我们在 Dashboard 页面底部新增了一个刷新缓存的功能,它将会在用户点击刷新按钮时,刷新缓存,这样就可以解决这个问题了。","docs-使用-nextra-作为文档工具-by-wibus-wee#[Docs] 使用 Nextra 作为文档工具 by @wibus-wee":"鉴于 Vitepress 的部分功能不足,我们决定使用 Nextra 作为文档工具,Nextra 是一个基于 Next.js 的文档工具,它的功能十分强大,我们将会在后续的版本中继续使用它。\n然后抄了“一些” Nextra 官网的样式","dev-渲染模块实现-by-wibus-wee#[Dev] 渲染模块实现 by @wibus-wee":"GitHub: @mogland-dev/mog-render-service我们之前曾说过要在 v2.0 中实现一个独立的渲染模块,它将会是一个独立的服务,它将会负责渲染 Markdown 和 Djot 文件,并且还支持文本宏,目前它已经可以正常工作了,但是我们还需要对它进行一些优化。你可以在文章中输入如这样的内容:\n接着渲染模块的文本宏模块将会将其渲染为:\n这个 feature 的想法来自于 Mix space,但是这次我们稍微优化了算法,并更容易拓展功能。由于需要安全执行代码,因此效率依旧不算高。","core-修复大量严重错误-by-wibus-wee--myxxts#[Core] 修复大量严重错误 by @wibus-wee & @MYXXTS":"依赖安全性修复\n错误指向评论详情接口\n替换旧有缓存模块为新缓存模块\n无法载入 ESM 模块\n主题服务无法注入依赖\n主题服务初次使用发生崩溃\n同时激活多个主题发生错误"}},"/blog/new-theme-single":{"title":"新主题 Single 发布","data":{"":"当代互联网上,人们对于博客的呈现方式越来越有了更高的要求。Single 主题的发布为博客的呈现提供了一个全新的选择。这个主题是基于 Paul 的 Typecho Single 主题移植而来,为 Mog 博客系统用户提供了一种全新的博客展示方式。Single 主题的设计风格简约大气,页面整洁明了,使得阅读体验更为舒适,响应式设计,使得博客在不同设备上都能够有良好的展示效果。GitHub Repo Page(欢迎 Star 🌟!): https://github.com/mogland/mog-theme-Single","其他版本#其他版本":"Hexo 版 - 原作者 Paul 发起的,但期望得到社区维护\nHalo 版 - 来自阑珊的移植版本,部分内容有差异\nPaul 的文档与此项目无关,请勿混淆,如果有相关问题请前往对应主题的 Issues 提问。","许可证#许可证":"本项目采用 AGPLv3 开源协议进行授权,衍生项目必须遵守相同的协议,必须开源。严禁将本主题进行二次售卖。在使用转载、移植等方式二次发布本主题时,需要保留本主题的版权说明,例如 “移植自奇趣保罗的 Typecho 主题:Single”。如未遵守本协议使用,作者将拥有追究的权利。原创不易!如果喜欢本项目,请 Star 以示对保罗的支持~ 同时欢迎前往 保罗的博客 提供赞助,谢谢您!"}},"/config":{"title":"配置索引","data":{"配置#配置":"Mog Core 将可以从以下两个地方获取配置信息以匹配你的不同需求并设置为你的 Mog 运行时环境。\n获取 YAML 的配置文件,优先级最高,默认读取当前目录下的 env.yaml 文件。\n命令行参数,优先级次之,有局限性,不建议使用","选项#选项":"当你使用传递命令行参数时,参数传递格式为 --=,例如 --db_port=8123:\n当你使用 YAML 配置文件时,配置文件格式为:","service_namekey#.":"类型:unknown\n默认值:undefined\n 为 Mog Core 的服务名称, 为服务的配置项。","key#":"类型:unknown\n默认值:undefined\n 为 Mog Core 的配置项。你可以通过后接 --help / -h 来查看有关配置项。","config#config":"类型:string\n默认值:/env.yaml\n别名: c\n配置文件路径。","collection_name#collection_name":"类型:string\n默认值:mog\n别名: N\n数据库集合名称。","db_host#db_host":"类型:string\n默认值:localhost\n别名: H\n数据库地址。","db_port#db_port":"类型:number\n默认值:27017\n别名: P\n数据库端口。","db_user#db_user":"类型:string | undefined\n默认值:undefined\n别名: U\n数据库用户名。","db_password#db_password":"类型:string | undefined\n默认值:undefined\n别名: W\n数据库密码。","redis_host#redis_host":"类型:string\n默认值:localhost\n别名: RH\nRedis 地址。","redis_port#redis_port":"类型:number\n默认值:6379\n别名: RP\nRedis 端口。","redis_password#redis_password":"类型:string | undefined\n默认值:undefined\n别名: RW\nRedis 密码。","redis_user#redis_user":"类型:string | undefined\n默认值:undefined\n别名: RU\nRedis 用户名。","jwt_secret#jwt_secret":"类型:string\n默认值: 无可奉告\nJWT 密钥。","jwt_expire#jwt_expire":"类型:number\n默认值:7d\nJWT 过期时间(天)。","consoleenable#console.enable":"类型:boolean\n默认值:false\n是否启用内置控制台。","consoleversiontype#console.versionType":"类型:string\n默认值:无默认\n版本类型,若需要使用非正式版本,则填入 pre-release,若需要正式版本,则任意填入一个字符串 或 不填写。","consolesource#console.source":"类型:string\n默认值:gh\n获取方式,可选择 gh 或 npm。gh 即 GitHub Release,npm 即 npmjs.com。事实上,并不建议使用 npm 方式,这似乎会导致 rate limit","consoleproxygh#console.proxy.gh":"类型:string | undefined\n默认值:无\nGitHub Release 的代理地址。\n我们没有提供支持 npm 是因为我们从 npm 获取文件使用的是官方的一个接口 https://www.npmjs.com/package/${name}/file/${fileId} ,而此接口似乎无镜像","corelisten_ip#core.listen_ip":"类型:string\n默认值:0.0.0.0\nMog Core 监听 IP","coreport#core.port":"类型:number\n默认值:2330\nMog Core 网关层启动的端口号","coreallow_origins#core.allow_origins":"类型:string[]\n默认值:['localhost:9528', 'localhost:2323', 'localhost:2222', '127.0.0.1', 'localhost:3000']\n允许跨域的域名列表, 不可以为 *,使用 , 进行分隔","配置举例#配置举例":"","传递命令行参数#传递命令行参数":"上述命令将会启动 Mog Core 网关层,端口号为 8080,允许跨域的域名列表为 ['localhost:9528', 'localhost:2323', 'localhost:2222'],用户服务部署的主机地址为 http://localhost:2331,用户服务部署的端口号为 2331,页面服务部署的主机地址为 http://localhost:2332,页面服务部署的端口号为 2332","yaml-配置文件#YAML 配置文件":"","其他#其他":""}},"/development/dev-mog":{"title":"启动 Mog 开发模式","data":{"1-从-github-上克隆下-mog-源码#1. 从 Github 上克隆下 Mog 源码":"","2-安装依赖#2. 安装依赖":"Mog 使用 pnpm 管理依赖,所以你必须要使用 pnpm 来安装依赖。","3-启动开发模式#3. 启动开发模式":"请注意,此项命令将有可能导致~~您的电脑彻底死机(CPU 100%)~~所以请确保您的电脑配置足够好,否则你可以使用下面的命令来启动开发模式:\n你可以在 package.json 中查看所有的命令。通过上面的命令,你可以启动指定的服务,而不是直接同时启动所有的服务,可以有效的减少电脑的负担。","4-打包#4. 打包":"目前还暂时无法只构建某个服务,所以你只能先一次性构建所有的服务,再使用 bundle 命令来打包。另外,如果你需要使用根目录的 ecosystem.config.js, 你必须要执行 bundle其他内容,我认为 Mog CONTRIBUTING 中已经写的很清楚了,所以我就不再赘述了。"}},"/development/extend-service":{"title":"拓展新的服务模块","data":{"":"文章来自 可愛い松 | NestJS 微服务通过订阅发布事件与其他技术栈交互, 但基于 Mog 做了部分补充\n此文章仅考虑的是 NestJS Gateway 场景下,对于其他情况暂时不做解释,按理来说应该你也能理解。此外,这篇文章使用的是 Redis 作为传输层,你需要知道基本操作才能来看此文章,并且此文章仅讲述交互原理。\n如果你想直接越过解释前往实践,可以直接看 使用 NodeJS 写一个微服务 这一节","创建一个微服务模块#创建一个微服务模块":"使用 nest g app tester NestJS CLI 将会自动帮你创建对应的模块,但是你需要自己修改部分内容,比如在 main.ts,你需要将 create 替换为 createMicroservice,还有其他的,但是需要注意的是,请将 transporter 设置为 REDIS\n接下来我们使用 redis-cli 来监控事件变化","使用微服务订阅事件#使用微服务订阅事件":"与 @nestjs/common 中不一样的 @Get(),你需要使用在 microservices 包内的 MessagePattern,以下是一个示范\n接下来,启动这个微服务,注意一下上方 redis-cli monitor 出现的日志\n看样子我们找到了一个开始订阅的事件,让我们记住这一个事件,继续下去。\n后续,我将使用 user.get.master 来代替 get.something 事件另外,这种事件命名方式并不是必须的,这只是我个人习惯","在网关层订阅事件#在网关层订阅事件":"你需要在网关层模块中导入一个 ClientModule:\n之后在 controller 构造函数中注入它,再任意搞一个请求:\n让我们继续启动网关层,redis-cli monitor 此时不会出现任何日志,这是正常的","当收到请求时事件发生了什么变化#当收到请求时,事件发生了什么变化":"我们访问一下网关层中配置的路径,注意一下 redis-cli monitor 出现的日志:\n这日志有点辣眼睛,而且这个是我们开了网关层 & 微服务出现的日志,我们暂时只想知道网关层,我们将上面的微服务关掉,再访问一次:\n我们精简一下,将无用的数据去掉,只留下我们想要的东西吧:\n可以看到网关层先订阅了一个基于之前我们定义的 user.get.master 的 reply 事件,之后,在 user.get.master 事件上发布了数据,就是将 pattern, data, id 发布了,十分重要的就是这个id,这是网关层中传输来的。对比一下,你就可以知道其中有一个特别长的日志就是由微服务发布的,可以发现微服务是向 reply 事件发布了事件,内容还包含了之前我们提到的 id,之后网关层收到了数据返回,接着返回来自微服务的数据,取消订阅对应的事件让我们用一个图来解释下吧:\n总结一下,其实就是这样的:","使用-nodejs-写一个微服务#使用 NodeJS 写一个微服务":"使用 pnpm 安装上 redis,根据上方我所说的内容,抽出来一些功能函数,以提高可维护性。因为 NestJS 文档 有说到两种模式,分别是 message 和 event,因此我们需要做一个判定和快捷生成对应的 pattern:\n我们分析一下信息的结构吧,很明显来自Gateway的信息带有3个key:pattern, data, id,其中 id 是自动生成的,也是返回响应时必要的;再分析一下NestJS Microservice 是怎么响应的,它的信息也带有3个key:response, isDispose, id,其中 isDispose 必须为 true,id 必须是来自 Gateway 的。\n所以剩下的就是创建 redis client 和发布/订阅事件了,需要注意的是,返回给 Gateway 的信息需要在事件后加上.reply,你在 monitor 上也能看到 Gateway 在发布事件的时候会同时订阅对应的reply事件:\n这样便是一个简单易启动的服务啦!使用 node^18 更可以使用其实验性功能:--watch 直接监听文件变化重载程序","在-mog-core-中注册事件#在 Mog Core 中注册事件":"在 Mog Core 中,我们需要在 Gateway 运行目录下创建一个 events.yaml 文件,它是用于注册非常规事件的,即非官方实现的事件,例如:user.login,user.register 等等。\n如上方例子,当请求 {API}/render/events 时,会触发 events.get 事件,由于 emit 为 true,因此 Gateway 会触发 events.get 事件,而不会开始监听 .reply 事件。但是下方的 events.get.id 事件,由于 emit 为 undefined,因此 Gateway 会同时监听 events.get.id 和 events.get.id.reply 事件,如果你的服务没有返回响应,那么 Gateway 会在 5 秒后返回一个超时的响应。","注意事项#注意事项":"注意的是:一个事件只能由一个服务受理,否则则会出现冲突情况。但是一个事件(Event-based)可以调度到多个方法\nYou can register multiple event handlers for a single event pattern and all of them will be automatically triggered in parallel. -- NestJS Documentaion\n因此,在编码的时候,不要与现有的服务监听的事件冲突,否则会出现不可预知的情况。"}},"/development/migrate-plugin":{"title":"开发第三方数据迁移插件","data":{"":"Mog 提供了一个数据迁移导入的接口,你可以通过这个接口来开发一个迁移插件,将你的数据迁移到 Mog。目前支持以下数据的迁移:\n文章 - posts\n页面 - pages\n评论 - comments\n分类 - categories\n用户信息 - user\n友链 - friends\n用户信息中没有导入密码的功能,在导入信息后,Mog\n将为您重新生成一个临时密码,您可以在控制台仪表盘中更改它","数据#数据":"","文章-post#文章 Post":"有几点是需要注意的:\nslug 字段必须是唯一的\ncategory 字段是填写已经存在的分类的 slug (需要在 categories 中存在),否则 Mog 会自动创建一个新的分类\ncreated 和 modified 字段必须是 ISO 8601 格式的时间字符串\nhide 一旦设置为 true,则文章将不会在文章列表接口和 RSS 中显示","页面-page#页面 Page":"","分类-category#分类 Category":"其中 slug 字段必须是唯一的,图标可以是一个 url(推荐),也可以是一个 base64 编码的图片","评论-comment#评论 Comment":"里面的 pid 字段是必须的,它将会被用来匹配文章,你需要在里面填写对应文章的 slug,如果文章不存在,那么这条评论将会被忽略\nid 字段必须是唯一的,它将会被用来匹配父级评论,如果父级评论不存在,那么这条评论将会被忽略","友链-friend#友链 Friend":"","用户-user#用户 User":"用户信息中没有导入密码的功能,在导入信息后,Mog 将为您重新生成一个临时密码,您可以在控制台仪表盘中更改它"}},"/development/theme":{"title":"开发新的主题","data":{"主题开发#主题开发":"创建主题时,需要在 package.json 中指定 name 字段、在 config.yml 中指定 id 字段和 language 字段,否则合法性检查会失败。示例主题可以在此处找到:mogland-dev/mog-theme-tiny-ejs\n按照主题目录结构创建主题目录。\n开始开发主题,其中需要有 EJS 的基础语法知识,主题渲染中提供了一些变量,可以在 EJS 中使用,具体变量见 变量。\n在 config.yml 中指定主题的配置,具体配置见 主题配置。\n开发完成后,将主题上传至 GitHub,然后标注 mog-theme 标签,等待 awesome-mog 更新完毕即可在主题市场中搜索到。\n正常情况下最多在 3 小时后,你的项目将能出现在 Awesome List 和 Mog 主题市场中","主题目录结构#主题目录结构":"packages.json: 主题的配置文件,类似于 npm 的 packages.json,用于描述主题的基本信息,如:主题名字、版本、作者、描述等\nconfig.yaml: 主题的配置文件,用于描述主题的配置项,如:头像源、评论系统等 - #主题配置\ni18n.yaml: 主题的国际化文件,用于描述主题的国际化信息 - #i18n-方案\nassets: 主题的静态资源文件,如:css、js、图片等 - #主题静态资源\nplugins: 主题的插件文件,用于注入方法到主题中,如:moment.js 等方法类库 - #主题模板扩展\nindex.ejs: 主页\npost.ejs: 文章页\npage.ejs: 页面页\narchives.ejs: 归档页,分类 & 标签页\nfriends.ejs: 友链页\n404.ejs: 404页\npage-*.ejs: 自定义页面,如:关于页 等, * 为自定义的页面路径\npreview.png: 主题预览图","主题配置#主题配置":"我们考虑使用 YAML 定义主题配置\nid: 主题的唯一标识,格式建议为 theme.{name}.{author}\nlanguage: 主题的语言,要与 i18n.yaml 中设置的语言匹配\nkey: 配置储存名(取值的时候使用此名)\nkey 是可选的,如果不去设置就与 name 是一样的。但是当 name 中涉及到一些特殊符号或者涉及中文字符的时候,强制需要填入 key\ntype: 配置组件\ndata: 传入配置组件的值(内部的定义与上方相似)\nvalue: 默认值,会传入配置组件,可选","配置组件#配置组件":"所有的 key 一般情况下除特殊要求,皆为可选字段,如果不设置 key 就与 name 一样。但是当 name 中涉及到一些特殊符号或者涉及中文字符的时候,强制需要填入 key。\ninput: 输入框\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,key 为可选字段,如果不设置 key 就与 name 一样。\nswitch: 开关\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,要求 value 为布尔值。\ncolor: 颜色选择器\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,要求 value 为颜色值。\nradio: 单选框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。\ncheckbox: 多选框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。\ntextarea: 多行文本框\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,key 为可选字段,如果不设置 key 就与 name 一样。\nselect: 下拉选择框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。","变量#变量":"","全局变量#全局变量":"","网站变量#网站变量":"","页面变量#页面变量":"页面(page): PageModel - 不会输出 password 等隐私字段文章 (post): PostModel - 不会输出 password 等隐私字段首页(index)\n分类 (category) :CategoryModel\n标签 (tag)\n归档 (archives)\n友链 (friends) :FriendsModel","url变量#URL变量":"","i18n-方案#i18n 方案":"我们可以使用内置函数 _i() ,这个函数可以根据传入的 key 来获取对应的 value。","定义-i18n-key#定义 i18n key":"我们使用 yaml 文件来定义 i18n,在主题根目录创建 i18n.yaml,并定义 key。\n按照上面的定义,我们可以通过 _i('hello') 来获取对应的 value。当无法找到对应的 key 时,会返回 key 本身。","主题模板扩展#主题模板扩展":"如果你想在主题模板中使用函数输出某些东西,你可以通过「扩展」来实现这个功能。在 plugins 文件夹下创建一个 js 文件,然后在该文件中使用 module.exports 导出一个对象,对象中包含一个 name 属性,用于定义插件名称,以及其他函数,用于在主题模板中调用。","定义主题模板扩展插件#定义主题模板扩展插件":"我们将会遍历 plugins 文件夹下的所有文件,将其作为主题模板扩展插件,将其挂载到主题模板中。比如说,我们创建一个 time.js 文件,用于输出当前时间。\n在主题模板中,我们可以通过 time() 来调用 time.js 中定义的 time 函数。\n在函数内,你依然可以使用 变量 中定义的变量。","例子在头部输出-opengrraph-标签#例子:在头部输出 OpenGrraph 标签":"在主题模板中,我们可以通过 opengraph() 来调用 opengraph.js 中定义的 opengraph 函数。","主题静态资源#主题静态资源":"如果你想在主题中使用静态资源,你可以将静态资源放在 assets 文件夹下,然后在主题模板中请求 /raw/assets/* 来获取静态资源。\n需要注意的是,以下文件可以直接访问,无需通过 /raw/* 来访问:\nassets/favicon.*\nassets/robots.txt\n./favicon.*\n./robots.txt\n也就是说,如果你想要获取 ejs 等源文件,你可以通过 /raw/* 来获取:","主题评论组件#主题评论组件":"以 mog-comments-wc 为例,我们可以使用它在主题中实现评论功能。","本地引入#本地引入":"从 Release 页面下载最新的 mog-comments-wc.js 文件,放到 assets/js 文件夹下。\n在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","cdn-引入#CDN 引入":"在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。"}},"/development/using-comments":{"title":"在其他地方使用评论组件","data":{"":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。多亏于 Mog 评论服务的设计,它可以在任何地方使用,只要你能够在你的网站上嵌入一个 HTML 组件即可。","变量解释#变量解释":"一般情况下,在生产环境中,API 地址被设计为 [protocol]://[domain]/api,例如 https://api.mog.land/api。在开发环境中,API 地址被设计为 [protocol]://[domain].\napi:API 的地址,例如 https://api.mog.land/api。\npid:页面的唯一 ID,例如 https://mog.land/developer/using-comments 的 ID 就可以是 developer/using-comments。在 Mog 中,你可以使用 文章的 Object ID 作为页面的唯一 ID。","启动服务#启动服务":"如果你仅需要使用评论服务,你大可以只启动以下服务:\ncore - 必要网关层 - 用于转发请求到其他服务\nuser-service - 用户服务模块 - 用于处理评论相关信息\ncomment-service - 评论服务模块 - 你实际需要的服务","在你的网站上使用#在你的网站上使用":"","本地引入#本地引入":"从 Release 页面下载最新的 mog-comments-wc.js 文件,放到 assets/js 文件夹下。\n在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","cdn-引入#CDN 引入":"在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","qa#Q&A":"","如果我在两个不同的系统中同时使用了评论组件会导致冲突吗#如果我在两个不同的系统中同时使用了评论组件,会导致冲突吗?":"有两种情况:\n如果你使用的是 Mog 和其他系统,那么不会有任何问题,Mog 在存入评论时并非仅使用 pid 作为唯一标识,其他系统仅使用 pid 作为唯一标识的。在后台的显示中,这两个系统的评论都会被分开显示,不会有任何冲突。\n如果你都不是使用 Mog,那么将会导致两个系统的评论混在一起,这是不被推荐的。"}},"/docs/build":{"title":"自主构建","data":{"":"如果你想要自定义构建过程,或者你想要在不同的平台上运行,那么你需要自主构建。我们在 「快速起步」 章节提供的是 Linux + macOS x86 平台的构建包。","直接构建服务#直接构建服务":"克隆官方远程 git 仓库\n使用 pnpm 安装项目依赖(依赖 pnpm 8.x 以上版本)\n使用 NestJS CLI 命令构建你需要的服务\n目前支持的 service-name 可在 目前支持的服务 中看到使用 node 命令启动你已构建完成的服务","目前支持的服务#目前支持的服务":"目前支持的 service-name 有:\ncore - 必要网关层 - 必须构建\nuser-service - 用户服务模块 - 必须构建\npage-service - 文章页面分类服务模块\ncomments-service - 评论服务模块\nfriends-service - 友情链接服务模块\nnotification-service - 通知服务模块\nthemes-service - 主题服务模块","拓展使用-vercelncc-重新打包#拓展:使用 @vercel/ncc 重新打包":"@vercel/ncc 是一个可以将 Node.js 项目打包成一个单文件的工具,让你可以在不安装项目依赖(node_modules)的情况下运行项目。core 中已经写好了相关构建命令,你可以直接使用,但前提是你需要先构建了服务。\n构建完成后,你可以在 out/ 目录下找到打包后的文件夹。请注意,请勿修改打包后的文件夹内的任何文件,否则可能会导致服务无法正常运行。接下来使用 node 命令启动你已构建完成的服务\n关于组件启动时的自定义配置,请前往「配置索引」章节\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose"}},"/docs/features":{"title":"主要功能","data":{"主题系统#主题系统":"除了使用 API 构建前端,Mog 还通过内置主题系统来实现多样化的博客样式。基于模板引擎,用户可以更便捷地制作主题。了解如何开发主题 主题开发","拓展系统#拓展系统":"Mog 通过拓展系统来扩展主题原有功能,这样可以让用户自定义部分功能。如自动生成目录、自定义文章样式等。了解拓展如何与主题配合 主题开发 #主题模板扩展","可扩展服务#可扩展服务":"Mog 采用了微服务架构,通过注册自定义活动,可以方便地扩展非官方实现服务。可以说这也是一种插件系统(吧?)了解更多有关扩展服务的信息 服务开发","评论系统#评论系统":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。得亏于 Mog 评论服务的设计,它可以在任何地方使用(甚至可以不使用 Mog 的前端),只要你能够在你的网站上嵌入一个 HTML 组件即可。了解更多有关评论系统的信息 评论系统","弹性部署#弹性部署":"Mog 采用了微服务架构,每个服务都可以独立部署,这样可以方便地进行扩容和缩容。同时,Mog 也支持多节点部署,这样可以保证服务的高可用性。通过使用如 Kubernetes 这样的容器编排工具,可以方便地进行部署和管理。了解更多信息 弹性部署","异步处理#异步处理":"得益于 Nodejs 的支持,Mog 会将一些没有必要的任务放到异步线程中执行,这样可以避免主线程被阻塞,从而提高性能。在处理大量数据时,将会使用多线程来加速处理速度。Mog 还隔离了一切与用户交互的操作,这样可以保证主线程的稳定性,避免因为用户操作而导致的崩溃。","备份快照#备份快照":"Mog 会自动备份所有的数据,包括用户数据、配置文件等。这样即使在意外情况下,也可以通过备份文件恢复数据。同时支持手动备份和恢复,以及自动备份上传到云端。了解更多信息 备份快照"}},"/docs/custom-setting":{"title":"自定义配置 Mog Core","data":{"":"此功能与原本规划的具有一定区别,请注意文档的改变。\nMog 的主要优势之一是它可以弹性组装服务。只要你的条件允许,你可以将服务部署至不同的终端中,但一般你只需部署到同一个终端上即可。但是当你需要配置网关连接服务的IP时(也就是当你将服务部署到了不同的终端时)你需要对 Core 进行配置所以一般来说,如果你只部署到了同一个终端上,以下的内容你是不需要了解且填写的,配置的内容越多,越容易出问题。","启动命令的改变#启动命令的改变":"我们提到「使用 NestJS CLI 命令启动你已构建完成的服务」使用的命令为\n当我们需要在启动 Mog 进行配置的时候,则需要命令之后在后方携带 --= 格式的参数启动","配置-core#配置 Core":"当你将服务部署到了不同的终端时,你需要对 Mog Core 的网关层进行配置。目前支持配置的字段可以查阅 配置索引我们同样支持 YAML 格式的配置文件,你可以在启动的文件夹下创建 core.yml 文件,然后将配置写入其中\n建议无论如何都携带YAML配置文件,若不进行配置则会自动获取当前执行目录下的 env.yaml 文件。若没有则会使用默认配置。命令行允许输入的参数有限,所以我们建议使用 YAML 格式的配置文件。有关允许命令行输入的参数可以查阅 配置索引"}},"/docs":{"title":"快速起步","data":{"总览#总览":"Mog 是一个易于扩展的现代博客系统。它突破地采用了微服务架构,在结构设计是模块化、灵活的。 您可以轻松地将其自定义以满足您的需求。 更可以通过接口来开发自己的前/中后台,也可以通过插件来开发自己的功能。你可以在 为什么选择 Mog? 中了解有关此项目背后的想法。","在线试用-mog#在线试用 Mog":"你 暂时还不可以在线尝试 Mog。它是 Mog 的后台系统 Demo,你可以在这里体验 Mog 的后台系统,当然,它自然是受到一定的限制的。","将-mog-core-安装到服务器#将 Mog Core 安装到服务器":"Mog 仅推荐在 Linux 和 macOS 系统上使用,Windows 系统上的使用可能会出现一些问题。如果你对 Docker, Docker Compose, NodeJS, npm-script, git 等技术不熟悉,建议先学习相关知识。文档中不会对这些技术进行详细介绍,且若由于不熟悉这些技术导致的问题,我们将不会提供技术支持。\n在 最新的 Release 中找到 Assets,下载你所需要的构建包版本,目前我们提供:\nmacOS x86\nLinux x86\n如果其中没有符合你需要的版本,请前往「自主构建」章节下载后,解压压缩包,你将会获得一个文件夹,请不要修改文件夹内的任何一件东西,打开终端,使用 cd 命令进入此文件夹后,分别输入以下命令启动组件:\n目前支持的组件,请前往「自主构建」章节,我们在那里给出了具体的组件名称关于组件启动时的自定义配置,请前往「配置索引」章节\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose","社区#社区":"如果你有疑问或者需要帮助,可以到 GitHub Discussions 社区来寻求帮助。"}},"/docs/migrate/backup":{"title":"备份与回滚","data":{"":"Mog 支持导出当前的配置,以及导入配置到当前的配置。在导出配置时,Mog 会将当前的配置导出为一个 JSON 文件,该文件包含了所有的配置信息,包括:\n文章 - posts\n页面 - pages\n评论 - comments\n分类 - categories\n用户信息 - user\n友链 - friends\n在导入配置时,Mog 会将导入的配置与当前的配置进行合并\n如果导入的配置中包含了当前配置中不存在的配置项,则会将其添加到当前配置中\n如果导入的配置中包含了当前配置中已存在的配置项,则会将其覆盖。","导出备份#导出备份":"为了保证数据的安全,Mog 不会将用户的密码导出到备份文件中。在全新导入用户时,Mog 会自动生成一个随机密码,您可以在导入完成后,通过 用户 页面,修改用户的密码。\n在 Mog 的 备份 页面,点击 导出备份 按钮,即可将当前的全部数据导出为一个 JSON 文件。\n在弹出的对话框中,点击 下载 按钮,即可下载该 JSON 文件。","导入备份#导入备份":"在 Mog 的 备份 页面,点击 导入备份 按钮\n在弹出的对话框中,点击 选择文件 按钮,选择需要导入的 JSON 文件。"}},"/docs/migrate/from-third-party":{"title":"从其他博客系统迁移","data":{"使用-markdown-迁移#使用 Markdown 迁移":"你的 Markdown 文件必须要携带 YAML Front Matter,并且最好是符合\nCommonMark 规范的,否则可能会出现一些问题。\n如果你的博客系统支持 Markdown,那么你可以直接将你的博客内容导出为 Markdown 文件,然后在 Mog 后台的迁移页面,导入这些 Markdown 文件。","从-typecho-迁移#从 Typecho 迁移":"下载 Typecho 数据导出插件 Typecho-Plugin-MogRun 插件,根据 READNE 介绍安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-wordpress-迁移#从 WordPress 迁移":"下载 WordPress 数据导出插件 MogRun-WordPress WIP 插件,安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-ghost-迁移#从 Ghost 迁移":"下载 Ghost 数据导出插件 MogRun-Ghost WIP 插件,安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-hexo-迁移#从 Hexo 迁移":"因为 Hexo 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Hexo 的博客文件导入到 Mog 中。\n打包 Hexo 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","从-jekyll-迁移#从 Jekyll 迁移":"因为 Jekyll 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Jekyll 的博客文件导入到 Mog 中。\n打包 Jekyll 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","从-hugo-迁移#从 Hugo 迁移":"因为 Hugo 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Hugo 的博客文件导入到 Mog 中。\n打包 Hugo 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","其他博客系统#其他博客系统":"如果你的博客系统不在上面的列表中,那么你可以尝试将其导出为 Markdown 文件,然后在 Mog 后台的迁移页面,导入这些 Markdown 文件。或者根据你的博客系统的数据格式,开发一个数据导出插件,然后在 Mog 后台的迁移页面,导入这些数据文件。"}},"/docs/migrate/upgrade":{"title":"升级版本","data":{"从-mog-v2internalalpha-升级到-mog-v2internalbeta0#从 Mog v2.internal.alpha 升级到 Mog v2.internal.beta.0":"v2.internal.beta 对服务进行了补充以及重要的破坏性修改。主要针对的是配置文件配置项的改动:\nx-service 将不再支持 port, host 配置项,全部服务将使用 redis 作为事件总线,默认情况下,只需要删除对应的配置项即可,若无配置可无视此项\nCore 内置基本模块在现有阶段暂时全部移除,在后续可能会继续引入,这取决于社区基本模块的需求量","从-mog-v1-升级到-mog-v2#从 Mog v1 升级到 Mog v2":"v1 至 v2 的技术栈改动不大,但是很重要,大部分沿用的是 v1 的技术栈,但是 v2 对数据模型和程序结构有一些重大的改动,其中有部分是修复了 v1 的一些设计缺陷导致的严重问题。你可以通过以下方式升级到 v2:\n前往 Console,前往「导入与备份」页面,点击「导出 MnogoDB 数据」,下载数据备份文件,再点击「导出 Markdown 数据」,下载 Markdown 数据备份文件\n前往命令行,使用 MongoDB 的 mongodump 命令导出数据备份文件\n导出的数据备份文件需要保证在导入之前不要被修改,否则可能会导致数据丢失直接使用 mongodump 导出的数据备份文件可能在 v2 导入时会无法使用,需要使用 mongorestore 命令进行转换,或只使用 Markdown 数据备份文件进行导入","从-mog-v0-升级到-mog-v1#从 Mog v0 升级到 Mog v1":"问题是这样的,v0 我们使用的是 MySQL 作为数据库,而 v1 我们使用的是 MongoDB,其中使用了很多 MongoDB 的特性,因此无法直接升级。目前只有一个可行的方案:\n将 v0 的文章页面数据导出,然后导入到 v1 中,v0 和 v1 在处理文章页面数据的方式是一致的,因此可以直接导入。\n由于 v0 是 Beta 版本,充满了不确定性,因此我们无法保证导出的数据能够完全正确导入到 v1 中,因此我们建议你在导入之前先备份好 v1 的数据库。"}},"/docs/usages/console":{"title":"使用内置控制台","data":{"":"我们在 mogland/core #604 中添加了一个内置控制台的功能,这个功能可以让你在不另外部署控制台的情况下,控制你的服务。","基础使用#基础使用":"由于此项功能仍处于测试阶段,因此我们默认暂时设置为关闭状态,你可以在你的启动配置文件中中设置 console.enable 为 true 来启用此功能。\n我们还提供了其他一些配置项,如 console.versionType,你可以在 配置 中查看更多信息。接下来,访问 /console,你将会进入到控制台:\n如果你还未注册,控制台将会自动跳转至注册页面。若你已经注册且已登录,但仍然无法访问控制台主页,请检查你的服务是否出现了问题。"}},"/docs/why":{"title":"为什么选择 Mog?","data":{"mog-是怎么样的#Mog 是怎么样的?":"Mog 默认推荐你使用的是前后端分离架构。这样可以给开发的人提供便捷,也避免了和其他领域的人做不太必要的争吵。专业的事情交给专业的人去做。它具有高度的开发自由度,您可以通过接口来开发自己的前/中后台,也可以通过插件来开发自己的功能。除此之外,多亏视图引擎,Mog 在 v0.x 引入了 「模板引擎」 功能,如优秀的 Hexo 等,使用 ejs 即可简单开发,局限性还是有的,毕竟是在后端处理,在变量提供方面我会尽量按照 Hexo 规范,但是并不能保证完全相同。在 v1 版本中,使用了 Fastify 作为底层,这并不妨碍使用视图引擎,Fastify 可以自动解析视图引擎,而且它的视图引擎支持多种类型的视图,比如 ejs、pug、handlebars 等。但是相关的变量还正在讨论中,暂时未上线。v2 版本中,我们颠覆从前的架构,选择了微服务架构,拓展了原有应用的功能。Mog 旨在探索一种新的博客系统架构,它的目标是提供一个高度自由度的博客系统,探索项目的最佳实践。继续阅读 快速起步","历史#历史":"v0.x:MySQL + Express, 此为第一个版本,但是由于一些原因,我并没有继续开发下去。\nv1.x:MongoDB + Fastify, 此为第二个版本,但是由于其中的大部分代码以及结构与 Mix Space 极度相似,我打算走一条新的路线。\nv2.x:MongoDB + Fastify + Microservices, 此为第三个版本,我们将会在这个版本中,探索一种新的博客系统架构。"}},"/docs/with-node":{"title":"使用 node 命令启动","data":{"":"除了使用 Docker,你还可以直接使用 Node 命令启动 Mog\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose\n在 最新的 Release 中找到 Assets,下载你所需要的构建包版本,目前我们提供:\nmacOS x86\nLinux x86\n如果其中没有符合你需要的版本,请前往「自主构建」章节下载后,解压压缩包,你将会获得一个文件夹,请不要修改文件夹内的任何一件东西,打开终端,使用 cd 命令进入此文件夹后,分别输入以下命令启动组件:\n目前支持的组件,请前往「自主构建」章节,我们在那里给出了具体的组件名称关于组件启动时的自定义配置,请前往「配置索引」章节"}},"/":{"title":"Mog - The Flexible Modular Blog System","data":{"":"Create your own unique site with Mog.\n模块化,弹性化、强大的博客系统。 开源,永久免费。\n5 分钟拥有自己的 Mog →\n几分钟内创建强大的博客网站。\n所有功能都是弹性的.\nMog 突破性采用微服务架构,模块化和弹性化设计,使您的博客更加稳定、可扩展和可维护。\n您可以轻松地定制它以满足您的个人自定义需求,更可以通过主题和活动系统轻松地扩展 Mog。\n黑暗模式 原生适配.\n先进的文本语言渲染解决方案。\n高性能、可靠、可扩展的文本宏函数和标记语言设置。在渲染过程中,Mog 会将大量的文本预处理工作交给后端服务,从而减轻前端的负担。\n更多特性...\n可插拔主题 / 备份系统 / 独立的评论系统... 更多新特性等待您的探索。\n拥有你自己的 Mog →"}}}
\ No newline at end of file
+{"/about/faq":{"title":"常见问题","data":{"谁在维护-mog#谁在维护 Mog?":"Mog 是一个独立的社区驱动的项目。它是由 Wibus 在 2021 年作为其个人项目创建的,原身为 Golden Space / NEXT Space,极大的受到了 Mix Space 的影响。如今,Mog 由来自于全国各地的志愿者们维护。自 2021 年以来,Mog 的发展主要是通过爱 ❤️ 和热情来驱动的。如果您觉得 Mog 不错的话,请考虑赞助我们,以支持 Mog 的发展!\n赞助事项请发送邮件至 wibus@qq.com。","mog-v1-和-mog-v2-之间的区别是什么#Mog v1 和 Mog v2 之间的区别是什么?":"从 NEXT 到 Mog 是一个比较惨痛的过程,已经有一部分人知道此项目了,他们通常称之为 \"nx\",现在修改这个名字对宣传来说并不是一件好事,但为了以后的发展我们必须这样做。新的名字由两个单词组成:Module + Blog = Mog,这和我们在 v2 版本的构思有关。我们在 v2 突破地采用了微服务架构,对于不同的服务分离,我们仍在探索当中,相信出版的时候可以寻找到一个较好的方案。","1x-存在的严重问题#1.x 存在的严重问题":"1.x 版本由于更新仓促,导致了很多的问题,比如:\nAPI RESTFul 规范\nDTO 与 Model 不匹配,导致输出存在问题\n接口方法书写混乱\n注释不规范\n很难继续向上堆积功能,原架构会导致功能臃肿\n为了长久的发展,我们发布了最后的 v1.7.0,并立即开始了 v2 的重构","v2-新增的特性有#v2 新增的特性有:":"2.x 版本将会内置后台,无需额外部署,也不应额外部署,这会增加更多的在意料之外的维护成本\n2.x 使用微服务架构,扩展性对比单一服务高了很多,且一个微服务的异常不会导致其它微服务同时异常,增强稳定性\n评论模块、邮件模块、友链模块、渲染模块将会独立为一个单独服务\n我们对文档进行了重写,重新使用了 Vitepress,并且参照了许多优秀的开源项目编写相关文档\n评论模块将会考虑与其他博客系统相兼容,并且提供独立的控制台\n邮件模块将会寓于交流模块之内,交流模块将会负责一切与交流相关的功能\n友链模块我们会考虑将其可以作为一个独立的友链页面,并且支持主题定制\n渲染模块我们会提供一个 Tiny markdown Server,推动更多的自定义语法渲染处理","mog-使用什么开源协议#Mog 使用什么开源协议?":"Mog 是完全免费的开源项目,且基于 AGPLv3 License 发布。","mog-可靠吗#Mog 可靠吗?":"Mog 是一个完全开源的项目,我们不会收集任何用户的数据,也不会做任何不可逆的操作,我们会尽可能的保证用户的数据安全。如果您觉得代码中存在安全问题,欢迎您根据安全策略反馈于我们团队,我们会尽快修复。","mog-功能健壮吗#Mog 功能健壮吗?":"Mog 的目标是提供一个可靠、健全的博客系统,我们会尽可能的保证功能的健壮性,但是我们也不会过度的追求功能的完善,我们会在功能的完善与稳定性之间进行权衡。我们会将很多的功能进行拆分,使得 Mog 可以更加的灵活,比如评论模块、邮件模块、友链模块、渲染模块等等,这些模块都可以独立的使用,也可以与 Mog 一起使用。这样一来,既可以向上堆积功能,也可以向下拆分功能,使得 Mog 更加的灵活。","mog-体积小吗#Mog 体积小吗?":"很不幸,全套 Mog 的体积并不小,因为我们使用了很多的依赖,构建了很多服务,这导致功能越多,体积越大。我们只能尽最大可能减小体积,当然,我们会保证体积的稳定性,不会出现突然增大的情况。","mog-能胜任大规模场景吗#Mog 能胜任大规模场景吗?":"目前表现效果或许还不是很理想,Mog 的计划之一就是能够胜任大规模场景,不断挑战极限使用场景,优化相关代码,使得 Mog 能够胜任大规模场景。","我可以为-mog-做贡献吗#我可以为 Mog 做贡献吗?":"当然,欢迎你阅读 贡献指南 为 Mog 做出贡献。","图标设计#图标设计":"v0 版图标 - By wibus-wee.\nv1 版图标 - By wibus-wee.\nv2 版图标 :\nIcon: By Jinhwan Kim.\nFont name: GlacialIndifference-Regular\nFont link: https://hanken.co/product/hk-grotesk/\nFont author: Hanken Design Co.\nFont author site: https://hanken.co/"}},"/about/release":{"title":"版本发布","data":{"":"当前 Mog 的最新稳定版本是 。完整的过往发布记录可以在 GitHub 查阅。","发布周期#发布周期":"Mog 并没有固定的发布周期。\n补丁版本 (patch releases) 发布会及时按需进行。\n小版本 (minor releases) 发布总是会包含一些新特性,发布周期并不确定,并会经历 beta 预发布阶段。\n大版本 (major releases) 发布会提前知会,且经历早期讨论和 alpha、beta 等预发布阶段。","语义化版本控制的特殊情况#语义化版本控制的特殊情况":"Mog 的发布会遵循语义化版本控制,同时伴随一些特殊情况。","编译后的代码和旧版运行时之间的兼容性#编译后的代码和旧版运行时之间的兼容性":"较新小版本的 Mog 编译器可能会生成与较旧小版本的 Mog 运行时不兼容的代码。例如,由 Mog v2.1 生成的代码可能不完全兼容 Mog v.2.2 的运行时。","预发布版本#预发布版本":"小版本发布通常会经历不定量的 beta 版。而大版本发布则会经历 alpha 和 beta 阶段。预发布版本 (pre releases) 是为了进行集成/稳定性测试,并让早期用户为不稳定的功能提供反馈。请不要在生产中使用预发布版本。所有的预发布版本都被认为是不稳定的,并且可能会在两者之间产生不兼容变更,所以在使用预发布版本时,一定要精确锁定版本号。","废弃的特性#废弃的特性":"我们可能会定期废弃那些在新的小版本中拥有更新更好的替代品的功能。被废弃的功能仍将继续工作,但会在进入废弃状态后的下一个大版本中被删除。","rfc#RFC":"具有可观表层 API 的新特性和 Mog 的重大变更都将经历意见征集 (RFC) 流程。RFC 流程的目的是为新功能进入该框架提供一个一致且可控的路径,并给用户一个机会参与设计过程并提供反馈。该 RFC 流程会在 GitHub 上的 mogland/rfcs 仓库进行。","试验性特性#试验性特性":"有些特性在 Mog 的稳定版本中已经发布并被记录了,但被标记为试验性的。试验性特性通常与某些 RFC 讨论相关联,这些讨论中的大部分设计问题已经在理论上得到了解决,但仍缺乏来自真实实践的反馈。试验性特性的目的是允许用户通过在生产环境中测试它们来提供反馈,而不必使用不稳定的 Mog 版本。试验性特性本身是被认为不稳定的,只能以某种受控的方式使用,且该特性可预期地会在任何发布类型中发生变化。此页面参考自 Vue.js 的 版本发布 页面。"}},"/blog/core-updated-to-v1.7.0-alpha.0":{"title":"Mog 1.7.0-alpha.0 (Continuation) 预发布","data":{"":"好久不见!距离我们宣布 Core 正式可用已经有一个月了,这期间我们做出了不少的优化、修补,以及功能更新,让我来给你慢慢列举一些较为重要的更改:","-breaking-changes#🚨 Breaking Changes":"备份模块:\n支持使用 JSON 恢复部分服务数据- by Wibus\n主题模块:\nEJS 模板引擎解析器支持 - by Wibus (b0e57)\n支持从 GitHub 或 自定义地址下载主题 - by Wibus (2622d)","最为重要的-feature----主题模块#最为重要的 Feature -- 主题模块":"这个模块曾经出现于 Core v0.x 版本中,但重构后的版本都并没有怎么提及此功能,今天归来纯属希望可以更加方便地来编写前端主题。目前模块已初步成型,相关模块接口已经公开,但是依然存在有且已知的问题:\n传递数据似乎不足,或对开发对应页面并不适用\n反向代理后,样式等文件无法正常获取\n对辅助函数支持不足(因为有很多函数支持都仅适用于 Express 平台)现在仅支持 moment 方法\n相关数据字段尚未完全确定,具体情况等待第一个 Demo 发版后再作商讨","-bug-fixes#🐞 Bug Fixes":"评论模块:\n模型 与 Dto 的属性不匹配 - by wibus-wee (f1e7d)\n从暴露的全部字段检索垃圾评论 - by wibus-wee (e139e)","-performance#🏎 Performance":"聚合模块:\n对查找最新文章的服务返回 新增 text 字段 - by wibus-wee (24e2d)\nGitHub Release Page:https://github.com/mogland/core/releases"}},"/blog/mog-core-v1.5.1-release":{"title":"Mog 1.5.1 (Evolution) 发布 - 重构后的新起点","data":{"":"感谢 @MYXXTS @origami-tech @Truimo 等大佬的鼎力相助经过1年的摸索与将近1个月的从零重构,我们发版了新的 Mog Core 版本,这将是一个全新的起点。","新特性#新特性":"新的数据库驱动 MongoDB:MongoDB 是一个 NoSQL 数据库,它提供了一种非常简单的方式来存储和查询数据,而且它的性能非常高。\n新的缓存机制 Redis:Redis 是一个高性能的内存数据库,作为一个缓存,它可以提供高速的查询和存储,目前 Mog Core 使用于配置获取中\n新的插件系统,插件系统是一个非常特别的框架,它可以让你在空间中添加新的功能,比如 WebHook, Macros, 可以让你的空间更加灵活,更加强大。\n新的插件系统尚未稳定,仅完成了基本的插件注册,激活,应用插件\n全新的文章备份模块:文章备份可以让你将文章备份到本地,以备以后使用,同时支持导入/迁移\n改进后的文章备份,将遵循以下逻辑:\n单篇文章直接输出\n多篇文章打包输出\n改进后的数据库备份模块:将全部 Mog 数据保存至本地,数据比文章备份模块更加全面\n在文章或页面中自动记录图片相关元数据:比如图片的宽高、图片的类型、图片的 URL 等等,但也需要前端支持,这样可以让你的文章更加美观\n提供了更多的文章管理选项:比如文章的标签,文章的分类,文章的显示/隐藏,文章的发布时间,等等\n支持标签或分类合并:将多个分类或标签中的文章合并如一个分类或标签\n使用了装饰器来验证密钥以使用高阶操作\n全新的跨平台 Cookie 解析装饰器:支持多种浏览器,比如 Chrome、Firefox、Safari、IE、Edge 等等","如何迁移#如何迁移?":"v0 我们使用的是 MySQL 作为数据库,而 v1 我们使用的是 MongoDB,其中使用了很多 MongoDB 的特性,因此无法直接升级。目前只有一个可行的方案:\n将 v0 的文章页面数据导出,然后导入到 v1 中,v0 和 v1 在处理文章页面数据的方式是一致的,因此可以直接导入。\n由于 v0 是 Beta 版本,充满了不确定性,因此我们无法保证导出的数据能够完全正确导入到 v1 中,因此我们建议你在导入之前先备份好 v1 的数据库。"}},"/blog/mog-is-now-available":{"title":"Mog 1.6.0 (GoLive) 发布 - 从新起点开始","data":{"":"在不断持续开发了将近一年的Mog,我们收到了大量的评论,并且支持Mog的开发。非常感谢各位的支持!今天,随着 Mog 第一款官方前端主题 Tiny 成功发布,Mog已经可以真正部署使用了!感谢全部成员的贡献,以及大家的支持!","正式部署可用版本#正式部署可用版本":"Mog Core: v1.6.0\nMog Admin: v0.2.1\nMog Theme Tiny: v0.1.2\n立即阅读文档部署!\nMog Core 1.5.3 至 1.6.0 之间内容修改较多,期间包括了 漏洞修复、新增功能、逻辑优化。","preview#Preview":"[Mog Admin]\t[Mog Theme Tiny]"}},"/blog/mog-v2-refactor-1":{"title":"Mog 2.0 (Odyssey) 开始重构 - Stage 1 Issue","data":{"":"从 NEXT 到 Mog 是一个比较惨痛的过程,已经有一部分人知道此项目了,他们通常称之为 \"nx\",现在修改这个名字对宣传来说并不是一件好事,但为了以后的发展我们必须这样做。新的名字由两个单词组成:Module + Blog = Mog,这和我们在 v2 版本的构思有关。我们在 v2 突破地采用了微服务架构,对于不同的服务分离,我们仍在探索当中,相信出版的时候可以寻找到一个较好的方案。","为什么突然要重构#为什么突然要重构?":"1.x 版本由于更新仓促,导致了很多的问题,比如:\nAPI RESTFul 规范\nDTO 与 Model 不匹配,导致输出存在问题\n接口方法书写混乱\n注释不规范\n很难继续向上堆积功能,原架构会导致功能臃肿\n为了长久的发展,我们发布了最后的 v1.7.0,并立即开始了 v2 的重构","这次更新有什么新功能或者优势#这次更新有什么新功能或者优势?":"2.x 版本将会内置后台,无需额外部署,也不应额外部署,这会增加更多的在意料之外的维护成本\n2.x 使用微服务架构,扩展性对比单一服务高了很多,且一个微服务的异常不会导致其它微服务同时异常,增强稳定性\n评论模块、邮件模块、友链模块、渲染模块将会独立为一个单独服务\n我们对文档进行了重写,重新使用了 Vitepress,并且参照了许多优秀的开源项目编写相关文档\n评论模块将会考虑与其他博客系统相兼容,并且提供独立的控制台\n邮件模块将会寓于交流模块之内,交流模块将会负责一切与交流相关的功能\n友链模块我们会考虑将其可以作为一个独立的友链页面,并且支持主题定制\n渲染模块我们会提供一个 Tiny markdown Server,推动更多的自定义语法渲染处理","这次更新的问题是什么#这次更新的问题是什么?":"1.x --> 2.x 预计会出现较多接口不兼容的情况,因此除核心外的生态需要全部重写\n由于 2.x 使用微服务架构,因此文档部署需要全部重写,建议全部重新开始.\n该版本的制作时间会大大增长,有可能需要到下一个假期才可基本完成.\n此次的重构代号为:Odyssey."}},"/blog/mog-v2-refactor-2":{"title":"Mog Odyssey 2.0 重构基础服务 - Stage 2 Issue","data":{"":"第一阶段,我们居多是进行路径规划,后续阶段,我们会加紧进行基础服务的重构,在完成所有基础服务的时候我们将会发布一次 Alpha 文档。我们目前已完成重构的基础服务有:\n数据库模块 (mogland/core#309)\n授权模块 ( mogland/core#309 )\n配置模块 ( mogland/core#336 )\n用户服务模块 ( mogland/core#348 )\n文库模块 ( mogland/core#363 )\n数据聚合模块 ( mogland/core#396 )\n余下的服务模块我们将会在下一阶段继续加紧重构,在此之前,我们需要对某些模块撰写 RFC。","距离-20-还有多远#距离 2.0 还有多远?":"很接近,但也很遥远\n我们已经在全力开发,但是我们还需要一些时间来完成,我们将会在 2022 春节前完成 v2.0 的开发,但是我们不会在这个时间点发布,我们将会在 2022 春节后发布 v2.0,我们将会在发布前进行一些测试,以确保 v2.0 的稳定性。我们目前遇到的困难包括且不限于:人手不足、架构考虑、规划不足我们真的很希望有更多的人能够加入我们。"}},"/blog/mog-v2-refactor-3":{"title":"Mog Odyssey 2.0 重构生态服务 - Stage 3 Issue","data":{"核心所有服务已成功重写#核心所有服务已成功重写":"如果你有关注我们的开发进度,你能发现我们已经将所有的服务都重写完成了。至此,Mog v2 的核心部分已经基本完成,目前我们正在进行一些发布前的测试以及部分模块中的功能补充与优化。此次新增的模块有:\n分类 / 标签 + 文章 / 页面的服务模块 ( PR in mogland/core#363 )\n基本评论模块 ( PR in mogland/core#404, 于 mogland/core#558 已移除)\n评论服务模块 (PR in mogland/core#558 )\n数据聚合模块 ( PR in mogland/core#396 )\n友链服务模块 ( PR in mogland/core#565)\n基本友链模块 ( PR in mogland/core#511,于 mogland/core#565 已移除)\n通知模块 (PR in mogland/core#568)\n可能你会感到疑惑,为什么我们在后续的 PR 中移除了基本模块?\n目前的设计结构暂时对基础内置模块的支持并不是很友好,将会极大提高其编码时的复杂度,我们可能会在后续的版本中重新设计这部分的内容,这取决于用户是否需要基本模块。\n非常感谢 Mog 团队成员对这部分代码的贡献,我们将继续提高核心模块的代码质量与稳定性。","新的控制台-ui-已就绪#新的控制台 UI 已就绪!":"全新的 core,肯定要有全新的控制台 UI,我们在过去的时间里,对控制台 UI 进行了大量的重构,目前已经基本完成了。我们依然使用了 React 作为控制台 UI 的开发框架,以及在设计上依然保持了与原来的控制台 UI 的风格基本一致,但是我们对控制台 UI 的设计进行了部分的优化,使得控制台 UI 更加的简洁。","新文档首页#新文档首页":"我们又一次重写了文档首页,实际上是从 Vuejs Fork 的,我们对其中的一些内容做了一些修改,并且在添加了一些章节。你可以在这里看到新的首页:https://mog.js.org/","接下来我们要做的#接下来我们要做的":"我们需要将 v1 生态全部迭代至 v2,这依然是一个很长且困难的过程,我们将会在接下来的时间里继续努力。此外,我们需要重写全部评论模块,目前的评论数据设计已经可以支持在不同的站点中使用了~"}},"/blog/mog-v2-refactor-4":{"title":"Mog Odyssey 2.0 加入部分特性 - Stage 4 Issue","data":{"":"全部修改日志在 https://github.com/mogland/core/issues/605","主题系统-by-wibus-wee#主题系统 by @wibus-wee":"我们新增了一个主题系统服务 (themes-service),它将配有 Fastify + @fastify/point-of-view,目前我们支持了 .ejs 格式的模板引擎,在 Stage 5 我们可能会加入自定义渲染器功能。主题系统支持 i18n,配置十分方便,仅需要 i18n.yaml + _i() 即可使用:\n除此之外,还支持了自定义主题插件支持,它能让你在渲染前处理某些数据,不过目前它还有些缺陷,有待 Stage 5 中继续改进。","重新设计-core-readme-by-wibus-wee#重新设计 Core README by @wibus-wee":"总是认为之前的 README 太过花哨,而我们在第四阶段中,重新设计了 README。\n移除了 Motivation 动机 章节\n移除了 Table of Contents 目录章节\n重新设计了 Contributors 章节\n移除了 Activity 章节\n移除了 @allcontributors 机器人\n国际化 README\n将 # --> ##,以去除默认样式中过长的下划线\n与我们而言,这是一个小改进。","core-支持内置控制台-by-wibus-wee#[Core] 支持内置控制台 by @wibus-wee":"为了便捷性,我们将控制台移入了 Core Gateway 服务中,需要注意的是,它并不是由模板引擎制作的,控制台的仓库依然在 mogland/console,但 Core 将会把全部请求转接到后端中,把 Cookie 等注入请求返回中,请求远端 HTML 等文件,将内容返回。我们增加了关于后台的自定义配置,由于这项功能仍处于测试阶段,我们默认将会把它关闭,如果需要启动你需要在配置文件中启动它。相关文档已更新","全新的评论组件-mog-comments-wc-by-wibus-wee#全新的评论组件 mog-comments-wc by @wibus-wee":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。为了方便主题开发,我们使用 @jwcjs 开发了通用的评论组件。多亏于 Mog 评论服务的设计,它可以在任何地方使用,比如 Hexo。在后期我们将会实现对应的专属评论控制面板"}},"/blog/mog-v2-refactor-5":{"title":"Mog Odyssey 2.0 错误修复与项目重构 - Stage 5 Issue","data":{"":"GitHub · Mog Stage 5: https://github.com/mogland/core/issues/661","icon-全新的图标-by-jinhwan-kim#[Icon] 全新的图标 by @Jinhwan Kim":"有关这个图标的版权,你可以前往「常见问题」查看","core-自定义发布活动与返回接口-by-wibus-wee#[Core] 自定义发布活动与返回接口 by @wibus-wee":"通过定义配置文件,你将可以通过定义发布活动来调度你自己的服务,比如说:\n这样,你就可以通过 GET /events 来获取全部活动,通过 GET /events/{id} 来获取指定活动,通过 POST /events 来发布活动。","core-自定义定时任务支持-by-wibus-wee#[Core] 自定义定时任务支持 by @wibus-wee":"定时任务是一个非常重要的功能,它可以让你在指定的时间执行指定的任务,比如说,你可以在每天的 00:00:00 发送一封访客信息邮件给自己,或者在每天的 00:00:00 清理一次数据库。于是我们做了一个较为简单的定时任务系统,它具有以下功能\n不同的任务类型(访问 URL,广播事件)\n及其自由的任务操作参数\n支持任务执行进行后续操作\n收集任务错误日志\n暂时来说较为简陋,在后续阶段我们会继续完善它。","core-其他新增功能-by-wibus-wee#[Core] 其他新增功能 by @wibus-wee":"数据备份恢复支持\n静态资源管理服务支持\n友链服务支持获取全部状态的友链数据\n在无密码注册用户的情况下自动生成临时密码\n你可以看到,我们本次的功能增强都是围绕着自定义进行的,我们希望用户可以通过自定义来实现更多的功能,而不是依赖于我们的功能。","console-使用-vercelswr-请求后端数据-by-wibus-wee#[Console] 使用 @vercel/swr 请求后端数据 by @wibus-wee":"重构几乎所有触发的请求\n重构几乎所有的 Hooks,减少明面上的 useEffect 狂魔\n重构几乎所有页面的请求钩子\n将重复组件抽象为 ActionButton 组件\n另外,我们还使用新的 Toast 组件以替换原有有缺陷的通知组件","console-控制台支持刷新版本缓存-by-wibus-wee#[Console] 控制台支持刷新版本缓存 by @wibus-wee":"我们内置控制台的资源获取策略是:优先使用缓存,如果缓存不存在则请求远端资源,这样做的好处是可以减少请求次数,但是也会导致一些问题,比如:缓存所储存的版本过期,但是我们的控制台并不会主动刷新缓存,这就导致了用户无法获取到最新的控制台。为了解决这个问题,我们在 Dashboard 页面底部新增了一个刷新缓存的功能,它将会在用户点击刷新按钮时,刷新缓存,这样就可以解决这个问题了。","docs-使用-nextra-作为文档工具-by-wibus-wee#[Docs] 使用 Nextra 作为文档工具 by @wibus-wee":"鉴于 Vitepress 的部分功能不足,我们决定使用 Nextra 作为文档工具,Nextra 是一个基于 Next.js 的文档工具,它的功能十分强大,我们将会在后续的版本中继续使用它。\n然后抄了“一些” Nextra 官网的样式","dev-渲染模块实现-by-wibus-wee#[Dev] 渲染模块实现 by @wibus-wee":"GitHub: @mogland-dev/mog-render-service我们之前曾说过要在 v2.0 中实现一个独立的渲染模块,它将会是一个独立的服务,它将会负责渲染 Markdown 和 Djot 文件,并且还支持文本宏,目前它已经可以正常工作了,但是我们还需要对它进行一些优化。你可以在文章中输入如这样的内容:\n接着渲染模块的文本宏模块将会将其渲染为:\n这个 feature 的想法来自于 Mix space,但是这次我们稍微优化了算法,并更容易拓展功能。由于需要安全执行代码,因此效率依旧不算高。","core-修复大量严重错误-by-wibus-wee--myxxts#[Core] 修复大量严重错误 by @wibus-wee & @MYXXTS":"依赖安全性修复\n错误指向评论详情接口\n替换旧有缓存模块为新缓存模块\n无法载入 ESM 模块\n主题服务无法注入依赖\n主题服务初次使用发生崩溃\n同时激活多个主题发生错误"}},"/blog/new-theme-single":{"title":"新主题 Single 发布","data":{"":"当代互联网上,人们对于博客的呈现方式越来越有了更高的要求。Single 主题的发布为博客的呈现提供了一个全新的选择。这个主题是基于 Paul 的 Typecho Single 主题移植而来,为 Mog 博客系统用户提供了一种全新的博客展示方式。Single 主题的设计风格简约大气,页面整洁明了,使得阅读体验更为舒适,响应式设计,使得博客在不同设备上都能够有良好的展示效果。GitHub Repo Page(欢迎 Star 🌟!): https://github.com/mogland/mog-theme-Single","其他版本#其他版本":"Hexo 版 - 原作者 Paul 发起的,但期望得到社区维护\nHalo 版 - 来自阑珊的移植版本,部分内容有差异\nPaul 的文档与此项目无关,请勿混淆,如果有相关问题请前往对应主题的 Issues 提问。","许可证#许可证":"本项目采用 AGPLv3 开源协议进行授权,衍生项目必须遵守相同的协议,必须开源。严禁将本主题进行二次售卖。在使用转载、移植等方式二次发布本主题时,需要保留本主题的版权说明,例如 “移植自奇趣保罗的 Typecho 主题:Single”。如未遵守本协议使用,作者将拥有追究的权利。原创不易!如果喜欢本项目,请 Star 以示对保罗的支持~ 同时欢迎前往 保罗的博客 提供赞助,谢谢您!"}},"/config":{"title":"配置索引","data":{"配置#配置":"Mog Core 将可以从以下两个地方获取配置信息以匹配你的不同需求并设置为你的 Mog 运行时环境。\n获取 YAML 的配置文件,优先级最高,默认读取当前目录下的 env.yaml 文件。\n命令行参数,优先级次之,有局限性,不建议使用","选项#选项":"当你使用传递命令行参数时,参数传递格式为 --=,例如 --db_port=8123:\n当你使用 YAML 配置文件时,配置文件格式为:","service_namekey#.":"类型:unknown\n默认值:undefined\n 为 Mog Core 的服务名称, 为服务的配置项。","key#":"类型:unknown\n默认值:undefined\n 为 Mog Core 的配置项。你可以通过后接 --help / -h 来查看有关配置项。","config#config":"类型:string\n默认值:/env.yaml\n别名: c\n配置文件路径。","collection_name#collection_name":"类型:string\n默认值:mog\n别名: N\n数据库集合名称。","db_host#db_host":"类型:string\n默认值:localhost\n别名: H\n数据库地址。","db_port#db_port":"类型:number\n默认值:27017\n别名: P\n数据库端口。","db_user#db_user":"类型:string | undefined\n默认值:undefined\n别名: U\n数据库用户名。","db_password#db_password":"类型:string | undefined\n默认值:undefined\n别名: W\n数据库密码。","redis_host#redis_host":"类型:string\n默认值:localhost\n别名: RH\nRedis 地址。","redis_port#redis_port":"类型:number\n默认值:6379\n别名: RP\nRedis 端口。","redis_password#redis_password":"类型:string | undefined\n默认值:undefined\n别名: RW\nRedis 密码。","redis_user#redis_user":"类型:string | undefined\n默认值:undefined\n别名: RU\nRedis 用户名。","jwt_secret#jwt_secret":"类型:string\n默认值: 无可奉告\nJWT 密钥。","jwt_expire#jwt_expire":"类型:number\n默认值:7d\nJWT 过期时间(天)。","consoleenable#console.enable":"类型:boolean\n默认值:false\n是否启用内置控制台。","consoleversiontype#console.versionType":"类型:string\n默认值:无默认\n版本类型,若需要使用非正式版本,则填入 pre-release,若需要正式版本,则任意填入一个字符串 或 不填写。","consolesource#console.source":"类型:string\n默认值:gh\n获取方式,可选择 gh 或 npm。gh 即 GitHub Release,npm 即 npmjs.com。事实上,并不建议使用 npm 方式,这似乎会导致 rate limit","consoleproxygh#console.proxy.gh":"类型:string | undefined\n默认值:无\nGitHub Release 的代理地址。\n我们没有提供支持 npm 是因为我们从 npm 获取文件使用的是官方的一个接口 https://www.npmjs.com/package/${name}/file/${fileId} ,而此接口似乎无镜像","corelisten_ip#core.listen_ip":"类型:string\n默认值:0.0.0.0\nMog Core 监听 IP","coreport#core.port":"类型:number\n默认值:2330\nMog Core 网关层启动的端口号","coreallow_origins#core.allow_origins":"类型:string[]\n默认值:['localhost:9528', 'localhost:2323', 'localhost:2222', '127.0.0.1', 'localhost:3000']\n允许跨域的域名列表, 不可以为 *,使用 , 进行分隔","配置举例#配置举例":"","传递命令行参数#传递命令行参数":"上述命令将会启动 Mog Core 网关层,端口号为 8080,允许跨域的域名列表为 ['localhost:9528', 'localhost:2323', 'localhost:2222'],用户服务部署的主机地址为 http://localhost:2331,用户服务部署的端口号为 2331,页面服务部署的主机地址为 http://localhost:2332,页面服务部署的端口号为 2332","yaml-配置文件#YAML 配置文件":"","其他#其他":""}},"/development/dev-mog":{"title":"启动 Mog 开发模式","data":{"1-从-github-上克隆下-mog-源码#1. 从 Github 上克隆下 Mog 源码":"","2-安装依赖#2. 安装依赖":"Mog 使用 pnpm 管理依赖,所以你必须要使用 pnpm 来安装依赖。","3-启动开发模式#3. 启动开发模式":"请注意,此项命令将有可能导致~~您的电脑彻底死机(CPU 100%)~~所以请确保您的电脑配置足够好,否则你可以使用下面的命令来启动开发模式:\n你可以在 package.json 中查看所有的命令。通过上面的命令,你可以启动指定的服务,而不是直接同时启动所有的服务,可以有效的减少电脑的负担。","4-打包#4. 打包":"目前还暂时无法只构建某个服务,所以你只能先一次性构建所有的服务,再使用 bundle 命令来打包。另外,如果你需要使用根目录的 ecosystem.config.js, 你必须要执行 bundle其他内容,我认为 Mog CONTRIBUTING 中已经写的很清楚了,所以我就不再赘述了。"}},"/development/extend-service":{"title":"拓展新的服务模块","data":{"":"文章来自 可愛い松 | NestJS 微服务通过订阅发布事件与其他技术栈交互, 但基于 Mog 做了部分补充\n此文章仅考虑的是 NestJS Gateway 场景下,对于其他情况暂时不做解释,按理来说应该你也能理解。此外,这篇文章使用的是 Redis 作为传输层,你需要知道基本操作才能来看此文章,并且此文章仅讲述交互原理。\n如果你想直接越过解释前往实践,可以直接看 使用 NodeJS 写一个微服务 这一节","创建一个微服务模块#创建一个微服务模块":"使用 nest g app tester NestJS CLI 将会自动帮你创建对应的模块,但是你需要自己修改部分内容,比如在 main.ts,你需要将 create 替换为 createMicroservice,还有其他的,但是需要注意的是,请将 transporter 设置为 REDIS\n接下来我们使用 redis-cli 来监控事件变化","使用微服务订阅事件#使用微服务订阅事件":"与 @nestjs/common 中不一样的 @Get(),你需要使用在 microservices 包内的 MessagePattern,以下是一个示范\n接下来,启动这个微服务,注意一下上方 redis-cli monitor 出现的日志\n看样子我们找到了一个开始订阅的事件,让我们记住这一个事件,继续下去。\n后续,我将使用 user.get.master 来代替 get.something 事件另外,这种事件命名方式并不是必须的,这只是我个人习惯","在网关层订阅事件#在网关层订阅事件":"你需要在网关层模块中导入一个 ClientModule:\n之后在 controller 构造函数中注入它,再任意搞一个请求:\n让我们继续启动网关层,redis-cli monitor 此时不会出现任何日志,这是正常的","当收到请求时事件发生了什么变化#当收到请求时,事件发生了什么变化":"我们访问一下网关层中配置的路径,注意一下 redis-cli monitor 出现的日志:\n这日志有点辣眼睛,而且这个是我们开了网关层 & 微服务出现的日志,我们暂时只想知道网关层,我们将上面的微服务关掉,再访问一次:\n我们精简一下,将无用的数据去掉,只留下我们想要的东西吧:\n可以看到网关层先订阅了一个基于之前我们定义的 user.get.master 的 reply 事件,之后,在 user.get.master 事件上发布了数据,就是将 pattern, data, id 发布了,十分重要的就是这个id,这是网关层中传输来的。对比一下,你就可以知道其中有一个特别长的日志就是由微服务发布的,可以发现微服务是向 reply 事件发布了事件,内容还包含了之前我们提到的 id,之后网关层收到了数据返回,接着返回来自微服务的数据,取消订阅对应的事件让我们用一个图来解释下吧:\n总结一下,其实就是这样的:","使用-nodejs-写一个微服务#使用 NodeJS 写一个微服务":"使用 pnpm 安装上 redis,根据上方我所说的内容,抽出来一些功能函数,以提高可维护性。因为 NestJS 文档 有说到两种模式,分别是 message 和 event,因此我们需要做一个判定和快捷生成对应的 pattern:\n我们分析一下信息的结构吧,很明显来自Gateway的信息带有3个key:pattern, data, id,其中 id 是自动生成的,也是返回响应时必要的;再分析一下NestJS Microservice 是怎么响应的,它的信息也带有3个key:response, isDispose, id,其中 isDispose 必须为 true,id 必须是来自 Gateway 的。\n所以剩下的就是创建 redis client 和发布/订阅事件了,需要注意的是,返回给 Gateway 的信息需要在事件后加上.reply,你在 monitor 上也能看到 Gateway 在发布事件的时候会同时订阅对应的reply事件:\n这样便是一个简单易启动的服务啦!使用 node^18 更可以使用其实验性功能:--watch 直接监听文件变化重载程序","在-mog-core-中注册事件#在 Mog Core 中注册事件":"在 Mog Core 中,我们需要在 Gateway 运行目录下创建一个 events.yaml 文件,它是用于注册非常规事件的,即非官方实现的事件,例如:user.login,user.register 等等。\n如上方例子,当请求 {API}/render/events 时,会触发 events.get 事件,由于 emit 为 true,因此 Gateway 会触发 events.get 事件,而不会开始监听 .reply 事件。但是下方的 events.get.id 事件,由于 emit 为 undefined,因此 Gateway 会同时监听 events.get.id 和 events.get.id.reply 事件,如果你的服务没有返回响应,那么 Gateway 会在 5 秒后返回一个超时的响应。","注意事项#注意事项":"注意的是:一个事件只能由一个服务受理,否则则会出现冲突情况。但是一个事件(Event-based)可以调度到多个方法\nYou can register multiple event handlers for a single event pattern and all of them will be automatically triggered in parallel. -- NestJS Documentaion\n因此,在编码的时候,不要与现有的服务监听的事件冲突,否则会出现不可预知的情况。"}},"/development/migrate-plugin":{"title":"开发第三方数据迁移插件","data":{"":"Mog 提供了一个数据迁移导入的接口,你可以通过这个接口来开发一个迁移插件,将你的数据迁移到 Mog。目前支持以下数据的迁移:\n文章 - posts\n页面 - pages\n评论 - comments\n分类 - categories\n用户信息 - user\n友链 - friends\n用户信息中没有导入密码的功能,在导入信息后,Mog\n将为您重新生成一个临时密码,您可以在控制台仪表盘中更改它","数据#数据":"","文章-post#文章 Post":"有几点是需要注意的:\nslug 字段必须是唯一的\ncategory 字段是填写已经存在的分类的 slug (需要在 categories 中存在),否则 Mog 会自动创建一个新的分类\ncreated 和 modified 字段必须是 ISO 8601 格式的时间字符串\nhide 一旦设置为 true,则文章将不会在文章列表接口和 RSS 中显示","页面-page#页面 Page":"","分类-category#分类 Category":"其中 slug 字段必须是唯一的,图标可以是一个 url(推荐),也可以是一个 base64 编码的图片","评论-comment#评论 Comment":"里面的 pid 字段是必须的,它将会被用来匹配文章,你需要在里面填写对应文章的 slug,如果文章不存在,那么这条评论将会被忽略\nid 字段必须是唯一的,它将会被用来匹配父级评论,如果父级评论不存在,那么这条评论将会被忽略","友链-friend#友链 Friend":"","用户-user#用户 User":"用户信息中没有导入密码的功能,在导入信息后,Mog 将为您重新生成一个临时密码,您可以在控制台仪表盘中更改它"}},"/development/theme":{"title":"开发新的主题","data":{"主题开发#主题开发":"创建主题时,需要在 package.json 中指定 name 字段、在 config.yml 中指定 id 字段和 language 字段,否则合法性检查会失败。示例主题可以在此处找到:mogland-dev/mog-theme-tiny-ejs\n按照主题目录结构创建主题目录。\n开始开发主题,其中需要有 EJS 的基础语法知识,主题渲染中提供了一些变量,可以在 EJS 中使用,具体变量见 变量。\n在 config.yml 中指定主题的配置,具体配置见 主题配置。\n开发完成后,将主题上传至 GitHub,然后标注 mog-theme 标签,等待 awesome-mog 更新完毕即可在主题市场中搜索到。\n正常情况下最多在 3 小时后,你的项目将能出现在 Awesome List 和 Mog 主题市场中","主题目录结构#主题目录结构":"packages.json: 主题的配置文件,类似于 npm 的 packages.json,用于描述主题的基本信息,如:主题名字、版本、作者、描述等\nconfig.yaml: 主题的配置文件,用于描述主题的配置项,如:头像源、评论系统等 - #主题配置\ni18n.yaml: 主题的国际化文件,用于描述主题的国际化信息 - #i18n-方案\nassets: 主题的静态资源文件,如:css、js、图片等 - #主题静态资源\nplugins: 主题的插件文件,用于注入方法到主题中,如:moment.js 等方法类库 - #主题模板扩展\nindex.ejs: 主页\npost.ejs: 文章页\npage.ejs: 页面页\narchives.ejs: 归档页,分类 & 标签页\nfriends.ejs: 友链页\n404.ejs: 404页\npage-*.ejs: 自定义页面,如:关于页 等, * 为自定义的页面路径\npreview.png: 主题预览图","主题配置#主题配置":"我们考虑使用 YAML 定义主题配置\nid: 主题的唯一标识,格式建议为 theme.{name}.{author}\nlanguage: 主题的语言,要与 i18n.yaml 中设置的语言匹配\nkey: 配置储存名(取值的时候使用此名)\nkey 是可选的,如果不去设置就与 name 是一样的。但是当 name 中涉及到一些特殊符号或者涉及中文字符的时候,强制需要填入 key\ntype: 配置组件\ndata: 传入配置组件的值(内部的定义与上方相似)\nvalue: 默认值,会传入配置组件,可选","配置组件#配置组件":"所有的 key 一般情况下除特殊要求,皆为可选字段,如果不设置 key 就与 name 一样。但是当 name 中涉及到一些特殊符号或者涉及中文字符的时候,强制需要填入 key。\ninput: 输入框\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,key 为可选字段,如果不设置 key 就与 name 一样。\nswitch: 开关\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,要求 value 为布尔值。\ncolor: 颜色选择器\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,要求 value 为颜色值。\nradio: 单选框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。\ncheckbox: 多选框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。\ntextarea: 多行文本框\n传入的 data 为一个对象,对象中包含 value 一个必须的字段,key 为可选字段,如果不设置 key 就与 name 一样。\nselect: 下拉选择框\n传入的 data 为一个数组,数组中的每一项都是一个对象,对象中包含 name, value 两个必须的字段。key 为可选字段,如果不设置 key 就与 name 一样。value 为传入的值,value 会传入配置组件,需要与 data 中的 key 对应。","变量#变量":"","全局变量#全局变量":"","网站变量#网站变量":"","页面变量#页面变量":"页面(page): PageModel - 不会输出 password 等隐私字段文章 (post): PostModel - 不会输出 password 等隐私字段首页(index)\n分类 (category) :CategoryModel\n标签 (tag)\n归档 (archives)\n友链 (friends) :FriendsModel","url变量#URL变量":"","i18n-方案#i18n 方案":"我们可以使用内置函数 _i() ,这个函数可以根据传入的 key 来获取对应的 value。","定义-i18n-key#定义 i18n key":"我们使用 yaml 文件来定义 i18n,在主题根目录创建 i18n.yaml,并定义 key。\n按照上面的定义,我们可以通过 _i('hello') 来获取对应的 value。当无法找到对应的 key 时,会返回 key 本身。","主题模板扩展#主题模板扩展":"如果你想在主题模板中使用函数输出某些东西,你可以通过「扩展」来实现这个功能。在 plugins 文件夹下创建一个 js 文件,然后在该文件中使用 module.exports 导出一个对象,对象中包含一个 name 属性,用于定义插件名称,以及其他函数,用于在主题模板中调用。","定义主题模板扩展插件#定义主题模板扩展插件":"我们将会遍历 plugins 文件夹下的所有文件,将其作为主题模板扩展插件,将其挂载到主题模板中。比如说,我们创建一个 time.js 文件,用于输出当前时间。\n在主题模板中,我们可以通过 time() 来调用 time.js 中定义的 time 函数。\n在函数内,你依然可以使用 变量 中定义的变量。","例子在头部输出-opengrraph-标签#例子:在头部输出 OpenGrraph 标签":"在主题模板中,我们可以通过 opengraph() 来调用 opengraph.js 中定义的 opengraph 函数。","主题静态资源#主题静态资源":"如果你想在主题中使用静态资源,你可以将静态资源放在 assets 文件夹下,然后在主题模板中请求 /raw/assets/* 来获取静态资源。\n需要注意的是,以下文件可以直接访问,无需通过 /raw/* 来访问:\nassets/favicon.*\nassets/robots.txt\n./favicon.*\n./robots.txt\n也就是说,如果你想要获取 ejs 等源文件,你可以通过 /raw/* 来获取:","主题评论组件#主题评论组件":"以 mog-comments-wc 为例,我们可以使用它在主题中实现评论功能。","本地引入#本地引入":"从 Release 页面下载最新的 mog-comments-wc.js 文件,放到 assets/js 文件夹下。\n在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","cdn-引入#CDN 引入":"在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。"}},"/development/using-comments":{"title":"在其他地方使用评论组件","data":{"":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。多亏于 Mog 评论服务的设计,它可以在任何地方使用,只要你能够在你的网站上嵌入一个 HTML 组件即可。","变量解释#变量解释":"一般情况下,在生产环境中,API 地址被设计为 [protocol]://[domain]/api,例如 https://api.mog.land/api。在开发环境中,API 地址被设计为 [protocol]://[domain].\napi:API 的地址,例如 https://api.mog.land/api。\npid:页面的唯一 ID,例如 https://mog.land/developer/using-comments 的 ID 就可以是 developer/using-comments。在 Mog 中,你可以使用 文章的 Object ID 作为页面的唯一 ID。","启动服务#启动服务":"如果你仅需要使用评论服务,你大可以只启动以下服务:\ncore - 必要网关层 - 用于转发请求到其他服务\nuser-service - 用户服务模块 - 用于处理评论相关信息\ncomment-service - 评论服务模块 - 你实际需要的服务","在你的网站上使用#在你的网站上使用":"","本地引入#本地引入":"从 Release 页面下载最新的 mog-comments-wc.js 文件,放到 assets/js 文件夹下。\n在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","cdn-引入#CDN 引入":"在主题模板中引入 mog-comments-wc.js 文件。\n在主题模板合适的地方中添加评论组件。","qa#Q&A":"","如果我在两个不同的系统中同时使用了评论组件会导致冲突吗#如果我在两个不同的系统中同时使用了评论组件,会导致冲突吗?":"有两种情况:\n如果你使用的是 Mog 和其他系统,那么不会有任何问题,Mog 在存入评论时并非仅使用 pid 作为唯一标识,其他系统仅使用 pid 作为唯一标识的。在后台的显示中,这两个系统的评论都会被分开显示,不会有任何冲突。\n如果你都不是使用 Mog,那么将会导致两个系统的评论混在一起,这是不被推荐的。"}},"/docs/build":{"title":"自主构建","data":{"":"如果你想要自定义构建过程,或者你想要在不同的平台上运行,那么你需要自主构建。我们在 「快速起步」 章节提供的是 Linux + macOS x86 平台的构建包。","直接构建服务#直接构建服务":"克隆官方远程 git 仓库\n使用 pnpm 安装项目依赖(依赖 pnpm 8.x 以上版本)\n使用 NestJS CLI 命令构建你需要的服务\n目前支持的 service-name 可在 目前支持的服务 中看到使用 node 命令启动你已构建完成的服务","目前支持的服务#目前支持的服务":"目前支持的 service-name 有:\ncore - 必要网关层 - 必须构建\nuser-service - 用户服务模块 - 必须构建\npage-service - 文章页面分类服务模块\ncomments-service - 评论服务模块\nfriends-service - 友情链接服务模块\nnotification-service - 通知服务模块\nthemes-service - 主题服务模块","拓展使用-vercelncc-重新打包#拓展:使用 @vercel/ncc 重新打包":"@vercel/ncc 是一个可以将 Node.js 项目打包成一个单文件的工具,让你可以在不安装项目依赖(node_modules)的情况下运行项目。core 中已经写好了相关构建命令,你可以直接使用,但前提是你需要先构建了服务。\n构建完成后,你可以在 out/ 目录下找到打包后的文件夹。请注意,请勿修改打包后的文件夹内的任何文件,否则可能会导致服务无法正常运行。接下来使用 node 命令启动你已构建完成的服务\n关于组件启动时的自定义配置,请前往「配置索引」章节\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose"}},"/docs/custom-setting":{"title":"自定义配置 Mog Core","data":{"":"此功能与原本规划的具有一定区别,请注意文档的改变。\nMog 的主要优势之一是它可以弹性组装服务。只要你的条件允许,你可以将服务部署至不同的终端中,但一般你只需部署到同一个终端上即可。但是当你需要配置网关连接服务的IP时(也就是当你将服务部署到了不同的终端时)你需要对 Core 进行配置所以一般来说,如果你只部署到了同一个终端上,以下的内容你是不需要了解且填写的,配置的内容越多,越容易出问题。","启动命令的改变#启动命令的改变":"我们提到「使用 NestJS CLI 命令启动你已构建完成的服务」使用的命令为\n当我们需要在启动 Mog 进行配置的时候,则需要命令之后在后方携带 --= 格式的参数启动","配置-core#配置 Core":"当你将服务部署到了不同的终端时,你需要对 Mog Core 的网关层进行配置。目前支持配置的字段可以查阅 配置索引我们同样支持 YAML 格式的配置文件,你可以在启动的文件夹下创建 core.yml 文件,然后将配置写入其中\n建议无论如何都携带YAML配置文件,若不进行配置则会自动获取当前执行目录下的 env.yaml 文件。若没有则会使用默认配置。命令行允许输入的参数有限,所以我们建议使用 YAML 格式的配置文件。有关允许命令行输入的参数可以查阅 配置索引"}},"/docs/features":{"title":"主要功能","data":{"主题系统#主题系统":"除了使用 API 构建前端,Mog 还通过内置主题系统来实现多样化的博客样式。基于模板引擎,用户可以更便捷地制作主题。了解如何开发主题 主题开发","拓展系统#拓展系统":"Mog 通过拓展系统来扩展主题原有功能,这样可以让用户自定义部分功能。如自动生成目录、自定义文章样式等。了解拓展如何与主题配合 主题开发 #主题模板扩展","可扩展服务#可扩展服务":"Mog 采用了微服务架构,通过注册自定义活动,可以方便地扩展非官方实现服务。可以说这也是一种插件系统(吧?)了解更多有关扩展服务的信息 服务开发","评论系统#评论系统":"Mog 评论服务的设计初衷是为了让用户可以在自己的网站上使用评论功能,但是也可以在其他更多的地方使用。因此它更像是一个独立的评论系统,而不是一个专属于 Mog 的内部组件。得亏于 Mog 评论服务的设计,它可以在任何地方使用(甚至可以不使用 Mog 的前端),只要你能够在你的网站上嵌入一个 HTML 组件即可。了解更多有关评论系统的信息 评论系统","弹性部署#弹性部署":"Mog 采用了微服务架构,每个服务都可以独立部署,这样可以方便地进行扩容和缩容。同时,Mog 也支持多节点部署,这样可以保证服务的高可用性。通过使用如 Kubernetes 这样的容器编排工具,可以方便地进行部署和管理。了解更多信息 弹性部署","异步处理#异步处理":"得益于 Nodejs 的支持,Mog 会将一些没有必要的任务放到异步线程中执行,这样可以避免主线程被阻塞,从而提高性能。在处理大量数据时,将会使用多线程来加速处理速度。Mog 还隔离了一切与用户交互的操作,这样可以保证主线程的稳定性,避免因为用户操作而导致的崩溃。","备份快照#备份快照":"Mog 会自动备份所有的数据,包括用户数据、配置文件等。这样即使在意外情况下,也可以通过备份文件恢复数据。同时支持手动备份和恢复,以及自动备份上传到云端。了解更多信息 备份快照"}},"/docs":{"title":"快速起步","data":{"总览#总览":"Mog 是一个易于扩展的现代博客系统。它突破地采用了微服务架构,在结构设计是模块化、灵活的。 您可以轻松地将其自定义以满足您的需求。 更可以通过接口来开发自己的前/中后台,也可以通过插件来开发自己的功能。你可以在 为什么选择 Mog? 中了解有关此项目背后的想法。","在线试用-mog#在线试用 Mog":"你 暂时还不可以在线尝试 Mog。它是 Mog 的后台系统 Demo,你可以在这里体验 Mog 的后台系统,当然,它自然是受到一定的限制的。","将-mog-core-安装到服务器#将 Mog Core 安装到服务器":"Mog 仅推荐在 Linux 和 macOS 系统上使用,Windows 系统上的使用可能会出现一些问题。如果你对 Docker, Docker Compose, NodeJS, npm-script, git 等技术不熟悉,建议先学习相关知识。文档中不会对这些技术进行详细介绍,且若由于不熟悉这些技术导致的问题,我们将不会提供技术支持。\n在 最新的 Release 中找到 Assets,下载你所需要的构建包版本,目前我们提供:\nmacOS x86\nLinux x86\n如果其中没有符合你需要的版本,请前往「自主构建」章节下载后,解压压缩包,你将会获得一个文件夹,请不要修改文件夹内的任何一件东西,打开终端,使用 cd 命令进入此文件夹后,分别输入以下命令启动组件:\n目前支持的组件,请前往「自主构建」章节,我们在那里给出了具体的组件名称关于组件启动时的自定义配置,请前往「配置索引」章节\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose","社区#社区":"如果你有疑问或者需要帮助,可以到 GitHub Discussions 社区来寻求帮助。"}},"/docs/migrate/backup":{"title":"备份与回滚","data":{"":"Mog 支持导出当前的配置,以及导入配置到当前的配置。在导出配置时,Mog 会将当前的配置导出为一个 JSON 文件,该文件包含了所有的配置信息,包括:\n文章 - posts\n页面 - pages\n评论 - comments\n分类 - categories\n用户信息 - user\n友链 - friends\n在导入配置时,Mog 会将导入的配置与当前的配置进行合并\n如果导入的配置中包含了当前配置中不存在的配置项,则会将其添加到当前配置中\n如果导入的配置中包含了当前配置中已存在的配置项,则会将其覆盖。","导出备份#导出备份":"为了保证数据的安全,Mog 不会将用户的密码导出到备份文件中。在全新导入用户时,Mog 会自动生成一个随机密码,您可以在导入完成后,通过 用户 页面,修改用户的密码。\n在 Mog 的 备份 页面,点击 导出备份 按钮,即可将当前的全部数据导出为一个 JSON 文件。\n在弹出的对话框中,点击 下载 按钮,即可下载该 JSON 文件。","导入备份#导入备份":"在 Mog 的 备份 页面,点击 导入备份 按钮\n在弹出的对话框中,点击 选择文件 按钮,选择需要导入的 JSON 文件。"}},"/docs/migrate/from-third-party":{"title":"从其他博客系统迁移","data":{"使用-markdown-迁移#使用 Markdown 迁移":"你的 Markdown 文件必须要携带 YAML Front Matter,并且最好是符合\nCommonMark 规范的,否则可能会出现一些问题。\n如果你的博客系统支持 Markdown,那么你可以直接将你的博客内容导出为 Markdown 文件,然后在 Mog 后台的迁移页面,导入这些 Markdown 文件。","从-typecho-迁移#从 Typecho 迁移":"下载 Typecho 数据导出插件 Typecho-Plugin-MogRun 插件,根据 READNE 介绍安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-wordpress-迁移#从 WordPress 迁移":"下载 WordPress 数据导出插件 MogRun-WordPress WIP 插件,安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-ghost-迁移#从 Ghost 迁移":"下载 Ghost 数据导出插件 MogRun-Ghost WIP 插件,安装并启用。\n在后台的插件管理页面,点击 MogRun 插件的设置按钮,选择你要导出的内容,点击导出按钮。\n下载导出的 zip 文件,解压后,将其中的 data.json 文件放入 Mog 后台的迁移页面,点击导入按钮。\n等待导入完成,即可完成迁移。","从-hexo-迁移#从 Hexo 迁移":"因为 Hexo 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Hexo 的博客文件导入到 Mog 中。\n打包 Hexo 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","从-jekyll-迁移#从 Jekyll 迁移":"因为 Jekyll 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Jekyll 的博客文件导入到 Mog 中。\n打包 Jekyll 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","从-hugo-迁移#从 Hugo 迁移":"因为 Hugo 为静态博客,其文件使用的是 Markdown + YAML Front Matter 的格式,所以你可以直接将 Hugo 的博客文件导入到 Mog 中。\n打包 Hugo 的博客文章 Markdown 文件,将其放入 Mog 后台的迁移页面,点击导入按钮。","其他博客系统#其他博客系统":"如果你的博客系统不在上面的列表中,那么你可以尝试将其导出为 Markdown 文件,然后在 Mog 后台的迁移页面,导入这些 Markdown 文件。或者根据你的博客系统的数据格式,开发一个数据导出插件,然后在 Mog 后台的迁移页面,导入这些数据文件。"}},"/docs/migrate/upgrade":{"title":"升级版本","data":{"从-mog-v2internalalpha-升级到-mog-v2internalbeta0#从 Mog v2.internal.alpha 升级到 Mog v2.internal.beta.0":"v2.internal.beta 对服务进行了补充以及重要的破坏性修改。主要针对的是配置文件配置项的改动:\nx-service 将不再支持 port, host 配置项,全部服务将使用 redis 作为事件总线,默认情况下,只需要删除对应的配置项即可,若无配置可无视此项\nCore 内置基本模块在现有阶段暂时全部移除,在后续可能会继续引入,这取决于社区基本模块的需求量","从-mog-v1-升级到-mog-v2#从 Mog v1 升级到 Mog v2":"v1 至 v2 的技术栈改动不大,但是很重要,大部分沿用的是 v1 的技术栈,但是 v2 对数据模型和程序结构有一些重大的改动,其中有部分是修复了 v1 的一些设计缺陷导致的严重问题。你可以通过以下方式升级到 v2:\n前往 Console,前往「导入与备份」页面,点击「导出 MnogoDB 数据」,下载数据备份文件,再点击「导出 Markdown 数据」,下载 Markdown 数据备份文件\n前往命令行,使用 MongoDB 的 mongodump 命令导出数据备份文件\n导出的数据备份文件需要保证在导入之前不要被修改,否则可能会导致数据丢失直接使用 mongodump 导出的数据备份文件可能在 v2 导入时会无法使用,需要使用 mongorestore 命令进行转换,或只使用 Markdown 数据备份文件进行导入","从-mog-v0-升级到-mog-v1#从 Mog v0 升级到 Mog v1":"问题是这样的,v0 我们使用的是 MySQL 作为数据库,而 v1 我们使用的是 MongoDB,其中使用了很多 MongoDB 的特性,因此无法直接升级。目前只有一个可行的方案:\n将 v0 的文章页面数据导出,然后导入到 v1 中,v0 和 v1 在处理文章页面数据的方式是一致的,因此可以直接导入。\n由于 v0 是 Beta 版本,充满了不确定性,因此我们无法保证导出的数据能够完全正确导入到 v1 中,因此我们建议你在导入之前先备份好 v1 的数据库。"}},"/docs/usages/console":{"title":"使用内置控制台","data":{"":"我们在 mogland/core #604 中添加了一个内置控制台的功能,这个功能可以让你在不另外部署控制台的情况下,控制你的服务。","基础使用#基础使用":"由于此项功能仍处于测试阶段,因此我们默认暂时设置为关闭状态,你可以在你的启动配置文件中中设置 console.enable 为 true 来启用此功能。\n我们还提供了其他一些配置项,如 console.versionType,你可以在 配置 中查看更多信息。接下来,访问 /console,你将会进入到控制台:\n如果你还未注册,控制台将会自动跳转至注册页面。若你已经注册且已登录,但仍然无法访问控制台主页,请检查你的服务是否出现了问题。"}},"/docs/why":{"title":"为什么选择 Mog?","data":{"mog-是怎么样的#Mog 是怎么样的?":"Mog 默认推荐你使用的是前后端分离架构。这样可以给开发的人提供便捷,也避免了和其他领域的人做不太必要的争吵。专业的事情交给专业的人去做。它具有高度的开发自由度,您可以通过接口来开发自己的前/中后台,也可以通过插件来开发自己的功能。除此之外,多亏视图引擎,Mog 在 v0.x 引入了 「模板引擎」 功能,如优秀的 Hexo 等,使用 ejs 即可简单开发,局限性还是有的,毕竟是在后端处理,在变量提供方面我会尽量按照 Hexo 规范,但是并不能保证完全相同。在 v1 版本中,使用了 Fastify 作为底层,这并不妨碍使用视图引擎,Fastify 可以自动解析视图引擎,而且它的视图引擎支持多种类型的视图,比如 ejs、pug、handlebars 等。但是相关的变量还正在讨论中,暂时未上线。v2 版本中,我们颠覆从前的架构,选择了微服务架构,拓展了原有应用的功能。Mog 旨在探索一种新的博客系统架构,它的目标是提供一个高度自由度的博客系统,探索项目的最佳实践。继续阅读 快速起步","历史#历史":"v0.x:MySQL + Express, 此为第一个版本,但是由于一些原因,我并没有继续开发下去。\nv1.x:MongoDB + Fastify, 此为第二个版本,但是由于其中的大部分代码以及结构与 Mix Space 极度相似,我打算走一条新的路线。\nv2.x:MongoDB + Fastify + Microservices, 此为第三个版本,我们将会在这个版本中,探索一种新的博客系统架构。"}},"/":{"title":"Mog - The Flexible Modular Blog System","data":{"":"Create your own unique site with Mog.\n模块化,弹性化、强大的博客系统。 开源,永久免费。\n5 分钟拥有自己的 Mog →\n几分钟内创建强大的博客网站。\n所有功能都是弹性的.\nMog 突破性采用微服务架构,模块化和弹性化设计,使您的博客更加稳定、可扩展和可维护。\n您可以轻松地定制它以满足您的个人自定义需求,更可以通过主题和活动系统轻松地扩展 Mog。\n黑暗模式 原生适配.\n先进的文本语言渲染解决方案。\n高性能、可靠、可扩展的文本宏函数和标记语言设置。在渲染过程中,Mog 会将大量的文本预处理工作交给后端服务,从而减轻前端的负担。\n更多特性...\n可插拔主题 / 备份系统 / 独立的评论系统... 更多新特性等待您的探索。\n拥有你自己的 Mog →"}},"/docs/with-node":{"title":"使用 node 命令启动","data":{"":"除了使用 Docker,你还可以直接使用 Node 命令启动 Mog\n有关持久化运行,请自行使用搜索引擎探索。这里给几个相关的关键词:pm2, screen, docker, docker compose\n在 最新的 Release 中找到 Assets,下载你所需要的构建包版本,目前我们提供:\nmacOS x86\nLinux x86\n如果其中没有符合你需要的版本,请前往「自主构建」章节下载后,解压压缩包,你将会获得一个文件夹,请不要修改文件夹内的任何一件东西,打开终端,使用 cd 命令进入此文件夹后,分别输入以下命令启动组件:\n目前支持的组件,请前往「自主构建」章节,我们在那里给出了具体的组件名称关于组件启动时的自定义配置,请前往「配置索引」章节"}}}
\ No newline at end of file
diff --git a/about/faq.html b/about/faq.html
index d968fd83..93fff7ca 100644
--- a/about/faq.html
+++ b/about/faq.html
@@ -11,7 +11,7 @@
--nextra-primary-hue: 204deg;
--nextra-primary-saturation: 100%;
}
-