DEV Community: Silvia Malavasi

Let’s Get Hands-On with WordPress FSE Theme and Custom Blocks — Part 2

Silvia Malavasi — Fri, 28 Jun 2024 09:45:24 +0000

A Complete Ecosystem

While we can create and compile our own blocks for integration into any FSE theme individually, the optimal efficiency is achieved by constructing an ecosystem that:

Automates all build processes
Establishes a clear folder structure
Allows for scalable expansion
Ensures stylistic consistency and facilitates the reuse of common elements across all blocks

So, let’s focus on the theme and develop a build system for our blocks, as well as for our SASS and JavaScript files. It’s important to note that all block-related computations occur only when the block is present on the page we’re viewing. Additionally, any globally used JavaScript functions should have their own file within the theme, following the same approach as traditional themes.

The Structure

In contrast to a basic FSE theme structure, we introduce a few additional folders:

src: this is where we place our JavaScript and styles that need to be compiled
blocks/custom-blocks: each block is housed in its own folder within this directory.
dist: this directory is designated for the compiled theme files

And the two files that pertain to the build process:

package.json
webpack.config.js

Therefore, before building, our structure resembles the following. If you manage the header and footer exclusively through the editor, you can remove the parts folder.



my-theme/
│
├── blocks/
│   └── custom-blocks/
│       └── first-block/
│           ├── block.json
│           ├── edit.js
│           ├── edit.scss
│           ├── index.js
│           ├── save.js
│           ├── save.scss
│       └── second-block/
│           ├── block.json
│           ├── edit.js
│           ├── edit.scss
│           ├── index.js
│           ├── save.js
│           ├── save.scss
│       └── ...
│
├── dist/
│
├── parts/
│   ├── footer.html
│   ├── header.html
│
├── src/
│   ├── css/
│   │   ├── style.scss
│   │   ├── dashboard-style.scss
│   ├── js/
│       ├── site.js
│
├── templates/
│   ├── index.html
│
├── functions.php
├── package.json
├── theme.json
└── webpack.config.js

Let’s briefly discuss the dashboard-style.scss file.

In WordPress, styles are enqueued in various ways. Block styles, as previously mentioned, are handled directly within each block. Frontend styles are enqueued in functions.php using wp_enqueue_style within the wp_enqueue_scripts action.



function zenfse_enqueue_style()
{
  wp_enqueue_style('zenfse-style', get_stylesheet_directory_uri() . '/style.css', array(), filemtime(get_stylesheet_directory() . '/style.css'), false);
}
add_action('wp_enqueue_scripts', 'zenfse_enqueue_style');

However, if we need to enqueue parts of our CSS, such as resets, these won’t be loaded within the editor by default. Therefore, in my themes, I include a dashboard-style.scss file to be loaded on the editor side through the admin_enqueue_scripts action. This approach ensures that these styles are applied specifically within the WordPress editor.



function zenfse_admin_styles()
{
  wp_enqueue_style('zenfse-admin-style', get_template_directory_uri() . '/dist/dashboard-style.css');
}
add_action('admin_enqueue_scripts', 'zenfse_admin_styles');

If I need to customize my dashboard, I can add specific styles to dashboard-style.scss. To ensure our resets and styles don't impact WordPress's default styles, we should wrap our declarations within the .wp-admin .editor-styles-wrapper selector. This confines our styles to apply only within the editor interface.

As a final touch, we apply our global styles to the iframe within the editor. This approach ensures consistency in how our theme appears across different parts and templates modified within the WordPress dashboard.



function zenfse_editor_style()
{
  add_editor_style(array('style.css',));
}

add_action('after_setup_theme', 'zenfse_editor_style');

End of digression.

The Toolbox

We are operating within a Node environment, so our first step is to initialize our project by creating a package.json where we define dependencies and commands. Personally, I use both webpack (on top of which @wordpress/scripts is built) and Parcel. While using two different build engines may lack elegance, Parcel’s user-friendly approach compensates for this compared to webpack. Its commands are straightforward, requiring no additional configuration files. However, if you prefer using webpack exclusively, you can achieve this with just a few additions to your webpack.config.js.

