You should be well-versed in the refactoring we’re doing regarding the WordPress Widget Boilerplate. If not, I recommend catching up on the series thus far by:
As far as the code base goes, we’re in a good place right now. We’ve begun to refactor much of the code into smaller, more focused classes. And we’ve just set up a Registry so that we can begin working with instances of objects throughout the plugin without the need for too much coupling.
But there’s still a problem we’re facing and it deals with namespaces and autoloading. I’ve talked a bit about this a couple of years ago but not as it relates to Composer.
And that’s what we’re going to look at in this post.
Continue reading “WordPress Widgets: Refactoring, Part 6 There’s a problem we’re facing with namespaces and autoloading and that’s what we’re going to review.“
In the previous post, we created a Registry that is going to be used to store all of the various classes responsible for giving our widget its functionality.
To do this, there’s going to be a variety of other classes introduced, but before going there, we need to add the Registry to the plugin’s bootstrap (let alone create a bootstrap for the plugin).
Specifically, here’s where we left off:
As mentioned earlier in the post, we need to add this to the bootstrap of the plugin. To do this, though, we need to define our own filter so that we can easily pass the registry around the rest of the plugin (when the time comes to do that).
So in this post, we’re going to focus on doing exactly that.
Continue reading “WordPress Widgets: Refactoring, Part 5 Once we have a Registry, we need to be able to access it throughout our plugin and we do that with custom hooks.“
Whenever you’re building a plugin that introduces a submenu, and you’re using the proper APIs, you’re going to be creating an administration page (whether or not it has settings).
When doing this, though, you can also introduce a plugin settings link. These are the links that appear under the name of the plugin from in the plugin dashboard.
If your plugin introduces its submenu item, then it likely introduces its own settings page. And if you’re looking to associate this page with your plugin settings link, it’s really easy to do.
Continue reading “Adding a Plugin Settings Link If you’re looking to introduce your plugin settings link, it’s really easy to do.“
Over the break, I had a lot of time to think about different things as it relates to Pressware and this blog. One of the things I’ve been thinking about for months now is the idea of starting a podcast.
I talked a bit about the initial idea some time ago. In the post, I mentioned the following:
I’m not particularly interested in doing the “interview others” for a podcast because other people are doing them so well and they are interviewing such interesting people.
But I did wonder if there’s not some room for a question-and-answer format. I know many podcasts end their episodes like this. However, I’m interested in experimenting with short podcasts (that is 10 – 15 minutes max) and those that answer questions.
The TL;DR version of the rest of the post is simple:
- If you have five minutes to spare, would you mind answering the following survey? It’s not closed to anyone, and this will help me to gauge interest in doing this. All submissions are kept completely private.
- The podcast will be short (20 – 30 minutes in length), will have a primary format, and will be geared towards anyone involved in WordPress.
Still curious? Read the rest of the post.
Continue reading “Gauging WordPress Podcast Interest I’ve come up with an idea for a podcast, how it will work, and the format for it. But I’d like your input.“
If you’re a WordPress developer who is using Composer without continuous integration, then odds are you’re left with a crucial step of figuring out how to manage the vendor directory when deploying your plugins.
- We know it’s a bad idea to throw the entire vendor directory under source control,
- Other developers who are familiar with using Composer should be able to get up and running without the need for much instruction,
- Continuous integration isn’t being used for any number of reasons,
- And we’re left with needing to provide a production-grade deliverable that uses certain dependencies but not others.
As much as the above points may describe our situation, it doesn’t tell us what we can do with it.
In other words, here’s the use case: You’ve built a WordPress plugin for someone. This plugin uses a variety of dependencies all of which are maintained by Composer.
You’re not checking the vendor directory into the repository, but you’re also not using continuous integration to deploy the plugin. Instead, the customer is, or a third-party is.
So what then?
Continue reading “Composer Without Continuous Integration One way to distribute WordPress plugins that use Composer without continuous integration.“