Using Meta Slider plugin

We integrated Meta Slider plugin today on the homepage. Took under an hour to have it working. Ran into one issue because our custom theme was not parsing shortcodes. Slider works nicely, admin interface is simple. Unlike some other slider plugins where slides are made on different pages, Meta Slider enables us to make the slide, configure settings, and add slides on the same page.

Meta Slider has an affiliate program for theme developers pays a generous 30%.

meta slider affiliate

Building a WordPress site plugin

Nearly every WordPress site can benefit from some custom programming. Code that tweaks things a little, usually using hooks (actions and filters) to adapt the output or how certain things function. These type of small changes are usually best organized in a “site plugin”, that is a custom plugin built for your specific website. This is done instead of the other more common “solution”, stuffing any custom code changes into the theme functions.php. Now there is a time and a place arguably, to use functions.php as a place to organize code. However theme stuffing as I tend to call it, is definitely over-used, and comes with many drawbacks.

At the very least you should ask yourself (as a developer) is the change I’m making really a presentation (theme layer) change? If not, use a site plugin. Even in cases where the change does affect the presentation, bear in mind if it involves any substantial logic it may not really be suited for the theme layer. You could make the argument for instance that a custom menu walker used to render the output of WordPress menu’s differently, is a presentation change. That’s true to some extent, however, that logic can be applied to almost anything that changes what you see in a web page, or template. The reason a custom menu walker would be better placed in a site plugin is because it may require future changes, and it’s a fairly substantial amount of code. A walker class can be several hundred lines. It is a PHP class, which should be your first clue that it belongs in a plugin.

As a site owner if you’re reading this and not sure when/where site plugins would help, that’s okay. My advice is aim to work with developers who have plugin build capabilities, rather than those who only work at the theme layer. You’ll get a lot more mileage from your developers in terms of extending and integrating plugins and API’s, and the benefit of keeping your custom code better organized.

Better organization of code isn’t just for a developers benefit. It has a direct impact on the cost and effectiveness of development. Site’s with a lot of theme stuffing can be very difficult to work on, time is lost sifting through poorly organized code. A well organized and commented site plugin can be structured to make finding custom code a lot faster, and that should translate into lower development costs.

A custom site plugin should not be the end all be all solution however, otherwise you may run into the same problems as in using functions.php. Although it’s fine to organize many smaller changes into a single plugin, it’s important to know when to create a second custom plugin (or 3rd or 4th) for specific site features. Don’t continue to expand the scope of your “catch all” site plugin which is there mainly as a utility plugin. If for instance you had an ecommerce site with a number of WooCommerce customizations, those should fit well into your site plugin. However if you have extensive subscriber management customization involving WooCommerce Subscribers, this is an area that probably deserves a second custom plugin to isolate that codebase.

Site naming conventions for site plugins should be kept simple and easy to understand. If the site name domain is “” use the domain name and make the site custom plugin name “cancun-dental”. Easy peasy. Now if you have need for more custom site plugins consider adding to that name such as for the example WooCommerce Subscriptions customizations, the plugin name would be “cancun-dental-subscriptions”.

Creating a custom post type with Meta Box

MB Custom Post Types extension installed

MB Custom Post Types extension installed.

In this tutorial we’ll build a custom post type named “Services” with the Meta Box plugin’s free extension Meta Box Custom Post Types. If your site doesn’t already have the plugin installed, search the WP Plugins directory through the WP Admin > Add New or download from the WP Plugins directory listing at

Meta Box Custom Post Type plugin menu

Meta Box Custom Post Type plugin menu

For docs and to read more about the Meta Box Custom Post Types extension visit it’s page on at

Now let’s get started using Meta Box Custom Post Types extension!


Our goal in this project is to build a “Services Directory” that provides general information about GoldHat Group’s services in a way that generates leads from propective clients. We don’t sell these services directly so this needs to be outside of our shop where we sell WordPress plugins and some packaged services. This is more of a traditional agency approach to displaying services so that prospective buyers know what our capabilities are. We also want to tie our services pages to the any product packages that contain the given service, and reference projects in our project showcase that demonstrate the services we offer. Using a custom post type helps us organize this in a way making regular WP pages would not. And this principle of using CPT’s for distinct types of content is one we can apply in many situations when building websites, key benefits include:

  • Having an archive page (directory listing page) that lists all the posts made using the custom post type
  • Breaking the content management of the custom post types into fields by using meta boxes and fields
  • Setup custom taxonomies (categories and tags) to apply to the content
  • Manage content more easily in the WP Admin


Meta Box add new post type

Step 1 Basic Settings

