Continuous Integrations (CI) is something that is pretty essential in WordPress theme and plugin development workflow, especially when building the theme out from a build system rather than in browser using a page builder.

I've recently been using Buddy (https://buddy.works) on a project and have also recently played around with AWS Code Pipeline. I really liked Buddy but when I take into account I'd need the Unlimited plan to maintain all of my clients themes and plugins, and after the initial build each project would only get used a couple of times a month I couldn't justify the cost. AWS Code Pipeline/Code Deploy (https://aws.amazon.com/codepipeline/)was great but a PITA to configure and after spending a few hours reading the docs and getting a system set up to work with my build system, I felt my time could be best spent somewhere else. I will however revisit it at some point in the future. I also don't really need to run the build on a remote system as I'm generally doing all of the code for a project solo, so a lot of these other systems are simply overkill for what I need.

Sometimes the simple solution is the best, and hopefully it helps someone out to see what I've come up with.

Before I go on I'll just outline my requirements, I'm sure it is the same for many WordPress developers.

  • I'm using a build process that compiles to a dist directory.
  • I have a git repo for the entire build and then another repo for the compiled project.
  • Throughout the build process it might deploy many times per day but after the build it will only deploy a couple of times a month for maintenance/feature updates etc.
  • I need a way of rolling out updates that is client friendly and done the way they are used to with other themes and plugins in the case that they do their own site management.
  • I'll also note that I'm generally the only one working on the code side of the project, so I'm not taking into account the needs of teams.

GitHub Updater

If you haven't checked out GitHub Updater, go and do it now. https://github.com/afragen/github-updater

It allows you update WordPress themes and plugins hosted on GitHub using the native WordPress updater. Even private repos. I've been using this for a while now as a way of distributing my themes and plugins to clients.

I won't go into too much detail on GitHub updater, but it is really easy to use and there is some great documentation on the repo. If you're building WordPress themes or plugins you'll definitely find many ways it can make your life easier.

Other Requirements

  • You'll need WP CLI on the server
  • You'll also need SSH access to the server
  • You'll also need node js and npm, but chances are if you're building plugins and themes from scratch you'll have that already.
  • I'll also assume you are running a build process that compiles to a dist directory.
  • You've got your dist directory hooked up to GitHub or similar.

The Process

The process is actually pretty simple which is the whole idea. This is what we need to do.

  1. Copy the dist folder to the directory housing the distribution repo.
  2. Add/Commit/Push the distribution repo to GitHub
  3. Run WPCLI via SSH on the staging or production server to clear the GitHub Updater Cache and update the theme.

Putting it together

Once you've got GitHub updater set up properly check you have the GitHub Theme URI tag and the version in the themes style.css. GitHub updater checks the theme version to determine whether it should pull an update or not. Also make sure you leave off the .git extension for the theme URI. Your style.css will look something like :

/*
Theme Name: My Aweome Theme
Author: Me
Author URI: https://mysite
Description: My Custom Theme
Version: 1.2.3
Text Domain: mytextdomain
GitHub Theme URI: cmbibby/my-theme
*/

Then we'll create a bash script to run our commands. I've just called this script deploy.sh

