调支付接口时,如果请求、回调和状态变化都写进 `system.log`,定位一笔订单很痛苦。临时用 `file_put_contents()` 虽然快,但绕过日志级别、异常处理和轮转。比较稳的方式是给模块配置独立的 Monolog Handler,再把这个 Logger 只注入需要的类。

继续阅读

一个模块里有三个 Data Patch:先创建默认数据,再补关联关系,最后迁移旧配置。只把类名写成 `Patch01`、`Patch02` 并不能保证执行顺序,文件时间也不可靠。Magento 判断顺序看的是 patch 之间声明的依赖。

继续阅读

Magento 老版本和一些扩展曾把 PHP serialize 字符串写进数据库,新版本改用 JSON 反序列化后,读取旧值就会报 `Unable to unserialize value` 或 `Syntax error`。最危险的“修复”是直接改 `vendor/magento/framework/Serialize/Serializer/Json.php`,让它失败后自动尝试 PHP `unserialize()`。这样会把脏数据问题扩散到整个系统,也让后续升级更难判断。

继续阅读

编译时报 `Class Vendor\Module\Model\SomethingFactory does not exist`,很多人的第一反应是删除 `generated` 再编译。这个办法只对“生成目录不可写或旧代码残留”有效。如果源类名称、命名空间或 Composer 自动加载本身就有问题,清十次生成目录也不会好。先分清报错的是“应该由 Magento 生成的 Factory”,还是“项目里本来就该存在的普通类”。

继续阅读

后台改商品时遇到过一个很怪的问题:页面没有明确报错,保存后内容还是旧的,日志里只有 No data to save。刚开始一直盯着商品 Repository 和插件,后来才发现代码根本没机会处理表单数据——保存请求先返回了 301,浏览器跟着跳到新地址时,POST body 已经没了。

继续阅读
这个问题最容易被“后台数量还有几十个”带偏。Magento 2.3 以后用了 MSI,页面上的 Source Item 数量并不等于前台可售数量。真正参与加购判断的是库存、来源分配、缺货阈值和 reservation 共同计算出来的 salable quantity。继续阅读
我遇到的场景是:客户在结账页停留着,又在另一个标签页登录账户,回来继续提交就报 No such entity with cartId。这不是 quote 表一定丢了,而是前端还握着旧的 guest cart 标识,登录动作已经把购物车合并到 customer quote。继续阅读
自定义 Admin Grid 卡在 Loading 时,我以前总先怀疑 SQL。后来发现很多时候接口已经 200,真正卡住的是 UI Component 找不到它等待的组件,spinner 就永远不会被替换掉。继续阅读
Mixin 没生效时最浪费时间的做法,是不断在 JS 文件里加 console.log。如果 RequireJS 根本没合并到那份配置,日志写再多也不会出现。继续阅读
后台列表加批量操作后,勾选几行再提交却提示没有选择记录,通常不是控制器收不到参数,而是 UI Grid 用来标识行的字段不一致。继续阅读

项目 911 到 920 共 1054个

每页
设置升序顺序