Within the js and css folders in src, you can get creative with importing modules, exporting and importing functions, creating mixins, etc. In short, you have a modern development environment at your disposal, allowing you to tailor your workflow as needed.

The build process

My package.json looks something like this:



{
  "name": "zenfse",
  "version": "1.3.0",
  "description": "blank fse developer theme",
  "scripts": {
    "dev:js": "parcel watch src/js/site.js",
    "dev:css": "sass --watch src/css/style.scss:style.css --style=expanded",
    "dev:css-dashboard-style": "sass --watch src/css/dashboard-style/dashboard-style.scss:dist/dashboard-style.css --style=expanded",
    "dev:wp-scripts-custom-blocks": "wp-scripts start --webpack-src-dir=blocks/custom-blocks/ --output-path=blocks/build-custom-blocks/",
    "dev": "concurrently --kill-others \"npm run dev:js\" \"npm run dev:css\" \"npm run dev:css-dashboard-style\" \"npm run dev:wp-scripts-core-blocks\" \"npm run dev:css-gsap-animations-frontend\" \"npm run dev:css-image-frontend\" \"npm run dev:css-image-backend\" \"npm run dev:css-image-style\" \"npm run dev:wp-scripts-custom-blocks\"",
    "clean": "rimraf ./blocks/build-custom-blocks ./dist",
    "build:js": "parcel build src/js/site.js --no-source-maps --no-content-hash",
    "build:css": "sass src/css/style.scss:style.css --style=compressed",
    "build:css-dashboard-style": "sass src/css/dashboard-style/dashboard-style.scss:dist/dashboard-style.css --style=compressed",
    "build:wp-scripts-custom-blocks": "NODE_ENV=production wp-scripts build --webpack-src-dir=blocks/custom-blocks/ --output-path=blocks/build-custom-blocks/",
    "build:css-autoprefixer": "postcss **/*.css --use autoprefixer --replace",
    "build": "npm run clean && run-s build:*"
  },
  "author": "Silvia Malavasi",
  "license": "ISC",
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "not ie <= 8"
  ],
  "devDependencies": {
    "@parcel/transformer-sass": "^2.10.3",
    "@wordpress/scripts": "^26.17.0",
    "parcel": "^2.10.3",
    "rimraf": "^5.0.5"
  },
  "dependencies": {
    "concurrently": "^8.2.2",
  }
}

While webpack.config.js will be simply:



const defaultConfig = require("@wordpress/scripts/config/webpack.config");
module.exports = [defaultConfig];

When I run npm run build, all of these commands will be executed:



"clean": "rimraf ./blocks/build-custom-blocks ./dist",
"build:js": "parcel build src/js/site.js --no-source-maps --no-content-hash",
"build:css": "sass src/css/style.scss:style.css --style=compressed",
"build:css-dashboard-style": "sass src/css/dashboard-style/dashboard-style.scss:dist/dashboard-style.css --style=compressed",
"build:wp-scripts-custom-blocks": "NODE_ENV=production wp-scripts build --webpack-src-dir=blocks/custom-blocks/ --output-path=blocks/build-custom-blocks/",
"build:css-autoprefixer": "postcss **/*.css --use autoprefixer --replace",
"build": "npm run clean && run-s build:*"

First, I clean up the project from the old build using rimraf. Then, I compile all my files using Parcel along with its parcel/transformer-sass, plugin, and I process CSS using autoprefixer.

wp-scripts handles the compilation of all my custom blocks based on the configuration specified in webpack.config.js.

This build process setup is highly convenient because whenever I create a new custom block, I just need to place its folder in blocks/custom-blocks, and it will be automatically compiled during the next npm run build.

Credit for this approach goes to the WebberZone article: “WordPress block development: Building multiple blocks.”

Similarly, npm run dev uses concurrently to manage all the various watch commands simultaneously.

Let’s import everything into functions.php

Now that our files are ready, we can proceed with importing them into our functions.php. We've already discussed some aspects related to styles. The complete process for importing global scripts and styles (which apply across the entire theme) is as follows:



// Enqueue scripts