#!/usr/bin/env bash
echo "=== Starting Deploy ==="
cp -R dist/* ~/my-theme-dist
cd ~/my-theme-dist
git add -A
git commit -m update
git push
echo "=== Finished Deploy Executing Remote Update ==="
ssh me@myservername.com "cd /var/www/websiteaddress/htdocs && wp github-updater cache delete && wp theme update my-theme-name"
echo "== Finished Remote Update =="

If you don't want to clear the GitHub updater cache you can leave that out and just enable automatic updates on the theme in WordPress or manage it through MainWP/ManageWP if you use that. However for staging you won't want to wait 12 hours for it to check for updates.

Next you just need to make deploy.sh executable (chmod +x)

Then create a NPM command to run your build and then the deploy script, which is as simple as adding the following deploy command in your package.json

"scripts": {
    "deploy" : "gulp compile && ./deploy.sh"
  },

You can see here my deploy is running my gulp compile task and then running the deploy script.

Simple. easy, does the job and most of all uncomplicated with not too many moving parts!

Something I get asked a fair bit by customers with existing WordPress sites is “How many plugins are too many?”. 

Well it depends.

Firstly let’s just have a quick look at what a WordPress plugin actually does. It is essentially some software that extends the core functionality of WordPress to do something that it doesn’t do out of the box. They’re pretty much apps for your website. 

One of the reasons WordPress is so popular is because it is so extensible through plugins. 

If you need a certain feature, well there’s a plugin for that!

It sounds great, and it can be, however plugins carry a certain amount of risk that needs to be understood and managed.

Every plugin that you add is something that can break (now or in the future), it is something that is written by someone other than the core WordPress team (so could potentially do something nasty), and it also may not play nicely with other plugins that you already have installed.

So you can end up with situations where your site ends up getting hacked, runs super slow, you get weird errors or it doesn’t work at all.

The general rule of thumb is to only use what you really need and be aware of developers that aren’t really developers that get around their lack of knowledge by cobbling together a solution by using a bunch of plugins. A tell tale sign of a shonky site is one that has many different plugins from many different authors other than the developer that do very simple things like add sliders, galleries etc. 

You can’t really say all plugins are bad and put a number figure on the max limit. Plugins are a great way for developers to isolate functionality. Often if I’m adding a feature to a site, I will code it into a plugin so I can maintain it separately from the rest of the site.

E-Commerce sites in particular often need quite a few extra plugins for things like payment gateways, shipment tracking, accounting systems integration and stuff that is unique to the site (not everyone uses Xero and ships via Australia Post for example). So you’ll find more plugins on an e-commerce site than you would on a “brochure” style website.

So the bottom line is it is really about quality over quantity. 

Have a look at who has written the plugin you are thinking of using. If it is a free plugin from the WordPress repository, have a look at their support forum and see if people are reporting any issues with it. How do they respond to issues? Are they on the ball, or do they take ages to reply?

Have a look at when the plugin was last updated, if it has been updated recently then that tells you that it is actively maintained and less likely to be problematic.

Keep in mind that just because a plugin is in the WordPress repository doesn’t necessarily mean that it is endorsed by WordPress or that it has been extensively checked and guaranteed not to cause issues.

If it is an e-commerce plugin, who’s selling it? Do they have reviews or a Facebook page you can check out? Do they offer a money back guarantee?

If you’re not sure whether a plugin is right for the job, or you’re worried your site is having issues because of plugins that you’re using. Ask a pro to take a look for you.

The payment gateway is probably the most integral part of your e-commerce solution. It’s how you get paid.

These days there are a bunch of offerings out there and trying to figure out which one is best for you can be a bit of a challenge.

Types of payment gateways

Payment gateways can be broadly categorised into two types. Classic Gateways and Modern Gateways.

Classic Gateways

Classic gateways require you to have a merchant account with your bank, and some kind of integration on your website that connects with the banks merchant system.

These gateways can have quicker clearing times, and sometimes lower fees, but can also be harder to set up and maintain. They also require additional steps and responsibility in regards to data compliance and security (go google PCIDSS compliance, it is boring but important).

Modern Gateways

In response to the pain of classic gateways a bunch of modern gateways have popped up. You may have heard of Stripe and of course you have heard of PayPal.

These solutions tend to be more popular with your customers as it can make it easier for them to pay.

Some also offer some kind of buyer protection and dispute resolution.

They also act as a clearing house, meaning that they clear the payments from your customers and pay out into your nominated bank account, so you don’t need a merchant account with your bank.

Generally speaking they’ll have higher fees, but the plus side is they are easier to set up and maintain, especially when it comes to to managing the data compliance and security side of things.

Considerations

Here are some things to consider when deciding on a Payment Gateway.

What do customers want?

You need to make it easy for people to pay, this is even more important if you sell things that people can easily get somewhere else. If you make it too hard for people to pay they will bail.

Look for a gateway that has a great user experience, preferably in context processng rather than sending customers off to another site to complete the payment.

If you are selling popular consumer products you really want to offer something that people are familiar with. ie. In Australia PayPal really must be an option.

Ongoing costs

Getting paid can be expensive and some providers have some pretty complex fee structures, usually revolving around a monthly fee, a transaction fee, a percentage of sale (either fixed or a sliding scale) or a combination of all the above.

None of the options are a one size fits all solution, you need to consider the margins in the products you are selling and the type of product you are selling.

For instance if you are selling a high ticket, low margin exclusive product, it may be more beneficial to spend the extra money on setting up a classic gateway directly with your banks merchant system to take advantage of the lower transaction fees.

Recurring Payments?

Are you offering subscription style services? Does your payment gateway allow for this and how will it integrate with your e-commerce software.

In Context or Offsite

Some gateways will send you off to the payment processors website to complete payment and others will process the payment on your site, known as in context.

In context payment processing provides a smoother checkout experience reduces the rate of checkout abandonment.

There’s no point having a highly optimised distraction free, easy to use checkout process only to ship the customer off to some clunky payment processor to take their money. They will bail.

You’ve got options

Whilst choosing a payment gateway can be a bit of a process, most good e-commerce platforms allow you to have more than one payment gateway and more than one payment method, so you can always try out different options and also give your customers options to choose methods that suit them the best.

This post is based on content from my 6 Week E-commerce Bootcamp, a done-with-you program consisting of professional e-commerce development, training and consulting to ensure both you and your business are set to succeed selling online.

Spots are available for early 2020. Get in touch below to register your interest.

This morning I was sitting in the waiting area waiting to get some blood taken for a routine old bastard test. All of a sudden my phone started going off with SMS messages advising me multiple web servers and sites were down. Crap!

A quick check at the network status of the upstream provider confirmed there were some network issues, so I started notifying clients and began to prepare to execute their failover plans to keep everything on the air.

Luckily service was restored within about 30mins and by the time I got to my desk everything was back to normal. Phew

However it reminded me of a hard lesson I learnt about five years ago when working at a company whose primary source of income was online sales from three different websites.

It was early December, and the company’s websites went down. All three revenue streams, down.

Initially we weren’t too stressed, thought it would just be a temporary glitch. After all we had outsourced the web hosting to a reputable company and were paying a pretty penny to do so.

However after numerous support requests and phone calls, it ended up dragging on for twelve days. The hosting company eventually stopped answering phone calls, their own website and email services were offline and attempts to get in touch with them failed. Not soo good.

Eventually service was restored just in time to salvage some sales, but we were way down on target, only just broke even, and went into the notoriously quiet start of the new year without the buffer that a good December usually provides. Anyone that relies on retail sales for a living will tell you the pre christmas period is where a good portion of the years sales are made. Jan and Feb can be quiet months as peoples credit card bills start rolling in and they get settled back into the real world.

The lesson learnt was quite a simple one really, Don’t put all your eggs in one basket.

This lesson led me to schooling up on cloud computing and studying for the AWS Solutions Architect certification from Amazon Web Services. Back in those days cloud computing was still kind of new and not really accessible to small to medium sized businesses.

Where were all the eggs?

Let’s just back up a bit for those that may not be too techy and have a look a the things that go together that make a web site work.

At its basic level for an online presence you need.

  1. DNS. Like the internets telephone directory, you need an entry on a server that tells people looking for www.yourawesome.site.com.au that it lives at IP address 45.22.222.22
  2. The Web Server. To store and serve up your web site.
  3. An Email Server. Because you want email, right?

Old school web hosts and even many still about today host all of these services on a single point of failure. An outage will typically affect your entire web presence.

Why is this particularly bad?

Where things can go really pear shaped is that often your backups will be stored on the web server, so unless you have downloaded your recent backups on a daily basis and kept them somewhere on your own computer you don’t have access to them.

Chances are you don’t have a local copy of your backups, because right next to the part telling you that the web hosting provies 99.9% uptime there was a part that said Backups included.

Backups are useless unless you have access to them.

The other thing that is also a right pest is that if you can’t get at the DNS records, moving the site becomes a much harder task. Not to mention the fact that redelegating a domain usually means having access to your email, which you don’t have because that was bundled into your hosting as well.

So things can go to shite pretty quickly.

Mitigating the risk

So let’s have a look how we can make sure we don’t end up in a pickle when things go bad.

The first thing you need to figure out is how much downtime can you afford? Hours, Days, Weeks? At what point does an outage really start costing you money?

Of course the answer will determine your monthly spend, so be realistic. Think of it like insurance. The more coverage you want, the higher the premium.

Moderate availability 24-36 hours

This is what I recommend as an absolute bare minimum. It is the most cost effective and the easiest to set up.

In a nutshell it revolves around isolating each of the moving parts and having a seperate accessible place to put your backups.

So let’s look at a common solution.

1. Use a service that specialises in managing DNS.

are some that come to mind.

2. Use a VPS for your web hosting

VPS stands for Virtual Private Server and is the mainstay of cloud based computing.

Basically it allows us to have our own mini server in the cloud, plus spin up more very quickly if we need to.

Once the realm of the linux nerd, it is easier these days to host your site on a VPS thanks to managed services like :

3. Have a place in the cloud for your backups

Make sure your web server backs up to a place that is not itself. Cloud based storage solutions are extremely reliable these days, safer than storing a backup on your own computer and likely safer than storing it in a bank vault.

Options here include :

4. Use a dedicated email provider

Much more common these days than it used to be, but people still get suckered into the all in one packages.

Keep your email separate.

Services like

  • Gmail (Gsuite so you can have @yourdomain)
  • Amazon Work Mail
  • MXRoute for a more budget friendly option.

The failover plan

In this set up the thing that is most likely to fail is the web server. The dedicated provider you'll for your other services have their own redundancy in place.

When did you last see Google go offline? Or Amazon for that matter?

So let’s say we have a failure at the web server level that can’t be fixed easily, it is getting towards our maximum window of pain, what do we do?

  1. Spin up a new VPS maybe with another cloud provider.
  2. Restore the website from your cloud backup
  3. Change the DNS record to point to the address of the new VPS.

That’s it, you’re back online.

High Availability

I was going to discuss some high availability architecture but it is probably outside the scope of this blog post, and I could end up going on for hours talking about stuff nobody is particularly interested in. Especially not site owners as they just want their stuff to work.

Let’s just say that if you want higher availability in the event of a service failure, or even during periods of high load (you are running a big promotion, or a blog post goes viral) there are ways to set it up.

Productising Services

I was having a chat the other day with a good mate of mine, he’s a sparky. He was telling me how he was spending so much time on the phone answering the same questions over and over again, so much so that it is cutting into his time available to actually do paid work. His thinking was he needed to put someone on just to handle the phone and appointments. Sound familiar?

This kind of situation is pretty common, and the reason it happens is because service businesses actually invite their customers to interact with them this way. They might have a basic website with a phone number as the call to action, a facebook page with the phone number as the call to action and if they have their crap together maybe even a google business page, again with the phone number being the main call to action.

So which ever way the customer comes accross the business it all leads to the phone call.

The next issue of customers asking the same thing over and over again, is because customers want to know a price, when it can be done and then to arrange the booking.

This whole process can be streamlined and integrated into an eCommerce solution that will free up your time, keep your customers happy, likely get you more customers and also get you paid quicker.

Thinking of services as products

Instead of thinking of trade services as jobs and projects, think of them as products, and especially in terms of the customer experience.

Traditional tradie pricing models usually go along the line of a callout fee plus the first x amount of time in labor, plus parts to arrive at a “should be round about this price mate” price, that is 99% of the time the same for the same type of job in the same area. eg a new powerpoint 20k’s from Timbucktoo costs $200 if they want to do two powerpoints whilst you’re already there the cost is $300.

A different approach more in tune to great customer experiences would be to offer power point installation as a product with a quantity break. Eg. Power Points installed from $200, the customer then enters the number of power points they want, a price is calculated, choose an availability time and pay for it just like they would a new pair of shoes from eBay.

Presenting your product as a service this way you have solved the following problems for the customer :

  • They know how much it is going to cost
  • They know when it can get done
  • They haven’t had to waste their time picking up the phone to call around

The problems it solves for the tradie are :

  • Less time spend on the phone answering the same questions
  • Money in the bank before the job is started
  • A customer that knows what they are going to get
  • A customer that is less likely to go elsewhere as you have answered all of their questions

But what about jobs that blow out or are a bit less straight forward

Of course you’re not always going to be able to productise every single service you offer. However that doesn’t stop you from selling the call out fee and the first block of time.

  • You get paid up front
  • You have captured the charge so adding additional hours when the job is complete is easy, and you know you’re going to get paid.
  • Your bookings are streamlined.

So even though the less straight forward jobs are likely to involve a phone call, you can always point them back to the booking system to do the rest.

Aarrrggh not another one you're thinking. The internet is full of these posts, and it is usually written by someone pushing their own barrow.

Well I kind of am too, as I develop for WooCommerce, however I certainly don't think WooCommerce is the right fit for everyone. Often when talking with potential clients, I'll even recommend their best bet is to use Shopify.

So rather than tell you about the differences in the platforms, and the pricing (there's a bunch of info on that elsewhere) I'm going to explain why I develop for WooCommerce from a developers point of view.

The simple answer ; clients come to me wanting me to build something for them around their business. To give my clients exactly what they want, I need a platform that is infinitely flexible and customisable. I'd be offering my clients no value at all if my default solution was to just shoe horn their business and business model into a rigid system.

So it is all about flexibility and customisability

I've got control over all aspects of SEO and being based on WordPress a good content marketing is really easy to achieve and make work effectively.

I've also got flexibility when it comes to choosing the right payment gateway that suits the clients needs. Shopify can get a bit expensive and restrictive there, especially if customers have high value, low margin products the fees can really take a good bite out of the bottom line.

Performance, backups, and reliability are also in my court. With the right technology stack I can get a WooCommerce site super fast and reliable, plus making offsite backups and exporting order data and customer data is trivial.

Not to mention I can also make the site look the way that works best for the client and the clients customers.

And then there's different types of e-commerce. It's not all about selling t-shirts and hats, WooCommerce allows me to offer solutions for bookings, deposits, subscriptions, software downloads & licensing and many more.

If it revolves around facilitating a transaction between two parties using the internet, chances are we can build it with WooCommerce.

Services

Info

Menu

Connect