Notes

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

WordPress Meta Data: Other Data (Not IDs)

Yesterday, I talked about some of the advantages of using IDs when working with various pieces of WordPress data and populating different input elements, saving it to the database, and more.

For certain types of data, this works well; however, this may not always be true especially as it relates to data types such as taxonomies. This is going to be most notable in WordPress 4.2.

Taxonomy Term Splitting

Taxonomy term splitting coming in WordPress 4.2

If you’re an experienced developer, then I recommend reading the blog post linked above; otherwise, suffice it to say that using IDs may not always be the best option depending on if you’re doing a database migration (and how that migration might be done).

So what else are we left to do?

WordPress Meta Data: Use IDs (Not Titles)

One of the features that I’ve often found myself having to implement when building custom solutions for others is implementing some type of select box – be it multi-select or single select – or another similar input element that’s [naturally] populated with a list of option elements.

These options may consist of posts, pages, custom post types, categories, taxonomies, etc. It doesn’t really matter what type of information it includes, but it does matter how the information is populated.

Avoid Loops With save_post in WordPress

When working on WordPress projects, there may be times during which you have to do some sort of processing on the content or attributes of the post before saving it to the database.

There are a number of ways to do this, but one of the most straightforward ways to go about it is to setup a custom function hooked to the save_post action and then handle the attributes of the post in that function.

If you opt to go this route, there are a few considerations that you need to make (mainly that help you avoid some type of infinite loop) in order to properly adjust the content to your liking.

Debugging with Query String Parameters

There are a number of ways that we debug our WordPress-based projects.

  • Some people end up going through the code and setting up print_r statements or var_dump statements
  • Some end up working through the code and changing variables or function names until they find where something breaks (or changes)
  • Some use debugging software (or the debugging features in their IDE)
  • Some use a combination of plugins and other techniques
  • And some likely use some strategy that isn’t listed here

Personally, I’m partial to using some of the developer tools that are provided by WordPress through the use of setting constants and using plugins that are available to us, but I’m also a fan of using Codebug App (which is the content for another point).

Codebug App

But, for the purposes of this post, that’s beside the point.

Using Transients For Storing Google Maps Data

A couple of weeks ago, I shared a quick tip on working with multiple InfoWindows with the Google Maps API specifically within the context of WordPress.

Google Maps InfoWindow

When working with this API, there are a number of considerations to take into account each of which is going to depend on how much of the API you’re going to be using; however, one constant that’s going to remain regardless of how much you’re using is the rate limit.

That is, unless you’ve paid Google a decent chunk of change, then you’re going to have to take rate limiting into account whenever you’re working with this API. And if you’re charting quite a few locations for, say, several different pages or several searches, then you can hit that limit quickly.

If you’re not at the point where you can pay Google to up the rate limit, but you’d like to still make sure your project doesn’t totally bomb out if the rate limit is hit, then I recommend using transients to store Google Maps data for an interval of time so that you aren’t making frequent calls to the API.

Quick Tip: Multiple InfoWindows with Google Maps

Recently, I’ve been working with the Google Maps API in order to plot locations that are stored as custom post type meta data in the WordPress database.

Google Maps InfoWindow

 

The general functionality is as follows:

  • For each of the locations stored in the database
  • Generate a pin for the location
  • In addition to creating a pin, create an information window that shows the pin’s location

The information windows that sit above the flags are also called infowindow within the context of the API.

The Google Maps API documentation is pretty good in covering stuff like this, but I did run into a couple of gotchas when working with it, so I thought I’d document them here just in case anyone runs into the same problem.

Searching with Substrings in WordPress

Let’s say you’re in the process of building some type of search mechanism using WP_Query and you want your users to be able to run the search using part of a string.

That is, let’s say that you’re searching Companies (which is a custom post type) and some of the company’s names is “Awesome Code.” The user doesn’t know this because you’ve built a huge database and have been wildly successful with your app.

So let’s say the user opts to try to run a search using the fragment of ‘awe’ or ‘some’ or ‘code’ or some fragment variation thereof – how are we supposed to be able to pull back results like that?

How To Check if a WordPress Term Has a Child

If you’re in the process of working with hierarchical terms, then there’s a chance that you’re eventually going to need to know if a given term is the parent to another term.

For example, let’s say that in one of your templates, you’re responsible for displaying a list of all of the terms that do not have children for one reason or another (or maybe you’re responsible for display only terms with one children or another).

Whatever the case, this is a relatively straightforward operation to do assuming that you have the term’s taxonomy readily available.

My Productivity and Entertainment in 2015

Every year we end up trying out new services, solutions, communities, chat rooms, groups, apps, and other forms of technology that, by the year’s end, may be contributing more noise than signal to our day-to-day.

Perhaps I’m about idealistic, but I think that the majority of us are concerned with making sure that we have the tools that we need to get our work done and nothing more, nothing less (with the occasional game or book for entertainment and/or educational purposes, of course :).

But you get the idea of what I mean: We start off with the best of intentions in getting only what we need in order to get our work done and end up with a plethora of extraneous things that we don’t necessarily need distributed across our various devices.

Then again, maybe I’m the only one who’s suffered from this. But not likely. Here’s a run down of the things that I’m looking to employ day-to-day for both productivity and entertainment.

What Are You Doing Inside of WordPress?

I know – the title of this post is kinda weird, but I figured it made sense given yesterday’s topic (that is, what are you guys and girls focusing on outside of WordPress in the coming year?).

After all, just because we’re looking to focus on things outside of WordPress, that doesn’t mean that we’re going to be moving on or moving away from WordPress.

And since WordPress is comprised of so much – that is, core developers, plugin developers, theme developers, documenters, teachers, educators, event organizers, and so on – I’m interested in seeing what you’re planning to do in the coming year, as well.