主题配置项：$zbp->Config 和那个后台设置页是怎么连上的

主题要让人能调，就得有个后台设置页。

Z-Blog 里这件事拆成两半：存，和显示。存靠 $zbp->Config('主题ID')，显示靠 Filter_Plugin_Admin_ThemeMng_SubMenu 这个钩子。这两半是分开的，很多人只知道一半，于是配置存进去了但没地方改，或者界面做了但存不住。

存：Config 本质上是个对象

写法很直接。

$zbp->Config('framehome')->cards = 3; 然后 $zbp->SaveConfig('framehome');

读的时候反过来：$zbp->Config('framehome')->cards，取不到给个默认值。

坑在 SaveConfig 上。 我最早不知道要这句，改完值当场生效，刷新后台一看又回去了。因为 Config 只是内存里改了，没落盘。

还有一点：Config 存的内容会被序列化进数据库，不要往里塞对象和资源。数组、字符串、数字、布尔都可以。塞对象的话，读出来可能是 __PHP_Incomplete_Class，看日志才知道。

显示：菜单是钩子加出来的

后台「主题管理」页面侧边那一条，来源是 Filter_Plugin_Admin_ThemeMng_SubMenu。

在 include.php 里挂上，往 $type、$actions 里 push 一项，指向主题目录下一个 php 文件，比如 main.php。

这里有个细节：push 的必须是 zbp 的对象结构，不是随便一个数组。我见过写成关联数组的，页面不报错，但菜单项点了没反应。

另外权限判断要自己加。不写的话，普通编辑也能进设置页改配置。可以用 $zbp->CheckRight('theme') 兜一下。

main.php 里怎么写

它的身份是「后台页面」，所以要有完整的 HTML 头尾，不能只输出一个表单就完事。

常规套路是：引入后台公共头 → 判断有没有提交 → 有提交就写 Config 并 SaveConfig → 输出表单 → 引入公共尾。

提交判断不能只看 $_POST 非空。要带一个 token 或者 action 参数做区分，否则后台别处的表单提交也会撞进来。

表单元素的 name，和 Config 的字段名保持一致，接收那一步可以少写一堆映射。

一个容易忽略的问题

Config 是在主题启用时才被读取的。

也就是说，你在主题 A 里存的配置，切到主题 B 之后 A 的配置还在数据库里，但不会被读。切回来又有了。

听起来合理。但如果你在 B 的模板里手贱去读了 A 的 Config 字段，也能读到旧值——这会造成「明明换了主题，某个数字还是老的」这种迷惑现象。

所以模板里读配置，一律用当前主题 ID，别写死。

调试时的一件事

配置改了前台不生效，先别怀疑代码。

Z-Blog 有配置缓存，清一次再试。zb_users/cache/ 下的东西删掉，后台右上角清理缓存也行。

我最早有一回排查了两个小时，最后发现就是没清缓存。

不体面，但真实。