开始使用 WordPress 块开发 PlatoBlockchain 数据智能。 垂直搜索。 哎。

开始使用 WordPress 块开发

让我们承认现在为 WordPress 开发很奇怪。 无论您是 WordPress 新手还是已经使用它多年,“全站点编辑”(FSE)功能的引入,包括 块编辑器 (WordPress 5.0)和 网站编辑 (WordPress 5.9),颠覆了我们构建 WordPress 主题和插件的传统方式。

尽管我们第一次遇到块编辑器已经五年了,但开发它很困难,因为文档要么缺乏要么已经过时。 这更像是关于 FSE 功能移动速度的声明, 杰夫在最近的一篇文章中感叹.

举个例子:2018 年, 介绍系列 关于进入 Gutenberg 开发的内容发表在 CSS-tricks 上。 从那时起,时代已经发生了变化,虽然这种开发方式仍然有效,但它是 不建议 不再(此外, create-guten-block 它所基于的项目也不再维护)。

在本文中,我打算帮助您以遵循当前方法的方式开始 WordPress 块开发。 所以,是的,在此发布后情况可能会发生很大变化。 但我将尝试以一种希望抓住块开发本质的方式专注于它,因为即使工具可能会随着时间的推移而发展,核心思想可能会保持不变。

Gutenberg 编辑器:(1) 块插入器,(2) 内容区域,以及 (3) 设置侧边栏
信用: WordPress 块编辑器手册

究竟什么是 WordPress 块?

让我们首先澄清一下我们所说的术语的含义 . 在 WordPress 5.0 之前,所有这些功能的开发都被代号为“古腾堡”——你知道,发明者 印刷机.

从那时起,“古腾堡”就被用来描述与块相关的一切,包括块编辑器和站点编辑器,所以它变得复杂到一些人 鄙视这个名字. 最重要的是,有一个 古腾堡插件 测试实验功能是否可能包含在内。 如果您认为调用所有这些“全站点编辑”可以解决问题, 对此也有担忧.

因此,当我们在本文中提到“块”时,我们指的是用于在 WordPress 块编辑器中创建内容的组件。 块被插入到页面或帖子中,并为特定类型的内容提供结构。 WordPress 附带了一些用于常见内容类型的“核心”块,例如段落、列表、图像、视频和音频, 仅举几例.

除了这些核心块,我们还可以创建自定义块。 这就是 WordPress 块开发的意义所在(还有过滤核心块以修改其功能,但您可能还不需要它)。

块有什么作用

在我们深入创建块之前,我们必须首先了解块内部是如何工作的。 这肯定会在以后为我们节省大量的挫败感。

我喜欢思考块的方式是相当抽象的:对我来说,块是一个实体,具有一些属性(称为属性),代表一些内容。 我知道这听起来很模糊,但请跟我来。 块基本上以两种方式表现自己:作为块编辑器中的图形界面或作为数据库中的一块数据。

当您打开 WordPress 块编辑器并插入一个块(例如 Pullquote 块)时,您会得到一个漂亮的界面。 您可以单击该界面并编辑引用的文本。 块编辑器 UI 右侧的设置面板提供了用于调整文本和设置块外观的选项。

开始使用 WordPress 块开发 PlatoBlockchain 数据智能。 垂直搜索。 哎。
拉引号块 包含在 WordPress 核心中

当您完成创建精美的 pullquote 并点击 Publish 后,整个帖子将存储在 wp_posts 桌子。 由于古腾堡,这并不是什么新鲜事。 这就是事情一直以来的工作方式——WordPress 将帖子内容存储在数据库中的指定表中。 但新的是 Pullquote 块的表示 是存储在其中的内容的一部分 post_content 的领域 wp_posts 表。

这种表示形式是什么样的? 看一看:


It is not an exaggeration to say that peas can be described as nothing less than perfect spheres of joy.

The Encyclopedia of world peas

