Category: Articles (Page 37 of 258)

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

Privacy is Hard: Email

April 18, 2019 / Tom

A few weeks ago, I started writing about a couple of things related to privacy on the web (which is a topic that I think many of us think about in some capacity).

You can catch up on everything I’ve written about thus far, but this post is going to follow-up with something I mentioned in the previous post.

Specifically, I mentioned a simple alternative for not giving out your email address.

Although Burner Mail works well, I also think it’s worth using third-party services for your standard email, too. After all, it’s worth having your privacy protected there, too, right?

BurnerMail (and services like Throttle) are great for providing temporary email addresses with which you can still access those messages for some time.

Email Privacy: BurnerMail

But what if you’re looking for an actual email service that respects privacy and, say, doesn’t parse the information in your inbox to generate advertisements (or other similar functionality)?

Tools for Writing Better WordPress Code: The Composer Lock File

April 17, 2019 / Tom

Before wrapping up our discussion on Composer, we have one important thing left to discuss: The vendor directory (and by extension, the Composer lock file).

Specifically, we need to talk about why we don’t need to commit the vendor directory to the repository but how our contributors can be sure they have the latest version of the software needed to work with our code base.

Using code quality tools to write better WordPress code is important, yes, but understanding how to properly manage dependencies and our repository is important, too. So before looking at said utilities, let’s review the lock file, the role it plays, and why we don’t need to commit the vendor directory to our repository.

Using Custom Filters with Shortcodes

April 16, 2019 / Tom

Once you understand the Shortcode API and how filters work, it’s easy to implement them in WordPress.

Custom Filters with Shortcodes: Shortcode API

And when you’re able to mix the two, you can do much more than usual than when they are operating independently of one another.

Specifically, you can filter data that are in the result of the shortcode, and this can be especially useful for other developers. If you’re familiar with implementing custom filters, then doing this within the context of a short code isn’t much different.

But if you’ve never used either the shortcode API or the functionality before, it’s still easy to do.

Structuring API Functionality (with a Separation of Concerns)

April 12, 2019 / Tom

I don’t have a lot of experience when it comes to creating APIs. I’ve done a fair share of work when it comes to integrating WordPress with third-party APIs, but I’ve spent very little time working on creating a system that has its API with which other systems can interact.

As far as the latter is concerned, I’m actually in the middle of doing that (and I’m learning a lot). The gist of the project is there’s an iOS app that’s interacting with WordPress via the REST API in a bi-directional way.

Structuring API Functionality: The WordPress REST API

I’m eager to share more about it, but I need to do so when the project is further along.

But when it comes to working with third-party APIs and then building components of a WordPress project that interact with them, two of the things I consistently find useful are:

using a proper library,
diagramming the system,
separating the functionality into parts.

And the last two points above are what I’m looking to cover in this post.

A General Example of the Repository Pattern in WordPress

April 9, 2019 / Tom

In my experience, the way we first interact with the repository design pattern often influences how we think about the pattern. (The whole first impressions are lasting impressions, right?)

The purpose of this post is to show how it can be implemented in WordPress specifically when writing object-oriented plugins to read data (writing data may be covered in another post), but before doing that I tried to think of a few consistencies among the variations of the pattern that I’ve seen.

Generally speaking, this is what I think a repository pattern should do:

provide a single place to read data,
abstract the details of how the data is accessed,
and have a consistent interface for doing so.

This means that whatever it is you need to retrieve from the application can be retrieved from the database. But how its retrieved can be considered a black box. That’s up to the developer implementing the pattern.

And in the case for those who read this post, that’s most likely us.