Tom McFarlin

Software, Development, and WordPress

Dracula Theme for Preformatted WordPress Blocks

When working on the articles for the Backend Engineer Learns to Build Block Editor Blocks series, I wasn’t happy with how the code samples were looking within the articles.

Previously, I’ve written – here and here – about my being a fan of the work done by Zeno Rocha in the Dracula Theme. Ideally, I wanted to be able to have the color scheme of the code in my articles match the theme. Something like a Dracula Theme for WordPress Blocks.

That’s when I found highlight.js and a Dracula theme for it. So I wrote a small plugin for WordPress that works with the existing Preformatted block and changes the color scheme to match that of Dracula.

I call it WP Dracula Highlight.js or, more simply, Dracula Highlight.

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

© 2022 Tom McFarlin

Theme by Anders NorenUp ↑