看起来像纯 HTML,对吧?! 用技术术语来说,这就是“序列化”块。 注意 HTML 注释中的 JSON 数据, "textAlign": "right". 那是一个 属性 - 与块关联的属性。

假设您关闭了块编辑器,然后过一段时间再次打开它。 相关内容来自 post_content 字段由块编辑器检索。 然后编辑器解析检索到的内容,以及它遇到的任何地方:

...

……它对自己大声说:

好的,这对我来说似乎是一个 Pullquote 块。 嗯……它也有一个属性……我确实有一个 JavaScript 文件,它告诉我如何在编辑器中从属性构建 Pullquote 块的图形界面。 我现在应该这样做来渲染这个块的所有荣耀。

作为块开发人员,您的工作是:

  1. 告诉 WordPress 您要注册特定类型的块,以及某某详细信息。
  2. 将 JavaScript 文件提供给块编辑器,这将帮助它在编辑器中呈现块,同时“序列化”它以将其保存在数据库中。
  3. 为块提供适当功能所需的任何其他资源,例如样式和字体。

需要注意的一点是,从序列化数据到图形界面的所有转换(反之亦然)仅在块编辑器中进行。 在前端,内容完全按照其存储方式显示。 因此,从某种意义上说,块是一种将数据放入数据库的奇特方式。

希望这能让您清楚地了解块的工作原理。

图表概述了后期编辑器状态以及数据如何保存到数据库并解析以进行渲染。
开始使用 WordPress 块开发

块只是插件

块只是插件。 嗯,从技术上讲,你 能够 将块放入主题中,然后您 能够 将多个块放入插件中。 但是,通常情况下,如果你想制作一个块,你就会制作一个插件。 因此,如果您曾经创建过 WordPress 插件,那么您就已经开始着手制作 WordPress 块了。

但是让我们暂时假设您从未设置过 WordPress 插件,更不用说一个块了。 你甚至从哪里开始?

设置块

我们已经介绍了块是什么。 让我们开始做一个。

确保已安装 Node

这将使您可以访问 npmnpx 命令,其中 npm 安装你的块的依赖项并帮助编译东西,同时 npx 在包上运行命令而不安装它们。 如果您在 macOS 上,您可能已经拥有 Node 并且可以使用 nvm 更新版本。 如果您使用的是 Windows,则需要 下载并安装节点.

创建项目文件夹

现在,您可能会遇到其他直接跳转到命令行并指示您安装名为的软件包的教程 @wordpress/create-block. 这个包很棒,因为它生成了一个完整的项目文件夹,其中包含您开始开发所需的所有依赖项和工具。

我个人在设置自己的块时会走这条路,但请逗我一会儿,因为我想剪掉它引入的固执己见的东西,只关注所需的部分,以便了解基线开发环境。

这些是我想特别指出的文件:

  • readme.txt:这有点像插件目录的正面,通常用于描述插件并提供有关使用和安装的其他详细信息。 如果您将块提交给 WordPress插件目录,此文件有助于填充插件页面。 如果你打算为你的块插件创建一个 GitHub 存储库,那么你也可以考虑一个 README.md 具有相同信息的文件,因此它在那里很好地显示。
  • package.json:这定义了开发所需的节点包。 当我们开始安装时,我们会打开它。 在经典的 WordPress 插件开发中,您可能习惯于使用 Composer 和 composer.json 文件。 这是等价的。
  • plugin.php: 这是主要的插件文件,是的,它是经典的 PHP! 我们将把我们的插件头和元数据放在这里,并用它来注册插件。

除了这些文件,还有 src 目录,它应该包含我们块的源代码。

拥有这些文件和 src 目录是您开始所需的全部内容。 在该组中,请注意 从技术上讲,我们只需要一个文件 (plugin.php) 来制作插件。 其余的要么提供信息,要么用于管理开发环境。

