Blog – Joshua David Nelson Bullshit Free WordPress Development Sun, 07 Aug 2016 19:00:06 +0000 en-US hourly 1 Adding Genesis CPT Archive Settings Metaboxes Sun, 07 Aug 2016 19:00:06 +0000 Expand the Genesis Custom Post Types Archive Settings with custom fields that can be used on your archive templates.

The post Adding Genesis CPT Archive Settings Metaboxes appeared first on Joshua David Nelson.

A handy thing shipping with the Genesis Framework, as of version 2.0, is the Custom Post Type (CPT) Archive Settings. This settings page allows you set a custom archive title and description, page layout, and set SEO options for the archive template.

To add the archive settings options page you must add the post type support, as shown here.

Custom Settings

I recently needed to add a custom field for all my post type archive templates (and I had a few), so the logical place for it is the CPT archive settings. It’s fairly easy to remove metaboxes from the CPT Settings.

Place the code below in your child theme‘s function.php file to add a “subtitle” field to your CPT archive settings:

View this code snippet on GitHub.

The code above is easily expandable with more fields within the metabox function. Here is a quick code breakdown:

  1. (Lines 9-33) This is set up in a class and gets all the functions hooked in correctly.
  2. (Lines 51-47) Set the default value.
  3. (Lines 54-59) Register the archive settings metabox, use the page hook variable.
  4. (Lines 66-78) We need to be sure we have a valid post type slug (this is a parameter passed in the url).
  5. (Line 81) Modify your post type slug(s) on this line – this checks the current post type to an array of those that you want this metabox to appear on.
  6. (Lines 82-83) The key difference from adding a metabox to the theme settings is the settings field constant, which is different and has the post type slug added to the end. It’s important to this that you utilize Genesis’ built-in settings field so the data is properly stored and easily retrieved. For custom post type archive settings, this field is built with a prefix (taken from the global variable) with the post type slug after it. Don’t forget to escape the post type slug, just in case. Thus: GENESIS_CPT_ARCHIVE_SETTINGS_FIELD_PREFIX . esc_attr( $post_type )
  7. (Line 83) Use genesis_get_option to grab the current value.
  8. (Lines 90-98) Add the sanitization filters to sanitize all the saved values.

Using it in your theme

Once this is up and working, you can grab the custom meta via genesis_get_cpt_option, and place it in your post type archive template, like this:

View this code snippet on GitHub.

See a full archive template example for the subtitle here.

You can also use the genesis_get_option with the post type specific settings field like this: $value = genesis_get_option( $key, "genesis-cpt-archives-settings-{$post_type}") but I think the above is a bit cleaner.

Featured image credit: Photo by Mr Cup on Unsplash

The post Adding Genesis CPT Archive Settings Metaboxes appeared first on Joshua David Nelson.

]]> 2
Disable Blog: WordPress Gone Blog-less Sun, 31 Jul 2016 18:30:46 +0000 Disable blog is a simple plugin used to create a website free of blog features. It seamlessly creates a static, page-based WordPress site.

The post Disable Blog: WordPress Gone Blog-less appeared first on Joshua David Nelson.

A year-and-a-half ago I released a plugin called Disable Blog.

Guess what it does: disables the blog on WordPress sites. (clever title, right?)

“Isn’t WordPress supposed to be a blog?”

WordPress has grown from a blog platform to a content management system. More recently it has progressed into an application framework/foundation.

No doubt, WordPress blog functionality is inherent to its core. And so it should be! Blogging is a useful device for much of the web. But the flip side, where it’s not utilized at all, exists on plenty of sites, too.

I have clients that only want WordPress for a static website, they don’t want or need a blog. I’ve experienced confusion around unwanted blog features at least eleventy-one times. I wanted to provide a better experience for my clients.

Okay, okay, okay – I’ll admit it: there’s an element of OCD involved for me here.

There are plugins to disable feedsdisable commentsdisable XML_RPC, and even one that will hide your admin ‘post’ pages. But none were quite the solution I wanted.

Just hide everything!

I wanted a plugin to disable blog functionality across the board. From the obvious items like the “Post” admin menu to the “invisible” things like feed links.

It couldn’t sacrifice anything shared by blog and non-blog things alike. It needed to be flexible enough for custom post types and taxonomies. (A lot of my work revolves around custom content management).

For instance, posts and pages can have comments. It had to obscure any comments attached to posts, but still keep comments available for pages. Not to mention the near-infinite possibilities with custom post types that use the built-in categories/tags, comments, feeds, et cetera.

Other considerations, too: What if the site’s reading settings were set to blog and not to a static page? How do you deal with redirects and queries? What about author pages?

As you can see, it turned into a (fun) challenge.

The plugin.

My goal with this plugin is to make it seamless and I think it covers all the major bases:

  • Disables the blog by hiding, redirecting, and/or completely turning off blog-related functionality. See the full list here.
  • Simple path to a blog-free website, without any changes to your database/content. Deactivate it to go back to blogging.
  • Custom post types and taxonomies support.
  • Works on Multisite!
  • There are a ton of filters to allow developers to tweak it further. (Documentation coming soon)

