Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 14 of 257)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

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

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.

Continue reading

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

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.

Continue reading

Start Writing WordPress Tutorials in these Gutenberg Times

Saying “here’s how to write a plugin” is far too general. It gives no frame of reference for what you’re going to be covering, what the plugin is going to do, what the prerequisites are, or what the end result is going to be. It may even get a beginner’s hopes up only to let them down to leave them feel more confused by the time they’re done.

Saying “here’s how to write your first WordPress plugin” is a little bit better because it sets a level of expectation in terms of the level of experience required. If the reader is a new developer or if they are an experienced developer, it’s still going to be teaching them how to work within the confines of WordPress. Sure, there are a multiple ways to write plugins but learning how to get started is the first step towards seeing that. 

Saying “here’s how to write a plugin that will read user profile information using the WordPress API to create a unique author page” is clear. It explains exactly what it’s going to do and lays out the different points of WordPress that will be used in the tutorial. 

Even if the reader doesn’t know it yet, the author knows that, when putting something like this together, s/he is going to need to use a combination of:

  • templates or template parts,
  • the ability to read user metadata with the API,
  • safely render information from the backend to the frontend, and how to handle all of the checks in between to make sure nothing is passed up from the database to the frontend that doesn’t need to be or that’s something like an empty value.

Further, there’s an opportunity to to highlight some other best practices like sanitization, escaping, maybe internationalization, etc. All of that would be content for another article, but teasing it out can help.  And this is speaking from experience.

So why bring all of this up?

Continue reading

Me, Myself, and I; Then, Now, and Soon

Previously, I wrote:

I’m having too much fun focusing on more things with less distraction. 

Maybe it sounds preachy, maybe not. If it does, I don’t mean it do be and if it doesn’t then I’m writing well enough; however, I still have the question as to what this means for this site. And though the answer isn’t necessarily as clear as I’d like, it’s better than that it was, say, four weeks ago.

And it may be a trivial, uninteresting thing to write about but I’ve written about just about anything and everything related to what it is I do with regard to this site, developing software, WordPress, and so for the majority for my career.

So as I hope to add to that, I seems to be reasonable to share why before getting back to what I normally do and starting to do more than I once did.

In other words, why stop now?

Continue reading

WordPress, Writing Daily, and Deep Work

I last wrote about the Magnitude of WordPress and said that the original version of the article was going to be much longer; however, the content was too scattered for me to try to bring it all together in a cohesive article.

So I’ve opted to separate them into at least a couple, if not three articles. If the last one was more outward focused on the status of WordPress and how we should think about as participants in its economy, this article is more inwardly focused on a few things about which I’ve been thinking.


The first thing I mentioned in the previous article that I didn’t cover was the following:

When I look back and see how much I used to write versus how much I’m publishing now (it’s been two months since my last post!), it’s weird.

But why “weird?”

At the time of this article, I’ve published 408 pages of content that dates back to October 3, 2010. For many, many years I wrote multiple times a week and for a long time I was writing almost daily specifically around various things regarding WordPress and software engineering within WordPress.

On WordPress, Writing Daily, and Deep Work

On one hand, I miss the frequency at which I was writing because I genuinely enjoy it and I think I’ve also lost some of proverbial muscle that comes with it (that is to say, I’m not as good as it as I once was – not to say I was necessarily good but I definitely do not feel as if I’m “in the habit” at the moment).

But a lot’s happened not to just to, y’know, the world over the last few years but also in my personal and and professional life.

Continue reading
« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