Vera

ZsAdmin「智数」BBS社区插件 前端模板标签文档

数据迁移实战：建表与版本升级时容易忽略的5个致命细节

最近在重构一个老插件时踩了不少坑，总结下数据迁移中最容易翻车的几个场景。建表SQL看着简单，但版本迭代时经常出现字段漏改、索引失效等问题： 1. 默认值陷阱 ALTER TABLE时如果没显式声明NOT NULL，老数据会被自动填充NULL而不是默认值： // 错误示范 ALTER TABLE `plugin_orde

报错信息像摩斯电码？我按"症状-真凶-秒查"整理了一份速查备忘录

昨晚三点被监控告警炸醒，生产环境抛了个 Undefined index: access_token，我盯着这行字愣了半分钟——明明本地跑得好好的。后来才想起是微信授权回调里少了一层 isset，但最气人的不是这个，是我花了二十分钟才确认问题不在 Redis、不在队列、不在别人改的配置，就在自己上周"临时"写的那个 if

分层写到"贫血"与"充血"之间：我用"命令对象"模式把 controller 从"参数搬运工"里救出来的实践

之前按常规 MVC 拆完，controller 里还是挤满了 $request->get_param('foo') → validate_foo() → service->do_something($foo, $bar, $baz) 的流水线代码。十几个参数一多，改个字段名要动三四个文件，service 方法签名膨胀得

ThinkPHP 模型 `saveAll` 批量更新时，我因为漏看了第三个参数，把全站商品价格改成了同一个数

昨晚给商城后台加了个"批量改价"功能，测试环境跑得好好的，上线后运营反馈：怎么所有 SKU 价格变成一样了？ 冷汗下来，回滚数据，翻代码。问题就出在 `saveAll` 的调用方式上。 先看我写的错误代码： // 从 Excel 导入的价格数组 $priceList = [ ['id' => 101, 'price'

后台 Ajax 接口"半开半掩"：我如何用 `check_ajax_referer` 与自定义 capability 织了一张"双层滤网"

上周给插件加了一个"批量导出用户行为日志"的后台 Ajax 接口，本地测得飞起，上线第二天就被安全组扫出"未授权访问"——明明挂了 nonce，访客怎么还能触发？追查下来发现是check_ajax_referer和权限校验的"职责真空"被我搞混了，今天把踩的坑摊开聊聊。 第一层坑：nonce 不是身份，只是"票根" 我

插件上线前最后一遍 walkthrough：我整理的「权限-路由-菜单-配置」四维度逐项确认表

上周又踩了个坑——本地测得好好的插件，上到 staging 发现超级管理员能看到菜单，普通管理员点进去直接白屏。根因是 add_menu_page 的 capability 参数和实际页面里的 current_user_can 校验用了两个不同的字符串，一个 manage_options 一个 manage_plugi

钩子调试实战：用过滤器动态修改第三方插件行为

遇到需要修改第三方插件输出内容时，直接改源码是最差选择。分享个实战案例：通过过滤器钩子动态替换插件输出的HTML结构，同时保持原始处理逻辑完整。 以修改某个电商插件价格显示为例，核心代码： add_filter('plugin_price_html', function($original_html) { // 调试时