Tag: WordPress (Page 60 of 220)

Articles, tips, and resources for WordPress-based development.

Rapid Prototyping with WordPress: Concept Analysis

May 23, 2017 / Tom / 0 Comments

In the previous post, I started walking through the process of taking the idea for a plugin that rapidly prototyping it into something that works within WordPress. And though it works, it doesn’t necessarily follow any object-oriented principles, nor is it in a place that we can easily continue to add features.

No, this isn’t an argument for why object-orientation is better. It happens to be my preferred way of writing code so I’m approaching it this way.

I know that the example code I’m giving is simple and I know that a case can be made that something like this can be left as it is. But the point of this is to show how to take a concept, prototype it, and then move it into something that follows object-oriented principles.

And, in my experience, it’s much harder to do that with a complex example from the outset. if you lose readers from the beginning, then what hope is there for them to understand what’s coming?

So with that said, we’re going to take a look at the code from the previous post and do a bit of a concept analysis on it to see what might work well within a class and how we might begin to organize it using classes, namespaces, and so on.

Rapid Prototyping with WordPress: From Concept To Plugin

May 22, 2017 / Tom / 0 Comments

I’ve talked about using WordPress as a tool for rapid application development in a past article.

But the longer I work with WordPress and the more code I see, the more potential I realize it has as both a platform for rapid prototyping and then taking those prototypes to fully developed applications.

These plugins can be web applications, plugins, themes, websites, whatever. For the purposes of this post, it doesn’t matter. Instead, what matters is that for example:

you have an idea for a plugin,
you want to see how it might work within WordPress,
you quickly put something together,
you begin refining it.

For many who are getting involved for more serious WordPress development, I thought it might be worth taking a look at what this looks like. Namely, I’ll take an idea for a plugin, prototype it, and then refine it into a well-organized, object-oriented plugin.

So in the next series of articles, I’m going to walk through that process.

What Are WordPress User Caches?

May 18, 2017 / Tom / 0 Comments

If you’ve ever worked on a project when you need to work with WordPress authentication cookies, then you’ve likely stumbled across the wp_set_auth_cookie function. In short, this function:

Sets the authentication cookies based User ID.

And when you use this function, you’re essentially creating a cookie that’s used to authenticate the user to log into WordPress.

WordPress User Caches

But if you’re looking to authenticate a user with WordPress programmatically, then there are a few extra steps required to do it properly especially if you’re working with caching plugins.

And that’s where WordPress user caches come into play.

Repository Pattern Benefits: Why We Should Consider It

May 17, 2017 / Tom / 0 Comments

Yesterday, I gave a primer on the repository pattern. In short, it’s one of those patterns that I think anyone working on middleware built on top of WordPress should understand.

When giving a primer on a pattern like this, it can be tough to do justice to the pattern when you need to:

introduce it,
explain how it works,
cover the benefits,
and give a small demo.

But the real advantage to the repository lies not only in abstracting the data layer away from the rest of the application but that it can (or should) be able to be easily swapped out with various data stores without changing the API.

For example, in one instance, you may need to retrieve data from the WordPress database, in other cases you may need to retrieve something from a third-party API, or perhaps there’s some other place from which you need to retrieve data.

Regardless, the idea behind the repository pattern is that whatever sits behind it doesn’t matter so long as the API it provides works for the layer of the application calling into it.

And since we’ve covered a primer on the repository pattern, let’s take a look at some of the repository pattern benefits and how we can implement it in the context of WordPress projects.

The Repository Pattern Primer

May 16, 2017 / Tom / 0 Comments

Whenever you’re working on a larger project that’s based on WordPress, the odds that you’re going to be working with more than a single data source – that is, the WordPress database – are higher than normal. For example, you may be working on a project that has to coordinate information from:

the WordPress database,
a help desk ticketing system,
a content importing system,
another third-party API,
and possible more.

And when this happens, it can become a bit cumbersome to write code that makes it easy to retrieve information from those different places. This what developers usually talk about when they refer to dealing with “layers” in their application. That is,

there are layers for presenting information to the user,
layers for handling business logic (or domain logic),
layers for communicating with APIs,
and layers for storing data.

Honestly, you don’t have to have a variety of data stores to watch to create a layer that makes it easier to send and retrieve data from the database, that’s just when it’s more common. You can just as effectively work with a single data store, like the WordPress database, when implementing the repository pattern.

Regardless, if you’re building a larger website, web application, or plugin, implementing the repository pattern is something that can pay dividends in maintenance, clarity of code, and separation of concerns.

But how might this be implemented within WordPress? It’s not terribly challenging, but first, it’s worth reviewing a repository primer before jumping into any code.