TL;DR: Here’s how you can use SQL to find WordPress users by metadata. This is useful when you have information such as their first name and last name and want to retrieve the full
WordPress provides a number of functions that make it easy to retrieve a user based on certain information. One of the most popular functions (or most useful, maybe?) is
However, what if you’re working on a system that maintains the user’s first name and last name or some other type of data point in the
usermeta table and you want to use that to retrieve the user’s information?
TL;DR: Here’s how you can programmatically authenticate a user into WordPress as long as you have a verified user ID for said user.
Earlier this week, I shared how to import necessary core files to programmatically manage users in the administration area of WordPress. Along those same lines, if you’re working with a third-party service for login and authentication, it may be useful to know how to programmatically redirect to the administration area once you have a valid user ID.
If you’re programming user management in WordPress there are a number of functions we have the convenience of using on the front-end. If you want to use the same functions in the back-end, though, you’ll need to include some “dependencies.”
TL;DR: Though knowing how to use a debugger is useful, it can be overkill for some of the work that we’re doing. In this article, we’ll look and see what debugging functionality Ray provides and how we can use it when traditional debugging may be overkill.
⚠️ If you’ve not already set up your environment, please read this post and make sure you have the free version of Ray installed.
TL;DR: The WP Plugin Scaffold repository contains a a very basic set of files that are needed to spin up a Composer-based WordPress Plugin.
Over the years, I’ve written or contributed to a number of different projects that have been aimed at making WordPress plugin development easier. At this point, there are a variety of ways people are creating WordPress plugins such that there isn’t really a way to create a boilerplate to capture all of them.
So I’m not aiming to do that.
But over the last few months (or maybe a year?), I’ve been working with the same structure for creating plugins. It normally grows into something larger based on if I’m taking an object-oriented approach or a procedural approach. It also changes based on how large the plugin is, what its purpose is, who is going to use it, or how it’s going to be used.
To that end, I’ve ended up with a very basic set of files that every project incorporates regardless of the size.
As such, I thought I’d share it.