function zenfse_enqueue_script()
{
  wp_enqueue_script('zenfse-script', get_stylesheet_directory_uri() . '/dist/site.js', array(), filemtime(get_stylesheet_directory() . '/dist/site.js'), true);
}
add_action('wp_enqueue_scripts', 'zenfse_enqueue_script');

// Enqueue styles

function zenfse_enqueue_style()
{
  wp_enqueue_style('zenfse-style', get_stylesheet_directory_uri() . '/style.css', array(), filemtime(get_stylesheet_directory() . '/style.css'), false);
}
add_action('wp_enqueue_scripts', 'zenfse_enqueue_style');

// Enqueue Dashboard styles

function zenfse_admin_styles()
{
  wp_enqueue_style('zenfse-admin-style', get_template_directory_uri() . '/dist/dashboard-style.css');
}
add_action('admin_enqueue_scripts', 'zenfse_admin_styles');

// Enqueue Editor styles

function zenfse_editor_style()
{
  add_editor_style(
    array(
      'style.css',
    )
  );
}

add_action('after_setup_theme', 'zenfse_editor_style');

Now let’s move on to importing our custom blocks, which we compiled into the directory blocks/build-custom-blocks:



function zenfse_register_blocks()
{

  add_filter('block_categories_all', 'zenfse_blocks_categories');
  function zenfse_blocks_categories($categories)
  {
    array_unshift($categories, array(
      'slug'  => 'zenfse-blocks',
      'title' => 'ZenFSE Blocks'
    ));
    return $categories;
  };


  $blocks = array(
    'navigation' => 'zenfse_render_navigation_block',
    'gallery' => '',
  );

  foreach ($blocks as $block => $render_callback) {
    $args = array();
    if (!empty($render_callback)) {
      $args['render_callback'] = $render_callback;
    }
    register_block_type(__DIR__ . '/blocks/build-custom-blocks/' . $block, $args);
  }
}
add_action('init', 'zenfse_register_blocks');

In this example, I have imported two blocks: one is the gallery block that we saw in Part 1 of the article. The other is a navigation block, included here to illustrate its render_callback.

Every time we want to add a new block, we simply add it to the $blocks array, optionally with its callback function. It’s straightforward and efficient.

Conclusion — for real

We’ve delved into setting up a custom FSE theme in WordPress, organizing its structure, and managing the compilation process. Now, the next step is to innovate and create new blocks.

While the process I’ve described may seem somewhat intricate, in a way, it is. Building my ZenFse starter theme involved a lengthy journey of trial and error.

Initially, working with FSE left me feeling disoriented. The absence of PHP was unsettling. However, as I grasped the logic behind the block system and understood the unique integration between PHP and React, I discovered a powerful, versatile, and… enjoyable system. The capability to craft interfaces for nearly any attribute of my theme or blocks enables the development of intricate custom systems, fulfilling the visual builder objective of FSE in WordPress.

Maintaining custom blocks in separate environments proves remarkably convenient. To replicate blocks from one theme to another, you simply copy a folder and add a line in the $blocks array within functions.php.

From a developer’s viewpoint, once the theme is structured, we enjoy an intuitive environment. But what about users? Granted, every CMS demands some training for end users, but does FSE simplify matters? Yes and no. For existing WordPress users, starting anew can pose challenges. Moreover, the decision to develop a site using an FSE or classic theme depends on the client’s requirements.

For example, if I’m constructing a site for an agency that requires precise control over colors, spacing, and enjoys experimenting with diverse block combinations on each project page, FSE is your choice. If a client wishes to incorporate an unexpected video or lengthy text into an existing block, they can experiment and preview the final outcome directly from the dashboard.

Conversely, for a newbie needing a more structured system, I might opt for a classic theme, potentially integrating a series of fields with ACF to limit theme flexibility.

In conclusion, from my perspective, I find developing with FSE much more enjoyable. It feels cleaner and more elegant to me, though these preferences are subjective. Additionally, since FSE is still evolving, I’m excited to see what new tools the WordPress team will introduce in the future.

Let’s also create a dedicated block category for our custom blocks, making it easier to locate and insert them into pages.

Let’s Get Hands-On with WordPress FSE Theme and Custom Blocks — Part 1

Silvia Malavasi — Wed, 26 Jun 2024 17:37:56 +0000