之前所提 @wordpress/create-block package 为我们搭建了这些文件(以及更多)。 您可以将其视为自动化工具,而不是必需品。 无论如何,它确实使工作更容易,因此您可以通过运行以下命令自由地用它搭建一个块:

npx @wordpress/create-block

安装块依赖项

假设您已准备好上一节中提到的三个文件,就该安装依赖项了。 首先,我们需要指定我们需要的依赖项。 我们通过编辑 package.json。 在使用 @wordpress/create-block 实用程序,为我们生成以下内容(添加了注释;JSON 不支持注释,因此如果您要复制代码,请删除注释):

{
  // Defines the name of the project
  "name": "block-example",
  // Sets the project version number using semantic versioning
  "version": "0.1.0",
  // A brief description of the project
  "description": "Example block scaffolded with Create Block tool.",
  // You could replace this with yourself
  "author": "The WordPress Contributors",
  // Standard licensing information
  "license": "GPL-2.0-or-later",
  // Defines the main JavaScript file
  "main": "build/index.js",
  // Everything we need for building and compiling the plugin during development
  "scripts": {
    "build": "wp-scripts build",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "packages-update": "wp-scripts packages-update",
    "plugin-zip": "wp-scripts plugin-zip",
    "start": "wp-scripts start"
  },
  // Defines which version of the scripts packages are used (24.1.0 at time of writing)
  // https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/
  "devDependencies": {
    "@wordpress/scripts": "^24.1.0"
  }
}
无评论查看
{
  "name": "block-example",
  "version": "0.1.0",
  "description": "Example block scaffolded with Create Block tool.",
  "author": "The WordPress Contributors",
  "license": "GPL-2.0-or-later",
  "main": "build/index.js",
  "scripts": {
    "build": "wp-scripts build",
    "format": "wp-scripts format",
    "lint:css": "wp-scripts lint-style",
    "lint:js": "wp-scripts lint-js",
    "packages-update": "wp-scripts packages-update",
    "plugin-zip": "wp-scripts plugin-zip",
    "start": "wp-scripts start"
  },
  "devDependencies": {
    "@wordpress/scripts": "^24.1.0"
  }
}

@wordpress/scripts package 是这里的主要依赖项。 如您所见,这是一个 devDependency 意味着它有助于发展。 怎么会这样? 它暴露了 wp-scripts 我们可以用来编译代码的二进制文件,从 src 目录到 build 目录等。

WordPress 还为各种目的维护了许多其他软件包。 例如, @wordpress/components 包提供 几个预制件 UI 组件 用于 WordPress 块编辑器,可用于为符合 WordPress 设计标准的块创建一致的用户体验。

你实际上并没有 需要 安装这些包,即使你想使用它们。 这是因为这些 @wordpress 依赖项未与您的块代码捆绑在一起。 相反,任何 import 引用实用程序包中代码的语句——比如 @wordpress/components — 用于在编译期间构建“资产”文件。 此外,这些导入语句被转换为将导入映射到全局对象属性的语句。 例如, import { __ } from "@wordpress/i18n" 被转换为缩小版 const __ = window.wp.i18n.__。 (window.wp.i18n 是一个保证在全局范围内可用的对象,一旦相应的 i18n 包文件已入队)。

在插件文件中注册块期间,“assets”文件隐式用于告诉 WordPress 该块的包依赖项。 这些依赖项会自动排队。 所有这一切都在幕后处理,前提是您正在使用 scripts 包裹。 话虽如此,您仍然可以选择在本地安装代码完成和参数信息的依赖项 package.json 文件:

// etc.
"devDependencies": {
  "@wordpress/scripts": "^24.1.0"
},
"dependencies": {
  "@wordpress/components": "^19.17.0"
}

现在, package.json 设置完成后,我们应该能够通过在命令行中导航到项目文件夹并运行来安装所有这些依赖项 npm install.

运行安装命令后的终端输出。 安装了 1,296 个软件包。
开始使用 WordPress 块开发

添加插件头

