logo

额外区块类型 (EBT) - 全新的布局构建器体验❗

额外区块类型 (EBT) - 样式化、可定制的区块类型:幻灯片、标签页、卡片、手风琴等更多类型。内置背景、DOM Box、JavaScript 插件的设置。立即体验布局构建的未来。

演示 EBT 模块 下载 EBT 模块

❗额外段落类型 (EPT) - 全新的 Paragraphs 体验

额外段落类型 (EPT) - 类似的基于 Paragraph 的模块集合。

演示 EPT 模块 滚动

滚动
03/10/2025, by Ivan

API 特性

按最少使用的 API 排序:

认证提供者服务
实现 \Drupal\Core\Authentication\AuthenticationProviderInterface 并使用服务标签 'authentication_provider'。

路由上的 _auth 选项
默认的认证管理器(见下文)允许开发者通过在路由参数中指定 _auth 来限制允许的认证机制子集。
示例: _auth: ['basic_auth', 'cookie']

认证管理器
认证管理器 (\Drupal\Core\Authentication\AuthenticationManager) 根据每个服务的优先级调用不同的认证提供者服务。

在非常复杂的使用场景下可以重写认证管理器;但在 99.9% 的情况下,默认实现已足够。

有用的接口
Drupal 提供了 2 个额外的接口用于高级认证。

03/10/2025, by Ivan

概览

在 Drupal 8 中,区块实际上由两个独立的 API 结构组成,以便创建与之前版本 Drupal 所支持的类似的用户界面。这两个 API 分别是 Block Plugin API(可复用的独立 API)和 Block Entity API(Drupal 8 特有的区块放置与可见性控制机制)。

使用 Block Plugin API 创建区块

要在模块代码中定义区块,需要学习和理解 插件 API,特别是 基于注解的插件发现机制,这是 Drupal 8 用来找到定义区块的代码的方法。

创建一个由模块定义的自定义区块包含以下步骤:

03/10/2025, by Ivan

在 Drupal 8 中,Cache API 得到了显著改进。接下来的章节将更详细地介绍每个功能。

要快速了解,请参阅 API 文档中的 Cache API 页面。

可缓存性元数据

所有直接渲染的对象,或者用于决定显示内容的对象,都会提供缓存元数据 —— 从访问结果到实体再到 URL。

缓存元数据由 3 个属性组成:

  • 缓存标签 (cache tags)

用于 Drupal 管理的数据依赖,例如实体和配置

  • 缓存上下文 (cache contexts)

用于区分不同变体,即请求上下文的依赖

  • 缓存最大存活时间 (cache max-age)

用于依赖时间的缓存,即时间相关的依赖

03/10/2025, by Ivan
缓存标签 = 数据依赖
缓存标签描述了对 Drupal 管理的数据的依赖

为什么?

缓存标签提供了一种声明式的方式来跟踪哪些缓存项依赖于某些由 Drupal 管理的数据。

这对像 Drupal 这样的内容管理系统/框架非常重要,因为同一内容可能会以不同方式被重复使用。换句话说:我们无法预先知道某个内容会在哪里被使用。在任何使用内容的地方,它都可能被缓存。这意味着相同的内容可能会在几十个地方被缓存。这就引出了那句著名的话:在计算机科学中,只有两个难题:缓存失效和命名。——即,如何让所有使用了该内容的缓存项失效?

注意:Drupal 7 提供了 3 种使缓存项失效的方式:使某个特定 CID 失效、使 CID 前缀失效,或者使整个缓存 bin 失效。但这三种方法都无法使包含已修改实体的缓存项失效,因为根本无法知道!

是什么?

缓存标签是一个字符串。

缓存标签以字符串数组 string[] 的形式传递(顺序无关)。这是一个集合,因为一个缓存项可能依赖于多个缓存标签。

03/10/2025, by Ivan
缓存上下文 = (请求)上下文依赖
缓存上下文类似于 HTTP 头中的 Vary。

为什么?

缓存上下文定义了如何根据上下文创建需要缓存的变体。这样编写生成缓存的代码会更易读,并且不需要在每个需要相同上下文变化的地方重复相同的逻辑。

示例:

  • 某些数据的输出依赖于当前主题,不同主题会产生不同的结果。此时就会使用主题缓存上下文。
  • 在生成一个渲染数组以显示个性化消息时,该渲染数组依赖于用户。此时缓存依赖于用户缓存上下文。
  • 通常情况下:当某些计算开销较大的信息依赖于服务器环境时,也会使用缓存上下文。

如何?

缓存上下文是一个字符串,它引用一个可用的缓存上下文服务(见下文)。

缓存上下文以字符串集合的形式传递(顺序无关),因此它们表示为 string[]。这是集合,因为一个缓存项可能依赖于多个缓存上下文。

通常缓存上下文来自请求上下文对象(即请求)。大部分 Web 应用的环境都来自请求上下文。最终,HTTP 响应在很大程度上是根据触发它们的 HTTP 请求的属性生成的。

03/10/2025, by Ivan

Cache max-age = 依赖时间

Cache max-age 类似于 HTTP Cache-Control 头中的 max-age 指令。

为什么?

缓存最大存活时间提供了一种声明式的方式来创建依赖于时间的缓存。

某些数据只在有限的时间段内有效,在这种情况下,你会希望为其指定相应的最大存活时间。然而在 Drupal 8 核心中,我们没有仅在有限时间内有效的数据;我们通常是永久缓存(见下文),并完全依赖 缓存标签 来进行失效处理。

是什么?

缓存最大存活时间是一个正整数,表示秒数。

缓存最大存活时间以单个整数传递,因为对于某个缓存项来说逻辑上只能有一个最大存活时间。

示例:

03/10/2025, by Ivan

Varnish Cache 是一种 Web 应用加速器,也称为 HTTP 缓存反向代理。Varnish 被成千上万个 Drupal 站点使用,可以将页面加载性能提高 10-1000 倍,并且它可以与缓存标签结合使用,从而简化缓存失效操作。

要实现缓存标签的基础集成,你需要做三件事,以确保 Varnish 能够正确处理 Drupal 生成的缓存标签:

03/10/2025, by Ivan

为了简化与缓存元数据(缓存标签缓存上下文最大寿命 max-age)的工作,Drupal 8 提供了 CacheableDependencyInterface。

为什么?

想象一下,如果你必须在渲染数组(或其他一些计算)中手动为你使用的每个实体对象和配置对象创建缓存标签。在多语言网站中,你还必须手动添加所需的缓存上下文(无论是翻译后的实体,还是带有语言覆盖的配置对象)。