FSE (Full Site Editing): Blessing and Curse

The introduction of Full Site Editing (FSE) represents one of the most significant evolutions in WordPress history. The aim is to provide users with a visual builder-like experience, allowing them to see a direct preview in the dashboard of what will happen on the frontend.

Since the beginning, the evolution of WordPress has pursued this need: to bridge the gap between the complexity of the CMS and the goal of creating a system where a moderately tech-savvy user can independently build a site suited to their needs, including the visual aspect.

Like any evolutionary process, this journey has seen its share of rapid transformations. Sometimes, developers have found themselves facing an enormous change that took time to digest. With FSE and Block Themes in particular, the change has been radical:

No more PHP in the theme root.
Strange HTML filled with comments that aren’t comments.
A configuration file in JSON format.

For an introduction to these topics, WordPress Developer Resources is a good starting point. Here, the structure of the new themes is explained.

A major innovation is the management of page parts. The header and footer can now be edited by users through a dedicated editor in the dashboard. Users can also visually manage templates in this editor, adding core blocks to each page template, including Query Loops. Templates and Parts are saved in the database but can be set via code using the strange HTML mentioned earlier.

In terms of styling, an FSE theme maintains its own style.css, while global styles for typography, colors, padding, and other site-wide elements are declared in the theme.json file. These styles are accessible to users in the sidebar of the selected block.

With these changes alone, it’s evident that the level of user control over the site is infinitely greater than in a traditional theme. Evolution has certainly taken place. However, as developers, we’re not just users; we want to delve deep into the possibilities that the Block Themes system offers.

A notable innovation is an integrated build process in FSE. Do we want to add JavaScript in ES6? Do we want to use SASS? WordPress provides the WordPress scripts package (built on top of webpack) to compile and include our files.

Block Editor: It Gets Even Better

Block Themes allow the integration of custom Blocks that can be used anywhere in the theme. I’m not talking about Patterns, which are essentially simplified versions of a Block designed to create a reusable graphic template (somewhat like the old reusable blocks). We’re talking about entities that use React and require a build process.

The anatomy of a block

A block consists of several components. Some are for declaring the block, others for how the block behaves in the dashboard, and others for the block’s display on the frontend.

index.js is our entry point and initializes the block
block.json declares the block properties, including custom attributes or additional JavaScript to be run on the frontend
edit.js and edit.scss (or css) handle the dashboard-related part
save.js and save.scss (or css) handle the frontend-related part

Additional JavaScript or PHP files can be incorporated for specific functionalities, such as animating elements using GSAP or adjusting server-side rendering for the block.

To use these blocks, they need to be registered in our functions.php file.

Example block: gallery with SwiperJS

Now, finally, some code. This block is moderately complex but perfect for explaining the integration between PHP and React. We will create a gallery with a management interface on the dashboard side. We’ll use SwiperJS library for the gallery’s JavaScript and import it into our block. The build process will be explained in the second part of the article because it differs somewhat from the standard process.

Let’s start with index.js:

import { registerBlockType } from "@wordpress/blocks";
import "./edit.scss";
import "./save.scss";
import Edit from "./edit";
import save from "./save";
import metadata from "./block.json";
registerBlockType(metadata.name, {
  edit: Edit,
  save,
});

Nothing more than an entry point for the WordPress scripts package build system.

In block.json, we start to see something more interesting

{
  "apiVersion": 2,
  "name": "blocks/gallery",
  "title": "Gallery",
  "version": "1.0.0",
  "category": "custom-blocks",
  "icon": "format-gallery",
  "description": "A block with a gallery on the left, and text on the right.",
  "supports": {
    "html": false,
  },
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./index.css",
  "viewScript": "file:./gallery.js",
  "attributes": {
    "slideCount": {
      "type": "number",
      "default": 1
    }
  },
  "example": {
    "innerBlocks": [
      {
        "name": "core/image",
        "attributes": {
          "url": "http://localhost/site/wp-content/themes/my-theme/blocks/custom-blocks/gallery/gallery.png",
          "alt": "gallery preview"
        }
      }
    ]
  }
}

In addition to the standard declarations, we have stated that we will use the gallery.js file on the frontend.

