这个错误经常出现在删掉一个旧主题、切换分支或从另一台服务器恢复数据库之后。文件系统里已经没有主题目录,但数据库仍保留主题注册记录,或者商店配置仍指向旧的 `theme_id`。Magento 解析主题继承关系时找不到物理目录,最后只抛出 `theme_dir` 参数缺失。

继续阅读

自定义命令里调用客户、税率或订单服务时,常见异常是 `Area code is not set`。把 `$state->setAreaCode('adminhtml')` 塞进构造函数,当前命令也许能跑,但随后执行任意 `bin/magento` 命令又可能变成 `Area code is already set`。原因是 Magento 启动 CLI 时会实例化命令列表,构造函数不是“只有执行这条命令时才运行”。

继续阅读

magento 2执行setup:upgrade提示pub/static没有写权限,别再直接chmod 777了

继续阅读

调支付接口时,如果请求、回调和状态变化都写进 `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。继续阅读

项目 1241 到 1250 共 1307个

每页
设置升序顺序