PrestaShop 1.7如何重写Entity类为导入类型下拉列表添加新选项

你不需要重写该final类即可实现需求，共有3种侵入性从低到高的可行方案，优先推荐第一种：

方案1：装饰器扩展下拉数据源（推荐） #

final类仅用于定义内置导入类型常量，下拉菜单的选项列表不会直接硬编码读取常量渲染，而是通过对应的数据源提供类（通常为导入表单的DataProvider或表单Type类）输出。

• 自定义装饰器实现对应数据源接口，注入原有数据源服务
• 在装饰器的选项返回方法中，先调用原有服务获取内置选项，再追加你自定义的SVG产品导入类型及对应标识
• 在模块的services.xml中配置装饰器，替换原有数据源服务即可
• 额外实现对应ImportProcessorInterface接口的处理器类，绑定你新增的导入类型，处理SVG文件解析、产品数据写入逻辑即可

方案2：编译器Pass替换常量读取逻辑 #

如果下拉菜单确实硬编码直接读取src/Core/Import/Entity.php常量生成选项，可通过容器编译阶段修改逻辑：

• 在你模块的DependencyInjection/Compiler目录下新增自定义编译器Pass
• 在Pass的process方法中，定位到生成下拉选项的服务定义，替换其中读取Entity类常量的逻辑片段，插入你的自定义选项
• 在模块的扩展类中注册该编译器Pass即可

方案3：Composer类映射替换 #

如果上述两种方案都不适用，可通过composer类加载优先级实现类覆盖，无需修改核心源码：

• 在你模块根目录下新建和核心类路径完全一致的文件src/Core/Import/Entity.php，拷贝原有类的全部代码，新增你需要的导入类型常量
• 在模块的composer.json中配置autoload的classmap规则，将核心类的命名空间路径映射到你自定义的该文件
• 执行composer dump-autoload后，composer会优先加载你自定义的Entity类

注意：方案3对核心代码侵入性最高，后续核心版本升级如果修改了原Entity类的代码，你需要同步更新自定义类的内容，避免兼容性问题。

内容的提问来源于stack exchange，提问作者webgrig