Tag: Gutenberg (Page 1 of 2)

A Backend Engineer Learns to Build Block Editor Blocks, Part 5

December 22, 2022 / Tom

Now that we’ve got the basics of the block built, it’s time to introduce some of the features afforded to us by the WordPress API that allow us to make changes to the visuals of our block. Namely, we want to using block attributes for custom colors.

Sure, up to this point, we’ve bee building the blocks using the WordPress APIs for block creation, serialization, and displaying, but we’ve also hard-coded a lot of our our styling. And when it comes to building custom blocks, sometimes that’s exactly what we want to do.

But other times, we want the users to be able to change, say, the color of their text or the background of their blocks, or maybe both. And the APIs for the Block Editor make this possible. As with the rest of the content of this series, though, it’s not without understanding what’s available to us.

Since this series builds upon itself, I recommend reading and following the previous articles thus far especially if you’re just now stumbling across this content.

So far, these are the things we’ve discussed:

If you’re ready to continue, we’ll get started. Remember, now that we’re this far in the series, I’m working to keep the articles a bit shorter. This is because:

We’ve laid enough ground work so it’s easier to focus on one thing at a time,
I find it easier to digest one concept at a time especially when it comes to learning something new, like building blocks as a backend engineer 🙂.

So in this post, we’re going to focus on one new thing: Introducing color options for our block.

A Backend Engineer Learns to Build Block Editor Blocks, Part 4

November 17, 2022 / Tom

At this point, we’re half way through a major improvement to the block we’ve been working on. We have the ability to edit the content in the editor but we aren’t able to save it and because we aren’t able to save it, we aren’t able to view it on the frontend.

Now, though, we’re at a place where we can save our data, render it on the frontend, and continue to make sure that what the author sees is what the visitors see.

As I’ve done with the rest of the series, I recommend reading these first parts because they are going to bring you up to speed on everything you need to do to get up to this point:

Note that I still don’t have a GitHub repository set up for this plugin. I will once we reach a certain point, but not yet. And that’s because I think reading through the material and having to implement it versus cloning and changing a few things around can help you learn some of this material faster.

Anyway, I ended the previous post stating:

We’re going to cover

how to save the content,

render it on the frontend

And that will wrap up this initial part.

So that’s what we’re going to do.

A Backend Engineer Learns to Build Block Editor Blocks, Part 3

November 11, 2022 / Tom

The first two articles in this series have been long. Not only long in terms of the content they cover, but long in comparison to the usual content I write. Part of this is because of the nature of what I’m trying to cover and part of it has to do with getting the basic plugin going.

We’re at a point now, though, where we can start to shorten the length of the article and focus more narrowly on the functionality and its implementation.

If you’re stumbling across this series and this is the first post you’re reading or you’ve not done any of the work prior to get everything off the ground yet (as I don’t have a GitHub repository set up for this plugin just yet – and that’s on purpose 🙂), here’s what’s been covered so far:

In the previous article, I stated:

In the next article, we’ll start talking about how we can edit text within the context of the Block Editor, how to save the changes, and then view them on the frontend.

Originally, I planned to cover the following in a single article:

convert the element in the block editor into a field we can edit,
save the content of the field,
render the content that’s above

Instead, I’m going to cover just the first point above so we can focuses solely on the editor and how to manipulate data within its context. Then we’ll follow the article up with how to save the content and render it on the frontend.

A Backend Engineer Learns to Build Block Editor Blocks, Part 2

September 26, 2022 / Tom

I ended the last article with a functioning block that shows one thing in the editor and another thing on the frontend. The reason for doing so was so we could see how to put together the basic foundation of a plugin for the Block Editor.

Now that we’re at this point, it’s much easier to start talking about things related to the Editor, things related to the frontend, how to start serializing data, how to start reading data, and so on. But because I’m trying to do this entire series as a backend engineer creating blocks – which is generally delegated to frontend development – I want to take it step by step.

In the last article, I wrote:

[T]he thing we’re going to look at doing next is adding styles for both the frontend and the editor and some basic functionality to the block.

As I continue to write about learning to build block editor blocks, we’ll continue with looking at adding styles to both the backend and the frontend.

In this article, we’re going to cover:

adding controls to the block in the editor so we can control its placement within WordPress itself (or even remove it from the editor),
ensuring what we see in the editor is what we see on the frontend

Like last time, there are going to be things we have to dive into that will require reference material and links to external resources. But consider that part of the journey of learning to build blocks.

A Backend Engineer Learns to Build Block Editor Blocks, Part 1

August 29, 2022 / Tom

When I first started working with the Block Editor a few years ago, I wasn’t excited about it.

As a user, I was lukewarm about it simply because of change (I’m not a fan of change 🤷🏻‍♂️), though I’ve come around to it and don’t mind the new writing. Sure, it has its learning curve (especially as someone who has used WordPress for for 15+ years) but I still use it every day as a user and developer and am working on developing the muscle memory that comes with that.

As a developer though, I wasn’t fond of it at all. There wasn’t a lot of documentation and whatever was there was always changing. Whatever was working for this release may not work in the next release. That gets frustrating after a while and it’s is enough to demotivate you to step away from building things for it.

Plus, coming from someone who generally works on the backend of software, getting started in a completely new paradigm was tough. Not because I mind learning new things (can you work in this industry and not expect to learn new things?), but because however I may learn to do something now isn’t going to necessarily work later and this was happening at an incredible pace. The inconsistency was a problem.

That seems to have settled a little bit. Sure, there are still things that I’m sure I’ll hit on in this series of posts that aren’t going to work whenever future me reads this and I’m not particularly a fan of experimental packages but here we are.

Regardless, fast forward a few years, and I’m far more comfortable building blocks that I once was.

I don’t and won’t claim to be as good as many of the frontend developers who are building and doing amazing things with the Block Editor,
I’m not satisfied with the fact that there isn’t yet a consistent standard for how to organize project files (perhaps this will come in time, but we’ll see).

But that doesn’t mean I’m not at a place where I can’t get on with whatever may be needed from a block development standpoint.

There are ways we can organize things to make our work easier. And that’s good enough for me.
I know the basics and I know how to use the reference material.
And if all else fails, there’s plenty of people online who are able to help or point me in the right direction.
I also think it helps to try to figure out a mental map of how what we’re doing in JavaScript maps to what we do in PHP (or how it may be similar).

With all of that said, though, I thought it might be worth holding myself to the task I mentioned in the previous article on writing better the Block Editor tutorials.

Before going any further, I want to reiterate something that I’ve already shared:

Ryan Welcher and Learn WordPress are two places that seem to be the most popular for learning block development and I want to make sure they get the credit they deserve.

Starting with this post, I’m going to go write a series of articles in which I’ll share my experience as something like “a backend engineer is learning to build Block Editor blocks.” I’ll go from the very rocky beginning to the full functional ending.

Maybe it’ll help some of you along the way. And if not, at least it captures my journey.