😶🌫️ 使用 Nobelium 从 Notion 构建你的个人博客
date
Jun 3, 2024
slug
use-nobelium-to-construct-your-blog-from-notion
status
Published
tags
Nobelium
Next.js
summary
从 0 开始介绍如何使用 Nobelium 构建你的个人博客,并部署到 Github Page
type
Post
Nobelium 主体部分
建议直接使用我的 fork,该仓库基于https://github.com/IMBlues/nobelium,在原先的基础上进行了改造,支持了部署在子目录下(比如https://musherm.github.io/nobelium),同时加入了一些开关来控制首页的行为。
fork 一份到自己的仓库里,然后 git clone 下来以便后续更改。
构建你的 notion 页
由于 nobelium 直接从 notion 获取并生成博客,自然需要从一个公开的 notion 页面获取内容,所以需要复制以下页面到自己的 notion 里,并将其设置为公开(也有不公开的办法,但这种方法需要获取 notion 登录的 token,比较麻烦,不推荐)
- 在复制过来的自己的 notion 仓库里,检查 share 设定,确保其设置为 Publish。
- 获取你的 notionPageId(即图中[id].notion.site/后面,?v前面的部分)
- 将其填入你 clone 下来的项目中的
blog.config.js
中的notionPageId 字段
- 顺便完善其他相关字段,比如 author, title 等
在我复制的 notion 页中,database 中的各个字段都有什么作用?
- slug 定义了每篇文章对应的路由名称,比如我的 blog 主页是https://musherm.github.io/nobelium ,一篇文章的 slug 设置为 path-middle,那么他最终的地址就是https://musherm.github.io/nobelium/path-middle。
- status 和 type 共同决定了这篇文章是否会出现在你最终构建的博客中,只有
status === ‘Published’ && type === ‘post’
才会出现在你的博客里,前者不为 Published 代表这篇博客还在写作状态中,没有准备好发表;后者如果是 page,则代表它并不是一篇博客。
阶段性检验
使用
npm install
命令安装好依赖后,使用 npm run dev
在本地运行开发环境,做了如上设置后,你应该已经能够得到一个在本地运行的博客系统,并且已经能抓取到你设置的 notion 页内的博文。部署到 Github Page
部署到 Github Page,首先需要前往你的仓库→settings→Pages→选择部署方式Deploy from branch,如果你已经进行过推送,则这里应该已经有 gh-pages 这个分支(如果没有,请 push 一次触发预先定义的 github action,如果 action 编译失败也没关系,后面我们还需要进行修改),选择从 gh-pages 这个分支进行构建。
子路径名称修改(如果你直接 fork 了我的 repo,可以跳过这部分)
前面提到过,作者改造的仓库能够支持部署在子目录下的 github page,比如https://musherm.github.io/nobelium,但每个人的子目录都不一样,所以你需要进行修改,如果你没有自己的域名,你的域名应该是[id].github.io/[repo],其中,[id]是你的 github 昵称,[repo] 是你的仓库名称,你需要对后者进行修改。
如何知道你的 repo 叫什么名字?
从你的项目主页后面的名字就可以得知。
打开你的
next.config.js
,你应该能在开头看到如下字段const isProd = process.env.NODE_ENV === "production";
module.exports = {
basePath: isProd ? "/nobelium" : "",
assetPrefix: isProd ? "/nobelium/" : "",
publicRuntimeConfig: {
basePath: isProd ? "/nobelium" : "",
assetPrefix: isProd ? "/nobelium/" : "",
},
...
你需要将其中所有的
nobelium
替换成你的 repo 名称。保存修改后进行 commit,然后 push 到 Github,此时应该触发了 Github Action 进行编译,你应该能够在这里看到一些细节。
部署成功后,你可以尝试访问你的 github page 来查看是否正常,你的 github page 链接能够通过 Settings→Pages 来查询到。
其实到这里如果一切顺利的话,你已经完成了从 notion 构建个人博客的工作流了,之后你只需要在 notion 书写你的内容,然后去 Github Action 去手动触发一下就行了(因为 Github Action 并不知道你的 notion 状态,所以没办法自动化这个过程)
尽善尽美——完善你的博客数据分析系统和评论系统
数据分析
知道你的博客访问数据是非常有趣的,尤其是自建博客没有像论坛一样的访问量统计功能,所以你可能想要通过其他方法知道有多少人,哪些人访问了你的博客,所幸 Nobelium 内嵌支持了 Google Analytics。
要使用 Google Analytics,你首先需要注册一个账号,前往https://analytics.google.com/,根据提示一路往下,直到你获取了你的 ga id,它应该是以G-开头的一串代码,在
blog.config.js
中,将以下字段中的provider
设置为’ga’,将 measurementId
设置为你自己的 ga id,这就能启用数据分析了。如果你需要在本地测试,你可能需要打开隐私模式并关闭“魔法”,因为 Adblock 之类的插件可能会拦截 ga 的请求,并且如果你的魔法规则包含广告过滤,可能也会拒绝 ga 的请求。
analytics: {
provider: "ga", // Currently we support Google Analytics and Ackee, please fill with 'ga' or 'ackee', leave it empty to disable it.
ackeeConfig: {
tracker: "", // e.g 'https://ackee.craigary.net/tracker.js'
dataAckeeServer: "", // e.g https://ackee.craigary.net , don't end with a slash
domainId: "", // e.g '0e2257a8-54d4-4847-91a1-0311ea48cc7b'
},
gaConfig: {
measurementId: "G-xxxxxxx", // e.g: G-XXXXXXXXXX
},
},
评论系统
Amazing!依托于 Utterances,你现在可以在静态的博客上实现评论系统!如果说你感觉到岁月静好,那就一定有人替你负重前行,一般来说实现评论系统都需要一个后端服务器来处理和存储评论,那么在静态服务器上是谁在替你负重前行呢,答案是 Github Issue。
Utterances 通过自动创建和搜索 Github Issue,来实现评论系统(即你的评论实际上直接发送到了 Github Issue,别人阅读评论也是直接通过 Github Issue 来抓取)。
由于Utterances的文档并不直接针对 Nobelium 的支持,所以本文给出一个详细的配置过程。
- 如果你的仓库是 fork 的,请先检查自己的仓库是否打开了 Issue,前往 Settings→General→Features 检查 Issue 是否打开,如果没有就打开它;
- 确保你的仓库是 Public 状态,否则别人将无法访问你的 Issue;
- 安装 Utterance App,至少允许它访问你用于部署博客的那个 repo。
- 在
blog.config.js
中修改如下内容
comment: {
// support provider: gitalk, utterances, cusdis
provider: "utterances", // 确保这里是utterances
gitalkConfig: {
repo: "", // 这里不用改
owner: "",
admin: [],
clientID: "",
clientSecret: "",
distractionFreeMode: false,
},
utterancesConfig: {
repo: "MusherM/nobelium",
// 这里填id/repo,比如我的 repo 写着MusherM/nobelium,那这里就填这个
// 如果你是 fork 的,应该只需要改前面的 id 就行
},
不出意外的话,评论系统现在应该已经出现在了你的每篇文章底部。
Utterances 评论系统的缺陷
- 由于使用了 Github Issue 来管理评论,所以显而易见地需要评论者使用 Github 账号进行登录
- 当然,无论是评论还是阅读评论,都需要读者能够拥有正常访问 Github 的网络环境(当然你都在 Github Page 部署网页了,可能也不需要担心这个问题了)
后谈
这里主要聊一聊我都做了哪些改动,让这个项目能够部署在子目录中,改动主要在以下内容:
静态资源访问
const isProd = process.env.NODE_ENV === "production";
module.exports = {
basePath: isProd ? "/nobelium" : "",
assetPrefix: isProd ? "/nobelium/" : "",
publicRuntimeConfig: {
basePath: isProd ? "/nobelium" : "",
assetPrefix: isProd ? "/nobelium/" : "",
},
这里在生产环境引入了一个路径名,从而让其能正确索引到静态资源。光是这样还不够,我们通过全局搜索<link 可以发现这样的标签
<link
rel="preload"
href="/fonts/SourceSerif.var.woff2"
as="font"
type="font/woff2"
crossOrigin="anonymous"
/>
这个项目通过一个写死的路径索引了一些字体,需要对这个路径进行一定的处理,不然你可能会在控制台看到一堆报错,同时你的网页还会失去 favicon(即小图标)。
就像我在https://musherm.github.io/nobelium/path-middle 里介绍的,basePath和 assetPath 对
<link>
标签是无效的,他只对 Nextjs 自己定义的 <Link>
标签有效,所以你需要手动引入 basePath,所以我们 nextconfig
中,还通过publicRuntimeConfig
字段重新定义了一遍 basePath,这是因为只有这个字段内的变量才能在运行时引入。所以我们可以对所有的 <link> 标签手动引入 basePath,以上述的标签为例,将其修改成这样:
// 记得先引入
import { basePath } from "@/next.config";
<link
rel="preload"
href={basePath + "/fonts/SourceSerif.var.woff2"}
as="font"
type="font/woff2"
crossOrigin="anonymous"
/>
将以上改动应用到所有的 <link> 标签上,即可完善剩余的静态资源访问,同时你可能会注意到你的网站有小图标了!Congratulations 😇
细枝末节
作为一个完美主义者,我不能接受我的网站上出现任何的死链,在原有的 fork 中,我发现首页的关于和冲浪两个链接点了是找不到的,我实际上也不需要这两个链接,所以干脆找了找,在 header 添加了对于这两个组件的控制选项。
const NavBar = () => {
const locale = useLocale();
const links = [
{ id: 1, name: locale.NAV.ABOUT, to: "/about", show: BLOG.showAbout },
{
id: 2,
name: locale.NAV.SURFING,
to: "/tag/surfing",
show: BLOG.showSurfing,
},
{ id: 3, name: locale.NAV.SEARCH, to: "/search", show: true },
];
同时在 blogConfig 里添加了两个控制选项,来把这两个东西关掉。
showAbout: false,
showSurfing: false,