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 WordPress.org 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.

Developer for MainWP

We’re always excited to discover new WordPress plugins that we can work with. It’s one of the benefits of providing services across a wide range of industries and to clients with a variety of website from elearning to ecommerce. Recently we were hired to work on a MainWP project. If you’re not familiar with it already, MainWP is a dashboard for managing multiple websites within the WP admin. It provides many of the same features found in SAAS (software as a service) dashboards available for WordPress. The advantage over those external system is MainWP is a WordPress plugin, and it runs in your own website. That means you own it! And yes, it’s free. Both the MainWP Dashboard plugin, and the MainWP Child Plugin (which is installed on all the child sites) are available for free in the WordPress directory. There are also numerous MainWP extensions, some are free, and others premium.

MainWP can clearly save time and help create a more systematic approach to content development and distribution across a network of websites. It also simplifies management of sites and updates, saving development time and cost. Are you sold yet? We were immediately sold on the idea of using MainWP, and added it here to GoldHat.ca.

The project we worked on with MainWP involved a custom integration of the MainWP Spinner plugin. The client had hired a previous developer to build a custom approach to creating posts that would be published across their network of over 200 websites. MainWP Spinner extension integrates with online article spinner services such as The Best Spinner, Chimp Rewriter and many more. It is however limited in the content it can spin, only posts and pages. In this case the client had a customization where there was a custom post type, and fields were setup for images, headlines and various body text sections. After the article was “spun” all these fields would be aggregated together as post content, and published using the MainWP bulkpost feature. At this point the 1 article would be published to 5 sites, 10 sites or more and would be sufficiently unique on each site to qualify as unique content.

The problem with the implementation our client faced was a typical case of offshore development gone wrong. The previous developer “hacked” MainWP (the core plugin), hacked MainWP Spinner extension, and put only about 10% of the functionality into the actual custom plugin he built! Best practices be damned I imagine the developer saying! Well the result is the client updated MainWP, and voila the custom functionality broke. Fortunately it did not down his website, which is not uncommon in these cases. Reversing the damage done by the previous developer was a painstaking process of moving code from MainWP and MainWP Spinner into the custom plugin which we named MainWP Spinner Upload.

If you’re a site owner contemplating hopping on Upwork and hiring an offshore developer for customizations or plugin development just remember that it is very common to have this situation where work has to be redone later by a qualified WordPress developer. Mistakes made can be very costly in terms of downtime, cost to debug errors, and finally the obvious cost of having to eventually rebuild the features that you’ve had added. This is not to suggest that all Upwork developers are problematic, we still sell on Upwork to this day! There are also offshore developers, particularly in places such as Russia, Eastern Europe who do quality work. However the most common “help me my website is broken” situation we find is from “Built in India” or “Built in Pakistan” websites. While there are probably many great developers in these countries, unfortunately there are thousands of developers and firms that violate the most basic principles of WordPress development such as don’t edit the plugins (extend them) and don’t edit base themes (use child themes). Edits to plugins and base themes render your site unable to receive updates and because the entire ecosystem of WordPress is constantly evolving, it’s only a matter of time until something breaks, or a security flaw opens up that hackers can exploit.

Now that we have experience with MainWP and MainWP Spinner, we’re looking at opportunities to build custom MainWP extensions. We already have one new project with MainWP underway, it’s an integration with MainWP Spinner called MainWP Spintax Templates. It solves the problem that sometimes when spinning content you may want to embed a link, video or other content that is very lengthy when pasted into a text editor. Also organizing that content is time consuming. With our MainWP Spintax Templates plugin content managers can setup these spintax templates that then generate a shortcode. The shortcode is then copied into the editor and processed when the content is published.

We welcome our readers to comment on their experiences with MainWP and other topics in this blog post. Thanks for reading!

Epic WP Guide to Custom Post Type Permissions with Map Meta Caps

Setting up custom capabilities (permissions settings) for custom post types. It’s a topic that has frustrated many developers from novice all the way to expert. It’s the type of technical topic that tends to require more than a surface level understanding. Following a tutorial often isn’t enough to grasp it in a way that allows you to fully unleash the power and flexibility of the WP capabilities system. The good news is this Epic WP Guide from GoldHat Group is going to give you an in-depth exploration of how to use custom capabilities with CPT’s, how to use the map_meta_caps filter, and what to expect from the WP admin when you take various approaches to capability mapping.

