In a recent project, I was working with someone who wanted to mark a comment as unapproved regardless of the value that was set in the WordPress settings.

Specifically, the person was using a plugin that allowed for certain attachments to the plugin. In order to make sure that the comment could be screened prior to allowing it to go public on the blog, they wanted to moderate it from the dashboard without needed to completely enable comment moderation across the board.

This is something that’s relatively easy to achieve programmatically.

Continue Reading…

For those of you who have been following development of the WordPress Plugin Boilerplate, you’ll recall that I previously included the register_activation_hook and register_deactivation_hook calls within the the class itself.

In the latest version of the Boilerplate, they’ve been removed outside of the context of the class and into a separate file. Last week, I received a great comment asking why this decision was made:

I have this one question – why plugin activation/deactivation hooks are registered outside the constructor (as they were in v1.0) ?

I thought it would be better to discuss the decision in a blog post rather than in a lengthy comment.

Continue Reading…

When it comes to defining custom option pages, theme pages, menu pages, and submenu pages, the provided API makes this trivially easy; however, one of the less used aspects of these functions is the ability to define a custom WordPress menu hook.

For example, in a recent project I needed to do exactly that when adding a submenu to the WordPress Tools menu so I thought I’d share my process for doing exactly this.

Note that if you’re looking to add a submenu to a different WordPress menu, then there are a couple of options that are available. First and foremost, the most common option is to use add_submenu_page and then use tools.php as the parent slug as specified in the Codex.

But if you happen to be working with the Tools menu, then the add_management_page function is your best bet because it’s designed for exactly that.

So for this article, that’s what I’ll be using.

Continue Reading…

During my time on working on the WordPress Plugin Boilerplate, I’ve had some really good discussions with Gary Jones about some of the practices and conventions used throughout the code.

Up until this point, I’ve traditionally included a plugin.po file with each of my plugins to make it easy for translators; however, Gary’s been kind enough to point out the a .pot file should actually be included.

From a discussion on GitHub:

If you read the Codex page you linked to, you’ll see that it explains that .pot is the correct extension to use for the original translation file, since it is the template from which .po and .mo files are generated.

I’m not above admitting when there’s something I’ve not been doing correctly – after all, most developers should constantly be improving right?

At least I hope that’s the case.

Luckily, there are tools that make generating this catalog trivially easy so I thought I’d provide the steps necessarily to internationalize WordPress plugins specifically how I did so for the latest release of the Boilerplate.

Continue Reading…

When it comes to working with remote requests on the server side, there are usually two solutions that I end up seeing.

In fact, there are two solutions that I’ve typically ended up using:

• file_get_contents
• cURL

Both of these functions generally work well; however, in our experience with Standard, we’ve had less than stellar experience especially when it comes to budget hosts.

This is where wp_remote_get comes into play. In short, wp_remote_get is a simple WordPress API function that’s used to retrieve data from a specified URL using the HTTP GET method.

Continue Reading…

The title of this post is somewhat misleading as I’m not actually sharing how to programmatically populate a WordPress template – instead, I’m walking through the process of populating a page that also has a page template applied to it.

Anyway, creating WordPress templates is easy business:

• Create the template file in the theme directory
• Give the template file the proper header comments
• Fill out the template with the proper markup

Back in March, I shared a proof-of-concept plugin for including a template file in a plugin. If you browse through the comments, note that there’s a lot of discussion on how to do it, why one way is better than the others, and so on.

But as I’ve continued to work on a project in which I include templates in plugins, I’ve also been working on populating template-based pages with content from HTML files.

Here’s how I’ve been working to programmatically populate a WordPress template.

Continue Reading…

Up until this point, I’ve never worked on a project or done any type of work that required a custom post type to be added to an existing menu in the WordPress dashboard.

For the most part, I’m generally of the mindset that custom post types should:

• Exist as top level menus
• Should be added at the bottom of the WordPress dashboard menu

This mentality is primarily motivated by the fact that I see the core WordPress menu options as first-class citizens in the dashboard, custom post types as being second-class citizens.

That’s just a rule of thumb, though. There are always exceptions.

But there are also times where custom post types could be treated as, say, third-class citizens where they should be integrated with an existing menu be it a core menu or another custom post type menu.

Luckily, it’s trivially easy to add a custom post type as a menu item to an existing menu.

Continue Reading…