How to Create Custom WordPress Editor Blocks in 2021

The WordPress block editor (previously titled Gutenberg) includes a new way to add content to your WordPress posts, pages and soon all content on your WordPress site. It marks WordPress’ move into the page builder space.

The base set of default blocks is pretty robust, but what if you wanted to create your own custom block for laying out content? In the past you would use something like Advanced Custom Fields (ACF) or shortcodes. These days, custom blocks are where it’s at.

I’ve been working with React full-time for the past year, rebuilding WP Migrate DB Pro’s frontend. React is on my mind, and given that the WordPress editor is also written in React, I thought it would be a good idea to see what it would take to create a custom block. So let’s get into it!

Getting started

We’re going to go over what it takes to go from nothing to a relatively basic, custom Gutenberg block. The documentation for the block editor is still kind of all over the place but there is some decent information in the “Block Editor Handbook”. Unfortunately I didn’t find it all that easy to parse, so we’ll go over some of the steps I went through to get set up.

One thing I would recommend before diving head first into creating a Gutenberg block, for now at least, is to get a solid understanding of React and modern JavaScript. If you’re not familiar with things like JSX you could use the ES5 syntax, but you’d be best suited to use the modern syntax in the long run.

It’s fairly straightforward these days to get set up with the WP CLI ‘scaffold’ command. This command will set up a WordPress theme or plugin with a ‘blocks’ folder that contains the PHP and base CSS and JavaScript required to create a custom block. The only drawback that I noticed is that the JavaScript uses the old ES5 syntax rather than modern ESNext. Modern JavaScript allows us to write more concise code and use JSX in our custom block code.

You can also use the ‘create-guten-block’ tool by Ahmad Awais. It gives you a lot of the boilerplate stuff you need out of the box, like Webpack, ESNext support etc. Setting it up is fairly straightforward, and it’s similar to Create React App.

However, rather than using a third-party tool, I used one of the example custom blocks available in the gutenberg-examples repo on Github. The recipe card example covers a lot of what you’ll want in a minimally interactive custom block. It also includes @wordpress/scripts which is a package to run and build our JavaScript code, allowing us to use ‘ESNext’ syntax and JSX.

To get up and running, I just copied the recipe card example locally, modified the fields in the package.json file, and ran yarn.

Blocks

Ok, so what is a ‘Block’ anyway? I had a hard time understanding this concept when I first started working with the block editor.

From the documentation:

Using a system of Blocks to compose and format content, the new block-based editor is designed to create rich, flexible layouts for websites and digital products. Content is created in the unit of blocks instead of freeform text with inserted media, embeds and Shortcodes…

Basically a ‘block’ is an organizational unit for editable ‘stuff’ in WordPress. At least that’s my take on it.

Blocks are the core building ‘block’, but how do you make one? Well, that part I can explain! Blocks are made almost entirely in JavaScript. Gutenberg brings a couple new actions (enqueue_block_assets and enqueue_block_editor_assets) to let you include your JavaScript and stylesheets to be used with Gutenberg.

function fancy_custom_block_block_init() {

    // automatically load dependencies and version
    $asset_file = include( plugin_dir_path( __FILE__ ) . 'build/index.asset.php');

    wp_register_script(
        'fancy-custom-block-block-editor',
        plugins_url( 'build/index.js', __FILE__ ),
        $asset_file['dependencies'],
        $asset_file['version']
    );

    wp_register_style(
        'fancy-custom-block-block-editor',
        plugins_url( 'editor.css', __FILE__ ),
        array( ),
        filemtime( plugin_dir_path( __FILE__ ) . 'editor.css' )
    );

    wp_register_style(
        'fancy-custom-block-block',
        plugins_url( 'style.css', __FILE__ ),
        array( ),
        filemtime( plugin_dir_path( __FILE__ ) . 'style.css' )
    );

    register_block_type( 'fancy-block-plugin/fancy-custom-block', array(
        'editor_script' => 'fancy-custom-block-block-editor',
        'editor_style'  => 'fancy-custom-block-block-editor',
        'style'         => 'fancy-custom-block-block',
    ) );
}

add_action( 'init', 'fancy_custom_block_block_init' );