Because this probably isn’t your first stop in making sense of how to use capabilities for CPT’s let’s start with an overview of the process before we begin to delve into the details. This epic guide is only going to involve 3 steps. That’s the good news. The bad news is there is enough complexity that we’ll be looping over these 3 steps a total of 3 times each in order to help your brain assimilate the information.

  1. How to use the capabilities settings (“capability_type”, “capabilities”, “map_meta_cap”) when registering CPT’s.
  2. Using the map_meta_cap filter to map primitive capabilities to meta capabilities.
  3. How to assign capabilities to roles and/or users.

CPT Capabilities Settings

When you setup your CPT there are 3 settings we care about that will affect how capabilities are mapped. These are “capability_type”, “capabilities”, “map_meta_cap”.

A common mistake is using capability_type and capabilities. This appears to cause conflicts, however we don’t have an authorized statement from any official docs saying don’t use them together. It’s just been our experience that using either setting alone works as intended, whereas using “capability_type” AND “capabilities” appears to cause either a problem with mapping capabilities which we handle later with the map_meta_cap OR it simple interferes with how permissions are applied. Whatever the case we advise using one or the other, not both. The “map_meta_cap” defaults to false, it should be set to true only when using “capabilities”.

To summarize you have 2 major configuration options using the 3 capabilities settings:

  1. Use capability_type (which defaults to string “post”). We call this a “semi-custom” approach, because WP will automatically create custom capabilities and map them for you. You won’t control the naming, that’s done by convention, and you won’t have control over the exact mapping that part will be done in a standard way. However before disregarding this approach, consider that you will still have extensive options to impose logic and affect permission utilizing the map_meta_cap filter. Ask yourself do I need more, and if so why? The more you understand how custom mapping of capabilities works, the more appropriately you’ll be able to make this decision. With this approach you DO NOT pass the “capabilities” or “map_meta_cap”. If you have a situation where these are being automatically set – you would need to pass an empty array for capabilities and false for map_meta_cap. These are both the defaults.
  2. Use custom capability mapping. This is the “fully-custom” approach, gives the maximum control. It allows you to pass an array of your custom capabilities, and to map them to the post capabilities which we’ll discuss in detail later. Using this approach allows you to control naming and to map multiple default capabilities to a single custom capability that you define. When using this approach DO NOT pass “capability_type”. You must set the “map_meta_cap” to true for this to work, and you’ll need to use the map_meta_cap filter.

Using Capabilities Settings in CPT’s

This is not a beginners guide to WP permissions so if you’re entirely new to capabilities and never used functions like user_can() we recommend brushing up on those basics. What we will cover here is how capabilities are mapped in relation to custom post types.

There are 2 types of capabilities: meta and primitive. Imagine meta capabilities as being major highways, routes or freeways. Let’s say you’re in a big city and you have 3 of these major highways, the one is called highway 5 another route 9, and finally we have route 17. If you want to head east, everybody knows, take the 9. You could be going to vastly different places, but you start with this major roadway. Same idea with capabilities. Always start by thinking about the meta capabilities, which will lead you to the primitives. You’ll see a lot of texts explaining these things in reverse, talking in terms of mapping primitives to meta capabilities. And it’s true, as you’ll see later when we work with the map_meta_caps filter that yes we do end up spending more time focused on the primitives. But that’s just like when driving someplace, you spend most of your time navigating the exits and smaller turns to find a place. You’ll never get even close if you don’t the right highway!

There are only 3 meta capabilities. Memorize them: edit, delete, read. For posts the actual name of them always ends with “post” so we have the list shown below:

  • edit_post
  • delete_post
  • read_post

Meta capabilities are not mapped to roles, whereas primitive capabilities are. The relationships here between the role, the primitive capability and the meta capability can be understood as follows:

  • Imagine you have a jug of water and a cup. As owner of the jug and the cup you can do whatever you want with either one, including pour the water in the cup, pick up the cup, drink from the cup and finally smash the cup on the ground.
  • Your child, can also pick up the cup and drink but cannot fill the cup or smash the cup!
  • Your dog isn’t allowed anywhere near the cup! He has full permissions only for the dish.
  • Our roles are owner/child/dog. The PRIMITIVE capabilities are pickup_cup, drink, fill_cup, smash_cup. The META capabilities are use_cup, destroy_cup.
  • When any of our users in this scenario try to pickup the cup, the question is asked “can they use the cup”? The question at this point is in the context of the meta capability, use_cup. We don’t directly get the answer, instead use_cup will reference which primitive capability(s) are required. The logic involved will take into account the user specific context, such as whether the user is the owner of the cup, or whether the cup has already been smashed!

