Drupal源控制策略？

在标准的基于php或源代码的项目中,我们可以轻松地将所有代码保存在SVN中,并且每个开发人员都可以签出自己的副本并在相同的代码上进行协作.

然而,在开发Drupal站点时,大部分工作都在"设置"中.除了主题和模块,你没有任何"源代码".如何运行同一站点的多个实例,以便开发人员可以同时工作但共享他们的工作？

示例场景:

我们启动了一个创建内容类型为"X"的Drupal站点的初始版本.我们最初还在网站上启动了一个视图,该视图按时间顺序列出了"X"类型的所有节点.客户端开始使用网站,添加内容,菜单项等.

计划在下一个版本中为该视图添加用户搜索功能.但是,它的设置包含在数据库中.我们可以将生产数据库复制到我们的开发版本,以便在我们更改视图时获取最新数据.但在此期间,客户端仍然可以更新站点,使我们的开发数据库不同步.当我们准备将新视图推向生产时,除了手动重复在生产安装上设置它的步骤之外,还有更简单的方法吗？

我认为这里的一个好策略是使用安装配置文件API.使用安装配置文件API,您可以使用Drupal管理工具执行大多数操作.大多数核心表单只是在变量表中设置变量.为了能够合理地版本化您的非内容数据库内容,即配置,使用更新功能是明智的.

在我的网站上,我们有模块"ec",除了它的ec.install文件包含更新功能,例如ec_update_6001()

您的主要安装功能可以负责在您为使模块更新而进行的任何新安装上实际运行更新.

function ec_install() {
  $ret = array();
  $num = 0;
  while (1) {
   $version = 6000 + $num;
   $funcname = 'ec_update_' . $version;
   if (function_exists($funcname)) {
     $ret[] = $funcname();
     $num++;
   } else {
     break;
   }
  }
return $ret;
}

现在跟随我们实际文件中的一两个样本更新函数

// Create editor role and set permissions for comment module
function ec_update_6000() {
  install_include(array('user'));
  $editor_rid = install_add_role('editor');
  install_add_permissions(DRUPAL_ANONYMOUS_RID, array('access comments'));
  install_add_permissions(DRUPAL_AUTHENTICATED_RID, array('access comments', 'post comments', 'post comments without approval'));
  install_add_permissions($editor_rid, array('administer comments', 'administer nodes'));
  return array();
}
// Enable the pirc theme.
function ec_update_6001() {
  install_include(array('system'));
  // TODO: line below is not working due to a bug in Install Profile API. See http://drupal.org/node/316789.
  install_enable_theme('pirc');
  return array();
}

// Add the content types for article and mtblog
function ec_update_6002() {
  install_include(array('node'));
  $props = array(
    'description' => 'Historical Movable Type blog entries',
  );
  install_create_content_type('mtblog', 'MT Blog entry', $props);
  $props = array(
    'description' => 'Article',
  );
install_create_content_type('article', 'Article', $props);
return array();
}

实际上,这主要解决了数据库和Drupal代码的版本控制问题.我们广泛使用它.它允许我们推广更改数据库配置的新代码,而无需重新导入数据库或进行实时更改.这也意味着我们可以正确测试版本,而不必担心隐藏的数据库更改.

最后cck和views支持这种方法.请参阅此代码段

// Enable CCK modules, add CCK types for Articles in prep for first stage of migration,
// enable body for article, enable migration modules.
function ec_update_6023() {
  $ret = array();
  drupal_install_modules(array('content', 'content_copy', 'text', 'number', 'optionwidgets'));
  install_include(array('content', 'content_copy'));
  install_content_copy_import_from_file(drupal_get_path('module', 'ec') . '/' . 'article.type', 'article');
  $sql = "UPDATE {node_type} SET body_label='Body', has_body=1
  WHERE type = 'article'";
  $ret[] = update_sql($sql);
  return $ret;
} 

我刚才用CVS和Subversion最佳实践写了一篇关于无痛Drupal版本控制的文章.

不幸的是,正如您所指出的那样,仍有源控制数据库的问题.有一些建议的方法,我在另一篇文章中提到过.

将数据库中的Drupal设置转换为代码一直在向前发展.在这个领域真正有用的两个模块是:

功能 - 允许您收集内容类型,分类,视图甚至提要等实体.我们非常成功地使用它,并且可以在开发人员之间共享这些更改.

Strongarm - 允许使用上述模块存储和导出变量.我已经用这个模块做了一些测试,但我们没有使用它,很简单因为我们真的不需要这个功能.

这些解决了将站点设置保留在数据库中的最大问题.然而,它们并不完美...我们发现不正确支持或支持的模块.