Click “Add New Post Type” from the MB Custom Post Types menu. Enter the plural and singular names for your CPT into the Basic Settings form.

We’re using “Services” as the plural name and “Service” as the singular name. The slug will be generated automatically, and unless you prefer to change it you can leave that automatically set. In our case the slug is “services” which means posts will be published at[SERVICE-PERMALINK].



Meta Box CPT advanced settings

Meta Box CPT advanced settings

Step 2 Set Advanced Post Type Settings

Under advanced settings you can edit the labels, set an icon for your Custom Post Type and configure how the CPT will be handled by WordPress. There are a lot of options, the Meta Box Custom Post Type plugin provides defaults that will work well in most use cases. If you are want to learn more about the options available one of the best resources is the register_post_type() documentation at What Meta Box CPT plugin does is organize these settings and then call the register_post_type() function, and most of the settings for that function seem to be represented in the MB Custom Post Types interface.

For our services CPT we set a custom icon, the “hammer” as a way to make this post type stand out in the WP admin menu.

After this step I like to save the custom post type so I don’t lose my work if for some reason the window is closed. The CPT is now published, but we have a few more steps left in setting up it up.

CPT Supports Settings

CPT Supports Settings

Step 3 Set the Custom Post Type Supports & Taxonomy Settings

On the right side of the post type editor screen Meta Box Custom Post Types provides the “Supports” meta box. The defaults are title, editor and thumbnail. We’ve added excerpt, comments and author support for Services.

Note that “thumbnail” means featured image, and this is the way WordPress describes it at the development level although in practice most content managers would be familiar with a post having a featured image. 

Meta Box Custom Post Types can also be used to build custom taxonomies, which are then applied to custom post types. Right now we’re just checking off the default Category and Tag used by posts (not shown in screenshot). We may build custom taxonomies for this post type later, but if so it’s easy enough to revisit the post type editor and attach them.

Caffeinate! Save your post type and grab a java it’s time to recaffeinate. In the next steps we’ll be making test posts and trying out our new post type.

Test post custom post type

Adding a test post with the new custom post type

Step 4 Adding test posts to our custom post type

Make at least 3 test posts so you can see how things look in the archive.

Our services list is now coming together with our test posts in place. Check the list of posts, and visit the single post (click view link for the post) to make sure permalinks are working correctly.

Meta Box custom post types list

Services list after adding test posts.








Working with WordPress Tags

How to enable Meta Box free extensions when Meta Box is embedded in a WordPress plugin or theme