To see the full list of capabilities available to map for a custom post type it’s worth reading the section at https://codex.wordpress.org/Function_Reference/register_post_type under the heading capability_type and capabilities. As mentioned earlier using the capability_type setting enables a “semi-custom” approach to mapping capabilities. As shown in the docs example, if the custom post type was “book”, setting capability_type to “book” would result in the capabilities shown below:

Now let’s look at an example of the fully custom capability mapping that is more commonly used when building plugins. When we want full control, and perhaps a different naming convention. This is form our QuizMaster plugin, notice that we prefix all our capabilities with “quizmaster_” which keeps them consistent with the naming conventions used in other areas of the plugin.

You’ll notice our custom definition of capabilities includes primitive capabilities such as “edit_published_posts” that are not automatically mapped when using the capability_type automatic mapping. This is because WP core generally does not use these in the WP admin. These other capabilities however can be very useful in providing more fine-grained control later when we define permissions logic in the map_meta_caps filter.

Mapping Capabilities with the Map_Meta_Caps Filter

The most common place where developers go wrong is in failing to utilize the map_meta_caps filter when they’ve set map_meta_cap to true in their CPT definition. If you’ve set map_meta_cap to true, you must use the map_meta_caps filter because generally speaking, all access will be denied until you return capabilities from this filter. You might think not using the filter would open permissions up, but quite the opposite in what may be a safeguard, no filter return means no permissions granted. That’s not to suggest that the purpose of map_meta_caps filter is to determine if permission is granted. It’s job is much more limited. It merely answers the question given the current context including the meta capability, the post, the user, what primitive capability would the user need to do what their trying to do?




Managing WordPress Plugins hosted in the WordPress.org Plugin Directory

At the start of 2016 I recall saying to one of my partners “I can’t believe we’ve never been able to make a finished plugin and release it to the WordPress community”. Of course there were reasons… certainly not a lack of ideas, or even ability to code. Just a lack of time, and focus. Well that’s all changed, today GoldHat Group has 3 plugins in the WP directory, and plans to add more. All of our plugins so far are based on ACF (Advanced Custom Fields) a plugin that I consider essential to install on any site I build. To me “fielding” to borrow the Drupal term for it, is one of the most beneficial aspects of using a CMS. If there wasn’t posts types and fields and taxonomies, I’d probably not use a CMS and go the PHP framework route.

WordPress.org SVN for hosted plugins

