- The inability to link a product to a picture upon upload (even though the import format says it’s supported).
- The inability to update products by running the import again with changed values for a product (it is unclear whether this is supported at all).
Because of these limitations, the inability to find a solution to them in a timely manner, and the need to get my client’s website up and running, we decided to make a change of hosting platform. With help from a friend, we’ve switched over to using using WordPress and WooCommerce hosted on SiteGround. Thanks to my friend dealing with a lot of the hosting and WordPress setup, I’ve been free to continue to deal with getting the product list uploaded to the site in a way that can be automated as much as possible and guide my client’s users to the products they need easily and quickly.
Why did we choose WordPress + WooCommerce?
There are two main reasons that we decided to use WordPress and WooCommerce:
It solves our problems with GoCentral
It was immediately clear from the documentation for the importer that the two problems I was having with GoCentral would be solved easily. By this I mean that they wouldn’t be a problem at all because they’re called out as supported in the documentation with examples of how to go about making them happen.
- Tying images to a product is as easy as uploading the images to the media library already included in WordPress and then using the name of the picture for the product in the images column of the CSV. This is MUCH easier than finding somewhere to host the pictures and trying to get a URL to it.
- As the documentation for the importer mentions, updating products that already exist in the system is possible via upload by clicking the “Update existing products” checkbox on the first screen of the importer. There are some rules for how the importer matches products and a limitation that new and updated products shouldn’t be included in the same upload. These, however, are things that can be worked around with good preparation.
I was able to confirm that these worked by installing Varying Vagrant Vagrants (VVV) on my computer, firing up a WordPress instance, and trying them out. This brings me to another point that makes my inner developer happy. Using VVV I can run an instance of WordPress locally to try things out without having my changes visible to the public on a live website. That can’t be accomplished, to my knowledge, with GoCentral.
They are low cost options
Given that my client is starting their business I want to be as cost conscious as possible. WordPress and WooCommerce are both open source projects and are, themselves, free. The only thing that we’ve paid for so far is for hosting on SiteGround which, for the small plans, isn’t that expensive monthly. There certainly are plugins for both WordPress and WooCommerce that cost money but, so far, we haven’t needed anything more than what is included out of the box.
What problems have we had to solve with WordPress and Woocommerce?
Sidenote on my experience
The process of loading my client’s products into this website has been an incredible learning experience for me. I’ve been a software engineer for many years now but all the companies I’ve worked for have had a single product I’ve worked on. Some of these products have had a fair number of components (one company in the 30 – 60 component range that I’ve had to care about at any one time) but they all worked together as one system. As far as data is concerned, none of the companies have had huge amounts of data to care about at any one time even if they have lots of data overall.
This experience, however, did not adequately prepare me for having to deal with the sheer number of products that distributors have to deal with. In the case of my client the manufacturer we’re dealing with has a product list that has on the order of 2,400 products. And that’s just the first manufacturer we’re likely to deal with and only part of their product list.
Sidenote on starting the process of importing products
When figuring out how to import the long list of products, I simply googled for “woocommerce import products.” This quickly led me to this page describing the process of importing products. Within the first screen full of information there was a link to a sample CSV file and the column header reference. Naturally, to my mind anyway, the first thing I did was to downloaded the sample CSV then copy and paste the column headers into a new sheet on my product list spreadsheet so that I could start mapping fields. Then, because I’m used to reading the documentation for how to do things like this, I opened the column header reference to, well, reference when I wasn’t sure what a column was supposed to contain.
I will note here that the headers from the sample CSV file don’t match up 100% with the headers described by the reference. If somebody from WooCommerce reads this, please take some time to update the documentation. If the documentation is open source there’s a possibility I could get around to helping eventually but I’m sure it could be handled better by somebody with more experience with WooCommerce than myself.
Automatically creating drop downs for products with sizes
The first problem I had to deal with is setting up products that need a drop down to select things like size and make sure that the sizes appropriately match to the correct SKU when added to the cart. Now setting up an individual set of products through the web interface of WooCommerce is no big deal. But, since we’re dealing with so many products, many of which map to different sizes of a single product, I don’t want my client or myself to have to set those up individually through the web interface. It was at this point that I ran into the first issue I wasn’t able to figure out easily. Aside: This tells you that many of things you think would be easy with WooCommerce actually are easy because it took something a little more complicated like this to trip me up.
The way to solve this is what WooCommerce calls variable products and variations. I will note that this is another place that the documentation is not quite up to date. Reading the documentation linked above I was able to figure out that variations were what I needed to setup to have WooCommerce automatically create the dropdowns for me. But, after doing some reading and experimenting with my products to import I didn’t have any success.
The next thing that I did was to go back to the sample CSV file and actually look at the sample products in it. Sure enough, there are variations included in the sample data. Hooray! Taking a look at these products I was able to see what I needed to do:
- There needs to be a parent product to control what the user sees for the product. This is not one of the SKUs that we’re selling. It is the generic product information. Its product type will be variable and its attribute columns will contain the name of the dropdown (Attribute Name column) and what appears in the drop down (Attribute Value(s) column, comma separated).
- The lines representing the SKUs you’re selling are separate lines. They need to be of type variation, contain the name or SKU of the parent product in the parent column, and provide the item in the dropdown that it maps to in the attribute value(s) column (with, of course, the same attribute name as dropdown you expect the value to be in).
Once I saw how the sample CSV file did this, this is how I felt because it was so clear and easy:
Problems with categories
After speaking with my client about how they want users to navigate their site, we decided to use categories to drive navigation from general product types through progressively more specific product types until it makes sense for a category to have products in it. Based on the sample CSV and the column header reference I was aware that placing multiple categories in the category column of a single product separated by the ‘>’ character would cause the importer to place the product inside the last category listed and nest the rest of the categories in order.
After setting up a few products in this way, I imported them and looked at the products in the product editor. Sure enough the categories showed up nested under each other and the only category to actually contain the products was the last category! HOWEVER (you knew this was coming right?), I ran into a snag when viewing the site as a user would.
Changing how WooCommerce displays categories
First, the categories displayed on the front page included both the top level category and the subcategories that I’d uploaded. This goes against the way that we’d like to guide our users to the products they need. Because I’d already confirmed that the categories were being set correctly, I started taking a look at the WooCommerce settings to see if there was anything that could change how the categories are displayed.
The setting I found that fixed the problem is found by going to the WordPress admin page and:
- Hovering over Appearance and selecting the “Customize” option.
- In the customization page, click on Woocommerce
- Click on Product Catalog
- From the Category Display dropdown select “Show Subcategories”
Selecting “Show Subcategories” has the effect of forcing the user to click through the subcategories before they finally got to the last category down a particular branch of the category tree. At that point, the products within that last category will be shown. This is what we want to do.
It does, however, have a side effect that may not be desirable for some users. If there are products in any of the subcategories before you get to the last one they won’t be shown. This forces us to organize all of our products in the last categories of a branch. This is ok for us but simply requires some advance planning.
At the end of the process of figuring out how to import the products in a way that satisfies my client’s desires I find that I really like WordPress and WooCommerce. Yes, it took me a while to figure out creating variable / variation products and how to change the display of the categories. However I always felt like there should be a way to do it and, sure enough, there were solutions that weren’t too hard to find. This contrasts with the frustration I felt searching for how to do things with GoCentral. As I said in my post about GoCentral, I think that it would be great for a small shop with a limited number of products but, for something like a distributorship, something like WordPress and WooCommerce will likely work a lot better.
The last note that I’ll leave on the subject is that, because I liked this combination of tools so much, I’m considering using WordPress to create a site for myself. I may also migrate my blog there since it’s able to handle both a website and a blog. Keep tuned for more on this!