frameworks - SugarCRM $beanFiles 数组修改最佳实践

Question

在 SugarCRM 中，您可以创建自定义模块(例如 MyModule)，它们就像库存对象一样保存在/modules 中，具有任何默认元数据、 View 、语言文件等。对于自定义模块 MyModule，您可能有一些东西喜欢:

 /modules/MyModule/MyModule.class.php
 /modules/MyModule/MyModule.php
 /modules/MyModule/language/
 /modules/MyModule/metadata

等等，以便一切都得到很好的定义并且所有模块都保持在一起。该模块通过诸如 /custom/Extension/application/Include/MyModule.php 之类的文件向系统注册，其内容如下:

<?php 
$beanList['MyModule'] = 'MyModule';
$beanFiles['MyModule'] = 'modules/MyModule/MyModule.php';
$moduleList[] = 'MyModule';

显然，$beanFiles 数组引用我们可以在其中找到基本模块的类，通常是 SugarBean 对象的扩展。最近我被告知我们可以调整该文件的位置以进行自定义，这在一定程度上是有意义的。将其设置为 $beanFiles['MyModule'] = 'custom/modules/MyModule/MyModule.php'; 将允许我们通过模块加载器访问基类，即使安全扫描工具阻止了核心文件更改，这也将使我们能够不完全扩展，而是替换诸如帐户或调用之类的库存模块，而无需修改核心文件并进行系统升级来消除更改。

所以这是我的问题:这里的最佳实践是什么？我多年来一直致力于 SugarCRM，这是我第一次尝试修改 $beanFiles 数组。我担心的是，我在这里偏离了最佳实践，而且不知何故，两个文件 modules/MyModule/MyModule.php 和 custom/modules/MyModule/MyModule.php可能会被加载，这会导致 PHP 中的类名冲突(即因为两个类都被命名为 MyModule...)。显然，对该类的任何引用都需要更新(例如与该模块一起使用的入口点)，但是我是否遗漏了任何潜在的后果？

Answer 1

从技术上讲，它应该没问题，但我可以看到，如果核心版本和您的版本都被引用，那么两者可能会发生冲突。这一切都取决于场景，但我更喜欢扩展核心 bean，并在堆栈中找到可以使用我的自定义版本来代替核心​​ bean 的位置。几年前我在这里写了一个例子:https://www.sugaroutfitters.com/blog/safely-customizing-a-core-bean-in-sugarcrm

对于大多数用例，有一种方法可以劫持 Sugar 以在给定点使用您的 Bean。

如果您无法解决这个问题，您可以随时使用 grep 来查看核心模块明确包含在何处，以确保将来不会发生冲突。