Why we stopped using Jigoshop

We’ve had this site a while now – since July 2011 as it happens. At the time we needed some ecommerce software and Jigoshop seemed fairly workable. It had only been out for about a month when we setup our site (it was released on 31st May 2011) although we didn’t start populating our catalogue until August. Back then there were a few other options and the other one I remember trying seems to have been completely wiped from the internet (Zing?). Odd.

I was relatively happy with Jigoshop for a time and it was far more user-friendly than other things I’d encountered. Restocking stuff was a colossal pain in the arse but nothing is perfect.

Given that their core software was free the business model was support and plugins. I bought their shipping plugin so that I could properly handle different weights and locations. That will come back later…

We went on to build up our catalogue and do business. I can’t say I noticed the launch of WooCommerce at the end of September 2011 and I didn’t pay much attention to it in years to come either as it’s a fork of Jigoshop. In software terms that means that at a certain point the code behind Jigoshop was copied as the base for a new bit of software. “Copied” sounds a bit damning but that’s how open source software works much of the time. The codebase is there and if you want to take it in your own direction you’re welcome to it (assuming the project’s licence supports it).

So the idea of there being another, very similar, bit of software to handle ecommerce on WordPress didn’t exactly fire my imagination. Generally speaking with “production” deployments one shouldn’t be aiming to hop to whatever is newest and shiniest – reliability and stability are more important concerns.

Over the years of Jigoshop 1.x (or JigoShop as it was then) the site broke many times. Sometimes it was something I did but more often than not it was due to bugs in Jigoshop. I put up with it though and stayed up all hours to fix things. Migrating to other software was not a task I wanted to undertake. The shipping plugin and its related subsystems would periodically break leading to orders failing to work and customers leaving in frustration without telling us why. So that was fun…

I spent a fair bit of time filing bugs for Jigoshop (to the point where with one update I was responsible for finding a third of the list of things they fixed) but never received any proper gratitude for it. I wasn’t expecting a parade but a “Good catch! Thanks!” wouldn’t have gone amiss. Still, that’s hardly a reason to switch software – I’m not that vindictive.

However last year Jigoshop end-of-lifed the 1.x branch of their software. Users wanting to continue with it would need to move to the 2.x branch. Fair enough, thought I, even if it felt a little rushed.

This next bit is a very real-world result. The “upgrade” didn’t result in everything catching fire. It wasn’t dramatic. What happened instead was that various features were missing, broken, or otherwise problematic.

For example they’d changed a lot of their CSS classes. The CSS I had for buttons no longer worked because instead of .button they were now referring to buttons as .btn. This was true of various things and resulted in me spending quite a while sorting out the site’s CSS rather than, you know, working on models.

You know what else didn’t work properly?

Their migration wizard wasn’t properly built and so countless products (I mean literally hundreds) were not hiding when they were out of stock. Wonderful. I’m fairly sure they never fixed this for deployed sites. I’m told they fixed it in the migration wizard but that’s naff all use to me.

I did my best to track down all the affected products and fix them but I’m sure I missed a few. While I was doing that I also had to fix the way Jigoshop 2.x handles images. Previously they’d been stored in the normal WordPress way (which WooCommerce also uses) but in the 2.x branch they were now stored as attachments!

I’m not really sure what the difference is other than they didn’t bother to migrate the old images. They’d have their main picture and that was it. All the alternate angles I’d taken photos of? Lost in the database. Again, I think they’ve fixed the migration wizard but not bothered with users who have already migrated. Cheers for that.

However, let’s be fair, I wasn’t paying them for support. Admittedly I wasn’t just whining about my problems either – I’d spend time tracking down particular database fields that were affected and compiling detailed reports so that fixing stuff wouldn’t require extensive detective work.

I was paying for their premium shipping plugin though. The thing that had broken many times before. Still – brave new 2.x launch. I’m sure that’ll have been tested thoroughly!

They never did fix the restocking issue I was having either. Editing hundreds of products individually for a restock wasn’t very fun. However they did implement an API. I had fun trying to figure out how to use it. Eventually I wrote a restocking script in Python that used it.

Last week though they pushed out another update that broke my site’s CSS and that was it.

No more.

I’ve got enough on my bloody plate without having to worry that orders aren’t being processed because the shipping calculator is poorly written. I shouldn’t have to be concerned that I’m going to have to sacrifice a few days to redo the CSS for my website because they pushed out a stupid update. I am done.

In the intervening years WooCommerce has grown to the point where WordPress reports that there are over 4 million installations active. That doesn’t suggest to me that it’s the best software known to man but it does suggest that it’s well supported and there’s lots of software available for it. It suggests that if they push out an update that breaks stuff there will be a lot of very grumpy users getting in touch within minutes.

Out of interest do you know how many installations of Jigoshop 2.x there are out there?

Over 4 hundred. Yeeeah…

Their Wikipedia page has even been deleted because they’re not considered significant enough anymore. It looked a bit like this, if you’re curious:

So what did I do?

Well I used what I’d learnt writing the restocker and working with Jigoshop’s API to output all our product data and orders. I then installed WooCommerce and used its much saner API to import all the data I’d exported. This wasn’t a trivial task but it wasn’t too bad either. Any proper programmer would manage it without issue, I’d expect, but I couldn’t talk someone through it if the idea of an API scares them.

Once the data was imported I sorted out all the CSS stuff for the site. There’s still a few things I’d like to tweak but with any luck I’ve covered all the major areas.

When it comes to the look of the site I do want to get a bucket load more images to convey what we’re selling. I do my best but there’s only so many hours in the day and having things professionally painted and photographed would mean that some of the weirdly specific stuff we sell would be much less commercially viable. Still, I’m getting better at this whole painting malarky!

I don’t want to make it seem like the transition to WooCommerce was without issues though – it wasn’t. It might have been if I’d changed to a different theme but I’m rather attached to the one we have. Making it work with WooCommerce was fairly easy (I had to add a declaration to the theme’s functions.php file to get some of the more advanced WooCommerce features working).

However there was one rather major flaw – for whatever reason the way the products were queried was buggy. By “queried” I mean anyway one requests products from the database – if you’re doing a search for something specific, looking for all products with the tag “Goblin”, or something like that. Hidden products weren’t properly hidden.

On the plus side they wouldn’t be shown to customers so that limits aggravation somewhat but, well, let me explain. Normally the process would go something like this:

*website finds all the posts of the type “product” which also have the product category “Fox Box Goblins” and puts them in a list*

*website splits the list into groups of 30*

*website removes results that are marked “private”*

*website checks the stock levels and removes results that are out of stock*

This resulted in a page of 30 products showing only 21 results on the first page, 16 on the second, and 30 on the third!

In one case it even resulted in the first page being completely empty!

As per usual I solved this myself after a lot of frustrated hours. However it should now stay solved and that’s the important thing. As I said before – I shouldn’t have to worry about the website breaking. I should be worrying about promoting our products, making new ones, and generally doing businessy things.