I still think this has its place, but there is a simpler solution that you may be able to implement using a specific hook that WordPress provides.
In the previous post, we walked through a lot of refactoring that separated concerns into their own classes.
Ultimately, this helps show how we can maintain a high level of cohesion while not only working with classes in WordPress but doing so alongside pre-existing APIs.
Because the last few posts on refactoring the code base have been so long, the current set of posts are focused on small, incremental changes and thus shorter, more focused posts.
As mentioned in the previous article:
But if you refresh the page, you may notice that the sanitization and serialization do not seem to work when retrieving the data. And that’s what we’re going to look into in the next post.
So that’s where we’re going to pick up in this article.
If you’ve ever built a custom plugin for yourself or for someone else, then you’ve likely done something with the WordPress plugin links even if it’s just providing author information a URL to the homepage for the plugin.
And you know what I’m talking about: These are the links that appear below the name of the plugin.
According to the code reference, this information is:
The plugin’s metadata, including the version, author, author URI, and plugin URI.
Occasionally, though, you may find that you want to add or modify the links. That is, you can add your own custom links to appear in the list below.
A little over three years ago, I wrote a post about starting to write shorter blog posts. And in that particular posts, I made two comments that I think are still relevant but that I’ve gotten away from doing.
First, I wrote:
Because the truth is with the amount of information coming from other blogs, Twitter, and whatever other social networks and news sources you read, odds are that this site is one that can also be easily marked as read or thrown into Pocket oblivion never to be read again.
And I also wrote:
Secondly, it’ll aim to be more to the point than anything else. The idea being that you can load up the article, read through it quickly, save whatever information you’d like (or not), and then move on to whatever’s in your queue.
I don’t know if old habits die hard or if I’ve simply gotten away from it and back to writing longer form writing because that’s how I tend to write.
But I don’t want all of my posts to be that way.
Programmatically creating taxonomies seems to be a point that comes up now and again for those who are building solutions for others on WordPress.
Taxonomies themselves can even be a little confusing; however, I’ve found that the following usually helps to solidify the concept a bit:
Hierarchical taxonomies are analogous to categories; non-hierarchical taxonomies are analogous to tags.
But still, let’s say that you’re creating a solution for someone such that you need to import information as a post and apply a taxonomy to it. Further, perhaps you want to apply a parent taxonomy to the post, as well.
How can we do that?