如果您来自经典的 WordPress 插件开发,那么您可能知道所有插件在主插件文件中都有一个信息块,可帮助 WordPress 识别插件并在 WordPress 管理员的插件屏幕上显示有关它的信息。

下面是 @wordpress/create-block 为我生成了一个创造性地称为“Hello World”的插件:

<?php
/**
 * Plugin Name:       Block Example
 * Description:       Example block scaffolded with Create Block tool.
 * Requires at least: 5.9
 * Requires PHP:      7.0
 * Version:           0.1.0
 * Author:            The WordPress Contributors
 * License:           GPL-2.0-or-later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       css-tricks
 *
 * @package           create-block
 */

那在主插件文件中,您可以随意调用它。 你可以把它叫做通用的东西 index.php or plugin.php。 该 create-block package 在安装它时会自动调用它作为项目名称提供的任何内容。 由于我将此示例称为“块示例”,因此包给了我们一个 block-example.php 包含所有这些东西的文件。

你会想要改变一些细节,比如让自己成为作者等等。 并非所有这些都是必要的。 如果我是从“头”开始滚动的,那么它可能看起来更接近于这个:

<?php
/**
 * Plugin Name:       Block Example
 * Plugin URI:        https://css-tricks.com
 * Description:       An example plugin for learning WordPress block development.
 * Version:           1.0.0
 * Author:            Arjun Singh
 * License:           GPL-2.0-or-later
 * License URI:       https://www.gnu.org/licenses/gpl-2.0.html
 * Text Domain:       css-tricks
 */

我不会深入了解每一行的确切目的,因为那已经是 WordPress 插件手册中的成熟模式.

文件结构

我们已经查看了块所需的文件。 但是如果你使用 @wordpress/create-block,您将在项目文件夹中看到一堆其他文件。

这是目前的内容:

block-example/
├── build
├── node_modules
├── src/
│   ├── block.json
│   ├── edit.js
│   ├── editor.scss
│   ├── index.js
│   ├── save.js
│   └── style.scss
├── .editorconfig
├── .gitignore
├── block-example.php
├── package-lock.json
├── package.json
└── readme.txt

呸,这么多! 让我们说出新的东西:

  • build/:此文件夹在处理文件以供生产使用时接收已编译的资产。
  • node_modules:这包含我们在运行时安装的所有开发依赖项 npm install.
  • src/:此文件夹包含插件的源代码,这些源代码被编译并发送到 build 目录。 稍后我们将查看这里的每个文件。
  • .editorconfig:这包含使您的代码编辑器适应代码一致性的配置。
  • .gitignore:这是一个标准 repo 文件,用于标识应从版本控制跟踪中排除的本地文件。 您的 node_modules 绝对应该包含在此处。
  • package-lock.json:这是一个自动生成的文件,包含用于跟踪我们安装的所需软件包的更新 npm install.

块元数据

我想深入了解 src 目录,但将首先关注其中的一个文件: block.json. 如果你用过 create-block ,它已经为你准备好了; 如果没有,请继续创建它。 WordPress 努力通过提供元数据来使其成为注册块的标准、规范方式,该元数据提供 WordPress 上下文以识别块并在块编辑器中呈现它。

下面是 @wordpress/create-block 为我生成:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "create-block/block example",
  "version": "0.1.0",
  "title": "Block Example",
  "category": "widgets",
  "icon": "smiley",
  "description": "Example block scaffolded with Create Block tool.",
  "supports": {
    "html": false
  },
  "textdomain": "css-tricks",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css"
}