The situation is this, we’ve embedded Meta Box (core) into our plugin Clay Framework (which powers this site, Everything works fine, and we added the Meta Box AIO (collection of all premium Meta Box extensions). Now so far AIO was just activated as a plugin, not embedded into Clay Framework. And all the premium extensions seem to work fine, though there are so many we haven’t had a chance to test them all yet! Where we ran into a bit of a snag was when we installed Meta Box Custom Post Types. This post types extension is not bundled into Meta Box AIO because it’s free (only premium Meta Box extensions are found in Meta Box AIO). And when we activated it, a notice appeared that said “Meta Box needs to be installed”.

Digging into the code we saw that Meta Box Custom Post Types plugin uses the “init” action to check if Meta Box is installed. The priority on that check is 0, which doesn’t leave a lot of room to integrate Meta Box before it’s called. We were able to solve that using -1 as the priority in our init hook call where we integrate Meta Box. I wasn’t sure if that would work because I didn’t know if “minus values” are supported as hook priorities, but apparently they are! Is it good practice though, could it cause some complications? I’m not sure, leave a comment if you know the answer to that.

For now we’ll continue setting -1 as our init priority to integrate Meta Box, and that solved the problem for the Meta Box Custom Post Types plugin. It now loads properly and seems to be functioning normally.

Using the Meta Box plugin as a foundation for your plugin

In the past I used to use ACF as the field system for many of my plugins. I’ve been a programmer since before there were field systems, and before there were CMS systems. I’m just really, really old now lol. Point is, I don’t see the point of spending the time creating forms and fields. That stuff has been done, and done again, and odds are when you reinvent the wheel that way you’ll make mistakes. Either ACF or Meta Box take care of infinite numbers of things you would never get around to when building your own field handling system.

I’ve recently switched from ACF to Meta Box. And I’m hugely excited about it, because as I pointed out in a recent post Meta Box is awesome! In this post I’m going to share with you the overall idea of how to use Meta Box in your plugin development. It’s an overview, so I’m not going to give you a lot of details, I’ll be posting code samples and more details on this approach later. If you’re a seasoned WP Plugin developer odds are you can read the Meta Box docs and piece things together yourself… what I want to share is the strategy, the methodology behind using Meta Box within a plugin.

Here is a common scenario in many plugins, written as requirements:

  • Custom Post Type (CPT) such as “animals”
  • Animals have distinct data fields such as “Number of Legs”. Your goal is partly to make managing the animals easier, and partly to better support displaying the animals.
  • Provide a custom single template for each animal post
  • Provide an archive page that is custom and in some form lists all the animals, possibly just a directory style list, but possibly a more advanced approach with search and filters.
  • Other possible requirements:
    • Support searching by meta such as finding all animals with 7 legs. By the way there are many animals with 7 legs, they’re called the spiders that escaped my foot.
    • Provide front-end submission of animal posts
    • Display animal posts in a widget or shortcode
    • Organize animal posts with a custom taxonomy
    • Connect animals to another CPT as either parent or child, for example an animal rescue agency might want to have “orphans” (pets available for adoption) which is referenced from the animals post

First off let’s look at where Meta Box would come into play in the above. It won’t do every one of these things, but it will support you in building out all the requirements listed above.

  1. Registering the CPT. You can register your CPT with the Meta Box Post Types extension. During development can register it using the interface, then export it to PHP and bundle that export into your plugin. If the plugin is for a single website though, you might continue using the interface driven post type instead. Personally I would always export simply because I want any plugin I build to be portable. The Meta Box Post Types extension to me is a utility tool, a valuable one that saves me time. But I won’t rely on it for the finished product.
  2. Meta Box Post Types extension can provide any taxonomies used.
  3. Meta Box provides the fields for the CPT, organized into metaboxes. Meta Box extensions can be used to improve the interface such as adding tabs, or repeating groups of fields. For me those two features are must-haves in most plugins I build.
  4. Meta Box can provide the front-end form for submission with an extension.
  5. Meta Box can create the references between the CPT and another CPT using post type fields, and with extensions there are different field and selection options.
  6. Meta Box provides functions to get field values which you’ll use in your custom templates.

Meta Box basically does most of the heavy lifting here to create the features I listed in the requirements above. Where you’ll need to fill in the gaps are mainly the template handling. I like to use a template override system which I first created for the WordPress quiz plugin QuizMaster. It’s been refined across many projects, and in it’s current version is integrated into Clay Framework. What it does is search the site active theme and find a template override, and if none are found it loads the default template within your plugin. You’ll need to build these default templates, using Meta Box get value functions to retrieve values and determine logic such as switching display based on values.

Imagine being able to cut as much as 80% of the work down on your next plugin build. That’s the power of Meta Box integration for WordPress plugin development. Have fun building, and stay tuned for follow-up posts where I’ll go more in-depth into implementing Meta Box features in a real plugin build.

Metabox plugin is awesome

How awesome is the plugin metabox from It’s amazing that’s what! Look, I’ve been an ACF fan for years. Coming from a Drupal background the first question I had about switching to WP development was “does it have a field API”? The answer was no, but try ACF. And I did. And I came to rely on it for just about everything. Long story though, I eventually became less enthused about ACF. I very much regretted embedding ACF into QuizMaster for instance, which is a different topic.

Metabox in my view stands head and shoulders above ACF. I actually like their extension driven approach, which I think is a good structure for WordPress plugins in general. ACF interestingly enough was extension driven earlier on and has since gone away from that model. Of course 3rd party developers can (and do) still publish extensions for ACF, but there is something about the core using the extension system that I trust a lot more. Meaning it’s one thing to say you can extend a plugin (but we don’t!) versus saying you can extend it using the same extension system we just used to built all these extensions over here. Metabox can say that, ACF cannot.

I’m not familiar enough with the Metabox extensions yet to say if Metabox can do all that ACF could. A quick tour of their extensions directory (salivating at the prospect of buying the development license!) and I found several extensions that do stuff I always wanted to see done in ACF. It looks to me like they either kept tabs on what ACF customers were asking for (and delivered it) or they just have a great vision of what a field system should be capable of. For instance one of the pet peeves with ACF is the way it stores data. It essentially “doubles” for lack of a better word, the meta storage for each field value. One meta entry to reference the key, another to reference the value. Something like that (it’s complicated). Now with ACF or Metabox you might not ordinarily be accessing the meta directly anyway… but if there is one thing I know about strange ways of handling things in any system, you usually suffer for it eventually. ACF’s odd way of storing data was often cited as the reason the developers could not deliver certain commonly requested features. Exporting values for instance has always been weakly supported by ACF.

Is this a post about ACF or Metabox you might ask? Well getting back on track here… Metabox has an extension that allows you to store your field values (meta data) in a custom table. There is one example of how it offers flexibility that ACF (AFAIK) does not. Another is something like a “merge data” option that enables grouping data together to reduce the table rows. Meta data does have the risk in WordPress of quickly piling up a massive number of table rows, WooCommerce for instance stores something in the range of 40 rows per order! Just think how that can add up on a high volume website.

Here are a few of the things I’m liking best about Metabox:

  1. Online Meta Box field and metabox generator. Visit to try it out yourself.
  2. Extension selection of Meta Box Extensions available at Many of the plugins are free, and for the premium plugins the licensing terms and prices are fair, especially if you buy either the developers license or the lifetime license.
  3. Data storage as regular post meta. Unlike ACF the Meta Box plugin stores post meta in much the same way we would normally, so it’s easy to retrieve manually even without using the Meta Box value getters. There is also an extension that can store your data in a custom DB table.
  4. Easy to integrate into a theme or plugin. Current versions of Meta Box integrate even more easily than in the past where it took setting constants and possibly using a class. Today it takes 1 line, that’s it! Perhaps to avoid conflicts or check for versions it is worth wrapping that integration in some form of plugin activation check, but if you own the site you’re building on you can just be sure to integrate Meta Box only once. 
  5. Great support by dedicated developers. After using Meta Box only a short while I’ve already been in touch with the developers and they provide great support. It’s clear from their regular updates and involvement with their community that their very dedicated to the Meta Box project.

Well I’m off to integrate more Meta Box extensions into Clay Framework which powers Stay tuned for more articles about Meta Box including some tutorials as I continue learning and working with it.

Setting templates from your plugin

Often when we make CPT’s (Custom Post Types) we want to provide a default template to render the single posts. We also want that template to be overridable in the theme layer. The answer is the filter single_template which allows us to direct WordPress to load the template from our plugin. As for making it possible to override the template, we won’t cover that here but you can learn about how we do this in QuizMaster and Clay Framework by watching this video:

Example code below shows the use of single_template filter to select a template from a plugin.


WooCommerce developer mods compilation

Removing the annoying “Showing the single result” message when the catalog has only 1 product.

This example does the job, but bear in mind that the ‘woocommerce_result_count’ action won’t show at all even if the count increases later.

Change the add to cart button text.

How to remove the “default sorting” dropdown from WooCommerce


7 reasons why hiring offshore based developers is a bad idea

Over the 15-years I’ve spent as a PHP programmer I’ve seen the rise of offshore development, the fall in average cost of development, and more recently the resurgence of on-shore development as customers realize they’re sacrificing business opportunity when they hire the cheapest developer they can find. Today Upwork, the largest freelancer site is dominated by Indian, as well as Pakistan based developers. There is no doubt that this region serves a definite need in the marketplace. Just look at some of the jobs posted at Upwork. Build me a WooCommerce website with a custom theme for $200 reads one. Build me a massive social network like Facebook for $120 reads another. One wonders what happens on these projects? Does the budget increase? Does the project fail? I can only gauge from what I see, which is the work provided by new customers whose previous developers were from India. Based on that experience of being “the guy that takes over” the site/plugin, here are 7 reasons why hiring Indian based developers is a bad idea.

  1. Many offshore developers fail to respect even the most basic development principles. The most common example is the “hacking” or editing of base themes and plugins. Nearly every site we take over from an Indian based developer has edits to plugins. The result is those plugins cannot be updated. This is a problem worthy of it’s own blog post. If you’re unsure if your site already has these kind of edits, ask your developer about it. While in some cases editing a plugin might be necessary, it should be a last resort. WordPress has a hook system, and is a modular framework that is designed to enable custom functionality and new features without editing existing plugins and themes. On the theme layer, a child theme should always be used rather than editing the base theme for instance.
  2. Errors are ignored and not fixed. Often sites built in India have hidden errors, or functionality bugs that have not been detected. Thorough testing reveals these errors, as does turning error reporting on. Because error reporting is usually turned off for live websites, as a site owner you might never see these errors. While they don’t break your site (warnings) it is possible data isn’t being stored correctly, notices are not being sent to customers, form submissions are not being processed, and a host of other actions are not happening. At the very least these errors indicate a lack of quality in the work, and symptomatic of larger problems hiding under the surface.
  3. Are you really saving money? An all too common story of the website development project sent offshore to an Indian developer is that part-way through the project the scope changes, more money is demanded, and the final cost is much higher than expected. In fairness scope management is a factor for developers everywhere in the world, but Indian developers have a reputation for holding their customers hostage refusing to deliver work or finish projects if their demands for more money are not met. This cuts into the savings you might perceive from the initial quote. A much costlier problem is that if you eventually realize you’re not getting good work from an Indian developer, you might bring your development projects back onshore. But is the foundation of your WordPress website solid? We’ve seen sites built in India that require major fixes before any new work can be performed, and the costs of this repair eliminate or deeply cut into any savings.
  4. Schedules are often missed by Indian-based developers. Having hired over 30 India based freelance developers myself before I stopped trying to work with developers from India, at least half of them stopped a project partway due to a festival. Now to be clear these were 30 different developers working on different projects at different times of the year over a decade. Yet, midway through the projects, it was suddenly festival time. Either India has a lot of national holidays, some that last for weeks, or developers use these kind of excuses to buy them time before they are fired when their unable to meet a deadline.
  5. Lack of commitment to project completion is one of the scariest factors in hiring offshore developers. In the west we are used to professionals feeling a sense of obligation to finish what they start, and unless there is a significant reason such as missed payments or serious disagreement over the terms, we expect once we’ve hired a freelancer that they will finish the job barring something catastrophic happening. Perhaps it’s a cultural difference, or just a side effect of trying to work on a massive volume of projects, but many offshore-based developers have been known to end a project over trivial disputes, or simply say “this project is too difficult we cannot finish”. In those situations there is often an unapologetic attitude, the offshore developer simply says the project is over, often refuses to refund any pre-payment, and will argue that even something as basic as sending over partially completed work is not something they need to do. When things go bad in India for example, they go really bad, and there is little recourse in these situations. Don’t be under the false impression that a freelancer website such as Upwork is going to resolve these issues, though they do provide some protection for buyers it’s often not enough to offset the damage done when a project fails.
  6. There are affordable developers in some parts of the world with vastly superior track records. Many buyers today feel they have to offshore somewhere, they simply cannot put together a budget high enough to hire an American or European developer. And the availability, and willingness to work on certain projects is also a concern with on-shore developers. So where can you offshore more safely than India? Personally I’ve had the most success with Ukrainian developers, and other Eastern European locations such as Serbia. The work ethic and attitude of developers there is much more similar to Western Europe and North America. The communication level is also better, with many Eastern European’s able to both write and speak fluently. You will certainly pay more for developers from these regions, but there is still substantial cost-savings compared to on-shore development.
  7. Offshore developers are rarely able to provide consultation and make development choices, which becomes a big burden on project managers and site owners. A typical situation early in a project is the Indian developers asks what to do. You might (should!) have a written project plan, requirements document, perhaps visual designs. You provide these to the developer and offer to clarify them. More often than not they will come back to you and say okay I got your docs, now can you tell me what to do? Whether it’s a communication issue, or lack of experience, Indian developers are famous for not being able to identify the tasks required to turn requirements into deliverables. If you want something done, you literally have to ask for each step. This leads to micro-management. It’s also dangerous for project scope, because now you’re essentially looking over the developer’s shoulder and telling them which steps to take on a one-by-one basis. If things go wrong and the requirements are not met, the developer can simply say “well I did what you told me to do, sorry it didn’t work out”. That’s why you should always try to ascertain that a developer is results-focused, that they can convert requirements to working solutions, and they can do this without hand-holding.

I know I might take some flak from those who would say this is generalizing about a large number of developers from a specific region who vary tremendously. There is no doubt that there are many talented developers in India and other major offshore regions. But is it 1%, or 5%, or 10%? Who knows, but I can say that in dozens of attempts, I rarely found an Indian based developer that would be considered equal in merit to the average hire from the Ukraine, as an example. And in cases where an Indian based developer is a proven professional, most of them are not available for freelance work as they either have high paying jobs, their own firms, or work on a select number of big projects. Like any other market, top developers in India earn double or triple that of their counterparts, so don’t expect the truly qualified to be bidding on what is effectively a $3/hour job.

Let me close with a tip when hiring WordPress plugin developers from any part of the world. Always ask to see a plugin they built, they should be able to share at least 1 that is publicly available either hosted at in the plugins directory or for sale on a site such as CodeCanyon. Verify they actually have plugin experience, rather than just being site builders. Going back to Indian based developers, I’ve rarely seen a WordPress plugin that was built in India. They do certainly exist, but rarely do they rank in the top options in any of the plugin categories. And of all the Indian based developers that routinely respond to our job posts, out of around 200 we asked to send us proof of plugin development experience, the number that were able to do that was 0.