Category: Notes (Page 18 of 49)

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.

Continue reading

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.

Continue reading

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).

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

Continue reading

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.

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.
Continue reading