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

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

继续阅读

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

继续阅读

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

继续阅读

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

继续阅读

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

继续阅读

项目 111 到 120 共 622个

每页
设置降序顺序