What I needed was a way to modify the basic toggle button output. The output wasn’t initially filterable, so I submitted a pull request that was merged into the plugin as of version 1.1.0. It adds filters for all the output stings, see these examples.

This update is great for a lot of purposes, but we’ll focus on my mission to start: using Font Awesome Icons!

How It’s Done

To replace the existing Dashicons with FontAwesome icons, we’ll use the gridlist_toggle_button_output filter. This filter passes three arguments: $ouptut, $grid_view, and $list_view. The $output argument is the output string we’ll be modifying, of course.

The $grid_view and $list_view arguments provide us the translated outputs for the “Grid View” and “List View” strings. These are important: if you’re using icons as the title attribute of the link, which might be used for your theme’s styling, or if you want to output an internationalized string for your buttons. If you want to drop these strings, or completely replace any outputted text (and provide translations), you can drop the two “view” arguments. Otherwise, we can use them in a similar fashion without worrying about translating them.

This snippet modifies the original output string, replacing the Dashicons with Font Awesome icons and flipping the icon order:

Hope you find this useful, feel free to share your customization ideas via gist or questions in the comments. Big thanks to James Koster for the Grid / List plugin.

*Also, if you’re loving the Font Awesome icons, check out their new version and consider buying a license.

The post Using Font Awesome Icons for WooCommerce Grid / List Toggle appeared first on Joshua David Nelson.

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 feeds, disable comments, disable 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 WordPress.org

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.

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.

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:

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:

• get_terms
• wp_dropdown_categories
• Understanding MySQL in WordPress
• Stack Exchange: Restrict taxonomy dropdown to post type

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

A recent project called for a “current weather” tile on the homepage. A quick look through the available weather APIs out there lead me to Forecast.io DarkSky.net, 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-DarkSky 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 DarkSky.net, 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.

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 Dark Sky 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:

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 Dark Sky, 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:

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

Bonus: Weather Icons

You 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 DarkSky\Forecast class and add some awesome Weather Icons (by Eric Flowers).

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

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 500px.com, under Creative Commons License.

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

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

Harder, better, faster, stronger: *

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.

I mentioned this code in a previous post, where I outlined how to link Gravity Forms with ACF Gallery fields.

Updated 3-29-17: Updated the function to a class and utilized a better method for creating the file.

Featured image via Flickr CC, by Michael D Beckwith

The post Programmatically Add Images to Media Library appeared first on Joshua David Nelson.