How to setup Swiftype Crawler Based Search Engine for WooCommerce

I first started using Swiftype late last year (2015). The user experience offered by SwifType is phenomenal. It makes searching fun and not guesswork.

I started with the regular SwifType Search Engine along with the WordPress plugin from SwifType. While it provided basic functionality, the array of results did not include all potential matches. Digging deeper, I discovered that the WordPress plugin did not index pages that WooCommerce generates on the fly. Examples of these include the Product Category Archives and the Product Tag Archives. In addition, it would also not index the Brands archive either. Any custom taxonomy that was added was not being indexed. When I inquired about this, I was told that any pages that are dynamically generated by WooCommerce, are not indexed.

That explains why certain pages would not show up in the SwifType Search Results box. In a quest to get this working, I approached SwifType for guidance.

With help from SwifType, I added some code that solved the problem. With this code, SwifType indexes the entire site, including all dynamically generated pages. Please do note that you will have to create a new Search Engine in your SwifType account and select it as being “Crawler Based” versus WordPress plugin-based.

Be sure to replace the <unique-code-from-swiftype> with the actual code you are assigned by SwifType. Similarly, replace the <name-of-search-engine> on Line 11 with the actual name of your SwifType Search Engine.


Let me know what you think of this. Did it work? Did it help you? Did it break anything?

[WooCommerce] Checkout Progress Bar

WooCommerce Checkout Progress Bar in Action

As you read articles/posts on ecommerce optimization, specifically checkout optimization, a popular theme emerges: The Checkout Progress Bar. The idea is to provide your visitors some kind of visual feedback that they are making progress. It tells them how far along they are before the purchase is complete. Conversely, it tells them how much longer before they can own the product/service they are vying for.

With this in mind, I googled for a free plugin that would accomplish just that. My search ended fruitless (almost). I did hit this gem of a plugin called Progress Bar. This is a simple plugin that can be used anywhere on a WordPress site.


In this article, my aim is to create your own customized checkout progress bar without the use of any paid plugins. You will need

  • Download the Progress Bar plugin from the WordPress plugin repository
  • Make some code changes (PHP and JS included). Download from github.

The code changes are shown below. The first change is in your theme/child theme’s functions.php file. Two things are happening here:

  1. Hooking into the “woocommerce_checkout_before_customer_details” action hook to display the Progress Bar. We use the shortcode for the Progress Bar because it allows to send in parameters for styling and appearance.
  2. Loading the JavaScript file that will manipulate the Progress Bar based on how much of the Checkout Form has been validated.

The second file is the JS script that checks in real-time which mandatory fields have been validated. Then it calculates the progress (in pixels) by simply dividing the “number of fields validated” by the “number of fields that require validation”. It also accounts for the “Shipping Address Same as Billing Address” checkbox.

The end result is you get a progress bar for your WooCommerce Checkout Page.

WooCommerce Checkout  Progress Bar in Action
WooCommerce Checkout Progress Bar in Action

Notes on Customization

The CSS for the progress bar can be easily customized. Follow the instructions on this link. Also, note that the plugin has quite a few options that can be used for customizing the look and feel of the Progress Bar.

[SOLVED] How to trigger emails of Failed Orders in WooCommerce

Update on February 3rd, 2016:

As of version 2.5 of WooCommerce, this functionality is now built into the WC Core. This plugin is not needed. See the WC 2.5 Changelog for more details.


Following the lead from this blog post by SkyVerge, I set upon to create email notifications when an order fails. Essentially, any time the credit card fails or the order processing is not successful, WooCommerce should notify the store owner that the order has failed.

Currently, WooCommerce is silent about Failed Orders. Note that there is a built in setting in WooCommerce for notifications about Canceled Orders, but not Failed Orders.

My first attempt at trying to modify this plugin by Justin Stern, failed. I tried to adapt the plugin for “Failed” instead of “Cancelled”. However, just replacing the instances of “Canceled” with “Failed” did not accomplish my objective.

After a lot of experimenting, I gave up and sought the help from the WooCommerce community. One of the most helpful WooNinjas, Caleb Burks, lent me a hand for this one. I take no credit for this. All I can say is that guy knows his coding very well.

In the future, I will try to explain the code. For now, here is the link to the completed plugin that sends out emails immediately after an order transitions into Failed status. To test this, simply change the status of an order to “Failed”. Emails should be fired off to the store owner.

Good luck to you. Let me know if it works or if you experience problems. This does work on my setup: WordPress 4.3.1, WooCommerce 2.4.6.


