Webinoly的娘化形象

依然是趁热打铁，之前一直也想画各种软件的拟人娘化形象，
索性就画了喜爱的Webinoly的娘化形象！

因为Webinoly是运维管理的用途，
所以设计元素便以管理员的形象靠拢。
像是年龄在25-28岁的大姐姐、给人沉稳信赖这样的感觉……
但相较于那些千禧年代的老前辈（比如各种面板）
Webinoly又有一种年轻的外貌。

额，也许有一种工具包的设计会更好？
因为随时会使用常用的工具模板部署简单的网站。
（那这样的话不就是科学搜查官嘛！！）

来源

本文以Webinoly提供的LNMP环境，记录安装BookStack的过程。

目前，安装BookStack要求的配置是：

• 命令行访问权限 并安装 gnupg git unzip curl 软件包
• PHP 版本>= 8.2
  • 需要在命令行执行php命令的权限
  • 要求开启的PHP扩展：gd, dom, iconv, mbstring, mysqlnd, openssl, pdo, pdo_mysql, tokenizer, xml, zip
  • 可选扩展：ldap （用于 LDAP 身份验证），exif （用于图像处理）
  • 对于PHP MySQL数据库驱动，首选 nd (Native Driver) 扩展，否则使用默认 mysql 驱动扩展。
• MySQL 版本>= 8.0 或MariaDB 版本>= 10.6
  • 用于存储 BookStack 内容和数据
  • 建议单独创建拥有所有权限的单个数据库
• Git 用于下载与更新
• Composer 版本>= v2.2.0 用于安装和管理依赖项
• 兼容 PHP 的 Web 服务器 例如 Nginx

创建网站

先通过Webinoly的site命令创建PHP网站、及其对应目录与数据库。顺带配置SSL证书：

site domain.ltd -php -mysql
site domain.ltd -ssl=on 
# 可选：自定义证书参数 -ssl-crt=[证书位置] -ssl-key=[证书私钥位置]

手动安装

前往 /var/www/domain.ltd/ 目录，克隆BookStack的Git存储库：

cd /var/www/domain.ltd/ 
git clone https://source.bookstackapp.com/bookstack.git --branch release --single-branch bookstack

进入bookstack目录，执行Composer安装：

cd ./bookstack
composer install --no-dev

基本配置

基于.env.example 模板复制，创建 .env 配置文件，填入网址和数据库信息：

# Application URL
APP_URL=https://example.com

# Database details
DB_HOST=localhost
DB_DATABASE=database_database
DB_USERNAME=database_username
DB_PASSWORD=database_user_password

后续可通过命令 php artisan bookstack:update-url 更新应用网址也就是APP_URL：

随后在终端执行生成应用密钥的命令：

php artisan key:generate

配置Nginx

下文的Nginx配置，以book.lan域名并以HTTP（仅80端口）访问为例：

