编译时报 `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 只注入需要的类。

继续阅读

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

继续阅读

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

继续阅读

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

继续阅读

生产站改了一点 CSS,如果直接运行不带参数的 `setup:static-content:deploy`,Magento 会把后台主题、Luma、多个语言包和所有自定义主题一起编译。站点越大,发布时间越长。实际只改一个主题时,部署范围可以收得很小,但 theme、area 和 locale 最好一起写清楚。

继续阅读

网站从正式域名复制到测试域名后,前台和后台都可能陷入重定向循环。这个问题不能靠反复清缓存碰运气,先看清楚到底是哪两个地址在互相跳。Cookie 域名、Base URL、反向代理传来的 HTTPS 标记,都会造成同一个表象。

继续阅读

有些站只卖很少几个产品,商品对比和Wishlist基本用不上。最容易想到的做法是直接禁用 `Magento_Catalog` 或 `Magento_Wishlist`,但前者根本不能动,后者也可能被主题、客户中心或第三方模块依赖。我的处理原则是:业务只是“不显示”,就只处理前台入口,不把整个模块从系统里拔掉。

继续阅读

项目 1 到 10 共 441个

每页
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
设置降序顺序