SugarCRM $ beanFiles数组修改最佳实践

在SugarCRM中，您可以创建自定义模块（例如MyModule），并将它们保存在/模块中，就像股票对象一样，具有任何默认元数据，视图，语言文件等。模块MyModule的，你可能有这样的：

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

等等，让一切是很好的定义，所有的模块都放在一起。

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

显然$beanFiles数组引用在这里我们可以找到基本模块的类，通常SugarBean对象的扩展：该模块就成为该系统由诸如/custom/Extension/application/Include/MyModule.php文件，内容类似于注册。最近我被告知，我们可以为了定制而调整文件的位置，并且它在一定程度上是有意义的。如果将它设置为$beanFiles['MyModule'] = 'custom/modules/MyModule/MyModule.php';，则允许我们通过模块加载器访问基类，即使安全扫描工具可防止核心文件更改，也可能导致我们无法完全扩展，而是替换库存模块（如帐户或调用），而无需修改核心文件并通过系统升级消除更改。

所以这里是我的问题：这里的最佳做法是什么？我一直在SugarCRM工作很多年，这是我第一次试图修改$beanFiles阵列。我担心的是我偏离了这里的最佳实践，并且不知何故文件modules/MyModule/MyModule.php和custom/modules/MyModule/MyModule.php都可能被加载，这将导致PHP中的类名冲突（即，因为两个类都被命名为MyModule ...）。很明显，任何对类的引用都需要更新（例如，与这个模块一起工作的入口点），但是我错过了任何潜在的后果吗？

来源

2014-07-14 Matthew Poer

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

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

如果你无法绕过它，你总是可以grep看看明确包含核心模块的位置，以确保不会出现冲突。

来源

2014-07-14 18:15:37 egg

SugarCRM $ beanFiles数组修改最佳实践

回答

相关问题