八月 2014

使用Deploy和Features导出Entities

Deploy Module可以把任何支持UUID的Entity导出到Features中。这个功能在创建安装范本或演示时非常有用,或者用于处理一些既非配置,也非内容的对象。

使用Deploy导出内容:

  • 安装DeployFeatures。如果不需要使用Deploy进行Drupal站点之间的内容同步,知识想要导出到Features的话,就无需关心Service Module的安装了。

  • 进入admin/structure/deploy/plans/add建立一个新的部署计划。

  • 选择聚合方式,参考Deploy基础用法,来获取关于将内容加入部署计划的不同方法。

  • 选择Fetch only,因为我们不需要部署处理,也不需要服务节点,而且没有选择这个选项的话,部署计划也不会出现在Features界面中。

Deploy的基本用法

在这个演示中,我们会创建和部署一个新的Node,然后发布一个针对该Node的更新。

部署

一次部署分为两个阶段:把内容添加到部署计划,发布部署计划。部署计划的发布将内容添加到目标服务器。

部署计划

一个部署计划包含一组将要发布到目标服务器上的内容。这些内容可以手工添加到部署计划中,也可以使用Views聚合或者Rules进行自动化操作。

手工添加内容

  1. 在源服务器进入node/add/article,创建一个新的Article。然后随便选一些选项并保存。

  2. 进入admin/content/node,查看刚新建的Node,从Update options中,Add to managed deployment plan下选择部署计划,点击Update按钮,然后在其他需要添加的内容上做同样的操作。

  3. 要发布这个计划,进入admin/structure/deploy然后点击Deploy连接,点击Deploy按钮进行确认。

使用定制Entity的时机和动机

介绍

Drupal 7开始出现了Entity,这一改进大大的提高了Drupal模块的数据建模能力。在这之前,Drupal是一个为文章设计的数据结构,我们的方案和数据建模只能在这个基础上修修补补。

然而,在我们已经习惯于利用内容类型和字段解决所有的数据模型问题的情况下,向Entity迁移也的确不是一个轻而易举的事情。

Entity需要一些时间和经验

如果你没有很多时间,也没有直接面对Entity API的经验,而手上的项目又逼近Deadline,那么这不是一个开始Entity的好时机,Entity的学习曲线也是颇为陡峭的。

利用 Entity construction kit(ECK)可能可以简化这一学习过程,这个模块提供了一个Entity的管理界面,尽管如此,要获得Entity的好处,还是需要一些开发工作的。ECK支持Features,能够把一个自定义Entity导出成为代码化配置,并且封装成为一个现成的模块形式。

尽管受限于实际情况,你可能不能立即投入Entity的怀抱之中,不过尽早投入时间来学习Entity还是值得的。

在版本管理过程中增强Drupal编码标准控制

根据Drupal.org的统计结果,Drupal社区共拥有:

* 27098个模块

* 2012个主题

* 827个发行版

* 33875个开发者

另外,来自230个国家,说着181种不同语言的107万4000多个用户在使用Drupal。上述数据完全来自Drupal社区。

我想要花时间来说一下这一条:27098个模块,这些模块由大约33875个开发者贡献的巨量代码构成。世上没有两片相同的树叶,如此众多的开发者,当然也可能产生各自的编码风格,如果这样下去,一个模块的代码对于其他开发者来说,可能就完全是晦涩难懂的了。

编码规范很重要,尤其是对于Drupal这种大规模项目来说。规范的代码能让初次接触项目的开发者不至于一头雾水。在规范代码的帮助下,新晋者可以顺利的进入代码并顺利完成工作,而无需在奇怪的变量命名和古怪的代码格式上浪费时间。

Drupal实现了大量的规范。从简单的代码格式,到复杂的安全实现,都被这些规范所涵盖。每个Drupal模块都要遵守这些标准。如果所有的模块都满足这一要求,那么Drupal就能够在安全、性能以及易读性方面更上一层楼。