最开始接触 Blog,总会遇到各种各样大大小小的问题,但是在网络上查找各种解决办法的时候,往往都是只告诉了你怎么做,却没有说为什么?我们也就机械化的进行ctrl+c,ctrl+v,这是十分不可取的。因此本着「授人以鱼不如授人以渔」的想法,决定对整个 Hexo 和 Next 的文件组织进行一波系统的整理,既便于我们维护管理,也可以更好更官方的进行 Blog 主题优化。
这是官方解释:
Hexo 是一个快速、简洁且高效的博客框架。Hexo 使用 Markdown(或其他渲染引擎)解析文章,在几秒内,即可利用靓丽的主题生成静态网页。
安装(详细过程这里就不再阐述):
Git
,分散式版本控制软件Node.js
,一个基于 Chrome V8 引擎的 JavaScript 运行时npm
安装 Hexo
,npm 是 node.js 的包管理器这里是从官网上摘录的一些我们日常中经常使用的命令:
hexo init [folder]
:新建一个网站。
hexo new [layout]
:新建一篇文章;
hexo publish [layout]
:发表草稿hexo g
:生成静态文件;
hexo g -f
:效果接近 hexo clean && hexo generate
hexo d
:部署网站
hexo g -d
hexo server
:启动服务器。
hexo clean
:清除缓存文件 (db.json) 和已生成的静态文件 (public)
$ hexo init
$ cd
$ npm install
Hexo 在指定文件夹中初始化完毕后,会出现如下文件结构:
.
├── _config.yml
├── package.json
├── scaffolds
├── source
| ├── _drafts
| └── _posts
└── themes
在后面的实际使用过程中还会创建一些其他文件或文件夹,后面都会进行说明。
网站的配置信息,在此修改大部分的配置参数;
详见:『配置 | Hexo』
应用程序的信息。可以查看 hexo 的版本以及安装的扩展版本。
模版 文件夹。当新建文章时,Hexo 会根据 scaffold 来建立文件。
详见:『模版 | Hexo』
资源 文件夹是存放用户资源的地方。
存放博客文章的地方,其中的 Markdown 文件、Html 文件、org 文件等会被解析并放到 public 文件夹,发布到站点。
会被忽略;
./img/picturename.png
引用本地图片,然后可以直接将整个文件夹上传至图床,然后再用匹配,一键替换 ./img
为完整的图床 url;会被拷贝到 public 目录并上传到站点;
hexo new page PageName
命令即会在 source 中自动新建子目录 PageName
主题 文件夹。默认安装 landscape 主题,可以安装新主题到 themes 目录,也可以自己新建主题。
这也是我们下面要讨论的 Next 主题文件存放的文件夹;
在部署到 github 后自动创建:
因此,该目录的结构和 public 目录基本一致;
存放安装的 Hexo 扩展;
存放生成的静态网页内容;
hexo g
命令,Hexo 程序会解析 source 、当前使用的 theme,将生成的静态网页内容保存到 piblic;hexo d
则将该目录内容复制到 .deploy_git 目录,然后由 Hexo 的部署插件 hexo-deployer-git 根据 _config.yml 里的 deploy 配置,完成上传;这个主要是用于 Blog 源资源的备份,防止电脑故障后数据丢失,也便于 Blog 的迁移;
db-json 是完全在 json 中的数据库。数据库,查询和结果都是 json 数据。它在客户端和服务器端均可使用。
数据库结构化,表由类型化字段组成,并带有可选验证(模式,长度,范围)
该库在浏览器和节点上均可使用。
dabase 的 json 代码是人类可读的,并且可以方便地在手边进行编辑。 如果发生任何错误,则在使用该 json 代码实例化新的 Database 对象时将检测到它们。
package-lock.json 是在 npm install
时候生成一份文件,用以记录当前状态下实际安装的各个 npm package 的具体来源和版本号;
以下是引用的知乎@周载南的解释:
- 因为 npm 是开源世界,各库包的版本语义可能并不相同,有的库包开发者并不遵守严格这一原则:相同大版本号的同一个库包,其接口符合兼容要求。
- 这时候用户就很头疼了:在完全相同的一个 node.js 的代码库,在不同时间或者不同 npm 下载源之下,下到的各依赖库包版本可能有所不同,因此其依赖库包行为特征也不同有时候甚至完全不兼容;
- 因此 npm 最新的版本就开始提供自动生成 package-lock.json 功能,为的是让开发者知道只要你保存了源文件,到一个新的机器上、或者新的下载源,只要按照这个 package-lock.json 所标示的具体版本下载依赖库包,就能确保所有库包与你上次安装的完全一样。
所以也就是说,原先的 package.json 只能帮助我们锁定大版本号(即:第一位),但是由于有的库包开发者并没有严格遵守规则,从而可能出现大版本号下的小版本不兼容等问题,让我们在更新或者迁移到新机器进行环境安装时出现各式各样的问题,package-lock.json 由此赢然而生,当我们每次安装一个依赖的时候就锁定在你安装的这个版本。
首先要说的是,很多人在网上查找的 NexT 主题安装和配置教程都比较早,他们给出的 NexT 地址是 「 https://github.com/iissnan/hexo-theme-next 」,但这个项目在 2017 的时候就宣布不再维护了,之后 2018-2019 年将 NexT 的地址变更为:「 https://github.com/theme-next/hexo-theme-next 」,2020 年最新的地址为:「 https://github.com/next-theme/hexo-theme-next 」
经过不断的版本迭代,NexT 目前已经提供了非常丰富的配置来满足使用者的个性化需求,在配置主题时,如果你像我一样对前端不是特别擅长,那么我更推荐使用官方推荐的方式配置主题,多挖掘博客自带的功能,尽可能少得修改源码。
我使用的 NexT 版本号为 7.8.0,请先到 themes -> Next -> package.json 里查看一下你的 NexT 版本,酌情考虑升级。新版本的官方主题配置内容会比以前会丰富,也更加简单。
直接到你的 Blog 的 themes 文件夹下 git clone 整个 NexT 仓库即可;
官方给出的教程:
$ cd hexo
$ git clone https://github.com/next-theme/hexo-theme-next themes/next
下载后,打开 Hexo 站点配置文件,找到 theme 部分,然后将其值更改为 next(或另一个主题目录名称);使用 hexo clean
清理缓存,然后 hexo s
,就可以去验证主题了。
.
├── .github # git 信息
├── docs # 官方的一些文档说明信息,不用管
├── languages # 多语言,我们常关注的是下面几个个
| ├── default.yml # 默认语言
| └── zh-CN.yml # 简体中文
| └── zh-HK.yml # 繁体中文
| └── zh-TW.yml # 繁体中文
├── layout # 存储相关的布局信息
| ├── _macro # 可以自己修改的模板,覆盖原有模板
| | ├── post.swig # 文章模板
| | ├── sidebar.swig # 侧边栏模板
| | ├── post-collapse.swig # 没动过,理解为文章崩溃后显示的模板文件
| ├── _partial # 有关文章、标题、页面等更加细节的局部布局,如果不是很懂建议不动
| ├── _script # 一些脚本的局部布局
| ├── _third-party # 第三方模板
| ├── _layout.swig # 主页面模板
| ├── index.swig # 一些索引模板
| ├── archive.swig # 一些解题实现的模板
| └── page.swig / tag.swig / post.swig / category.swig # 相应模块的主控制模板
├── scripts # script 源码
├── source # 源码资源
| ├── css # *.styl 的 css 源码
| ├── images #图片
| ├── js # javascript 源代码
| └── lib # 其他的库文件
└── _config.yml # 主题配置文件
Stylus 比较年轻,是一个 CSS 的预处理框架,2010 年产生,来自 Node.js 社区,主要用来给 Node 项目进行 CSS 预处理支持,可以创建健壮的、动态的、富有表现力的CSS。默认使用 .styl 的作为文件扩展名,支持多样性的 CSS 语法。
SWIG 是一种简化脚本语言与 C/C++ 接口的开发工具。SWIG 是一个通过包装和编译 C/C++ 语言程序来达到与脚本语言通讯目的的工具。推荐个学习地址:『Swig:一个适用于 Node.js 和浏览器的模板引擎』
看了上面的文件结构后,我们大致就知道所需要修改的信息应该在哪部分。通常,只需要修改 NexT 的 _config.yml 文件即可,配置初建议把这个文件都过一遍,然后根据自己的需求更改,里面也会有许多网上可能没提到过的配置。
记住不要一味的参照网上各式各样的配置教程,许多时候因为版本不同,配置的方式也不同,可能导致修改许多本没必要的位置,加入杂乱的代码等等,长时间后,我们可能自己都忘了曾经修改过啥,这样十分不利于后期的维护,和 NexT 的更新。
详见:『官方配置文档』
看完官方文档,发现我的 Blog 也还有一些配置的地方,不说了,我先行一步!别光看了,do it,加油!