Baseline Status In A WordPress Block | CSS-Tricks

Baseline Status In A WordPress Block | CSS-Tricks


You know about Baseline, right? And you may have heard that the Chrome team made a web component for it.

Here it is!

Of course, we could simply drop the HTML component into the page. But I never know where we’re going to use something like this. The Almanac, obs. But I’m sure there are times where embedded it in other pages and posts makes sense.

That’s exactly what WordPress blocks are good for. We can take an already reusable component and make it repeatable when working in the WordPress editor. So that’s what I did! That component you see up there is the web component formatted as a WordPress block. Let’s drop another one in just for kicks.

Pretty neat! I saw that Pawel Grzybek made an equivalent for Hugo. There’s an Astro equivalent, too. Because I’m fairly green with WordPress block development I thought I’d write a bit up on how it’s put together. There are still rough edges that I’d like to smooth out later, but this is a good enough point to share the basic idea.

Scaffolding the project

I used the @wordpress/create-block package to bootstrap and initialize the project. All that means is I cd‘d into the /wp-content/plugins directory from the command line and ran the install command to plop it all in there.

npm install @wordpress/create-block
The command prompts you through the setup process to name the project and all that.

The baseline-status.php file is where the plugin is registered. And yes, it’s looks completely the same as it’s been for years, just not in a style.css file like it is for themes. The difference is that the create-block package does some lifting to register the widget so I don’t have to:

The real meat is in src directory.

Mac Finder window with the WordPress project's src folder open with seven files, two are highlighted in orange: edit.js and render.php.

The create-block package also did some filling of the blanks in the block-json file based on the onboarding process:

{
  "$schema": "
  "apiVersion": 2,
  "name": "css-tricks/baseline-status",
  "version": "0.1.0",
  "title": "Baseline Status",
  "category": "widgets",
  "icon": "chart-pie",
  "description": "Displays current Baseline availability for web platform features.",
  "example": {},
  "supports": {
    "html": false
  },
  "textdomain": "baseline-status",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css",
  "render": "file:./render.php",
  "viewScript": "file:./view.js"
}

Going off some tutorials published right here on CSS-Tricks, I knew that WordPress blocks render twice — once on the front end and once on the back end — and there’s a file for each one in the src folder:

  • render.php: Handles the front-end view
  • edit.js: Handles the back-end view

The front-end and back-end markup

Cool. I started with the web component’s markup:

 

I’d hate to inject that