Notes on programming-related problems that I’ve encountered while working on various projects.

Organizing WordPress Meta Box Code

When working with themes or public-facing views for a website, WordPress components can generally be thought of in three distinct areas:

  1. Templates are used for rendering the view (that is, the markup and the styles) of data.
  2. Partials are reusable fragments of templates.
  3. Helper Functions are used to help process, format, and generally work with data.

As far as templates and partials are concerned, these are relatively common with themes or working with anything on the front-end, but we don’t see it as much as we do when talking about the context of the Dashboard.

But when it comes to working with the back-end, all of these things are still applicable. Sometimes you’ll see them in isolation – like with helper functions – other times, all three things can work together such as in the case of meta boxes.

That is, you have a function for defining the meta box, a function for rendering the meta box (which can include a template), and then the template may have multiple parts – or partials – such as the contents for various tabs.

Display Post Meta Data Error Messages in WordPress

One of the things that’s nice bout working with post types – custom or standard – in WordPress is that it’s really easy to hook into the serialization process in order to handle the data. This means that we have the ability to sanitize, format, read, access, modify, verify, etc. all of the data with the post type and with the post type’s meta data before it’s written to the database.

WordPress has a pretty consistent way of displaying error messages throughout the application. Really, it’s pretty consistent in how it displays all types of messages – success, updates, and errors – throughout the  system.

Let’s say that you’re working with a WordPress meta box, several of its fields are required, and you want to:

  • verify the input has been specified
  • either display an error message if it’s not specified
  • or write the data to the database if it checks out

The serialization process is pretty standard stuff, but if you’re looking to make sure required fields aren’t empty and that a error message is displayed whenever they’re not entered, then you’ll need to do some additional work.

Programmatically Deactivate WordPress Widgets

If you’re in the business of building themes for fun, for clients, or for purchase within a marketplace or your own store, then there’s a chance that there’s some type of functionality that’s unique to your theme that should be activated whenever the theme is activated.

In my experience, this is something that’s typically unique to niché WordPress themes because they tend to have specific features, customizations, and so on that are relevant to their theme.

Case in point: Let’s say that you’re working on a niché theme that has a number of widgetized areas, but also has very specific widgets for said areas. That is, upon theme activation, you want to make sure that each widgetized area is clear so not to bust up the layout.

In other words, you need to programmatically deactivate WordPress widgets whenever the theme is activated so that the layout of the theme looks as it should when the user activates it.

One Way To Add Multiple Meta Boxes

One of the things that I like about open source the most is having discussions not only about how a person goes about doing something, but why they’ve chosen a particular route over an alternative.

Yes, reading books, articles, and other material from prolific, well-known, and respected programmers matters – I’m definitely not saying that we should throw that out – but there’s a lot that can be learned from peers who are sitting a couple of tweets, emails, or gists away from you.

Though I generally enjoy seeing how other people have approached their work and understanding the rationale behind it, I’m also pretty open about how I approach certain problems if for no other reason that the garner feedback from those of you who take the time to update gists, add comments, and so on.

Using jQuery To Set Select2 Selected Value

As much as I firmly believe in making sure that anything we build for WordPress especially as it relates to the dashboard should remain as consistent as possible.

As with anything, there are a few exceptions that I’ve made in the work specifically when it revolves around large select elements (multiselect or no).  That is, I’m a big fan of Select2 – I’ve written about it a couple of times and how I’ve used it in a couple of projects.

Because this is something that I regularly use, and because I know a number of WordPress developers (and general web developers, as well) also use this in their work – both in the dashboard functionality and in the public-facing functionality, as well – I wanted to share one way in which I’ve needed to programmatically set an option.

Display an Error if a File Is Too Large for WordPress

If you’re working on a project for WordPress that’s going to allow users to upload files – be it a video, an image, a CSV, or any other type of data – then you’re likely going to be faced with a situation where you’re going to need to determine if a file is too large for WordPress.

Yeah, it's a little too large.

Yeah, it’s a little too large.

What’s considered “too large” can be related to any number of factors:

  • The size of the file is larger than you want to accept (or the file system accepts)
  • A PHP timeout occurs when uploading a file because of its size
  • The file system doesn’t have enough space
  • …and so on.

Whatever the case may be, there are two things that you’re going to need to be able to do:

  1. Determine if the file fits within constraint of the system (whatever the constraint is)
  2. Display an error message to the user before the upload occurs

It doesn’t exactly provide for a stellar experience when trying to upload something only to have it rejected by the server without a proper error message, does it?

Resolving PHP Timeouts in WordPress

When it comes to working with long running scripts and WordPress, you’re usually at the mercy of one of two things:

  1. PHP configuration file
  2. The server’s PHP configuration

Granted, the case could be made that these are one and the same, and in a sense they are, but if you’re working with PHP on your local machine, you clearly have more control over the environment than when you’re working on a web server.

Technically, if you’re working on a dedicated server, you should have full control over the configuration of the environment.

If that’s not the case, this is article won’t be of much use; however, if you’re in the business of working with PHP scripts on your local machine and a shared server, and you’ve hit the maximum execution timeout message, then there are a few of ways to go about handling the problem.

Upload Files to the WordPress Media Library

Programmatically uploading files to WordPress is really just the same as uploading files from any source location to a destination.

That is to say, there are a number of PHP functions all of which make it pretty easy to deal with file-level operations, grabbing files from one location, and moving them to the next.

And yes, there are some nuances that can come with PHP’s configuration such that you may not be able to write to certain directories, perform certain options via HTTP, and so on. All of these can be managed by either changing up the configuration or by changing the way in which files are handled by the code.

The WordPress Media Library

One thing that WordPress offers that manual uploads don’t manage is adding files – specifically media types – to the Media Library after uploading a file. This is relatively easy to do given media_sideload_image.

But let’s say the situation is a little more complex.

Programmatically Add Multiple Post Terms in WordPress

A couple of weeks ago, I shared a simple gist for how to programmatically add post terms in WordPress. If you’ve read the series on importing CSV files into WordPress, then you’re likely to encounter something like the following scenario:

Given a CSV, apply multiple terms to a single post when the terms are delimited by another character.

So, for example, let’s say that you have a CSV and each value is, naturally, separated by a comma. Within one of the columns, words – or terms, in our case – are delimited by semicolons. Each value that precedes a semicolon represents a term (related to any given taxonomy in the system – this is irrelevant for this particular post).

Adding multiple terms to a post, or post type, is relatively simple and can be based off the functionality already shared.

Programmatically Add Post Terms in WordPress

Importing CSV files (or something similar) is something that’s nothing new to web development.

If you’re writing a server side code that’s responsible for importing a file in the context of WordPress, then you can be doing anything from programmatically creating posts to creating more complex relationships among post types, taxonomies, and so on.

In this case, it’s nice to have an abstract function that can help to do a lot of the repetitive work for you. After all, aren’t functions specifically for that?