All you essentially need to do PHP-wise is enqueue your JavaScript and CSS files and call register_block_type() with each asset’s handle.

A world of JavaScript

If you were thinking there’d be more PHP from this point, think again! From here on in, we’re in a JavaScript world.

The key aspect to creating blocks in Gutenberg is the registerBlockType() function. It does all the work.

registerBlockType( 'my-block/cool-block-name', {
    // ... Massive JS object
}

And that’s it! See you next time!

…

Ok so, there’s a bit more to it than that, but at its core, this is how to create a WordPress Gutenberg block. In the ‘Massive JS object’ there’s a few things to take note of.

If you take a look in /05-recipe-card-esnext/src/index.js file in the gutenberg-examples repo, you can see there’s a lot of config that goes into setting up a block. There are three main sections we’ll go over – attributes and the edit() and save() methods.

Attributes

If you want a block that actually does something, like allow you to edit text, you have to use Gutenberg’s state management system. That’s what the attributes object is. It’s pretty much identical to React’s state management concept, a top level object that keeps track of properties and what’s changed.

attributes: {
    title: {
        type: "array",
        source: "children",
        selector: ".callout-title"
    },
    mediaID: {
        type: "number"
    },
    mediaURL: {
        type: "string",
        source: "attribute",
        selector: "img",
        attribute: "src"
    },
    body: {
        type: "array",
        source: "children",
        selector: ".callout-body"
    },
    alignment: {
        type: "string"
    }
},

The above is a JavaScript object that’s used to configure the appearance of the block.

You can see that for each editable ‘thing’ in your block you need to define an attribute for it. There’s the mediaID and mediaURL for the image, values for a title and body content, as well as the overall alignment of everything. The edit() method takes these attributes as an argument so we can modify them in the editor interface.

edit()

The edit() function lets you customize the editing interface in Gutenberg. If you’re familiar with React’s render() function it’s pretty similar. You essentially specify a return statement that has your JSX in it.

 edit: props => {
    const {
        className,
        isSelected,
        attributes: { mediaID, mediaURL, body, alignment, title },
        setAttributes
    } = props;

    useEffect(() => {
    // console.log(props);
    });

    const onChangeTitle = value => {
        setAttributes({ title: value });
    };

    const onSelectImage = media => {
        setAttributes({
            mediaURL: media.url,
            mediaID: media.id
        });
    };

    const onChangeBody = value => {
        setAttributes({ body: value });
    };

    const [imageClasses, textClasses, wrapClass] = sortOutCSSClasses(
        alignment || 'left',
        className
    );

    return (
    <>
        {isSelected && (
            <BlockControls key="controls">
                <AlignmentToolbar
                value={alignment}
                onChange={nextAlign => {
                    setAttributes({ alignment: nextAlign });
                }}
                />
            </BlockControls>
        )}

        <div className={wrapClass} key="container">
            <div className={imageClasses}>
                <div className="callout-image">
                <MediaUpload
                    onSelect={onSelectImage}
                    type="image"
                    value={mediaID}
                    render={({ open }) => (
                    <Button
                        className={mediaID ? "image-button" : "button button-large"}
                        onClick={open}
                    >
                        {!mediaID ? __("Upload Image") : <img src={mediaURL} />}
                    </Button>
                    )}
                />
                </div>
            </div>                                  
            <div className={textClasses}>
                <RichText
                    tagName="h2"
                    className="callout-title"
                    placeholder={__("Write a callout title…")}
                    value={title}
                    onChange={onChangeTitle}
                />
                <RichText
                    tagName="div"
                    multiline="p"
                    className="callout-body"
                    placeholder={__("Write the callout body")}
                    value={body}
                    onChange={onChangeBody}
                />
            </div>
        </div>
    </>
    );
},

You can see that the first thing we do is assign our attributes to some local variables to be used within the function.

const {
    className,
    isSelected,
    attributes: { mediaID, mediaURL, body, alignment, title },
    setAttributes
} = props;

The above syntax is object destructuring and is mostly for the ‘less-typing-is-better’ effect. The next few functions are for handling the onChange() events in the editor. Basically when you change any value you want to update your application state. That’s what the setAttributes() method does.

const onSelectImage = media => {
    setAttributes( {
        mediaURL: media.url,
        mediaID: media.id,
    } );
};

A lot of what’s included in the edit() method are event handlers that set state in the block’s attributes object. You’ll also notice the usage of the useEffect() hook in there. That’s a core React hooks method – under the hood Gutenberg is largely a wrapper over React.

The last part of the edit() function is the return statement. In here we have a bunch of JSX code that determines what the Gutenberg interface actually looks like. You can load in some standard components and blocks from the @wordpress/block-editor package.

import {
    RichText,
    MediaUpload,
    BlockControls,
    AlignmentToolbar
} from "@wordpress/block-editor";

Then in your return statement you can use them and assign attribute values:

    return (
        ...
            <div className={textClasses}>
                <RichText
                    tagName="h2"
                    className="callout-title"
                    placeholder={__("Write a callout title…")}
                    value={title}
                    onChange={onChangeTitle}
                />
                <RichText
                    tagName="div"
                    multiline="p"
                    className="callout-body"
                    placeholder={__("Write the callout body")}
                    value={body}
                    onChange={onChangeBody}
                />
            </div>
        ...
    );

The WordPress block editor includes a block called RichText. This is the main block you’ll want to use to make editable areas with. There are options for setting the type of HTML tag it outputs as well as a variety of other settings. The onChange attribute is where you assign your onChange() function. This is important as it’s how you update your block attributes and make everything update in real-time.

save()

So that’s cool and all but we’re not actually saving anything yet. The next part of our custom block is the save() method.

This method defines how you want your block to be displayed on the front-end.

Gutenberg actually does something quite unique with how it saves data. Unless you’re saving data to post_meta the block configuration is serialized in an HTML comment above the block. WordPress appears to filter this out on the front-end, but it’s visible in the database record.

<!-- wp:fancy-block-plugin/fancy-custom-block {"mediaID":4035} -->
<div class="wp-block-fancy-block-plugin-fancy-custom-block bootstrap-block"><div class="wrap-left-"><div class="image-left-"><img class="the-image" src="http://wpdevelop.devtest/content/uploads/2020/01/image-5.jpg"/></div><div class="text-left-"><h2 class="callout-title">Test 2</h2><div class="callout-body"><p>Test</p></div></div></div></div>
<!-- /wp:fancy-block-plugin/fancy-custom-block -->

It’s a bit weird, but maintains backwards compatibility – if you ever disable Gutenberg the content will remain intact.

save: props => {
    const {
        className,
        attributes: { title, mediaURL, body, alignment }
    } = props;

    const [imageClasses, textClasses, wrapClass] = sortOutCSSClasses(
        alignment || "left",
        className
    );

    return (
        <div className="bootstrap-block">
                <div className={wrapClass}>
                    <div className={imageClasses}>
                        {mediaURL && <img className="the-image" src={mediaURL} />}
                    </div>
                </div>
                <div className={textClasses}>
                    <RichText.Content
                        tagName="h2"
                        className="callout-title"
                        value={title}
                    />
                    <RichText.Content
                        tagName="div"
                        className="callout-body"
                        value={body}
                    />
                </div>
        </div>
    );
}

The save() method is actually much simpler than the edit() method and you get the values of the attributes passed in as well. Then it’s mostly a matter of creating your front-end markup and inserting your values. Easy-peasy.

Issues I came across

Alright, so that’s the ‘how’ of creating a custom block, but what about the gotcha’s? Well, it turns out, there’s a few 😢.

The documentation is a little hard to parse. It’s not super easy to understand and is split up in a strange way. I found it hard to track down the documentation for each piece of building a custom block and ultimately just read through the example block code. There’s a lot of digging through code required to understand how things work.

I also found it really annoying working on a block that’s actively changing in code. Every time you reload Gutenberg, you’ll get the “This block appears to have been modified externally…” message because the markup of the block has changed.

I get why it’s throwing the error, but it slows you down.

I also had some strange console errors because SCRIPT_DEBUG was enabled. This constant is required to use the uncompiled version of React locally. Apparently this is a known issue, but it’s a bit crappy seeing console warnings because a WordPress core constant is enabled.

Further, React devtools are essentially useless as the React component names in Gutenberg are one character names…

All this is to say: there are still some rough edges so your mileage may vary.

Alternatives

Ok, so it’s a bit of work to create a truly custom block. But what if you want to create a block type via a UI? Well, it turns out you can with ACF. ACF Blocks does much of this configuration all within the familiar ACF fields interface. The other benefit is that you can write the display code for ACF Blocks all in PHP.

ACF Blocks are a bit different than a custom created block though. The recommended approach with ACF Blocks is to edit the fields in the sidebar editor and view the preview in the main editor area. It’s a bit of a different experience to creating blocks, but it’s more inline with how ACF has traditionally worked – adding content in fields that are separate from the main editor.

If you’re only interested in rendering field values inside a block, this may be an option for you. You can also style the ACF block with an editor stylesheet so that it appears as it would on the frontend.

ACF Blocks feel more like a ‘hack’ of Gutenberg rather than the official way of creating blocks.

There are also other WordPress plugins that let you ‘assemble’ blocks, like Block Lab and Lazy Blocks. I haven’t tried either, but they may be an option if you’re looking for a minimal-code method for creating a custom block.

After it’s all said and done

So there you have it, how to create ‘custom’ blocks for the WordPress editor (or Gutenberg).

Have you created a custom Gutenberg block yet? What was your impression? Let us know in the comments.

This entry was posted in WP Migrate DB Pro, Code and tagged Plugin, WordPress Core, WordPress Development, JavaScript, Gutenberg.

.replybox-fallback, .replybox-fallback ul { list-style: none; }

bigbassroller@gmail.com says:

March 6, 2018 at 9:29 am

Thanks for the timely article. I feel like theres multiple ways to build wp sites now. The regular way, wp-json and in the future the gutenberg way. Either way, I think the future looks strong for WordPress.

Per Sturesson says:

March 7, 2018 at 12:51 am

Thanks for another great article! Being a little more experienced than the usual client I’m not fully seeing the potential of Gutenberg. While I understand it’s easier when you get a representable presentation on how your content will look when published, I seem to lean towards decoupling the CMS from the frontend and rather build an app that consumes data from the CMS as it gives me more freedom in the end.

Peter Tasker says:

March 8, 2018 at 7:19 am

Yep, you’re 100% correct. I think the REST API is probably the real future of WordPress. But from what I can tell focusing on the editor is to compete with other platforms (Wix, Squarespace) that have better editors (allegedly).

Reply
- Adam Patterson says:
  
  March 8, 2018 at 8:07 am
  
  They should test it our on WordPress.com then 🙂
  
  Reply
- SunShine says:
  
  May 6, 2020 at 6:32 pm
  
  So you’re thinking headless is the way to go, eh?
  
  Reply

Adam Patterson says:

March 7, 2018 at 4:39 pm

The one off putting thing to me, is that the blocks are made using Javascript. Specifically React with Redux. In theory it’s possible to have custom blocks calling and conflicting with Redux core / new actions. Possibly some how extending ( can you? ) and managing changes as the block developer sees fit. It also seems strange to me that the ultimate end product of this editor is HTML entered into a database ( while I have not looked to confirm this ). Would it have not been more straight forward and fit the WordPress mold a little more to have used HTML blocks with special data attributes that could reference functionality? This could allow the editor to be a separate thing from the blocks. Like the only reason the blocks are in React is so that they work with the Editor. Not so that they work WordPress themes. How does this impact the WordPress API? What if you were already building a theme that was React powered and uses the WordPress API. It’s possible that these blocks now are very limiting to what you could have done if you stored this data as an object and rendered it out into the HTML template you already had OR consume it as a natural object from the API. Kind of like using ACF.

Peter Tasker says:

March 8, 2018 at 7:17 am

As far as I know, React and Redux are just used with the new editing experience. The front-end will continue to be the same as it always has. I think the bigger issue is that now Gutenberg creates a real WYSIWYG editing experience people may be jarred when looking at the front-end if it looks drastically different then what they’ve created in wp-admin. I hear you with the ACF API, I think it would’ve been awesome if a new API was created so that we could also query and assemble the front-end a bit easier!

Reply
- Adam Patterson says:
  
  March 8, 2018 at 8:06 am
  
  If it becomes part of Core, I can see there being a "classic" plugin created 🙂 I am conflicted really. It seems like the benefits are a-lot stronger for designers, and maybe even the theme industry. But not as convincing for developers. I am also curious to see how any preexisting visual editor theme will work.
  
  Reply
  - mikelking says:
    
    March 9, 2018 at 5:05 am
    
    There already is a classic editor plugin ready to go for 5.0. Just in case you’re feeling a little editorially retro… https://wordpress.org/plugins/classic-editor/
    
    Reply
- Adam Patterson says:
  
  July 7, 2020 at 12:45 pm
  
  Circling back 2 years later 🙂 Here is another problem that I came across, It might be very specific but for my use cases I have still stuck with ACF and custom layouts because the sites I build are not suited to the Gutenberg Editor. That said, I have my own blog where I wanted to add a Mailchimp subscription form. And would you look at that, Jetpack has a Mailchimp block! Presto… Oh wait, ALL of the elements are inside of paragraph tags… I can change the layout by targeting child paragraph tags but to me that sucks. I wish there was a way to modify the layout from your template, since the HTML is stored in the database it wouldn’t have any impact on performance.
  
  Reply

Rob Mehew says:

March 9, 2018 at 5:37 am

I am excited but nervous about learning to create my own Guten Blocks, am I being silly about not learning it yet incase the framework changes from React? Is that likely even after the license changes from Facebook. Should I just dive in and create some blocks? – I have already created a basic block that does nothing, but I guess I am just wondering what is the best direction to focus my learning with regards to the Block Editor.

Peter Tasker says:

March 9, 2018 at 6:30 am

I don’t think there’s anything to worry about with the Facebook licensing stuff now. That’s largely been resolved as they’ve changed their patent clause, which is what everyone had issue with. https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/ I’d start with the Gutenberg documentation, they have some basics on how to create blocks, but it’s an evolving thing.

Reply
- Rob Mehew says:
  
  March 9, 2018 at 7:56 am
  
  Ah awesome ok, I only ask because on this post: https://ma.tt/2017/09/facebook-dropping-patent-clause/ Matt says that the React choice is a decision still be made. Thanks I’ll take a look! 🙂
  
  Reply

jvanpelt says:

July 16, 2018 at 9:09 am

Nice article! I’ve been contributing to the development of Gutenberg and the effort that the WP team have put into it has been huge, wether one agrees with the directions they’re taking or not it’s amazing how much has been done in such a short time. Something I wanted to point out is that block attributes should be defined "on the server" so PHP is aware of them, in fact you probably don’t need to return anything in the save() method since you can render the block for the frontend server-side, eg the latest post block: https://github.com/WordPress/gutenberg/blob/e31c87b3df0824f9edff2f9904292c7f370de3ec/blocks/library/latest-posts/index.php I don’t think this is documented yet and like you said it’s most likely subject to change but just felt worth to point out. Another thing I came across is that you can’t just use another ‘default’ block in your own custom block. Not every built-in block has an API or is exposed as a public class. Not sure what you meant about this, do you mean using it in a way different than: import { SomeBlock } from ‘@wordpress/blocks’;

Danny van Kooten says:

August 20, 2018 at 1:15 pm

Thanks for the article, I really enjoyed it. The "modified externally" thing is a so annoying. You wrote this in March – did you come up with a workaround or a way to update blocks?

Peter Tasker says:

August 27, 2018 at 10:02 am

TBH I haven’t revised this code at all since I wrote the article! A lot has changed in React and Gutenberg since I wrote it, so I think it’s due for an update.

Reply

Wouter de Vries says:

August 27, 2018 at 2:46 am

Thanks for this tutorial, but I’m getting an error in the editor "ReferenceError: sortOutCSSClasses is not defined". Any ideas how to fix this?

riw777 says:

December 8, 2018 at 5:40 am

It’s all well and good to force everyone to use react, but not all of us are full on developers. It seems, to me, that what wordpress is doing here is cleanly separating content producers from developers. This may be great for the developer community, or it could, ultimately, kill wordpress, as there is no way to ‘tinker’ with the content any longer. Doing anything custom with a post, for someone who is not a full time developer, now requires going to some marketplace and hiring someone, rather than playing with some css and html to make it look the way you want. Is this a good thing for the ‘web, or a bad one? IMHO, a bad one. It closes off the ability to develop custom content, relegating this role solely to full time developers and shutting the "tinker" market out. Tthe entire look and feel of wordpress sites will become even more generic and uniform over time. Experimenting will be expensive because it must be done by a professional, and hence it will not be done. Overall, I think wordpress just shot themselves in the foot. They will gain a million new users and build a larger development market in the short term, but in the log term they have ossified their product, making it something anyone can publish content with, but only a professional can tinker with. In the longer term, wordpress will crash because all the vitality of individuals experimenting and building unique things will be sucked out. WordPress is becoming the McDonald’s or Walmart of the web publishing world. Successful after a sense, but ultimately representing a huge dead zone of corporate sameness. I’m certain this is all great for you as a professional wordpress developer, but for the overall community, it’s a disaster.

Graeme says:

December 18, 2018 at 5:24 am

I dont think it has to be used… and Im sure themes will be built as they were before. People will continue to use flexible content (ACF) for example… I personally find it hard to picture a client who wants a professional website going to an agency and saying design me some blocks please. It’s just not practical, and whats available isn’t good enough to compete with the designed/developed market.

Reply

aezaz shaikh says:

January 17, 2019 at 9:31 am

Yeah, API change is a pain, I’m also tired of this

aezaz shaikh says:

March 11, 2019 at 1:35 am

This is such an great post about custom gutenberg block. I love everything about gutenberg blocks as it helps to add stunning animations to make your website looks great.

Simon H Lee says:

January 17, 2020 at 7:30 pm

If I remember correctly, Project Gutenberg was in large part, developed to enhance the WordPress.com publishing experience for non-coders. I think Automattic understands and wants to deliver products to coders and non-coders, so Gutenberg will continue to evolve to compete with SquareSpace, Wix, etc. I don’t think this will hurt WP at all. If anything, it’s a good business move to clearly differentiate WordPress.org for coders, and WordPress.com for non-coders.

leoloso says:

April 22, 2020 at 12:48 pm

There is now an official scaffolding package too: @wordpress/create-block, which also works for creating single-block plugins. And it supports hot reloading! (well, sort of, it’s not very fast to reload… but it is still triggered automatically when making a change to the source files). Here I explain how to set it up.

Peter Tasker says:

April 22, 2020 at 1:30 pm

Hey, that’s cool! I didn’t know about @wordpress/create-block before I wrote this article, nice tip.

Reply

Pere Cat says:

April 23, 2020 at 11:11 pm

Nice article buddy! But in fact, WordPress blocks s*ucks… More than 15% of the WordPress sites (it means millions), still in 4.9, 4.8… and from version 5 and above, just check how may millions of times have been download the classic editor plugin to still working in an easy, clear and safe mode ;). Just and opinion…

