CDN breaking Hueman’s Font Awesome? Here’s how you fix it.

If you have been using MaxCDN (or any other CDN, really) and have used Font Awesome in WordPress (for example, in the Hueman theme), then you might notice your awesome looking fonts and icons puking itself into little square icons instead.

Here’s how you fix it. Open up functions.php on your child theme and add the following snippet to make Font Awesome load via BootstrapCDN instead. Snippet courtesy of Sridhar Katakam:

//* Load Font Awesome
add_action( 'wp_enqueue_scripts', 'enqueue_font_awesome' );
function enqueue_font_awesome() {

wp_enqueue_style( ‘font-awesome’, ‘//’ );


After that, remember to purge the cache off MaxCDN, and obviously clear your browser cache too.

If this fix doesn’t work, you might want to look into modifying your .htaccess file to send the right CORS headers (MaxCDN reference or WP support thread from theme author)

This means:

  1. Download existing .htaccess via FTP from your web root folder
  2. Tack on the code from reference articles into .htaccess
  3. Save
  4. Upload new .htaccess file back onto web host
  5. Clear MaxCDN cache
  6. Test

For what it’s worth, the .htaccess method didn’t seem to work for me, but adding the BootStrapCDN snippet worked.

If you’re using Sucuri CloudProxy as well, here’s a handy guide on what to do.

For WordPress MaxCDN, set it up this way with W3TC plugin.

Adding hAtom structured data to the WordPress Hueman theme

I literally crapped my pants the first time I saw 800+ hAtom errors, when testing my site out with Google Webmaster Tools. It’s a little amazing why something like this isn’t baked into WordPress themes by default. Nevertheless, we all know how rapidly trends like these shift.

Less whinging, let’s get to work! I’ll just share my fixes on this problem.

Note: This fix is largely specific to the WordPress Hueman theme, a really fantastic theme if I might say so.

Errors encountered when testing structured data

When using the Google Webmaster Tools Structured Data testing tool, you get these errors.

Error: At least one field must be set for HatomEntry.

Error: Missing required field “entry-title”.
Error: Missing required field “updated”.
Error: Missing required hCard “author”.

Creating a child theme

  1. Best to apply this fix in a Hueman child theme (download sample), rather than editing the actual theme files. No fear of losing modified source code on theme updates!
  2. Unzip the .zip file into a folder. Place that folder on the same level as your original Hueman theme, under wp-content/themes.
  3. Copy functions.php from /themes/hueman (the original theme), into /themes/hueman-child-master (child theme folder)
  4. Add this code snippet from David Tiong’s website. This will fix all errors, excluding archives pages (category, author)
  5. Remember to switch from the original theme to the child theme, under Appearance – Themes.
  6. To fix the remaining errors in the author and category pages, you have to copy content.php from the original theme, into the child theme folder.
  7. Make sure the content.php looks like this:

<article id="post-<?php the_ID(); ?>" <?php post_class('group'); ?>>
" title=""> /img/thumb-medium.png" alt="" /> '; ?> '; ?> '; ?> ">
<!--/.post-thumbnail--> <!--/.post-meta--> <h2 class="post-title"> <span class="entry-title"><a href="<?php the_permalink(); ?>" rel="bookmark" title="<?php the_title(); ?>"><?php the_title(); ?></a></span> </h2><!--/.post-title--> <?php if (ot_get_option('excerpt-length') != '0'): ?>
<!--/.entry--> <?php endif; ?> </div><!--/.post-inner--> </article><!--/.post-->

It was a long night, and I was a little fuzzy when putting it all together, but this should mostly be it. Pop a comment if it doesn't work!

Related read: Hueman theme and Google Authorship

Disabling Open Graph from Facebook’s official WordPress plugin

I was looking for a way to remove the OG meta because Facebook’s OG Object Debugger tool kept throwing this really annoying error to do with multiple og:url values. Something like this:

Object at URL ‘; of type ‘article’ is invalid because it specifies multiple ‘og:url’ values:

I checked my source code multiple times, it was clean but it just refused to quit unless I disabled the Facebook plugin. The catch here was that I really wanted to have Facebook comments integrated and none of the other third-party plugins made it an easy job, so I had to have the Facebook plugin back regardless.

Then I found this thread, but saying “If you want to remove the Open Graph protocol content output by the Facebook plugin for WordPress you should unhook the Facebook_Open_Graph_Protocol::add_og_protocol function from the wp_head WordPress action.” isn’t very helpful to someone who’s been shamefully remiss with his WP-fu skills.

It took a lot of searching to get this snippet, so if you’re looking for a way to disable the built-in OG (or Open Graph) data that Facebook’s official WordPress plugin spews, here you go.  Courtesy of aendrew from the WordPress forums.

* OpenGraph stuff is now handled by Yoast or whatever.
* This removes Facebook's broken use of its own technology.
add_action('wp_head', 'remove_fb_og_stuff', 0);
function remove_fb_og_stuff() {
remove_action( 'wp_head', 'Facebook_Open_Graph_Protocol::add_og_protocol' );

Good luck and if you found this useful, feel free to share this with someone else who needs it.

Update: Disabling the action inside Facebook’s plugin seems to work better. The above code killed every possible OG being output by all plugins for some reason.

Comment the below line from facebook.php inside the Facebook plugin’s directory. It’s on line 465 if you’re using the same version. I then used Facebook Open Graph Meta Tags for WordPress to output the OG meta tags I needed.

// add_action( 'wp_head', array( 'Facebook_Open_Graph_Protocol', 'add_og_protocol' ) );

Ideas about Edit Flow

Edit Flow is a seriously well-designed plugin for WordPress, and I’ve been very thankful for its presence throughout the lifetime of PnR so far. That being said, there are still some features I would like to see addressed, and at this point I wouldn’t even mind paying to get it done, so long as it doesn’t cost me an arm and a leg.

For starters, fixing my current bug with contributors not being able to assign notifications to the required editors. Authors and above can see the box just fine, but contributors are outcasts as far as this is concerned. I’ve made it work by creating user groups with the editor and writer pairs, but it’s a little clunky to do.

I’ll probably have to take time out to set up a dev site and test this further, just in case it’s a site-specific issue. In which case, I’d need help on debugging anyway. HALP!

Next up, my “ideal editorial notification system“:

I have this idea about how the editorial notification system should be like for a multi-author, multi-editor environment.

1. Contributor Dan writes a draft, and sets it to pending review.
2. Editor Sean automatically gets an email notification.
3. Secondary editor Dave automatically gets an email too.

I understand this can be achieved by creating a user group with Dan/Sean/Dave and using this snippet:

It’s a little unwieldy in that if Sean or Dave happen to write up a draft, Dan will get the notification as well. It’d be great if there was an easy way to automatically assign an editor (or two) to every user, and have them receive notifications only when the article is ready for review.

Now, if only I get some assistance on making the above stuff work, it’ll seriously make my life a lot easier in terms of assigning editors to writers and making sure the notifications are done properly.

WP Super Cache does not play well with WP HTTP Compression

So I was getting this cache issue with WP Super Cache, where it was refusing to serve the generated cache file. Enabling debug threw this error:

03:39:38 /category/articles/test/ No wp-cache file exists. Must generate a new one.
03:39:39 /category/articles/opinion-columns/ In WP Cache Phase 2
03:39:39 /category/articles/opinion-columns/ Setting up WordPress actions
03:39:39 /category/articles/opinion-columns/ Created output buffer
03:39:40 /category/articles/opinion-columns/ Output buffer callback
03:39:40 /category/articles/opinion-columns/ No closing html tag. Not caching.

Checking the source code on index.php made it clear there was no timestamp on the page, so what the hell?

Referring to this WordPress support thread made it pretty clear something else was interfering with the way the HTML was being generated, so I began disabling my recent plugins one by one.

Lo and behold, the caching test performed fine soon as WP HTTP Compression was disabled. (Not a knock on the plugin by the way, I’m just pointing out what happened.)

Cache Tester

Test your cached website by clicking the test button below.

Fetching to prime cache: OK

Fetching first copy of OK (1.html)

Fetching second copy of OK (2.html)

Page 1: 2013-10-05 13:57:49

Page 2: 2013-10-05 13:57:49

The timestamps on both pages match!

And the world was right once more. Kudos to Darrel aka Big Mellz for his sharp eyes on noticing the bug, because it was only happening on the archive pages, rather than the index page, which always seemed to be fine.

WordPress: Of Cart66 and categories

WordPress at its core is a blogging platform, but has one of the most intuitive management interfaces for CRMs, with Joomla being the other extreme: powerful but tough to learn. That being said, is WordPress a true CRM? With Custom Post Types, it is possible to use it that way. Let us not forget the maturity of third-party plugins, which extend the capabilities of WordPress by an infinite degree.

I recently began exploration into the use of WordPress as an ecommerce platform, and out of all the plugins used, Cart66 appeared to be the easiest to implement. It’s free with limited functions, so trying it out should not cost you anything.

I made the decision to buy Cart66 because I wanted to do a fuller evaluation (testing MailChimp integration), and also because it has a 60 day money back guarantee. If you are looking for a Cart66 refund, use this request refund form.

Adding a product

  • You first add the product into Cart66 (pricing mostly), then
  • Write a post and do the usual descriptions, images et cetera. All Cart66 requires is that you include a shortcode for the product, which gives the customer a button to add the product into his shopping cart.
  • Bingo, one product done.

Adding a few products is relatively easy, the real challenge comes when the number of products increase. Cart66’s drawback is the lack of built-in functionality for categorising products. It has a guide on using Custom Post Types to supplement this need, but this guide does not entirely solve the question. The guide shows how you could add items one by one into the top menu, but how does that work if you have a hundred products or more?

For example, how is one supposed to display all products easily on a single page without laboriously typing them all out? Shortcode functionality for displaying products based on category (or all categories) needs to be present. Ideally, I would like the products to have categories, and the navigation should be intuitively tied. This means if I’m adding Apple as a product under Fruits, I should not need to add Apple to the Fruits category in the navbar, it should be already present in the Fruits listing.

A query to support (comes with the plugin purchase) got me the following response:

We provide support for the Cart66 plugin, but not for any other plugin. Cart66 does not feature Custom Post Types or “Category” listings. The only thing we have available regarding Post Types is this document:

Not very helpful.

Not a knock on the guy doing support, I’m sure he is only doing his job. The question is, what good is support for if Cart66 recommends the use of CPT but does not provide any assistance whatsoever on helping its customers with this?

It feels like they are kind of shooting themselves in the foot when they draw the line like this. It feels like the customers want Cart66 to work, but Cart66 is just throwing a few road blocks in the way even though the software is purchased, and at the same time saying “Go on, figure it out yourself.”

Another alternative is to buy their themes with built-in categories. It could be a good alternative if you like their templates, but I would prefer to retain the flexibility of using my own chosen theme without being locked in.

As you can see, this ticked me off a fair bit, simply because I’m of the opinion that such functionality is basic and should be built-in without the user getting their hands dirty and going on another learning curve.

Of course, everyone has a different take on the same thing. As Luke P puts it:

You can already easily do this kind of thing with WordPress it’s self with a custom post type, feature images, and categories. Building this functionality into Cart66 would be a waste of time and just replicate WordPress’s core functions. Cart66 strength is its flexibility to work with WordPress without adding allot of extra infrastructure.

We’ll just have to agree to disagree. I still think Cart66 is a good plugin nonetheless, and will continue to use it. Hopefully future versions will improve on this flaw (my opinion) and allow better user friendliness.