I am always finding little ways to improve a (see the To-Do list).

I just pushed out the newest release this last week. See the full changelog, if you’re interested.

View the plugin on Github and on

Please direct any issues to the Support Forums, not the comments below.

To comment/contribute, reach out on Github or contact me on this site.

Like the plugin? Please consider leaving a positive review.

Featured Image credit: Photo by Alejandro Escamilla on Unsplash.

The post Disable Blog: WordPress Gone Blog-less appeared first on Joshua David Nelson.

]]> 0
Category (Taxonomy) Dropdown Filtered By Post Type Sat, 20 Feb 2016 05:56:16 +0000 Filter the wp_categories_dropdown function by a specific post type.

The post Category (Taxonomy) Dropdown Filtered By Post Type appeared first on Joshua David Nelson.

Screen Shot 2016-02-19 at 9.20.28 PMWhile working on a large custom content management solution for a client I was building templates for multiple post types all sharing a common taxonomy. Most of these templates needed a dropdown to filter the results by the common taxonomy, in this case a taxonomy named “department.”

Should be fairly straight-forward, right? WordPress does offer a great function for creating taxonomy dropdowns called wp_dropdown_categories, which works with custom taxonomies as well as categories.

However, it will return all taxonomies with any posts. If you have multiple post types, you could very easily get a list of taxonomies with posts, but not the post type you want for the template – as was my issue.

Luckily, we can filter the SQL query used in the get_terms function, which is called by wp_dropdown_cateogies.

View this code snippet on GitHub.

The above utilizes the term_clauses filter, and hunts for the post_type argument. The beauty of this is that we’re extending the functionality of the get_terms function directly.

This means we can use wp_dropdown_categories and simply pass our new post_type argument. Furthermore, the fallback here is the built-in function, which is a double bonus. I love the extend-ability of WordPress!

Here’s the basic usage, now that we have the filter above:

View this code snippet on GitHub.

That said, I built a custom function to wrap the wp_dropdown_categories, so I could grab the current query var and add a wrapper element.

Here are some useful resources if you’re going down this rabbit hole:

The post Category (Taxonomy) Dropdown Filtered By Post Type appeared first on Joshua David Nelson.

]]> 1
Weather in WordPress with Mon, 01 Feb 2016 07:47:21 +0000 Extend your WordPress website with access to weather data from with this helper class.

The post Weather in WordPress with appeared first on Joshua David Nelson.

weather-tileA recent project called for a “current weather” tile on the homepage. A quick look through the available weather APIs out there lead me to, which is pretty slick. There are more than a few PHP approaches already put together. I took Guilherm Uhelski’s PHP helper class and expanded it for WordPress.

The purpose of this helper class is to: perform the API call, process and return the JSON response, and store that response for quick reuse. Check out here. Feel free to drop it into a custom plugin for use on your site or your projects.

WP-Forecast-io (what I’ve named this project, very original, right?) uses the WordPress HTTP API helper functions (as well as transients). If you’re not familiar with external HTTP calls or WordPress’ helper functions, check out this great series of walkthroughs by Tom McFarlin. Here’s a good walk-through on transients. With a good understanding of the HTTP API and transients, this class will be pretty straight-forward.

Next up, sign up for a free account and API key from, you’ll need that in order to use this helper class.

Okay, now that we’ve got the basics out of the way, let’s use it!

Using It

Here’s a quick example on using this class. At the bare minimum you need an API key, a Latitude, and a Longitude.

View this code snippet on GitHub.

Then, it’s a simple matter of calling the elements you need out of the response. Using the magic __get() method, all of the response data is available to call.

Familiarize yourself with the typical response, and the Forecast API. From there you can take the response data and build some cool things.

In my case, I wanted today’s minimum and maximum temperatures. Here’s a basic version of the function I use in my template:

View this code snippet on GitHub.

How it Works

Using the great HTTP API functions in WordPress, the helper class grabs the API response. It’s then stored in a transient (by default, but this can be overridden – see below), allowing us to store the response for quick recall later. This is important from a page load standpoint, of course, but also critical with services like, which provides 1,000 free calls per day.

It makes sense to grab the forecast once for a set period of time, rather than at every page load. If the latter is true, you could end up with quite a lot of calls to the API and quickly reach your free limit.

For my purposes I only needed the daily forecast, so a 6-hour cache is sufficient (it could be set to 24, but 6 hours allows for 4 API calls a day and accounts for potential changes in the forecast). If you needed, for instance, the current weather, then you could easily reduce the transient time to 5 minutes and still keep your calls below the 1,000/day limit.

Need a fresh of the API call? Just use the get_response function with the first parameter set to true clear the cache and get a fresh API response:

View this code snippet on GitHub.

You can modify the other cache settings in the initial arguments or by setting the specific parameter, as shown below:

View this code snippet on GitHub.

Bonus: Weather Icons

weather-tileYou might notice that the image shown above (and here) include an icon, yet my example code above doesn’t? Oh myyy, you’re observant!