Brad says:

April 27, 2020 at 9:34 am

Pete is entitled to his opinion, but I strongly disagree that ACF Blocks is a hack. It’s a much needed bridge for some WP developers who are struggling to get up to speed with React. Not to mention all the use cases where having settings in the sidebar is what you want anyways.

Nicolas Scott says:

April 28, 2020 at 7:25 pm

I agree with Brad. Just the other day I was doing a site build and needed some custom markup that the client could easily edit. I dusted off the ACF Block documentation that I hadn’t looked at for a while and had exactly what I needed in a few minutes. The nice thing is it saves the data right in post_content, too so doesn’t take up meta table space for simple formatting purposes. My mind is so invested in PHP and SCSS as a one-man developer shop. I use jQuery where I need to modify the DOM. And as much as I’d love to be up to speed on modern JS and React, I just don’t know where to start and when (especially now that the family is home ALL THE TIME (4 kids 7 years and under). AHAHHHHH!

Reply

dzulfriday says:

April 28, 2020 at 7:52 am

The Block Lab team was hired by WP Engine. They discontinued the development of new features, so it’s not a very promising option to develop WordPress blocks anymore.

Jonathan Bossenger says:

April 30, 2020 at 1:26 am

That’s what the attributes object is. It’s pretty much identical to React’s state management concept, a top level object that keeps track of properties and what’s changed. Thank you for this!!! From the docs I couldn’t understand what the block attributes were supposed to do, then I read this and it all clicked into place.

clifgriffin says:

July 15, 2020 at 1:37 am

I am the creator of a plugin that adds functionalities for adding code into wordpress in a per-page or per-post basis. https://wordpress.org/plugins/ultimate-shortcodes-creator/ It can be done via shortcodes or Gutenberg Blocks. It’s lightweight and no overload is paid if the shortcode is not present in the page. Code can include php, js, css, and even ajax code. Also, scripts code can be inserted via or footer. May be is interesting for someone.

Mark Lee says:

July 17, 2020 at 11:13 am

Nice dev tutorial that also raises issues of strategies and user concerns. Somehow it seems to me that at the base, WordPress is losing its focus as a BLOGGING platform. Blogging is about writing and maybe sharing some images. More advanced users are also interested in or concerned about design and tinkering. Block editing sends novice coders like me into the stone age. For example, after setting up a post on a full-width page with no sidebar (because the theme doesn’t make the sidebar responsive), I wanted a tiny script, rather than another plugin, to make a shortcode to add to a a right column. Thanks to the WP support group, I was able to do it after 12 hours when it didn’t display or appeared at the top of the page with JSON errors. And this wasn’t even React, just plain old PHP code. Fifteen minutes tops if I really knew what I was doing. To create a Gutenberg sidebar block, from the sound of this post that’s three months for me. Blocks are entirely about design and editors such as Gutenberg and the popular Elementor, are not post-friendly. For example, Elementor does not even sell the idea of creating POSTS. So their freebee app does not even make creating a post simple. That’s in their paid version. But this is about Gutenberg. It’s even less intuitive than the commercial products. With Web presentation being increasingly driven by mobile and tablet viewers, design options are narrowing as UI considerations focus on user interactions (ease of navigation, clicks, form filling while conserving real estate etc). The wide canvases of the desktop are mainly for content creators and office functions. It’s not nice using a block editor on my little tablet. Bottom line then, is that block editors are suited for a declining market of layout that mimics magazines and newspapers and now, rightly, take the form of the applications like PageMaker and QuarkXpress. There’s no use for a right aligned photo on a phone. Properly done, the block editor should obviate the need for themes as a few templates should suffice with WordPress shipping with a blank table for the designer to play on. What we have is something we can’t describe as a horse, a camel or a giraffe. When I start LibreOffice Write, I know exactly what I’m about to do and when I open Scribus, I don’t expect to be preparing an interoffice memo. And that’s the problem with Gutenberg. Clicking Add New from the Posts menu doesn’t begin an intuitive experience. P.S. A negative about the block editor environment is that you’re completely locked out of the admin interface.

Michael McGlynn says:

December 18, 2020 at 3:04 pm

Great article and well considered. Thank you for writing it.

Kristina Bressler says:

March 11, 2021 at 12:21 pm

The Gutenberg Examples repo that you mentioned. On their main page, the installation section mentioned:

Download a pre-built zip archive of the latest release. Do not download from the "Clone or download" GitHub button, as this includes the source material only. Read the Development instructions below if you’re interested in building your own copy of the plugin.

This is what I see before clicking on the link to download the files. However, what I see is this: <img width="1023" alt="Screen Shot 2021-03-11 at 9 48 23 AM" src="https://user-images.githubusercontent.com/5368455/110814362-fedeb400-824e-11eb-9519-4f2a0cccd6d2.png"> I download both the gutenburg-examples.zip and source code in order to look at both folders. The source code has package.json, etc that the gutenburg-examples.zip doesn’t have. I’m trying to follow the block tutorial from develop.wordpress.org: https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/writing-your-first-block-type/ So which one should I be using to edit as I follow the block tutorial?