WordCamp Miami 2015 Recap

I attended WordCamp Miami 2015 during May 28th-May 31st. The venue was Florida International University (FIU), my alma mater. The FIU campus has undergone a transformation. 16 years after I graduated, the campus has new buildings, fast food joints like a mall. I do feel proud of the fact that FIU campus at University Park has undergone such upgrades. The buildings sure look nice.

Enough about the venue, let us get down to what this post is really about. First day of the WordCamp was Theme and Front End Development course. There were talks about getting your feet dirty in the theme development. What follows are my tidbits on what I gathered during the talks. I was not able to attend all sessions. I focused more on the development/theme coding sessions.

Presentation/Slides are located here.

Day 1 : Core Concepts of WordPress Themes

  • Double quotes in PHP echo statements will automatically replace the variables with their respective values.
  • Template Hierarchy :
  • Presentation Slides
  • Any member of the template hierarchy will have a version of The Loop
  • The “body” of The Loop is where all posts are rendered
  • Show Current Template” plugin shows the actual template being loaded for a particular page/post.

Day 1: Building A Theme Using _S

Personally, this was my favorite talk. It was presented by Morten Rand-Hendrickson. Morten (“Mor10”) took a very hands-on approach by walking us through an actual project he did for Emily Carr university. For the project, he had to design a site for a mouse-only navigation where movies created by student artists would be showcased. He used the _s theme and built on top of that, incrementally achieving the final outcome.

  • Code Location – Project code used for Presentation. This theme was derived from _S (
  • Advanced Custom Fields is an easy plugin for adding custom fields to posts
  • CPT UI – Used for creating Custom Taxonomies
  • – Used for video controls
  • Isotope – automatically filter content on page. It does by appending class names.
  • When you download from, whatever you put in the “Name” field will be inserted into the code (example: wcmia_*).
  • will show you the preview of all fonts
  • display:flex (flex box can be used for auto prefixer) allows equal height columns without using float and clear. This is a CSS directive that enables equal height column layout. Can be used for orienting any content, horizontal or vertical.

Particularly, this talk was very insightful. Mor10 kept us engaged for 2 hours. That is a long talk by any coding standards. Mor10 was patient with our questions. He went step by step through his git changes. Moral of the story: For something so complex, break things down into smaller pieces. Connect the actual pieces from the problem into WordPress posts, taxonomies, custom fields etc.

Day 2: [Development Track] Beyond the Post: Pushing the limits of Custom Post Types

Look at this for an example of custom post type:

FieldManager – github

CMB2 – WebDevStudios

ACF ( may still require coding)

Day 2: [Content Track] How to Come Up With Articles for your Blog


  1. We only blog when we feel inspired
  2. We let our insecurities hold us back (“I am not a writer; I don’t have any thing important to say”). This prison is one of your own making.
  3. We only blog when we have a new insight.
  4. We simply need to learn to tell good stories. You do not need to be a story teller to be able to blog/write. The process of telling a story starts with Point, progresses to Context and then you Start.
  5. We will only blog when we are interesting.


  • Source : What did you see?
  • Story: What is the story?
  • Lesson: What is the point?
  • Audience: How do I shape it?
  • Point: What should they do?

Day 2: [Content Track] Constructing a Large Informational Site by Becky Design

Use Facets for filtering and narrowing down content from different taxonomies. The FacetWP plugin sounds very interesting in that it has a broad range of applications. I am excited to make this work for ecommerce sites using WooCommerce.

For creating custom taxonomies, you can either code your own via a plugin or use the CPT UI plugin.

Day 2: [Development Track] Cache Money Business by Mark Jaquith

2 Slow 2 Furious – Slow Sites are not good for performance

Caching Principles

  1. Do Less Work
  2. Work Less Often ($TTL = 5400;)
  3. Make Generic Output (less personalization)

BatCache – WordPress cache plugin – for full Page Cache Output

W3 Total Cache – Complex WordPress cache plugin

WP Super Cache – Medium complexity cachine plugin

CDN – Content Distribution Network – Points setup around the world for better performance

Nginx Cache Purging – 3rd party module for purging nginx cache

Varnish – Does not support SSL pages

Logged in = no page caching?

Cache Buddy – Subscribers and Users will not appear as logged in users

Cache WordPress Objects

APCu (Single Server Only), Memcache, Redis

Day 2: [Developer Track] WordPress and Third-Party API

API’s – WordPress API’s are written in in JSON (REpresentational State Transder)

How to build plugin’s which communicate via JSON API

json_decode(), $get., CURL are not what we use in WordPress

WordPress APIs – HTTP API is an important API for sending and receiving data to/from external sites.

  • wp_remote_get()
  • wp_remote_post()
  • is_wp_error($response)
  • wp_remote_retrieve_body()
  • set_transient()

Example was retrieving a random joke via JSON from the ICN Joke Database (Internet Chuck Norris Joke Database). You can integrate this code into a widget within WordPress or a shortcode.


That’s it! I only attended 2 of the 3 days. I skipped the Sunday schedule. All in all, it was a good event. As with any WordCamp, some talks were more useful to some people than others. It all depends on whether or note you received actionable stuff from any or some of the speakers. In my case, constructing a custom theme based on _s was enlightening. Additionally, I am excited to try out the FacetsWP plugin within an ecommerce site. By that measure, this WordCamp event was very useful for me. I look forward to WordCamp Miami 2016.

[SOLVED] Unable to login to WordPress after WooCommerce upgrade

If you are having an issue logging into the WordPress Admin for your site, read on. Specifically, it seems that the WordPress login authentication completes. However, there is a redirect loop which is cyclic and recursive, so the browser eventually gives up.

My Environment:

  • Shared hosting based on LAMP
  • Static Cache, Dynamic Cache (varnish) and memcached enabled
  • WooCommerce along with a bunch of other useful plugins including Yoast SEO, Google Analytics by SEO, Revision Control, AKismet and a few others.
  • Theme: WooCanvas by WooThemes


A couple of days back, a new version of WooCommerce was available. Thinking nothing of it, I just clicked the upgrade button on it. I like to keep everything updated to avoid zero-day exploits. The upgrade seemed to complete successfully without any noticeable issues.

The following day, I logged into my hosting account and noticed I was using the Google PageSpeed module for caching. With my host, if you enable Google PageSpeed, it disables all the other 3 kinds of caching mechanisms. These caching mechanisms are Static Cache, Dynamic Cache and memcached. All 3 of these caching schemes are at the hosting interface. I should mention that the site is hosted at Siteground.

Caching (at hosting server)

When I noticed that Google PageSpeed was not giving me acceptable speed, I decided to disable it and re-enable the 3 Siteground provided caching schemes. I enabled Static Caching, Dynamic Caching (varnish) and also memcached. From what I understand, memcached stores the dynamic database related objects in RAM to avoid database server latency.

Little did I know that this would cause me huge trouble. Specifically, I was unable to login to the WordPress Admin of the site after I did this. At the time though, I did not know that enabling “memcached” had somehow led to this lockout.

Redirection after login

Specifically, I was being redirected from any Admin page to the ‘wc-about’ page within WooCommerce Admin. I used the FireBug console to determine as much. The redirect however would not work and the browser would give up after a few times of constant redirect. I believe it was an endless redirect loop.


At first, I logged a ticket with Siteground to determine what had caused this disruption. As usual Siteground responded promptly (a good thing). However, their response was not exactly helpful. They said they had tried several different things, but nothing worked. This included renaming the “plugins” folder, disabling all the plugins, reloading stock .htaccess. I should also clarify that the site itself was totally operational from the front end. There were no issues at all browsing the front end of the site. It also loaded a bit quicker now that all 3 caching schemes were enabled.

As disappointed as I was with the response from Siteground, I was determined to get to the root cause of the issue. After a couple of hours of trying a few different things, I finally narrowed it down. It turned out that if I disabling the “WooCommerce” plugin, the problem disappeared. This was consistent because the “wc-about” page is a WooCommerce Admin page. It made sense that WooCommerce was somehow tied into the equation.

The next step however was not so simple. I stumbled upon the caching setup once again. This time, however, I only disabled memcached. Voila! That seemed to fix it.

Possible memcached conflict/interaction with WooCommerce upgrade

At this point, I believe that there is some play between enabling memcached on a newly upgraded WooCommerce plugin. Somehow, the upgrade process did not complete fully maybe? I do not recall if the “wc-about” page was displayed after WooCommerce was upgraded. Once I disabled “memcached“, logging into the WordPress Admin, I was greeted immediately by the “wc-about” page.

I hope this helps someone who is locked out of their WordPress Admin after upgrading WooCommerce. Who knows if this could have happened while upgrading any other plugin as well?  Let me know if you have seen this issue.