Author: Tom (Page 18 of 427)

Useful Safari Extensions: Twitter and Nags

October 3, 2022 / Tom

In 2019, I started writing a bit about the different things I was using to make my online experience a more private (because I, like many of you, think privacy is important 🙂).

Though I’ve not written much about since then, I have found a couple of utilities that I use to help my browsing experience. Though they don’t necessarily fit in with things you may find in my articles on privacy, they still help with certain things that are simply annoying.

Here are are a couple of Safari extensions that I’ve found useful to have installed on iOS when browsing the web.

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.

Dracula Theme for Preformatted WordPress Blocks

September 12, 2022 / Tom

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.

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.

Start Writing WordPress Tutorials in these Gutenberg Times

August 19, 2022 / Tom

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?