今天,`Brave Love` 正式发布 `v1.0.0`。
这不是一次简单的版本号升级,也不是一次样式微调,而是一次完整的产品化收口:从前台视觉、后台配置、内容
模型,到主题元信息、文档、截图、安装包、测试报告与发布说明,都按照正式发布的标准重新整理了一遍。
更重要的是,`Brave Love` 并不是凭空诞生的项目。它的灵感来源、情侣站点的产品方向,以及一部分早期代码迁
移工作,来自开源项目 [`zwying0814/Brave`](https://github.com/zwying0814/Brave)。原始 `Brave` 是一款面
向情侣博客场景的 Typecho 主题,原作者也在公开介绍中提到,它围绕计时器、留言板、恋爱清单、点点滴滴等功
能展开,是一个非常有辨识度的垂直主题作品。
在这个基础上,`Brave Love` 做的事情,不是简单“换壳”,而是把这套情侣记录站的核心体验,迁移到 WordPress
生态里,并围绕 WordPress 的内容模型、模板体系、评论系统、媒体库、自定义器与后台能力,做了一轮真正面向
产品落地的重构和继续开发。
如果说原始 `Brave` 给我的是“方向感”和“浪漫感”,那么 `Brave Love` 想做的,是在尊重原始灵感的前提下,把
它变成一个更适合 WordPress 用户部署、使用、维护和长期记录的主题产品。
## 一、这个主题到底是什么?
`Brave Love` 是一款为情侣记录而生的 WordPress 主题。
它的目标不是做一个泛博客模板,而是做一个有明确使用场景的站点系统:你可以用它记录相遇、纪念日、点点滴
滴、随笔心情、恋爱清单、亲友祝福,以及一整个恋爱关系中的日常与时间感。
和很多“浪漫主题”不同,`Brave Love` 在设计上更强调两件事:
第一,是“可长期阅读”。
不仅是首页好看,而是每一个页面都能成为可读的、可归档的、能反复回看的内容结构。
第二,是“完整的站点感”。
它不是几个零散模块的拼接,而是首页、关于我们、点点滴滴、相册、说说、留言、清单之间彼此联动,最终形成
一个统一叙事的情侣纪念站。
## 二、Brave Love 的产品结构
目前,`Brave Love` 已经形成了一套完整的页面与内容结构。
### 1)首页:氛围与信息的入口
首页承担的是“第一眼体验”。
它包含:
– 情侣头像与站点品牌信息
– 两组计时器:已经一起多久、距离特别日子还有多久
– 今日天气模块:支持多城市、空气质量、紫外线、日出日落、穿搭建议
– 特别的日子模块:承接纪念日与关系中的关键时间节点
– 进入其他内容页的统一入口
首页的目标不是信息堆砌,而是把“日常感”和“仪式感”放在一个页面里自然地建立起来。
### 2)关于我们:把关系写成一条可以阅读的故事线
`关于我们` 不只是一个静态介绍页,而是一个有独立内容模型支撑的页面。
通过 `story_milestone` 故事节点结构,可以按时间组织相遇、靠近、相守、未来约定等内容,并和具体的点点滴
滴文章关联。
从产品视角看,这一页更像整站的“目录页”和“关系总览页”。
### 3)点点滴滴:真正的时间轴内容中心
`点点滴滴` 是整个主题最核心的内容页之一。
它承担的是:
– 按年份回看重要瞬间
– 展示地点、心情、摘要、日期等信息
– 承接详情页阅读
– 作为相册、关于我们等模块的内容来源
这个页面经历了大量反复调整:从年份筛选、日期口径、卡片结构,到详情页节奏和手机端阅读体验,最终才逐步
稳定下来。
### 4)甜蜜相册:从内容里自动长出来的相册页
相册不是孤立上传的照片墙,而是从 `moment` 内容中的特色图与正文图片自动提取和聚合出来。
这意味着:相册页不是额外维护的负担,而是点滴记录自然生成的视觉索引。
同时,它也支持年份筛选、灯箱浏览和详情跳转,让“照片”重新回到“故事”里。
### 5)随笔说说:承接碎片化情绪
并不是所有内容都值得写成长文。
所以 `随笔说说` 承接的是短句、碎片化心情、想念度和某一刻的即时表达。
这个页面后来做成了更完整的内容页:
– 支持年份 / 月份 / 日期三级筛选
– 支持前台快捷发布
– 支持心情与想念度信息
– 卡片结构更轻,更偏日常记录
它的意义,是让整个站点不只有“大事件”,也有“小情绪”。
### 6)祝福留言:让站点从“自我记录”走向“被看见”
祝福留言页的核心价值,是把亲友互动留在站点里。
基于 WordPress 评论系统,它加入了:
– 审核机制
– 自定义留言表单
– 本地卡通头像池
– 年份筛选与统一卡片布局
这页承担的是“公开互动”的场景,也让整站从私密记录走向更完整的纪念感。
### 7)恋爱清单:把想做的事变成一份长期计划
恋爱关系不只是回忆,也包含计划。
`恋爱清单` 这一页用独立内容结构和状态体系来承接:
– 已完成
– 待完成
– 完成度
– 分类与状态筛选
– 详情展开与图片补充
它更像一个“未来目录”,和点点滴滴形成回忆与计划的双向结构。
## 三、从 Typecho 到 WordPress,这次“移植”到底改了什么?
如果只从表面看,`Brave Love` 似乎只是把原始 `Brave` 的气质搬到了 WordPress。
但真正做下去之后,会发现这其实是一项结构性重建。
### 1)内容模型重建
原始情侣主题的很多体验,放到 WordPress 里不能直接照搬。
所以 `Brave Love` 基于 WordPress 做了新的内容模型设计,例如:
– `moment`:点点滴滴
– `love_list`:恋爱清单
– `note`:随笔说说
– `story_milestone`:关于我们故事节点
这让每一个页面不再只是“样式模板”,而是建立在真实内容结构之上。
### 2)模板体系重建
WordPress 的页面模板、单篇模板、归档模板、评论系统和媒体系统,与 Typecho 的实现思路完全不同。
因此,很多原本在其他系统里通过主题逻辑拼出来的内容,在这里都必须重新组织。
`Brave Love` 最终形成了:
– 首页模板
– 关于我们模板
– 点点滴滴模板
– 甜蜜相册模板
– 随笔说说模板
– 祝福留言模板
– 恋爱清单归档模板
– 点滴详情模板
### 3)后台配置重建
一个真正能用的 WordPress 主题,不能只看前台。
所以除了前台页面,这次移植还做了大量后台能力:
– Customizer 配置
– 天气城市管理
– 纪念日管理
– 相册旧数据管理
– 页面链接、图标、页脚导航配置
– 访问统计与自定义代码配置
这部分工作其实决定了主题是不是“产品”,而不是一套 Demo。
### 4)交互与视觉重做
在保留情侣主题浪漫气质的同时,`Brave Love` 逐步走向了更克制的杂志感方向:
– 默认固定浅色模式,不再跟随系统自动切换
– 增加右上角全局深浅色切换按钮
– 统一筛选区、按钮、卡片、Hero 与页脚的节奏
– 减少突兀渐变和强对比
– 强化手机端单手浏览与阅读连续性
这也是为什么它最终没有停留在“可爱风模板”,而更接近一个可长期使用的内容主题。
## 四、技术栈与实现方式
`Brave Love` 当前使用的核心技术栈如下:
– `WordPress 6.0+`
– `PHP 7.4+`
– `Bootstrap 5.3.2`
– `PhotoSwipe 5.4.2`
– 原生 `JavaScript` + WordPress 提供的 `jQuery`
– `Open-Meteo Forecast / Air Quality API`
– 本地化字体与前端依赖资源
– 基于 `transient` / `post meta` 的轻量缓存策略
– 本地 Docker WordPress 测试环境
从实现角度看,我更在意几个点:
### 1)尽量减少外部依赖
项目在后期做了明显收口:
– Bootstrap、PhotoSwipe、字体资源改为主题本地化
– 去掉多个外部头像与图片兜底依赖
– 降低前端核心体验对外链服务的依赖
这样做的好处是:
– 更稳定
– 更适合正式发版
– 也更像一个可以放心部署的主题产品
### 2)围绕 WordPress 原生能力开发
很多功能最终都选择和 WordPress 原生能力深度结合,而不是另起一套逻辑,例如:
– 评论系统承接祝福留言
– 自定义文章类型承接页面内容模型
– Customizer 承接主题配置
– 媒体库与特色图承接相册能力
这让主题后续的维护成本更可控,也更符合 WordPress 用户的操作习惯。
### 3)发布前加入更严格的质量检查
在 1.0 前,项目补做了比较完整的发布检查流程,包括:
– PHP 全量语法检查
– 主题结构检查
– 安全扫描
– 本地运行态 smoke test
– 主题截图与安装包校验
– 后台输入校验、权限边界与安全跳转审计
这也是 `v1.0.0` 和前面版本最大的区别之一:
它不只是“能跑”,而是开始按“可发布”的标准去看待整个项目。
## 五、版本演进:从 v0.1 到 v1.0,这个主题是怎么长出来的?
`Brave Love` 的演进速度很快,从 `2026-03-29` 的 `v0.1.0` 到 `2026-04-03` 的 `v1.0.0`,几乎是以高频迭
代的方式在推进。
如果按阶段来看,大致可以分为 6 个版本阶段。
### 第一阶段:v0.1.x,打基础
这是项目从 0 到 1 的阶段。
这个阶段完成了:
– 6 个核心页面模板
– 4 个自定义内容类型
– Bootstrap 响应式基础框架
– PhotoSwipe 灯箱
– 双计时器系统
– 天气模块雏形
– 点点滴滴时间轴与详情页
– 相册上传与展示的初步能力
– 本地 Docker 测试环境
这一阶段最大的特点是“快速建立骨架”。
### 第二阶段:v0.2.x,开始关注页面质量与安全
在基础结构稳定后,项目开始进入“能用”之后的下一步:
– 恋爱清单页面重做
– 安全扫描工具加入
– XSS 相关输出修复
– 移动端样式与点滴摘要优化
这个阶段开始出现明确的产品意识:不只是做页面,还开始关心安全、内容表达与真正的使用体验。
### 第三阶段:v0.4.x,把随笔说说做成独立内容页
`v0.4.x` 是一个非常关键的阶段。
这里完成了:
– 随笔说说三级级联筛选
– 瀑布流布局
– 前台发布能力
– 想念度与心情表达
– 头像上传与情侣昵称配置
这意味着主题不再只有“静态展示页”,而开始具有持续生产内容的能力。
### 第四阶段:v0.6.x,进入体验调试与系统能力建设
`v0.6.x` 看似版本很多,实际上主要围绕三件事反复打磨:
第一,祝福留言重构。
第二,页脚 PV 统计与后台配置。
第三,深色模式与页面 Hero 区域的大量调试和修复。
这是一段很典型的“工程化调试期”:
– 留言页重构为瀑布流
– 加入评论审核
– 页脚访问统计上线
– 深色模式逐页适配
– Hero 背景层叠问题反复诊断和修复
从结果看,这一阶段虽然“看起来不那么性感”,但其实为后面的稳定定版扫掉了很多基础障碍。
### 第五阶段:v0.7.x,全面进入发布前收口
如果说前面是在做功能,那么 `v0.7.x` 更像是真正进入了“产品收口期”。
这个阶段完成了很多关键动作:
– 移除有问题的子页面 Hero 结构
– 修复测试脚本和发布路径
– 加强权限检查、Meta Box 保存保护与安全重定向
– 恢复和统一年份筛选
– 将字体、Bootstrap、PhotoSwipe 本地化
– 给相册增加缓存与失效策略
– 加入正式主题截图
– 祝福留言本地头像池
– 统一各页面 Hero、筛选区与卡片节奏
– 恋爱清单 canonical 和 URL 收口
– 新增关于我们页面与故事节点内容模型
– 首页天气升级为多城市详情弹层
– 文档和主题元信息逐步对齐
可以说,今天 1.0 的大部分“完成度”,都是在 `v0.7.x` 这个阶段打磨出来的。
### 第六阶段:v1.0.0,正式产品发布
`v1.0.0` 的重点不在继续加功能,而在于正式发布的完整性。
这一版重点完成了:
– 主题头信息正式化
– README / Release / Checklist / Test Report 重写
– GitHub About 文案统一
– 主题截图重做
– 后台输入与配置字段的 sanitize 加固
– 权限边界补齐
– PV 统计污染修复
– 重定向统一为安全跳转
– 本地 smoke test 与安装包检查完成
如果说前面的版本是在不断逼近“一个好主题”,那么 `1.0.0` 做的是把它真正变成“一个可以发出去的产品”。
## 六、完整版本轨迹
为了更完整地记录项目过程,这里也把完整版本链路列出来。
### v0.1.x:从骨架到内容基础
这一段主要完成了:
– 初始架构建立
– 计时器系统完善
– 天气模块从雏形到卡片化
– 点点滴滴年份筛选、摘要和详情页能力
– 相册与灯箱能力补齐
– 测试环境和基础诊断能力加入
### v0.2.x:页面质量和安全基线
这一段主要完成了:
– 恋爱清单页面重做
– 安全扫描工具加入
– 输出转义修复
– 点滴列表与移动端样式优化
### v0.4.x:随笔说说独立成型
这一段主要完成了:
– 随笔说说三级筛选
– 瀑布流布局
– 前台发布表单
– 点滴卡片样式优化
– 情侣头像上传与首页展示
### v0.6.x:留言、统计、深色模式与 Hero 调试
这一段主要完成了:
– 祝福留言页重构
– 页脚 PV 统计与后台配置
– 深色模式适配
– 页面标题、布局与页脚细节调整
– Hero 背景结构反复诊断和修复
### v0.7.x:全面收口,进入准发布状态
这一段主要完成了:
– 子页面 Hero 策略调整
– 测试脚本修复
– 权限与安全加固
– 年份筛选与日期口径统一
– 静态资源本地化
– 相册缓存
– 主题截图
– 本地头像池
– 恋爱清单 SEO 收口
– 关于我们页面与故事节点
– 首页天气模块重做
– 元信息和文档统一
### v1.0.0:正式发布
`v1.0.0`
这一版完成了:
– 正式发布文档重写
– GitHub About 文案统一
– 主题详情与截图重做
– 发布级别的 sanitize / capability / redirect 加固
– 本地测试、安装包、元信息与文档最终对齐
## 七、这次开发里,我最在意的几件事
回头看整个项目,我最在意的不是“功能数量”,而是下面几件事。
### 1)它是否真的适合长期记录
情侣主题最怕的是“第一眼惊艳,第二天就不想用了”。
所以后期的很多优化,其实都在围绕长期记录展开:
– 内容是否可归档
– 页面是否可回看
– 筛选是否顺手
– 卡片是否耐看
– 手机端阅读是否顺滑
– 深浅色模式是否统一
### 2)它是否像一个真正的 WordPress 主题
不是能跑就行,而是:
– 是否有完整主题信息
– 是否有后台配置路径
– 是否能被正常上传安装
– 是否有正式截图
– 是否有发布文档
– 是否有测试报告
`v1.0.0` 真正完成的,就是这层“产品感”。
### 3)它是否尊重原始灵感,同时走出自己的路
`Brave Love` 的确来自 `zwying0814/Brave` 给我的启发,也基于其公开项目与思路做了移植和继续开发。
但我更希望它不是一个停留在“复刻”的项目,而是在 WordPress 里,形成属于自己的结构、节奏与完整度。
它保留了情侣记录站最核心的情绪价值,也逐步长成了一套更适合 WordPress 用户使用的主题系统。
## 八、致谢与说明
最后,需要认真写明这件事:
`Brave Love` 的产品灵感、情侣记录站的核心主题方向,以及部分早期代码迁移工作,基于开源项目
[`zwying0814/Brave`](https://github.com/zwying0814/Brave) 展开。
原始 `Brave` 是一款非常有代表性的 Typecho 情侣主题,原作者赵阿卷在公开介绍中,将其定位为面向情侣博客
场景的主题,包含计时器、留言板、恋爱清单、点点滴滴等功能模块。
`Brave Love` 在此基础上,围绕 WordPress 的主题体系、内容结构、后台能力与发布流程,进行了移植、重组、
扩展和持续迭代开发。
感谢原始开源项目提供的灵感与基础方向,也感谢开源世界里那些让“喜欢”和“认真”都能被延续的作品。
## 九、结语
从 `v0.1.0` 到 `v1.0.0`,`Brave Love` 只用了几天时间。
但真正完成的,不只是一个主题版本号,而是一条从“想做一个情侣站”到“认真发布一个主题产品”的路径。
如果说这次发布有什么意义,我想它是:
把那些原本零散的喜欢、记录、纪念、仪式感,做成了一个可以被长期保存、长期回看、长期使用的 WordPress 主
题。
而这,或许正是“Brave Love”这个名字最想表达的东西。
—
## 参考链接
– 原始项目仓库:<https://github.com/zwying0814/Brave>
– 原作者介绍页:<https://blog.zwying.com/archives/59.html>
– 当前 WordPress 移植项目:<https://github.com/unclecat/WP_Brave>

原创文章,作者:彩虹,如若转载,请注明出处:https://www.1ink.ink/archives/733