"viewScript": "file:./gallery.js",

And we have declared a new attribute called slideCount

"attributes": {
    "slideCount": {
      "type": "number",
      "default": 1
    }
  },

which we will use. We have also included a preview image to replace the standard preview system. This part is optional.


"example": {
    "innerBlocks": [
      {
        "name": "core/image",
        "attributes": {
          "url": "http://localhost/site/wp-content/themes/my-theme/blocks/custom-blocks/gallery/gallery.png",
          "alt": "gallery preview"
        }
      }
    ]
  }

Alright, now React comes into play. Let’s look at edit.js It’s a bit long, but if you prefer, you can skip directly to the explanations below the code.

import { Button } from "@wordpress/components";
import { useDispatch, useSelect } from "@wordpress/data";
import { InnerBlocks, useBlockProps } from "@wordpress/block-editor";
import { useEffect, useRef } from "@wordpress/element";
import Swiper from "swiper";
import { Navigation, Pagination } from "swiper/modules";

export default function Edit({ attributes, setAttributes, className, clientId }) {
  const ref = useRef();
  const swiperRef = useRef();
  const blockProps = useBlockProps({ ref });

  const { blockOrder, rootClientId, areBlocksInserted } = useSelect(
    (select) => {
      const { getBlockOrder, getBlockHierarchyRootClientId } = select("core/block-editor");
      const blockOrder = getBlockOrder(clientId);
      const rootClientId = getBlockHierarchyRootClientId(clientId);
      return {
        blockOrder,
        rootClientId,
        areBlocksInserted: blockOrder.length === blockOrder.length,
      };
    },
    [clientId]
  );

  const { insertBlock, removeBlock } = useDispatch("core/block-editor");

  useEffect(() => {
    if (
      areBlocksInserted &&
      ref.current &&
      !ref.current.querySelector(".block-editor-inner-blocks").classList.contains("swiper-container-initialized")
    ) {
      let swiperElement = ref.current.querySelector(".block-editor-inner-blocks");
      let swiperWrapper = ref.current.querySelector(".block-editor-block-list__layout");
      swiperElement.classList.add("swiper");
      swiperWrapper.classList.add("swiper-wrapper");
      let swiper_pagination = ref.current.querySelector(".swiper-pagination");
      let swiper_prev = ref.current.querySelector(".swiper-prev");
      let swiper_next = ref.current.querySelector(".swiper-next");

      swiperRef.current = new Swiper(swiperElement, {
        modules: [Navigation, Pagination],
        observer: true,
        observeParents: true,
        pagination: {
          el: swiper_pagination,
          clickable: true,
        },
        navigation: {
          nextEl: swiper_next,
          prevEl: swiper_prev,
        },
        slidesPerView: 1,
        speed: 800,
        touchStartPreventDefault: false,
      });
    }
  }, [areBlocksInserted, ref.current]);

  const TEMPLATE = [
    [
      "core/columns",
      { className: "gallery-cont swiper-slide" },
      [
        ["core/column", {}, [["core/image", {}]]],
        [
          "core/column",
          {},
          [
            ["core/heading", { placeholder: "Insert title", level: 2 }],
            ["core/heading", { placeholder: "Insert small title", level: 3 }],
            ["core/paragraph", { placeholder: "Insert content" }],
          ],
        ],
      ],
    ],
  ];

  const addSlide = () => {
    const newSlideCount = attributes.slideCount + 1;
    setAttributes({ slideCount: newSlideCount });
    const slideBlock = wp.blocks.createBlock(
      "core/columns",
      { className: `gallery-cont swiper-slide slide-${attributes.slideCount}` },
      [
        wp.blocks.createBlock("core/column", {}, [wp.blocks.createBlock("core/image", {})]),
        wp.blocks.createBlock("core/column", {}, [
          wp.blocks.createBlock("core/heading", { placeholder: "Insert title", level: 2 }),
          wp.blocks.createBlock("core/heading", { placeholder: "Insert small title", level: 3 }),
          wp.blocks.createBlock("core/paragraph", { placeholder: "Insert content" }),
        ]),
      ]
    );
    insertBlock(slideBlock, blockOrder.length, clientId);
    swiperRef.current.update();
    swiperRef.current.slideTo(attributes.slideCount);

    setTimeout(() => {
      swiperRef.current.slideTo(attributes.slideCount);
    }, 300);
  };

  const removeSlide = () => {
    const newSlideCount = attributes.slideCount - 1;
    setAttributes({ slideCount: newSlideCount });
    if (swiperRef.current) {
      const activeIndex = swiperRef.current.activeIndex;
      const blockToRemove = blockOrder[activeIndex];
      removeBlock(blockToRemove, rootClientId);
      swiperRef.current.update();
    }
  };

  return (
    <div
      {...blockProps}
      className={`${className || ""} my-block gallery edit`}
    >
      <div className="swiper">
        <div className="swiper-wrapper">
          <InnerBlocks
            template={TEMPLATE}
            templateInsertUpdatesSelection={false}
            templateLock={false}
          />
        </div>
      </div>
      <div className="swiper-pagination"></div>
      <div
        className="swiper-navigation"
        style={{ height: attributes.slideCount === 1 ? "0" : "50px" }}
      >
        <div className="swiper-prev"></div>
        <div className="swiper-next"></div>
      </div>
      <div className="button-wrapper">
        <Button
          isSecondary
          onClick={addSlide}
        >
          Add a Slide
        </Button>
        <Button
          isSecondary
          onClick={removeSlide}
          style={{ display: attributes.slideCount > 1 ? "inline-flex" : "none" }}
        >
          Remove Current Slide
        </Button>
      </div>
    </div>
  );
}