Normally we only use GIT, so one of the first challenges of managing WordPress.org hosted plugins is that upon approval you get an SVN repo. Rather than really learning SVN, I installed SVNTortoise (https://tortoisesvn.net) and highly recommend that to lessen the learning curve.

Managing WordPress.org hosted plugin assets

See the handbook at https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/#plugin-icons.

There are a couple of places where information is stored about how to control various parts of the actual WordPress.org plugin directory listing. And I was months into it having Googled at least a dozen topics, before I discovered this “Plugin Author Handbook” which clarifies a few important parts.

This post is a WIP, apologies to all who have stumbled upon it!


Programmatically Install WordPress Plugins

Have you ever wondered if you could programmatically install WordPress plugins? Well of course you can, and it’s easier than you might think.

Here is a shortcut to the solution, use WP core function activate_plugin().

Here is an example that could be helpful if you want to do the activation from outside WP:

Is Plugin Install and Activation the Same Thing?

No, plugin activation only handles activation of a plugin that is already installed. In WP “installed” means the plugin already exists in the wp-content/plugins/ folder. If you manually drop a plugin there, it is installed but not active and will appear on your list of plugins… presuming it isn’t broken or invalid. In other words “plugin install” alone doesn’t really do much, WP becomes aware of the plugin, lists it, but doesn’t include it or run it.

What matters about this is that a full external WP plugin install service/platform has to handle putting the plugin into the plugins directory (install) then handle the activation. But when we talk about programmatically installing WordPress plugins, it’s usually the activation we’re concerned with.

Potential Use Cases for Programmatically Installing WordPress Plugins

  • External (outside WP site) service that installs plugins to a given site. In this use case the service would need to deliver the plugin (zipped) to the wp-content/plugins/ folder, unzip it, then run the activate_plugins() function.
  • Bundled plugin installation for suite of plugins. If you’re building a collection or suite of plugins that work together and require each other, you may want to have them installed together. You could build a central or main plugin, which has the other plugins in the suite contained within it. When the main plugin is installed, the suite plugins are moved/unzipped and then activate_plugins() is run. With this use case you might also have an interface where the admin user can select optional plugins within the suite to install.
  • Custom WordPress installs. After installing WordPress, deliver/install plugins. This use case could be used to create deployable packages, such as a WooCommerce deployment where WC is automatically installed.

Improvement in variations display

This new and improved approach in displaying the different types of options for each and every item on your online store available and ready to be added on your site.
Instead of showing a plain and static text, we made the colors display to be in small thumbnail icons – which could be rather just colors or textures.
This will improve the overall look of your options field and will make choosing easier and nicer to your clients.

My Favorite CMS Features from WordPress and Drupal

I work with both WordPress and Drupal. As a PHP programmer I was drawn to Drupal in 2009 and started with D6. I avoided WP despite all its popularity, always thinking of it as a blog, or more for small sites. I wanted more structure, more of a programming framework. Back then I also worked with PHP frameworks, and given the choice I would have normally rathered to work with CodeIgniter than any CMS. After all when I started building sites in 2002, there were no CMS’s at least nobody told me about any worth trying.

Today I am always a bit torn about “which is better” between Drupal and WordPress. Like many others I’d like to be able to make a definite statement on that and say well, I’ll just focus on ____BLANK. It’s not that simple, I used to have this site goldhat.ca in Drupal. Then I tried Concrete5 briefly, that didn’t work and when shifting away I decide no I’m not going back to Drupal, I’m going to try WordPress. Having seen how easily many parts of WP work on client sites, I wanted to see if it could handle some of the customizations and extensions I wanted to add to goldhat.ca. I found it could, especially with the help of a plugin now use in nearly every WP site I run, ACF (Advanced Custom Fields).

What is the key differentiation between Drupal and WordPress?

If I had to point to 1 key different in these systems it’s that in WordPress generally things just work, and they look good. In Drupal, again speaking generally (and no offense to Drupal gods!) most things look terrible and arrive broken and require extensive work to make functional. Now that might sound like a damnation of Drupal, which it is to some extent. But we have to consider that if you measure based on the general “size” of a website, measure not really by number of pages but by complexity of features especially the need for external integrations, complex logic, custom programming etc., then the comparison tends to look like this in my mind:

  1. Small, simple site: WordPress rocks. Install it, pick a theme, customize theme, install some plugins, everything looks good and works good and the build is fast. Management is fast, further development easy. Drupal in contrast, much more configuration needed to get this simple site looking and working well in most cases.
  2. Medium site: here is where it’s a bit of a toss-up because in this range WordPress might be okay, and Drupal starts to be more competitive. I’d still tend to lean toward WP but that’s because I’m very comfortable extending WP with plugins and using ACF to add the fielding and custom content options that make it seem a lot more like Drupal. With a medium complexity and size you have to start looking at specific plugins and modules and features and asking which system fits the specific site being built.
  3. Large, complex site: no question in my mind that when already have more complexity in your site, then the complexity of Drupal starts to make sense. The time required to get up and running, is acceptable because you would have to spend that time in WordPress anyway given all the functionality you might need to build up. A key example of this is when you need advanced roles/permissions. Drupal generally has better support for this (though WP has plugins that add more support in this area).

A principle I now live by is to use WordPress whenever possible. Meaning only go to Drupal, or another solution including a PHP framework or custom platform like Moodle/Magento if WordPress really seems like a poor fit. And I find increasingly that is a rare situation. In fact I’m working on a site right now where the lead build team said absolutely no way we could build this in WP, it’s too big, too complex, needs too many roles and access handling, security features, etc., but I’m not really convinced that was true. Often I believe that Drupal builders make the presumption that only Drupal has various features, when in fact WP has them perhaps implemented in a different way.

Best Drupal Feature

In my mind without question Drupal is a leader if “Fielding” or custom content type development. This is where you need custom content such as a real estate listing, and you can build your own content type and add the various fields such as bedrooms, baths etc. It’s like being able to develop your own custom application inside the Drupal admin. Other CMS systems of course have some equivalent feature, WP now has custom content types in the core but it doesn’t have fielding in the core. So fielding is a key feature because in almost any significant site your main goal is to store various types of content. And being able to do that with “fields” rather than building up pages with text alone is crucial. Drupal handles this in a powerful way. And fielding doesn’t stop at making the fields, there is also display handling so you can dictate how your fields display. For many situations, you can make your custom content types and your fields in the admin, and configure the display, and never need to do any custom coding to have a function system to add/edit/delete custom content and display it.

Best WordPress Feature

Is simplicity and everything working and looking good a “feature”. It’s not as easy here to pick something that stands out and maybe that’s because WordPress is less about “powerful features” and more about a holistic system that is balanced and works well in every aspect. You might complain about lack of a feature in some areas, but you will rarely complain about something not working or not being well designed. Back to the point… best WP feature in my book is the drag/drop widget handling and the sidebar system. This makes adding widgets really easy and when you’re building themes or doing more extensive customizing there is enough power under the hood to extend this system and create whatever sidebars you want. It’s definitely much friendlier to use than the Drupal equivalent which is either Blocks Management or Context. And the fact that Drupal has Context, which is basically a more advanced way of handling Blocks showcases that the core blocks system is not very friendly to use.



WordPress Automatic Blogging Plugin

WordPress is the undisputed ruler of blogging software. It makes writing blog posts fast, easy, fun… wait is this a WP love-in or a blog post? I’m too tired to write a good blog post and I definitely don’t want to spend valuable minutes optimizing the SEO or categorizing it. What’s the solution? Don’t blog and fail to meet content goals and develop a strong search ranking mixed with social credibility? No no no! There is a better way care of smart marketing meets digital innovation. It’s called Automatic Blogging.

Great writing has it’s place, quick rants have their place too, carefully crafted blah blah… sometimes you just need relevant information posted quickly. Like today when I found and started using the WooCommerce Teams plugin, I would have loved it if my website was smart enough to realize I’d installed a new plugin, that I like it, and went ahead and crafted a post about it.


Which Wordpress Plugins Can't We Live Without?

At GoldHat we run many different sites and there are certain plugins that we love to use across multiple sites and consider must-haves. Topping that list is WordPress SEO by Yoast. Whenever I work in Drupal or Concrete5 on content I immediately miss WP SEO by Yoast. Without it, SEO takes WORK! Can’t say enough good things about having immediate feedback on your content optimization.

  1. WordPress SEO by Yoast. Provides search optimization ratings for posts and helps focus your SEO work while editing.
  2. Clicky by Yoast. Integrates Clicky analytics, an alternative to Google Analytics that we started using.
  3. Quick Adsense. Integrates Google Adsense.


Food Service Wordpress Plugin Research

Food Service WordPress Plugin Research Summary

As in most plugin categories for WordPress we find lots of selection for the food service industry. Restaurant menus, recipe plugins, nutritional data plugins, it’s all there in some form or another. The question is how well covered are the essential features in these food service plugins and how easily can these plugins be extended? How does the output look in this category where presentation and style is so important?

Restaurant Menu WordPress Plugins

In this category out of 8 plugins we looked at 5 deserved installation and review. Of those 5 plugins only 2 stood out for us as high quality plugins that are ready to use. And it was not easy differentiating between those 2 which are FoodList and Food and Drink Menu. After further consideration Food and Drink Menu won the battle and gets our top recommendation.

Here is the full list of restaurant menu WordPress plugins that we tested and reviewed:

  1. Food & Drink Menu (Top Recommendation)
  2. FoodList (Second Recommendation)
  3. Restaurant Menu Manager (Recommended for Special Use)
  4. Restaurant (Not Recommended)
  5. Easy Restaurant Menu Manager  (Not Recommended)

What features are missing in the restaurant menu plugin category?

Menu print options are weak or not supported in most of these plugins. They also lack support for import/export which might be very helpful when importing lots of menu items. We saw many support tickets asking various plugin developers about import options when setting up their menus. Initial menu item entry can be laborious with some of the plugins because the process is often 2-3 steps.