第六部 全新的后台

##全新的配置管理系统

对建站人员和开发者来说，Drupal 8的最值得期待的变化就是配置管理系统。在Drupal 7和之前的版本中，内容和配置都保存在数据库里（甚至有的配置和内容会混在同一张表中），这使得不同环境间的站点迁移非常困难（例如开发环境到生产环境）。围绕这个难题，诞生了很多相关的技术，包括 hook_update_N(), Features module，还有更古老的方式——记录一套环境上的配置，然后去另一套环境上手工执行。然而，所有这些尝试都是做着同一个事情：想要规避一个残酷事实——Drupal核心没有很好的提供配置发布支持，直到Drupal 8的出现。

在Drupal 8中，所有的配置都变了（包括标准的管理配置项目，例如站点名称之类；以及任何的ConfigEntity，这里包括Views，用户角色以及内容类型，都会通过统一的configuration API运行），每个环境都拥有一个”备用配置”和一个”激活配置”仓库，备用仓库一般保存的是从其他环境中导入的待审核配置，而激活配置保存的是目前站点运行过程中将要读取的配置。出于性能上的考虑，缺省情况下激活配置保存在数据库中的配置表中（和Drupal 7中的Variables表类似），当然，保存位置是可变更的。例如Configuration Development Module使用Drupal 8核心对待备选配置的方式来处理活动配置——将活动配置写入文件系统的YAML文件中。

Drupal 8自带了一个基础的UI用于处理配置的导入和导出，并且配置还可以利用Drush的config-*系列命令来进行操作，这些操作也可以支持后续的Git之类的版本管理操作。

基础的配置变更流程如下：

1. 在开发环境中，导出激活配置，导出结果是一个包含很多YAML文件的tar压缩包。

2. 在生产环境，导入这些文件，这些配置会出现在备选配置区域中。

3. 在配置界面，现在可以看到一个列表，其中列出了发生变化的配置，并且可以进一步查看变更前后的差异。

4. 如果这些变更可以接受，用户可以选择进行同步，同步过程将会把生产环境中的备选配置替换掉当前的激活配置，Drupal就会使用新的配置提供服务了。

当然，还有一些配置是针对当前环境的，这些配置是不应该跨环境进行迁移的，一个例子就是Cron上次运行的时间。对于这种情况，有一组State API可以用来处理这种短期配置。

##什么是内容发布

Drupal 8没有对Node, User以及Taxonomy Terms之类的内容进行站点间迁移的支持（可能会在8.1或8.2中提供），不过一个进步是Drupal 8为每个内容都提供了UUID（全局唯一标识符）。UUID可以用于判断一个内容是否存在于目标站点，而不会去理会数字ID是否冲突，这大大的简化了内容的导入和导出。注意Deploy modue的Drupal 8版本。如果你还在Drupal 7，可以通过UUID Module得到类似效果。

##Entity，到处都是Entity

Entity是Drupal 7中的一个新概念、新特性，他抽象了以前Node才有的添加字段的能力，把这一能力扩展到了Users，Taxonomy Terms等数据结构上。然而，Drupal 7的核心API非常有限，需要Entity API模块的辅助来完成一些基础工作，例如保存和删除。

在Drupal 8中，Entity API进行了全面增强，不仅克服了Drupal 7版本的缺陷，还极大的增强了开发者的体验。所有的Entity现在都实现了EntityInterface这一接口（再也不用猜那100多个hook了），下面对比一下读取活动语言的代码：

<?php
# Drupal 7 code.
$node->title
$node->body[$langcode][0]['value']

# Drupal 8 code.
$node->get('title')->value
$node->get('body')->value
?>

除了现在已有的Entity之外，几乎所有可以新建的东西都成了Entity，这极大的增强了Drupal开发过程的一致性。现有两种Entity：配置和内容Entity。他们有什么区别呢？

###Content Entity

• 可以自定义字段

• 缺省存储于数据表中

• 多数在前端创建

####举例

• Nodes

• Custom Blocks

• Users

• Comments

• Taxonomy 词汇

• Menu Links

• Aggregator Feeds/Items

###Config Entity

• 能够发布到不同的环境

• 存储在配置系统中

• 多数在后端创建

####举例

• 内容类型

• 用户角色

• Views

• Taxonomy 词汇表

• 菜单

• 图形样式

相对于Drupa 7，内容Entity还提供了一些新的特性，例如不仅Node有版本，自定义Block也有了版本；所有的内容Entity都有了添加评论的能力（比如为评论添加评论）。Drupal 8的网站建设增强一节描述了更多的Entity相关特性。

##hook_schema()淡出？

作为一个开发者，这对你有何意义么？这意味着，Drupal 8中，有了Entity API，还有Config/State API，几乎没有创建和管理自己的数据表的必要。使用这些标准API，不但可以少些代码，还让你易于迁移到其他种类的数据库，例如MongoDB。

##Web Service

Drupal 8的主要目标，不仅仅在于创建Drupal为后端的移动应用，还在于促进站点间的通信能力以及同第三方资源的整合能力，有鉴于此，Drupal 8从RESTful web services模块里吸收代码，内建于核心之中，提供本地的REST API。这样就可以配置什么Entity(Node, Tarxonomy, Users)可以允许什么样的HTTP操作(GET, POST, PATCH, DELETE..)，进行这些操作需要什么样的认证。REST UI模块提供了进行这些配置的界面。这样，对于这些被允许的HTTP方法，用户还可以设置什么角色才可以利用这些方法访问对应的资源——例如让匿名用户可以GET，但是只有管理员才可以POST。

在RESTful Web Service模块配置之后，可以从站点内容中获取一大堆的机读数据，例如：

...
   [title] => Array
    (
        [0] => Array
            (
                [value] => Hello, world!
                [lang] => en
            )

    )
...
[body] => Array
    (
        [0] => Array
            (
                [value] => <p>This is my <strong>awesome</strong> article.</p>
                [format] => basic_html
                [summary] =>
            )

    )
...

这有很多好处，下面是一个Drupal 8的例子，获取JSON格式的数据，并再一个独立的jQuery Mobile应用中展示：

Drupal 8还打包了一个叫做Guzzle的库，他实现了简单的语法，用来获取和提交数据，或者同Twitter或者Github之类的第三房服务进行通信。

最后一个Drupal 8 Web Service特性就是”REST 导出”功能，他会在任何View中显示：

##增强的缓存

让人高兴地是，Drupal 8的缓存进行了全面的增强。

• Entity缓存进入核心。

• 缓存标签：在站点内容或配置发生变化时候，允许更细致的缓存清空操作。

• 所有的缓存特性，例如CSS/JS聚合等在缺省状态就会打开，让Drupal 8的缺省配置就能够快速运行

我们还在努力的增强Drupal 8的性能，这些新增的缓存特性，会加速绝大多数的页面的载入过程。

##小结

本文对Drupal 8的代码变化做了一些说明，下一次，将会对主要的API变化，以及这些变化的影响做更加深入的讲解。