On my project I built another helper class to extend the original class and add some awesome Weather Icons (by Eric Flowers).

Drop this extra class into the same plugin as the WP class above to build some awesome weather outputs. To take the temperature example above and expand it, here it is with a weather icon:

View this code snippet on GitHub.

Note that this doesn’t enqueue the Weather Icons stylesheet. You’ll have to do that in your functions.php file. Refer to the Weather Icons Documentation and the wp_enqueue_style function.

Featured Image: Fingers of Heaven by Robert Postma on, under Creative Commons License.

The post Weather in WordPress with appeared first on Joshua David Nelson.

]]> 0
Fixing Your Deprecated Widget Constructors in WordPress 4.3 Wed, 19 Aug 2015 16:42:58 +0000 A quick update to your code can fix these depreciated widget constructors for WordPress 4.3.

The post Fixing Your Deprecated Widget Constructors in WordPress 4.3 appeared first on Joshua David Nelson.

As of WordPress 4.3 older versions of constructor functions are deprecated. Typically these are common in widgets, where you’re extending the parent WP_Widget class. I’ve recently updated a few of my older versions in my plugins and on client site’s, here’s the basics.

Older, now depreciated code (truncated to the first 20 lines):

View this code snippet on GitHub.

Harder, better, faster, stronger: *

View this code snippet on GitHub.

It breaks down to being an older PHP method – naming the constructor function the same as the class and/or calling the parent constructor via the class name. Newer versions of PHP allow us to call parent classes via parent:: and utilize the __construct() function, which is now the preferred method for WordPress.

For more information, check out the WP Core Blog post on the subject and the Widgets API Documentation.

The post Fixing Your Deprecated Widget Constructors in WordPress 4.3 appeared first on Joshua David Nelson.

]]> 2
Creating a Project Scope Document Fri, 17 Jul 2015 16:35:11 +0000 A good scope document is vital for understanding the work that's being done on a project. For both you and your client.

The post Creating a Project Scope Document appeared first on Joshua David Nelson.

When I’m in the prospecting phase of a project there are two documents I put together for a client: a contract and a scope document. Both are crucial. A contract is important for having the project terms written down and agreed upon, while a scope document is vital for understanding the work that’s being done.

I also put together an instructional Functionality Document when I hand a site off to a client, which outlines all the custom functionality (where to edit custom content, how to use any custom post type functionality, et cetera). Often a scope document can be used as a jumping off point for the functionality document.

It’s important to be clear and communicative in, well, everything we do in life. Also, it’s quite handy with delivering quality work. If you need help with a good contract, check out the Killer Contract (there are a few spin-offs, Curtis McHale’s is pretty good). This post will cover the all-important Scope Document. It’s pretty straight-forward, but let’s walk through it anyway.

The Scope Document

The purpose of a scope document is to outline what the site will do when you’re done building it. This is vital for you, the developer, to breakdown the various tasks and see the bigger picture. It’s vital for your client, because it sets their agreed upon expectations.

Did they want that slider to include videos? Well, if they approved a scope that said “image slider” then you can refer back to this document and say, “sorry, that’s extra.” Or, if that was included and you missed it, you’ll be issuing a slightly different apology.

I break down a scope into four categories:

  1. General Overview: outline the service. I do this with a simple statement like: “PSD to WordPress: custom Genesis child theme based on PSD with mobile responsive design.”
  2. Custom Page Templates: This is beyond the post type templates. Perhaps you have a custom contact page template. What’s editable and how? Should the slider pull from the staff post type? Are you using Gravity Forms or Contact Form 7?
  3. Custom Content Types: Also know as custom post types. I sometimes refer to these as “custom content types” for more clarity with my clients. If you’re customizing content management, this is how you do it.Make a list of each type, what custom meta fields are going to be necessary, and what templates are being provided (generally, an archive template and/or a single page template – both optional). Go through each template in detail – what’s in the sidebar, if there’s a custom archive title and description, meta values being used. Is there a taxonomy to filter the post type? What’s that template look like?
  4. Customizable Content: Outline all the areas where content is editable outside the usual post editor or meta fields listed in the above areas. One that I use often is the landing page: generally there are sections, each with editable content. I’ll put these together into a options page on the back end so the client can control how the landing page looks from the dashboard. Walk through each section, how it should work, and what will be editable. Is it pulling projects from a custom post type? Does the client enter testimonials directly into the settings page, or are they pulled from published projects?

That’s it. Really. If you have something that doesn’t fit into those four categories, by all means add it, but that usually covers everything. The more complex a site, the more thorough you’ll need to be about each of those areas.


Below is an example of my starter scope document, based on my child theme and core functionality plugin, which each come with a few custom post types and page templates that I use frequently.

View this code snippet on GitHub.

This is, of course, just one way to outline project scope with your clients. If you have another way, please share!

Featured image via Flickr CC, by Steven Snodgrass

The post Creating a Project Scope Document appeared first on Joshua David Nelson.

]]> 0