2

在 SugarCRM 中，您可以创建自定义模块（例如 MyModule）并将它们保存在 /modules 中，就像库存对象一样，带有任何默认元数据、视图、语言文件等。对于自定义模块 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';允许我们通过 Module Loader 访问基类，即使安全扫描工具阻止核心文件更改，这也将允许我们不完全扩展，而是替换库存模块，如 Accounts 或 Calls，而无需修改核心文件和进行系统升级以消除更改。

所以这是我的问题：这里的最佳做法是什么？几年来，我一直在密切地使用 SugarCRM，这是我第一次尝试修改$beanFiles阵列。我担心的是我在这里偏离了最佳实践，而且不知何故这两个文件modules/MyModule/MyModule.php都custom/modules/MyModule/MyModule.php可能被加载，这会导致 PHP 中的类名冲突（即因为这两个类都被命名为 MyModule...）。显然，对类的任何引用都需要更新（例如，与此模块一起使用的 entryPoint），但我是否遗漏了任何潜在的后果？

4

1 回答 1

2

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

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

如果您无法绕过它，您可以随时使用 grep 来查看明确包含核心模块的位置，以确保以后不会发生冲突。

于 2014-07-14T18:15:37.557 回答