实际上有一个 一堆不同的信息 我们可以包括在这里,但真正需要的是 nametitle. 一个超级最小的版本可能是这样的:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "css-tricks/block-example",
  "version": "1.0.0",
  "title": "Block Example",
  "category": "text",
  "icon": "format-quote",
  "editorScript": "file:./index.js",
}
  • $schema 定义用于验证文件内容的模式格式。 这听起来像是一个必需的东西,但它是完全可选的,因为它允许支持代码编辑器来验证语法并提供其他附加功能,如工具提示提示和自动完成。
  • apiVersion 指的是哪个版本 块API 该插件使用。 今天,第 2 版是最新的。
  • name 是一个必需的唯一字符串,有助于识别插件。 请注意,我已在此前缀 css-tricks/ 我将其用作命名空间,以帮助避免与可能具有相同名称的其他插件发生冲突。 您可能会选择使用您的姓名首字母之类的东西(例如 as/block-example).
  • version 是什么 WordPress 建议使用 作为新版本发布时的缓存清除机制。
  • title 是另一个必填字段,它设置显示插件时使用的名称。
  • category 将块与其他块组合在一起,并将它们一起显示在块编辑器中。 当前现有的类别包括 text, media, design, widgets, themeembed,你甚至可以创建 自定义类别.
  • icon 让您从 Dashicons 图书馆 在块编辑器中直观地表示您的块。 我正在使用 format-quote icon](https://developer.wordpress.org/resource/dashicons/#format-quote) 因为我们在这个例子中制作了自己的 pullquote。 很高兴我们可以利用现有图标而不必创建自己的图标,尽管这当然是可能的。
  • editorScript 是主要的 JavaScript 文件, index.js,生活。

注册块

在我们编写实际代码之前的最后一件事就是注册插件。 我们只是设置了所有元数据,我们需要一种方式让 WordPress 使用它。 这样,WordPress 知道在哪里可以找到所有插件资产,因此可以将它们排入队列以在块编辑器中使用。

注册块是一个双重过程。 我们需要在 PHP 和 JavaScript 中注册它。 对于 PHP 端,打开主插件文件(block-example.php 在这种情况下)并在插件标题之后添加以下内容:

function create_block_block_example_block_init() {
  register_block_type( __DIR__ . '/build' );
}
add_action( 'init', 'create_block_block_example_block_init' );

这是什么 create-block 为我生成的实用程序,这就是为什么该函数以它的方式命名的原因。 我们可以使用不同的名称。 同样,关键是避免与其他插件发生冲突,因此最好在此处使用您的命名空间以使其尽可能独特:

function css_tricks_block_example_block_init() {
  register_block_type( __DIR__ . '/build' );
}
add_action( 'init', 'css_tricks_block_example_block_init' );

为什么我们指向 build 目录如果 block.json 所有块元数据都在 src? 那是因为我们的代码还需要编译。 这 scripts 包处理来自文件中的代码 src 目录并将生产中使用的编译文件放在 build 目录,同时也 复制 block.json 文件 在这个过程中。

好的,让我们转到注册块的 JavaScript 方面。 打开 src/index.js 并确保它看起来像这样:

import { registerBlockType } from "@wordpress/blocks";

import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";

const { name } = metadata;

registerBlockType(name, {
  edit: Edit,
  save: Save,
});

我们正在进入 React 和 JSX 领域! 这告诉 WordPress:

  • 导入 registerBlockType 来自的模块 @wordpress/blocks 包。
  • 从导入元数据 block.json.
  • 导入 EditSave 来自其相应文件的组件。 稍后我们会将代码放入这些文件中。
  • 注册块,并使用 EditSave 用于渲染块并将其内容保存到数据库的组件。

怎么了 editsave 功能? WordPress 块开发的细微差别之一是将“后端”与“前端”区分开来,这些功能用于在这些上下文中呈现块的内容,其中 edit 处理后端渲染和 save 将块编辑器中的内容写入数据库,以在网站前端呈现内容。

快速测试

我们可以做一些快速的工作来查看我们的块在块编辑器中工作并在前端渲染。 让我们打开 index.js 再次使用 editsave 函数返回一些说明它们如何工作的基本内容:

import { registerBlockType } from "@wordpress/blocks";
import metadata from "./block.json";

const { name } = metadata;

registerBlockType(name, {
  edit: () => {
    return (
      "Hello from the Block Editor"
    );
  },
  save: () => {
    return (
      "Hello from the front end"
    );
  }
});

这基本上是我们之前拥有的相同代码的精简版本,只是我们直接指向 block.json 获取块名称,并省略 EditSave 组件,因为我们直接从这里运行函数。

我们可以通过运行来编译它 npm run build 在命令行中。 之后,我们可以在块编辑器中访问一个名为“块示例”的块:

如果我们将块放入内容区域,我们会得到从 edit 功能:

WordPress 块编辑器,块插入器面板打开,并且 pullquote 块插入到内容区域。 它从后端读取 hello。
开始使用 WordPress 块开发

如果我们保存并发布帖子,我们应该得到我们从 save 在前端查看时的功能:

在网站前端呈现的 pullquote 块。 它从前端打招呼。
开始使用 WordPress 块开发

创建块

看起来一切都已经挂钩了! 我们可以恢复到我们所拥有的 index.js 既然我们已经确认一切正常,那么在测试之前:

import { registerBlockType } from "@wordpress/blocks";

import metadata from "./block.json";
import Edit from "./edit.js";
import Save from "./save.js";

const { name } = metadata;

registerBlockType(name, {
  edit: Edit,
  save: Save,
});

注意, editsave 函数绑定到两个现有文件 src 目录 @wordpress/create-block 为我们生成并在每个文件中包含我们需要的所有其他导入。 更重要的是,这些文件确立了 EditSave 包含块标记的组件。

后端标记 (src/edit.js)

import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";

export default function Edit() {
  return (
    

{__("Hello from the Block Editor", "block-example")}

); }

看看我们在那里做了什么? 我们正在从 @wordpress/block-editor 包,它允许我们生成以后可以用于样式的类。 我们也在导入 __ 国际化功能,用于处理翻译。

后端的 pullquote 块,已选中并在其旁边打开 devtools,显示标记。
开始使用 WordPress 块开发

前端标记(src/save.js)

这创造了一个 Save 组件,我们将使用几乎相同的东西 src/edit.js 文字略有不同:

import { useBlockProps } from "@wordpress/block-editor";
import { __ } from "@wordpress/i18n";

export default function Save() {
  return (
    

{__("Hello from the front end", "block-example")}

); }

同样,我们得到了一个很好的类,可以在我们的 CSS 中使用:

前端的 pullquote 块,选中并在其旁边打开 devtools 显示标记。
开始使用 WordPress 块开发

造型块

我们刚刚介绍了如何使用块道具来创建类。 你正在一个网站上阅读这篇关于 CSS 的文章,所以我觉得如果我们没有专门解决如何编写块样式,我会遗漏一些东西。

区分前端和后端样式

如果你看看 block.json ,在 src 目录你会发现两个与样式相关的字段:

  • editorStyle 提供应用于后端的样式的路径。
  • style 是应用于前端和后端的共享样式的路径。

Kev Quirk 有一篇详细的文章 这显示了他使后端编辑器看起来像前端 UI 的方法。

回想一下 @wordpress/scripts 包复制 block.json 文件处理代码时 /src 目录并将编译的资产放在 /build 目录。 它是 build/block.json 用于注册块的文件。 这意味着我们提供的任何路径 src/block.json 应该写成相对于 build/block.json.

使用 Sass

我们可以在 build 目录,参考路径 src/block.json,运行构建,然后收工。 但这并没有充分利用 @wordpress/scripts 编译过程,它能够将 Sass 编译成 CSS。 相反,我们将样式文件放在 src 目录并在 JavaScript 中导入它们。

在这样做的同时,我们需要注意如何 @wordpress/scripts 处理样式:

  • 名为的文件 style.css or style.scss or style.sass,导入到 JavaScript 代码中,编译为 style-index.css.
  • 所有其他样式文件都被编译并捆绑到 index.css.

@wordpress/scripts 包装用途 的WebPack 用于捆绑和 @wordpress/scripts 使用 PostCSS 插件 用于加工风格。 PostCSS 可以使用其他插件进行扩展。 这 scripts 包使用 Sass、SCSS 和 Autoprefixer 的包,所有这些都可以在不安装额外包的情况下使用。

事实上,当你启动你的初始块时 @wordpress/create-block,您可以使用 SCSS 文件快速开始运行:

  • editor.scss 包含应用于后端编辑器的所有样式。
  • style.scss 包含前端和后端共享的所有样式。

现在让我们通过编写一个小 Sass 来看看这种方法的实际效果,我们将把它编译到我们块的 CSS 中。 尽管这些示例不会非常 Sass-y,但我仍然将它们写入 SCSS 文件以演示编译过程。

面前 后端样式

好的,让我们从应用于前端和后端的样式开始。 首先,我们需要创建 src/style.scss (如果你正在使用它已经存在 @wordpress/create-block) 并确保我们导入它,我们可以这样做 index.js:

import "./style.scss";

打开 src/style.scss 并使用从块道具为我们生成的类删除一些基本样式:

.wp-block-css-tricks-block-example {
  background-color: rebeccapurple;
  border-radius: 4px;
  color: white;
  font-size: 24px;
}

现在就是这样! 当我们运行构建时,它被编译成 build/style.css 并且被块编辑器和前端引用。

后端样式

您可能需要编写特定于块编辑器的样式。 为此,创建 src/editor.scss (再次, @wordpress/create-block 为您执行此操作)并在其中放置一些样式:

.wp-block-css-tricks-block-example {
  background-color: tomato;
  color: black;
}

然后将其导入 edit.js,这是包含我们的文件 Edit 组件(我们可以在任何我们想要的地方导入它,但由于这些样式是针对编辑器的,所以在这里导入组件更合乎逻辑):

import "./editor.scss";

现在当我们跑 npm run build,样式在两种上下文中都应用于块:

WordPress 块编辑器中的 pullquote 块,应用了番茄色背景。 黑色文字后面。
开始使用 WordPress 块开发
pullquote 块离子前端与黑色文本后面的应用 rebecca 紫色背景。
开始使用 WordPress 块开发

引用样式 block.json

我们在 edit.jsindex.js,但请记住,编译步骤为我们生成了两个 CSS 文件 build 目录: index.cssstyle-index.css 分别。 我们需要在块元数据中引用这些生成的文件。

让我们在 block.json 元数据:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 2,
  "name": "css-tricks/block-example",
  "version": "1.0.0",
  "title": "Block Example",
  "category": "text",
  "icon": "format-quote",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css"
}

运行 npm run build 再次在您的 WordPress 网站上安装并激活该插件,您就可以使用它了!

您可以使用 npm run start 在监视模式下运行构建,每次更改代码并保存时都会自动编译代码。

我们正在摸索表面

实际块利用块编辑器的设置侧边栏和 WordPress 提供的其他功能来创建丰富的用户体验。 此外,事实上我们的区块基本上有两个版本—— editsave — 您还需要考虑如何组织代码以避免代码重复。

但希望这有助于揭开创建 WordPress 块的一般过程的神秘面纱。 这确实是 WordPress 开发的新时代。 学习新的做事方式很难,但我期待看到它如何发展。 像这样的工具 @wordpress/create-block 帮助,但即使那样,也很高兴确切地知道它在做什么以及为什么。

我们在这里介绍的内容会改变吗? 最有可能的! 但至少你有一个基线可以工作,因为我们一直在观察 WordPress 块的成熟,包括制作它们的最佳实践。

参考资料

同样,我的目标是在这个季节为进入块开发制定一条有效的路径,因为事情正在迅速发展,而 WordPress 文档也很难迎头赶上。 以下是我用来汇总的一些资源:

时间戳记:

更多来自 CSS技巧