# WebinolyNginxServerStart
server {
	listen 80;
	listen [::]:80;

	server_name book.lan;

	access_log /var/log/nginx/book.lan.access.log we_log;
	error_log /var/log/nginx/book.lan.error.log;

	root /var/www/book.lan/bookstack/public;

	index index.php index.html index.htm;

	include common/auth.conf;

	# WebinolyCustom
	  location / {
	    try_files $uri $uri/ /index.php?$query_string;
	  }
  
	  location ~ \.php$ {
	    include fastcgi_params;
	    fastcgi_pass unix:/run/php/php-fpm.sock;
	  }
	# WebinolyCustomEnd

	#include common/phpx.conf;
	include common/locations.conf;
	include common/header.conf;
	include /var/www/book.lan/*-nginx.conf;
	include /etc/nginx/conf.d/*.conf.srv;
}

分析：

Webinoly默认的php配置 include common/phpx.conf;
不适用Bookstack要求的query_string，需要将其注释而不调用。

官方文档位于 location ~ \.php$ { 部分的配置行： include snippets/fastcgi-php.conf;
也不适用于目前Webinoly安装的配置（没有这个目录与文件）， 不然会无法调用PHP FastCGI导致白屏。

取而代之的是：include fastcgi_params;
后者文件实际位置位于nginx目录根。

使用

此时打开浏览器即可使用 Bookstack ，创建并登入账号……

来源

把服务器那档子事情处理一些之后，
就准备把Webinoly的命令手册翻译一下了。

上一次翻译一个项目也是23年，我翻译了一个Aria的远程下载器AWGG…… 那时候还在用旧圈名。

话说回来Webinoly最近更新了网站主题和LOGO，咦？怎么没有繁体中文版了？访问 zh 页面只有得到410，看起来好像是撤了，不清楚是不是有瓜葛，只有Wayback Machine还有一份 主页存档 。

有这个想法还得是2024年Alex翻译了繁体中文版本之后（而且直接用zh我觉得很想吐槽），不过当时动笔也只是用OneNote还没拷完下了一份英文原版，然后一直搁置至今。

现在有了Obsidian这个工具，就用了Obsidian Web Clipper来保存。说起来Obsidian这金刚石也在我电脑呆了一年多没用，实际上手感觉真的很好用。虽然跟OneNote那种自由笔记+绘图功能的模式没法比，但不得不说OneNote在笔记这方面也老了。加上之后打算用MkDocs或是其他Markdown的Wiki网站生成器，Obsidian自然是首选。

关于翻译流程呢，还是是先翻译文章内容：
用谷歌和Deepl辅以人工上下文润色，再重新审阅修复一些翻译出现的问题，根据上下文替换专有和习惯词汇（例如子文件夹原文是folder但在中文网管环境、用目录更容易理解）。
不得不说谷歌翻译的质量其实可以，只有某些地方会出现无法理解甚至出现俄语的BUG……

其实可能可以用AI，但一方面画师身份不允许我这样搞，
其次AI目前还是顾及不到这种小众文档，全文直接翻译的话感觉质量很差。换句话说，谷歌翻译实质上还是神经模型的AI，只是拷贝粘贴变成出力不讨好的人工操作，
但即便如此费力，对我来说也算是重新回顾了一遍文档上的各种功能。

而且软件文档这种东西，果然还是用过的人翻译比较靠谱，
问题实际上不是AI翻译质量、而是AI是否在用过的前提下理解Webinoly程序的功能。AI味和普通机翻味一样，实际上是译者不负责任的表现，如果译者用心润色的话，那么机器翻译的效果其实不会那么糟糕。

不过复制粘贴确实很累，左边窗口放Obsidian、右边放谷歌跟Deepl浏览器窗口。

半夜坐台式机面前端坐滑鼠标相当累，但实际上用触屏笔记本就能改善很多。我爱YOGA！（虽然现在我用的是戴尔的YOGA，就像吉普车可以指代各种越野SUV）。

翻译进度

Webinoly主要有五个指令手册，大部分指令基本放在一个页面下，
截止本文撰写时，现在翻译的进度在Webinolys这一页。

当然，还有一篇Full Example Tutorial。
不过目前的打算是先把五章翻译完就传第一版。

至少先方便查阅基本指令。

因为我还得研究用哪个Wiki比较适合Obsidian的链接功能。
实在不行用WordPress也不是不可行。

基于mkdocs搭建的景の域开发手册现已上线！
可以通过 vsdn.v1sta.xyz 的Webinoly导航栏目访问翻译手册。

来源

起初以为是依赖问题，于是在本地搭建的虚拟机建立测试站点，问题依旧复现。

在终端机界面，使用webinoly的 log 指令，
可对特定网站查阅访问日志：

log h5ai.lan -error

若提示没有syslog日志，可以先执行系统更新： sudo apt update && sudo apt -y upgrade

通过查看日志可见，问题出在PHP的函数 putenv 没有开启。
同时putenv也是此前安装社交网站known所需的。
在新版的Webinoly中，一些函数因安全问题被默认禁用。

一般情况的解决办法很简单，修改 /etc/php/版本号/fpm/php.ini 文件，编辑 disable_functions 去除即可。大约在323行：

不过直接编辑php.ini对Webinoly在恢复配置备份的时候并不适用。

事实上， /opt/webinoly/webinoly.conf 配置文件也有关于php禁用函数的配置：

注释436行，去掉putenv的字样，然后重设php（这个reset的含义类似于BIOS，并不是恢复出厂）

webinoly -server-reset=php

搞定。

来源

其实我很早之前就了解到Known了，大概是2022年左右，那会我还在联邦宇宙寻找推特替代品（原主时间线）。没想到拖到26年才在PVE装虚拟机研究起来。另外i3 7100会不会性能有点差？

因为是PHP的缘故，加上有Webinoly的标准化PHP+MySQL模板参照，所以安装难度还算是可以，把包传上去或者用GitHub+compose安装均可，再把生成的MySQL数据库信息填进去就安上了。棘手的部分主要在于Nginx重写规则以及修改php.ini去打开一个弃用的不安全选项。

毕竟Known是一个将近10多年前的老软件了，即使正式版也发布于2019年。安全起见，我只在内网尝试，在CVE也能看到XSS漏洞报道。因此真的在公网搭建发布还是要在心里窦量一下子。

Known原生支持IndieWeb的各项标准，虽然在Fediverse和Bluesky两大新锐派面前IndieWeb的老标准显得稍有过时，不过也离不开IndieWeb标准的启发。即便如此，Known因为兼容IndieWeb还是有三方客户端API接口的支持。

至少从老手机就安装的IndiePass经过四年时间沉寂终于派上用场，IndiePass也支持Mastodon、Pleroma还有Pixelfed，可以把IndiePass理解为一个早期Twitter风格的三方app，不过可能是兼容性问题导致Known的主站Feed显示不出来，只能发帖。IndiePass这种MD1.0设计的老软件现今也被称为古董了。

Known与外界（外部站点）的通讯方式似乎是Birdgy插件，这是一个非营利性的在线服务，通过Bridgy在社交网络上发布网站的链接帖子，Birdgy从这帖子查看回复、并复制内容转告到网站评论，总体而言相当于信使来回跑。并不是真正具有跨界功能的去中心化网络。

Known我曾想过一个中文译名为「知世」，谐音知识（Knowledge），也是源自于「魔卡少女樱」的人物；但就字面意思「知晓世界」而言，Known的功能其实完全称不上这个名号就是。

Known还有一个特别的功能是收藏夹发帖，把后台的一个JavaScript快捷方式拖进浏览器收藏夹，在上网的时候选中内容拖至这个快捷方式，就可以把内容共享到Known，这个功能在Nextcloud也有类似实现（不过我好久没用Nextcloud了）

打不中就没有意义！

对于社交网络也是如此，没有人来用的话也不好玩。不过Known看起来似乎没有联邦宇宙的跨站浏览信息流，而Known设计之初也是为了个人和小型组织发布内容的「独立轻博客平台」，远远不算联邦的定义。

Known倒是支持从WordPress或者Blogger等xml信息导入文章，但除了作为个人博客之外，我能想到的用途就是学校社团小组专门用来建立公告板网站了。毕竟看样子没有不登陆Known就直接回复的功能。

所以现在来看的话，Known这东西给我感觉更像是……Web2.0版的腾讯频道？Tumblr社区？

亦或许是人人网？也不对。

但现在对我来说最重要的问题是社交是否还存在意义。人人网的没落，实际上是因为那些人步入中年不再社交。

现在新一代的网民大部分只有机会接触到手机，并不了解早年Web2.0及之前的互联网结构，被app驯化而不是被电脑浏览器驯化。这使得我生来与同龄人存在文化隔阂，却又作为这种桥梁。

咳咳，可能说的有点偏题了。

所以也许只是为了满足我的孤岛欲罢了。恰好搭建Known是一个不错的研究案例。。

过会整理好发下安装教程。另外是时候切换到Obsidian了。

1月23日更新：

其实感觉Known更像是昔日的WordPress P2/O2，后者是一种实时资讯模式的WP团队网站解决方案，颇有SharePoint门户的样子。

对于现在的人来说，可以理解为一个大号的腾讯频道/Tumblr社区，而小团体相当于微缩版的企业环境。

嗯……我又有点想试试P2和SharePoint了……研究老技术真的合适吗？

来源

简单说一下要点就是：直接在wp-config.php编辑站点目录的define编码项目。

前置条件：

• 一个真正的域名，可创建SSL证书
  
• 可以映射端口转发的路由器、未被运营商封锁的端口，未被系统占用的端口
  

1.创建网站

在内网的Webinoly可以首先用site命令使用域名创建普通的WordPress网站，端口号80（开启SSL则为443），在局域网访问的情况下，域名的端口号其实应该能够直接连接，若是没有则修改客户机系统的hosts也能达到直连访问的目的。

此时也可以顺带申请一下SSL证书，不过由于公网端口封堵，因此只可选择dns txt验证方式：

sudo site domain.ltd -ssl=on -manual=dns

2.配置WordPress

随后根据正常步骤访问域名配置WordPress，之后要额外安装一个WordPress插件 —— Make Paths Relative ，
这个插件顾名思义，可以将WP网站转换为相对链接的结构。

如有需要，还可在设置页面添加域名信息：（包括「域名:端口」形式）

3.编辑Nginx端口配置

编辑Webinoly服务主机上的域名主机配置 sites-available/domian.ltd.conf ，在需要访问的Server部分添加需要监听的端口，或是复制一份现有80或443的Server配置，将端口号改为自定义的端口：

# WebinolyNginxServerStart

Server {
listen 443 ssl;
listen [::]:443 ssl;
listen [::]:443 quic;
listen 443 quic;
listen [::]:2000 ssl;
listen 2000 ssl;
listen [::]:2000 quic;
listen 2000 quic;
server_name domain.ltd;

……

4.编辑WordPress的wp-config.php硬配置

寻找到自定义编辑行，添加如下代码。原理是硬配置网站链接为根部分（这可能会导致网页分享插件发生空白错乱）

/* Add any custom values between this line and the "stop editing" line. */
define('WP_SITEURL','/');
define('WP_HOME','/')

注意事项

可以通过浏览器的开发者工具查看页面资源（如CSS与JS）指向的服务器目录位置，
这样就可以看到资源究竟是从HTTP/HTTPS的标准端口加载，还是从自定义的端口号加载了。

若是无法打开网页的话，可以尝试用浏览器的隐私模式查看。手机LTE（或有WWAN连接的笔记本）也是个不错的公网测试环境。

直接在浏览器输入域名并不能直接跳转到端口号，这个功能需要DNS管理侧跳转实现，不是所有DNS服务商都提供这一功能，对于私人用途也没有必要。

Webinoly自带黑洞模板，理论上直接从IP+端口号无法访问，只有从域名+端口访问才能显示网页。
至于运营商侧是否因此探测或者禁止……并不可测。因地区而异吧，本文不会探讨法律风险。
不过安全起见仍然建议使用HTTPS协议。
另家宽不建议开启爬虫探测，必要时开启整站HTTPAUTH也并非不可。

最后，测试完毕后，切勿忘记将临时修改的自定义hosts，将其复原回来！开发愉快~

来源

我不太想在VPS上再运行一些带数据库的Web服务，除非用SQLite，所以选择了Dokuwiki，虽然最后发现并不太合适（可能还不如用Typecho+SQLite，奈何Typecho没有我比较喜好的主题）

安装

这次还是使用我喜爱的Webinoly运维脚本配置，和上次搭建Blessing Skin的过程类似，一行site命令，使用标准的php模板并配置SSL证书，一气呵成：

site [domain.ltd] -php -ssl=on

打开 Dokuwiki 的官网下载页面，可以选择自定义最小化的编译版本，仅保留需要的插件和语言：

然后点击下载，会自动转到下载页面，下载编译的压缩包，并提示如果没有自动下载则点击链接，复制这个链接即为wget下载链接。注意有下载时限，过一段时间后会过期，因此我也无法提供下载链接。

使用 tar -xvzf 解压后获得名为 dokuwiki 的目录，将其替换默认的 htdocs目录（也可以在nginx配置文件改成 dokuwiki ），并递归设置目录所有者为www-data以取得权限。

tar -xvzf dokuwiki-*.tgz
chown -R www-data:www-data ./htdocs
nginx -s reload

此时已经可以在浏览器中访问了，在域名后面输入 install.php 就能够访问安装器页面，出于安全原因，这个安装器只能在全新的Dokuwiki使用一次，配置以后还需要移走 install.php 以阻止访问。

URL重写

参考Dokuwiki上的Rewrite页。可以通过URL重写移除链接中的doku.php字样，需要在配置页 > 高级设置中设定userewrite项为 .htaccess(2)，以及打开canonical 完全标准的URL。

虽然userewrite表述为.htaccess，但并不是Apache HTTP Server特有的重写配置，同样也支持IIS、Nginx等多个其他的Web服务器。在此附上启用Nginx重写功能的片段，顺便设置敏感目录的阻止访问。

location / { try_files $uri $uri/ @dokuwiki; }
 
location @dokuwiki {
        rewrite ^/_media/(.*) /lib/exe/fetch.php?media=$1 last;
        rewrite ^/_detail/(.*) /lib/exe/detail.php?media=$1 last;
        rewrite ^/_export/([^/]+)/(.*) /doku.php?do=export_$1&id=$2 last;
        rewrite ^/(.*) /doku.php?id=$1&$args last;
    }
 
    location ~ \.php$ {
        if (!-f $request_filename) { return 404; }
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param REDIRECT_STATUS 200;
        fastcgi_pass 127.0.0.1:9000;
    }
    
location ~ /(data|conf|bin|inc|vendor)/ {
    deny all;
}

需注意的是，第一行的 location 配置与 Webinoly自带的 common/phpx.conf 相冲突，需要在站点Nginx主配置注释include后者以识别 @dokuwiki 。

这时URL重写便已经配置好了，如同WP的伪静态一样简单。

主题

Dokuwiki可以安装很多模板主题 (Template) ，它们以Wikipedia的风格居多，也有少数现代扁平化的设计。我比较喜欢 SprintDoc 模板，是德国人开发的，基于Material设计语言，简单而优雅，而且有著浓厚的德国工业文件的风格。

在扩展管理器中搜索 SprintDoc 就可以直接下载，然后去配置页启用template，当然也可以自己下载上传压缩包安装。

结尾

最后，我还是放弃了使用Dokuwiki，研究了一会发现，Dokuwiki的结构并不是很适合我。

尽管Dokuwiki是一种纯文件架构（Flat-file CMS）的程序，比较类似的是Grav CMS，但是并不代表从服务器下载文件就能直接所见即所得，除非直接离线存储整个网页。

Dokuwiki特有的synatx格式与富文本编辑器也不太好用，虽说有插件支持Markdown，但不是文件格式存储，依然没什么优势。

其次，Dokuwiki对于英语/拉丁语以外的语言体系的支持并不算好，虽然并不是完全不支持亚洲语系，但是URL只能设定为英文。分类的功能也不太好用，不像Mediawiki的几个站点。

最初的初衷只是为了想要记录一些服务端、客户端区分的MC模组，然而本来就有先人在mcmod百科上记载了，而且也被很多支持BMCLAPI的启动器所引用，我为何不直接写文笔记附上mcmod.cn的链接呢？

可能还是担忧突然一夜之间内容消失的重创。

虽然对一个小服务器没什么影响……我还是用OneNote吧。其实，支持metaweblog发布到WP功能的旧版Word更适合记录啊。

来源

不过后续可能会分享更多的文件、图片等，NGINX自带的索引列表过于简陋，索性尝试一下热门的h5ai吧。于是，我基于h5ai搭建了本站的资源存放箱（File Cabinet）共享文件。

并且考虑到SFTP的速度很慢，实在不想上传几个文件还要打开WinSCP之类的运维工具，顺便也搭建了一个WebDAV服务端，用于管理上传的文件。后续再更新

在此之前我使用的是SSHFS-Win，就是下图这个，它可以在资源管理器（Explorer）挂载目录，类似于RaiDrive之类的第三方软件，不过它是自由免费的开源软件。奈何SFTP的文件传输效率还是太低了些……

安装h5ai

h5ai是一个基于PHP开发的文件共享索引程序，由德国人Lars Jung，全称是 HTML5 Apache Index，本是取代Apache自带的静态文件索引功能，不过也可以支持其他的Web服务器。

h5ai · modern HTTP web server index for Apache httpd, lighttpd, nginx and Cherokee · larsjung.de

modern HTTP web server index for Apache httpd, lighttpd, nginx and Cherokee

larsjung.de

h5ai很好安装，打开上面的项目主页，可以看到一个大大的版本号下载按钮，右键复制按钮的链接，通过wget就可以下载到服务器上。目前最新的版本号是0.30.0，用cd命令转到文件共享的虚拟主机（vhost）网站目录内下载并解压。

cd /var/www/[domain.ltd]/htdocs
wget https://release.larsjung.de/h5ai/h5ai-0.30.0.zip
unzip h5ai-0.30.0.zip

解压后会出现一个名为 _h5ai的文件夹，这是h5ai的程序目录，不过默认是隐藏的，下文会提到如何隐藏前缀文件。

然后编辑虚拟主机的配置文件，添加_h5ai路径的index.php索引程序：

root /var/www/[domain.ltd]/htdocs;

index index.php index.html /_h5ai/public/index.php;

location ~ .*\.(zip|ini|jar)?$ { 
     allow all; 
} 
...

由于我使用的Webinoly有安全模板限制，默认不能通过直链访问一些压缩包和可执行文件后缀的静态资源，因此也添加了特定的文件后缀赦免。

此时在浏览器中输入文件站的域名，在后方加入 /_h5ai/public/index.php/ 访问h5ai的自检（探针）页面，默认无密码就可以进入，编辑option文件添加访问密码。

根据自检页面的指示设定文件和目录的权限、安装需要的扩展等等。

一切就绪以后，h5ai就可以正常运行了。

配置h5ai

如果想达到上图域主的效果，还需要设定h5ai的配置。

h5ai的主要配置文件位于 _h5ai/private/conf/options.json ，可以设定的配置非常多，在此仅列出我主要修改的几项：

"view": {
    "binaryPrefix": false,
    "disableSidebar": false,
    "fallbackMode": false,
    "fastBrowsing": true,
    "fonts": ["Ubuntu", "Roboto", "Helvetica", "Arial", "sans-serif"],
    "fontsMono": ["Ubuntu Mono", "Monaco", "Lucida Sans Typewriter", "monospace"],
    "hidden": ["^\\.", "^_h5ai", "icon.ico"],
    "hideFolders": false,
    "hideIf403": true,
    "hideParentFolder": false,
    "maxIconSize": 40,
    "modes": ["details", "grid", "icons"],
    "modeToggle": false,
    "setParentFolderLabels": true,
    "sizes": [20, 40, 60, 80, 100, 140, 180, 220, 260, 300],
    "theme": "comity",
    "unmanaged": ["index.html", "index.htm", "index.php"],
    "unmanagedInNewWindow": false
},

这里可以设置UI的显示模式、字体、隐藏文件、主题等等，比如hidden设置隐藏文件可以使用正则、也可以单独匹配文件名，这里我添加了 icon.ico 图标文件。

语言设置

"l10n": {
        "enabled": true,
        "lang": "zh-Hans",
        "useBrowserLang": true
 },

修改 lang 为简体中文 (zh-Hans) ，默认为英语 (en)。不过h5ai本身亦内置多种语言，useBrowserLang 可根据用户端浏览器自动切换显示的语言。

修改谷歌镜像

h5ai的界面默认使用Google Fonts，可以灵活更换字体，但在国内也可能会出现打不开的现象，好在可以替换成其他链接：

"resources": {
        "scripts": [],
        "styles": [
            "//fonts.googleapis.com/css?family=Ubuntu:300,400,700%7CUbuntu+Mono:400,700"
        ]
},

在 styles 中填写自定义字体的URL，使用Google Fonts的话可以把Ubuntu Mono换成其他的字体名称；

以及将 fonts.googleapis.com 替换为国内可用的字体镜像，比如 fonts.loli.net 的，这个是老生常谈了。

添加MD文件备注

还是在 options.json 中，找到 custom 开头，修改 enable 为 true ，可开启文件页眉/页脚备注，支持Markdown和HTML格式。

"custom": {
"enabled": true,
"stopSearchingAtRoot": true
},

随后可在文件目录中添加 _h5ai.header.md(.html) 和 _h5ai.footer.md(.html) 文件

修改根目录标题

h5ai默认根目录标题显示为当前的域名，可以在 _h5ai/public/js/scripts.js 文件中修改自定义名称

找到PHP域名函数 ("/"===t?f.getDomain():n.name)

替换为自定义字符串 ("/"===t?'资源存放箱':n.name)

修改网页标题

网页标题 (Title) 位于 _h5ai/private/php/pages/index.php 文件中，以 <title> <title/> 开头/结尾的HTML代码：

<title>index - powered by h5ai v0.30.0 (https://larsjung.de/h5ai/)<title/> 

此代码即为网页显示的标题，默认显示h5ai的版本、版权信息，可以将其替换成要显示的自定义文字。

需要在 options.json 关闭面包屑导航的动态标题功能。

域主顺便用Rclone搭建了额外的WebDAV文件传输和管理服务，天色已晚，待我吃完饭后，放到下篇再写……

嗯……如果在自己的服务器架设Jekyll、Hugo或Grav之类的Markdown博客引擎，也许可以用H5ai作为图床和视频站……

来源