Php 什么时候开发新的drupal模块，而不是使用现有的模块？

这可能适用于其他可扩展内容管理系统，但我一直在使用Drupal。具体来说，我创建了一个图像共享web应用程序，其功能依赖于比Drupal核心代码更多的原始代码。我使用WebForm模块，将其表单指向带有硬编码php的自定义页面，以编程方式创建节点和其他奇怪的巫毒

就在我完成之前，我意识到也许我应该制作自己的模块，或者我应该？ 即使回想起来，也很难说

---

您使用什么来决定何时需要编写新模块，以及何时可以从可用功能中拼凑出您正在寻找的功能？

当您希望轻松共享或重用功能时，请创建一个新模块。这样做是有开销的，所以如果是一次性的，就不值得了。

我更喜欢在drupal.org上搜索所有具有我所需功能的模块。我搜索drupal.org和groups.drupal.org（甚至可能是论坛）和该模块的名称，以了解其他人对它的看法。最后，我总是查看drupalmodules.com，看看社区中的其他人对此有何评论

---

如果我找不到我需要的东西，我就推出自己的模块。Plynx也是正确的，如果您计划重用该功能，请创建一个新的模块，如果它足够独特，还不存在。

我对此有一个强烈的意见，即所有自定义编码都应该在自定义模块中完成，只有一个可能的例外（见下文）：

我发现三种情况：

全新的功能-这显然需要一个封装新功能的自定义模块。它使它可重用，甚至可以变成一个“官方”贡献的Drupal模块，如果功能满足大众需求的话

调整现有功能-对于每个站点，我立即设置一个空白的自定义模块（以站点命名）。所有用于调整现有功能的自定义代码（无论是来自核心模块还是贡献模块）都发生在该模块中。这样，我的所有定制都被清晰地分开，这使得更新核心或其他模块变得更加容易，而不必不断地将我的定制重新应用到更新的代码中（当然，必须检查定制在更新后是否仍然有效，并根据需要调整或删除它们）

修复bug/添加缺失的功能-这是上述可能的例外情况。如果我的更改只是一个bug修复或添加了一个明显但缺少的功能，我可能只是在原始代码中这样做，将我的更改作为补丁提交给原始模块，希望它们能被纳入未来的版本中，从而使我的更改过时

---

根据我的经验，将定制与原始代码分离的“开销”并不是真正的“开销”，因为“一次性”调整和修复通常比预期的要长得多，并且在站点的生命周期中有增长的趋势。将它们从一开始就分开可以避免维护过程中的许多麻烦，因为应用更新和安全修复以及扩展调整将更加容易。

感谢您的精彩帖子。我真的很喜欢你对案例2的解释。将在我的下一个项目中采用它。