使用Drupal 7安装配置文件的经验

Question

“如何编写Drupal 7安装配置文件”：http://drupal.org/node/1022020

有这方面的经验(好的还是坏的)？

上面的链接引用了创建安装配置文件的能力。问题是，它能做多少？

真正的目标是能够将所有内容放入定义网站的代码(和版本控制)中；权限，OG字段组设置，您可以命名它。然后把它作为从开发到阶段，到生产的常规生产路径。

我听说过这样的理论，即这种技术不仅可以用来建立一个站点，也可以作为从dev环境迁移到阶段和生产的工具。

显然，像Pressflow这样的组织能够构建一个预先配置的基本发行版，这是有好处的。但是，这种技术对于日常的网站更新和维护有多大的可行性呢？

Answer 1

我有一个网站在生产(再)建立每一个学年的安装配置文件。我有不同的网站在开发，我正在建设使用安装配置文件。

在我看来，尝试并将内容包含到安装配置文件中是一个皮塔。这似乎是一个很好的方式来编码一个网站的功能。但是我仍然依赖于build和Drush来运行额外的导入工具--就像迁移、Taxonomy_csvimport和备份迁移一样，将“内容”迁移到其他地方。

我确实喜欢使用安装配置文件“构建”站点代码库，并推荐Profiler模块来帮助您。你可以做很多安装配置文件。

Answer 2

我在一段时间前就开始考虑这一选择；我已经开始从一个现有站点向生成安装配置文件发出drush命令。我的一般想法是，备份未经修改的Drupal核心和cont肋骨模块的版本是低效和笨拙的分析；更好的方法是只提交makefile和包含自定义组件的安装概要文件。

还有一个悬而未决的问题:配置应该在安装配置文件中表示，还是在特性中表示。Drupal 8有更好的解决方案，但在此期间，许多人使用特性来部署配置选项。因此，我的假设是，我应该制作捕获我的配置的特性，并将这些特性保存在我的安装配置文件中。不过，我发现drush feature-revert并不总是很好地处理特性中的依赖关系。我没有深入了解它，但作为一种解决方法，多次运行drush fra (直到没有进一步改变)似乎是一种潜在的解决办法。还可以创建多个特性，然后依次安装，有效地手动管理依赖项。当然，功能不能捕获代码中的所有配置信息，但是手动手工在安装配置文件中手工完成所有配置对于较小的项目来说似乎过于劳动密集。

但有些人，我还没有达到对任何活动站点使用这种机制的地步。

Answer 3

不要尝试使用配置文件中的安装脚本来维护您的配置，除非您正在拍摄发行配置文件。在D8中使用特性或CMI的结果是维护配置的好方法。

将所有内容分组到一个配置文件中，以便您可以使用存根、钻取make文件和单个git存储库，这不仅是“理论”的，而且是保持事物组织和部署的极好方法。

您可以使用Aegir管理不同版本的概要文件之间的备份、部署和迁移。