First, let’s import some built-in WordPress functions

import { Button } from "@wordpress/components";
import { useDispatch, useSelect } from "@wordpress/data";
import { InnerBlocks, useBlockProps } from "@wordpress/block-editor";
import { useEffect, useRef } from "@wordpress/element";
import Swiper from "swiper";
import { Navigation, Pagination } from "swiper/modules";

Some of these are familiar to those who use React. Here we import a version of those functions that is usable in the editor.

As attributes of Edit function, we use, among others, our custom attribute that we declared in block.json

export default function Edit({ attributes, setAttributes, className, clientId }) {

Then we set up Refs in the React way and use useDispatch and useSelect to manage the dynamic data flow from the server.

Inside useEffect, we handle SwiperJS. This is intriguing because we are launching a gallery that will be displayed directly in the editor. If we optimize the block interface effectively, our user will see the gallery almost exactly as it will appear to site visitors (on the frontend). Of course, in the editor, we’ll also include buttons to add more slides, which won’t be visible to visitors. This marks a notable shift in perspective.

Now, what does TEMPLATE refer to?

const TEMPLATE = [
    [
      "core/columns",
      { className: "gallery-cont swiper-slide" },
      [
        ["core/column", {}, [["core/image", {}]]],
        [
          "core/column",
          {},
          [
            ["core/heading", { placeholder: "Insert title", level: 2 }],
            ["core/heading", { placeholder: "Insert small title", level: 3 }],
            ["core/paragraph", { placeholder: "Insert content" }],
          ],
        ],
      ],
    ],
  ];

It’s a part of InnerBlocks, a very handy system for importing elements already present in WordPress into our custom block, such as images (including the media library handling) and text elements. Optionally, we can insert videos, quotes, and many other blocks, each with their integrated management system. This syntax closely resembles what we find in the strange HTML of FSE themes, akin to what we see when copying a block and pasting it into a text file.

The template will be rendered with minimal code in save.js, while here it is invoked within InnerBlocks in our return statement (yes, exactly, we're in React logic).

The functions addSlide and removeSlide manage the insertion of new slides. The slide count is managed through the attribute we added. Why isn't it an internal variable? Because we need the slide count to be stored in the database, and that's exactly what custom attributes do. We use createBlock, insertBlock, and removeBlock to insert and remove the slides, which are structured exactly like our initial TEMPLATE. Let’s take a look:

const slideBlock = wp.blocks.createBlock(
      "core/columns",
      { className: `gallery-cont swiper-slide slide-${attributes.slideCount}` },
      [
        wp.blocks.createBlock("core/column", {}, [wp.blocks.createBlock("core/image", {})]),
        wp.blocks.createBlock("core/column", {}, [
          wp.blocks.createBlock("core/heading", { placeholder: "Insert title", level: 2 }),
          wp.blocks.createBlock("core/heading", { placeholder: "Insert small title", level: 3 }),
          wp.blocks.createBlock("core/paragraph", { placeholder: "Insert content" }),
        ]),
      ]
    );

In the end, our render function mirrors the HTML structure needed by SwiperJS, with our TEMPLATE inserted as the first slide.

<InnerBlocks
  template={TEMPLATE}
  templateInsertUpdatesSelection={false}
  templateLock={false}
/>

And we include buttons for inserting or removing slides:

<Button
  isSecondary
  onClick={addSlide}
  >
  Add a Slide
</Button>
<Button
  isSecondary
  onClick={removeSlide}
  style={{ display: attributes.slideCount > 1 ? "inline-flex" : "none" }}
>
  Remmove Current Slide
</Button>

The frontend part is much simpler. The file responsible for rendering our block on the site is save.js

import { InnerBlocks, useBlockProps } from "@wordpress/block-editor";

export default function Save({ className }) {
  const blockProps = useBlockProps.save();

  return (
    <div
      {...blockProps}
      className={`${className || ""} my-block gallery`}
    >
      <div className="swiper">
        <div className="swiper-wrapper">
          <InnerBlocks.Content />
        </div>
      </div>
      <div className="swiper-pagination"></div>
    </div>
  );
}

We import InnerBlocks to display the content of our InnerBlocks as defined in edit.js.

Finally, we add the JavaScript code to launch the gallery with SwiperJS on the frontend in gallery.js.

import Swiper from "swiper";
import { Pagination } from "swiper/modules";

function gallery() {
  document.querySelectorAll(".my-block.gallery").forEach(function (el) {
    var swiper_pagination = el.querySelector(".swiper-pagination");

    var swiper = new Swiper(el.querySelector(".swiper"), {
      modules: [Pagination],
      pagination: {
        el: swiper_pagination,
        clickable: true,
      },
      slidesPerView: 1,
      speed: 800,
    });
  });
}

document.addEventListener("DOMContentLoaded", gallery);

Create your own Blocks

Creating your own blocks following this structure is straightforward at this point. Here, I’ve shown a block with a dynamic interface for managing slides, but you can apply the same method to create blocks that are simpler or much more complex. What remains to be defined is the folder structure of the project (whether it’s a theme or a plugin) and, of course, the build process. This will be the topic of the second part of the article.

Another function we can employ when we want to fetch dynamic data is render_callback, which we pass as an argument when registering the block in functions.php. render_callback allows us to retrieve a list of posts, an archive, or navigation menus directly from the server. For instance, in my ZenFSE theme, I've developed a custom header that allows users to choose between two different menus—one for desktop and one for mobile. These menus are fetched using render_callback.

Even more: Modifying Core Blocks

Now that we understand how a block works, keep in mind that WordPress Core Blocks operate in the same way (but with many more features). If you want to take a look at the source code of the blocks, you can go to the WordPress Repository on GitHub.

All blocks, including Core blocks, can be customized using hooks. In particular, we’re interested in addFilter. With this hook, for example, we can enhance an existing block’s functionality without having to rewrite it from scratch. For instance, we could add an additional text field to an image block, or add a dropdown in the block sidebar for selecting an animation to execute when the block is rendered. In ZenFSE, I've used GSAP to add an entrance animation to all my blocks.

Conclusion — Part One

Conclusion — Part One
This level of interactivity with components truly leaves ample room for creativity and imagination, both from the developer and the user perspectives. Another advantage is the modular nature of the code. Each block resides within its own folder with its files, and in terms of dependencies, each block has its own CSS and JavaScript. Blocks can be used anywhere on the site and can also be inserted into other blocks (such as groups or columns). Moreover, InnerBlocks inherit the properties of the blocks they are composed of, so it’s possible to apply colors, typography, and all globally declared properties from the theme.json file.

WordPress continues to evolve with new solutions, the latest of which, at the moment I am writing, is the Interactivity API, which allows defining block interactions in an even more immediate manner.

There is no rest for developers.