The importance of WordPress website optimisation with Justin Frydman

Website optimisation

Build it. Theme it. Watch it fail. Or not. If you know how to optimize.

Few things are as frustrating as a website slower than molasses going uphill.  Even fewer people stick around to see whether the website was worth waiting for in the first place. There are plenty of other websites in the great online sea and if yours is slow visitors will just go somewhere else.

Website optimisation is the key to online success. It really is. So, to pin it down and get clarity around the issues that influence it, I spoke to Justin Frydman. Justin is a full stack web developer, systems administrator and (in his words) ‘passionate problem solver’ and since I joined Codeable he’s become one of my go to guys with regards to website optimisation. Justin and I had a chat about the how, the why and the what of website optimisation…

JB: Why is website optimisation so important?

JF: The short answer is that people hate slow websites. It doesn’t matter if you’re selling a product, trying to increase reader conversion or gain leads that result in sales. A slow website is going to impact your goals significantly.

There are a lot of studies that prove this point but one of the most popular is how Google found that a .5 second loading variable cost them a 20% dip in traffic. While your business may not match the sales of a giant like Google, removing roadblocks to potential sales makes sense. Right?

Considering how many people use their mobile devices to shop online it is even more important to focus on web optimisation now than ever before. Any slowness on your site is magnified on mobile. These devices have slower hardware and connectivity and will load far more slowly than the desktop.

JB: What are the top three worst and best WordPress themes in terms of performance (themes or plugins that affect site performance)?

JF: It’s the themes that try to ‘have it all’ that tend to suffer from performance degradation. The more that a theme does in each page load, the harder the server has to work to serve up your page. There are ways you can hide these shortcomings from your visitors such as using caching methods or other techniques but you did ask for a list. Here it is…

The worst three themes:

  1. Avada
  2. Divi
  3. Flatsome

The best three themes:

  1. Custom built and tailored to your needs. This way you don’t have more or less than YOU need.
  2. Many of the themes built on the Genesis Framework
  3. The Beaver Builder theme for a visual builder

JB: What are the factors that influence website optimisation?

JF: There are numerous factors that can affect your website’s performance. It’s about ensuring that each of them is as good as possible so they add up to having a truly fast loading website.

01: Host

You must have a good host with a good stack (server software) that is properly configured to serve WordPress as fast as possible. A great host doesn’t have to cost a fortune but if you’re spending less than a cup of coffee a month on your host, well, you’re probably getting what you pay for. It’s also important to ensure your server is as close as possible to your target market. The closer it is to your visitors, the faster your website will be.

02: Plugins

Every plugin you add to your website has the potential to slow it down. Not all WordPress plugins are created equal. Many are developed without performance in mind. So, a single plugin could perform a taxing database query that adds seconds to your page loading.

If you have too many plugins it will complicate the technical debt and debugging of your site. This will make it harder to track down any problem plugins. Some can add bloat to your database as time goes by so the slowing down of your site won’t show until your database queries take seconds instead of milliseconds. Ensure you have a staging website and thoroughly test and vet every new plugin before you use it.

03: Themes

Themes that include a lot of JavaScript can visually slow things down on the front-end of your website. Some CPU intensive JavaScript can really slow older computers to a crawl. Depending on when that JavaScript is loaded, it can even render block your website.

Themes that make heavy use of animations can look slow to the visitor even if they aren’t. It’s also worth noting that the heavier themes need a lot more time to process a page before it can even be rendered. The longer it takes to process a page, the longer things are loading before the website is visually drawn in the browser.

04: Images

Using images that haven’t been optimised (and using many of them) increases loading times. Images can be compressed, saving up to 80% in file size without compromising on quality. The less the browser has to download, the faster your website. Sliders with 10 images or large background images can increase page size significantly. So, to optimise your website, consider each image’s purpose on the page and ensure the dimension and file sizes are appropriate.

05: Videos

Fully loading videos will destroy your website metrics and often cause a laggy experience. Use videos sparingly and make decisions based on the data you collect. If a video really is converting sales, then it is probably worth keeping.

06: Adverts

While ads are often needed to help you make a living, they can really slow things down. Even once they are fully loaded they can slow scrolling and the functionality of the website, especially on slower devices.

07: CDN

A Content Delivery Network (CDN) can help in serving your static assets (images, JavaScript and CSS) to your visitors at speed. Often this lightens the load on your server as well.

JB: How can you test your website’s performance?

JF: There are a number of online tools to help you with website optimisation and performance. That said, the grades don’t always align with a faster website. If you are shooting for straight As that doesn’t actually mean you will end up with a visually faster loading website.

The Page Load Time Google Chrome Extension is an interesting tool but it tracks fully loaded time, including JavaScript that is running after your website has rendered. In my opinion, the goal is to show your visitor your website as quickly as possible. If things are going on in the background that aren’t affecting user experiences then they are not a priority.

Here are some steps you can take to website optimisation:

Step 01: Your browser

Really use your website, logged in and logged out. Does it feel fast? Is the initial load pretty fast? What about clicking on additional pages? How about the WordPress dashboard?

Human testing goes a long way towards website optimisation as it is humans who use your site.

Step 02: Pingdom 

Not all items in the Performance Grade can or should be fixed. It’s important to understand this report in detail but what should matter to you the most are: Load Time, Page Size and Requests. The ultimate goal is to get these as low as possible. Increasing the grades is a bonus and only IF they don’t affect the ultimate metric – Load Time – negatively.

I’ve seen websites taken from a C to an A but at the cost of 400ms. It’s just not worth adding that extra loading time to increase a score.

Step 03: Gtmetrix

The recommendations here must be properly analysed by an expert GTmetrix tracks Fully Loaded Time. This considers the background scripts running – if they are running after the page is visually drawn in the browser that’s not a big deal, however, if your page is waiting for them to load before it shows your site then you have a problem. Ideally, you want to get Fully Loaded Time, Total Page Size and Requests as low as possible. This may involve removing items you don’t need on your site.

Step 04: Google PageSpeed Tools Insights

Until recently, this test didn’t even show your actual website speed and still doesn’t for many websites. What this does is make suggestions around how you can improve your speed. Keep in mind that these are suggestions and may not result in lowering the key speed metrics mentioned earlier. Some of these suggestions can be complex and expensive to solve and the payoff may not be worth the effort. Google has a FAQ that explains a lot of these elements in more detail.

Want to get your hands on Justin? Need a bit more website optimisation expertise?

Click here, hire Justin, and fix your problems…

Setting up the PHP Code Sniffer with WordPress Coding Standards Integration for PHPStorm on Ubuntu 18.04

(aka the longest blog title I’ve probably ever written).

Recently I reinstalled upgraded my laptop to Ubuntu 17.10 (Artful Aardvark) Ubuntu 18.04 Bionic Beaver. I’ve been wanting to upgrade since it was released in October to try out the updated Gnome interface since Ubuntu officially dropped the Unity interface for the latest release. Usually I stick with the LTS releases but the draw to try out the new, shiny thing was too much.  I prefer running on the latest stable LTS release so as soon as 18.04 came up I upgraded. 17.10 was a solid release and I enjoyed working on the Gnome shell again, so it was a no brainier when the LTS came out.

As I have adopted PHPStorm as my development IDE this meant I had to set up the PHP Code Sniffer and WordPress Coding Standards integration again. I remember this being a bit of a pain when I did it on my 16.04 install.

The Jetbrains documentation about WordPress Development using PhpStorm (specifically the section on  the coding standards) was written back in 2015 and the issues I had were mainly due to different paths for newer PHP/PEAR versions, so I thought I would document the updated process here.

Step 1) Install PHP Code Sniffer via the PEAR package

sudo pear install PHP_CodeSniffer

I could probably have done this using either the PEAR package or by using the Composer package but I found that the Jetbrains document refers to the location of the Code Sniffer sniffs using the PEAR method and I already had PEAR installed, so it was easier for me to use this method. At some later stage I might try the Composer method.

Step 2) Determine the location of the PHP Code Sniffer Standards

In Ubuntu 17.10 18.04 with a default PHP 7.1 install the Standards are located in the following path:

/usr/share/php/PHP/CodeSniffer/src/Standards

Step 3) Clone the WordPress Coding Standards GitHub repository

In this case I simply cloned this repository to the root of my home directory.

git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git

Step 4) Copy the relevant Coding Standard to the PHP Code Sniffer Standards location determined at Step 2

I copy all the available WordPress Coding Standards, and merely enable WordPress-Extra for my projects. I am thinking about enabling WordPress-VIP for some extra fun, but I’m not sure I’m brave enough to be shouted at by my IDE…

cd ~/WordPress-Coding-Standards
sudo cp -r WordPress /usr/share/php/PHP/CodeSniffer/src/Standards/ 
sudo cp -r WordPress-Core /usr/share/php/PHP/CodeSniffer/src/Standards/ 
sudo cp -r WordPress-Docs /usr/share/php/PHP/CodeSniffer/src/Standards/ 
sudo cp -r WordPress-Extra /usr/share/php/PHP/CodeSniffer/src/Standards/ 
sudo cp -r WordPress-VIP /usr/share/php/PHP/CodeSniffer/src/Standards/

As of 2.0.0-RC1, the WordPress VIP standards have been deprecated.

I also realised recently I could merely create symlinks, thereby automatically updating the Coding Standards every time I pull the latest release from GitHub

cd /usr/share/php/PHP/CodeSniffer/src/Standards/
sudo ln -s /home/jonathan/WordPress-Coding-Standards/WordPress WordPress
sudo ln -s /home/jonathan/WordPress-Coding-Standards/WordPress WordPress-Core
sudo ln -s /home/jonathan/WordPress-Coding-Standards/WordPress WordPress-Docs
sudo ln -s /home/jonathan/WordPress-Coding-Standards/WordPress WordPress-Extra

Step 5) Enable PHP Code Sniffer with WordPress Coding Standards in PHPStorm

First step is to enable PHP Code Sniffer in PHPStorm. To do so you’ll need to know where phpcs is installed. Run the following from your command line to find out.

which phpcs

Mine is located at /usr/bin/phpcs.

In PHPStorm, go to your Settings screen (File->Settings or CTRL+ALT+S) and navigate to Languages and Frameworks -> PHP -> Code Sniffer. Next to the Local Configuration click the browse button and enter the path to phpcs in the PHP Code Sniffer (phpcs) path field. Hit Validate to make sure PHPStorm can find it, then click Ok.

Next you will need to enable the WordPress Coding Standards. Back to the Settings screen navigate to Editor -> Inspections, scroll down to PHP and open the tree. Then scroll down to PHP Code Sniffer Validation and tick the box next to it. In the box that appears to the right when you select PHP Code Sniffer Validation hit the little refresh button and then choose your WordPress Coding Standard of preference and click Ok.

Remember to do this last bit for each new (or existing) WordPress project as you can have different Code Sniffer rules set for each project type (for example if you’re working on any non WordPress projects, like Laravel).

Upgrading the Psyrig

Upgrading the Psyrig

About 8 years ago I built my first “proper” gaming computer, which for various reasons I nicknamed Psyrig. It wasn’t the first gaming computer that I owned, but it was the first time I carefully selected all the components, including the case, and put it together myself from the ground up. It was built to serve two purposes, both as a development workstation and a gaming rig. 

In the years that have followed I upgraded the cooling fan, added a 128GB SSD to improve boot times and eventually upgraded the graphics card to handle newer games. After 8 good years of service, it was time for a more drastic upgrade: new motherboard, processor, memory and graphics card!

Part 1 – the plan

I’ve been toying with the idea of upgrading the computer for a while now. Since purchasing my first development laptop about 5 years ago, the computer was relegated to powering our home media centre, and the odd game when I had time. However I find gaming in the lounge to be suited better towards consoles and games that play better with controllers, so having a gaming computer not connected to a keyboard and mouse never seemed logical. What seemed even less logical was letting the power of a  gaming computer run mostly as a media centre. So, after I purchased a 2nd hand workstation to take over media centre capabilities, the gaming computer was taken to my office and I started planning the upgrade.

The purpose of the upgrade was two fold.

First, I wanted to have a dedicated workstation at my office, on which I would maintain all my work. This would mean I would be less inclined to bring work home. Right now everything is on my laptop, which I bring home, and it’s too easy to just open it up and do some work. I also wanted to make sure that the upgrade would last me at least the next 5 years.

Second, I wanted to be able to play some of my newer game purchases on it. I recently purchased the latest Deus Ex game, and I’ve not had the time to get into it. So the idea was that whenever I took a break from work I could pop in a half hour of gaming instead of watching some YouTube video.

Part 2 – the parts

After much online shopping for probably the better part of the last year, I finally settled on another AMD powered set up. I’ve been an AMD fanboy since I got into serious PC gaming and my last two computers were AMD powered.

This time around I chose a AMD Ryzen 5 2600x with 6 cores and a core clock speed of 3.4 GHz. I partnered it with an MSI x470 gaming motherboard, 16GB of DDR4 RAM and a Zotac Geforce GTX 1060.

Part 3 – the OS

This was probably the trickiest part of this build.

I’ve been a Windows user, because gaming, for as long as I remember. However, I’ve been what I like to consider an Ubuntu power user since I discovered it in 2008. On my laptop, which came with a 128GB M.2 drive, I also installed a 500GB SSD, which runs Ubuntu and is my main OS of choice. I have Windows installed on the M.2 for when I feel like a game, or if Ubuntu isn’t playing nicely with some projector, which hasn’t happened since Ubuntu 17.10. I really like Ubuntu and all the unixy goodness when it comes to development. I also liked the fact that Valve recently started working on a project that will one day allow all my games to run smoothly on Ubuntu. That day is not however today.

Because I only have one SSD installed in the PC, it means either installing Windows now and then purchasing a new SSD later to dual boot, or installing Ubuntu and only playing the games that currently work on Linux. Granted the primary purpose of the computer is not gaming, so I doubt this will be a problem, but it’s also nice to have a Windows install for things that don’t work on Ubuntu (I’m looking at you Adobe Creative Suite).

I even went as far as asking folks on Twitter, and the resounding response was dual boot, which was going to be difficult at this time.

By the time I came to the actual build, I still didn’t know what to do.

Part 4 – the build

Pre build – look how neat everything looks.

When I’m building or upgrading a computer I like to open all the boxes and lay all the new parts out on the table around the case, along with any tools I might need. After 10 or more years of building, upgrading and fixing computers, I’ve learned to make sure everything I will need is close at hand. The one thing that is missing are the cable ties, but I knew where to find them when I needed them.

During the upgrade I was reminded why I decided to not go into computer hardware for a living. Having big hands and fingers makes it tricky to get into all the nooks and crannies of a computer casing to ensure mounting screws and the like are properly installed. 

About halfway through the process, things got a little interesting. While plugging in the various case cables (power switches, front side audio and the rest) I discovered that my new motherboard supported M.2 drives! This was quite a moment, because I realised that if I could take the M.2 drive out of my laptop, I could keep the laptop as an Ubuntu machine and effectively dual boot the computer.

Taking the M.2 drive out of the laptop proved to be easier than expected, once I realised that part of the bootloader was installed on the M.2 drive. I quickly created a bootable Ubuntu USB, booted live from the USB and installed the Boot Repair tool. This reinstalled the bootloader onto the Ubuntu installed SSD, and I could now safely remove and install the M.2 drive into the computer.

The build is complete.

The next things that happened absolutely shocked me. After plugging all the cables in I booted the computer, expecting it to give me some ‘non bootable disc error’ or similar. But no, it actually booted into the Windows 10 install on the M.2 drive and, after setting up some devices, I was actually able to use the computer. I was not aware that Windows 10 was able to do this and even though I intend to reinstall everything from scratch anyway, I was pretty impressed. Maybe Microsoft has come as far as everyone says they have.

And that was it, I’ve installed Windows on the SSD and Ubuntu on the M.2 and I’m happy dual booting on the computer. I was hoping to be able to Activate my Windows install using the Windows 10 key I had installed on the old system, but it turns out the free upgrade license I have doesn’t support a motherboard change. I found this a little annoying. I could go and buy a new Windows license, but seeing as I’m only going to use that drive for gaming, I may just leave it un-activated, it turns out that Microsoft doesn’t cripple un-activated installs like they used to

Now all that’s left is installing all the software…

Why I will be moving my private source code repositories away from GitHub

In case you’ve been living under a rock, it was announced on Monday that Microsoft as acquired GitHub for $7.5 billion. For various reasons, this has upset open source developers around the world.

Since then there has been a lot of discussion online about the pros and cons of this event. While I do feel that a lot of the complaints are probably coming from a vocal minority who are decidedly anti Microsoft (no doubt angrily typing their responses on Apple products, the irony) I also agree that this is perhaps not the best news for the open source movement in general.

Personally I will be moving my private (and possibly later public) git repositories over to GitLab and I thought it might be interesting to share my reasons why, if for no other reason than they were referred to as ‘a far sight more measured than most of the opinions about this that I’ve seen so far!‘. I feel like the world could use more measured opinions about popular or unpopular topics in general, so here goes:

  1. GitLab is open source, nuff said!
  2. While I don’t disagree that Microsoft has, under the leadership of it’s current CEO Staya Nadella, done a lot to prove that it now supports open source, something that the company was vehemently against in previous years, I feel it’s important to note that this change has only happened since Nadella took over as CEO 2014. This means that the company shift is directly as a result of the mindset of it’s CEO and that CEO will not be in place forever. The next leader of the company may not share Nadella’s love of open source.
  3. Personally, I don’t like the fact that any large company is in control of the world’s largest open source, code hosting platform. Did Microsoft really have to acquire GitHub to help it grow and improve? I would have been more impressed if Nadella had simply become a member of the GitHub board of directors and helped raise capital in order to support and grow GitHub, instead of outright buying it. Interestingly, this is a path that Matt Mullenweg took with GitLab about a year ago.
  4. GitLab has some cool features that GitHub doesn’t built right in, like Continuous Integration & Deployment on the free plan right up to Epics, Roadmaps and License Management on the top pricing tiers. They really seem to be building a seamless, integrated product for modern software developers and I want to support them in this cause.

I was already paying GitHub $7 a month to host my private repositories, so switching to GitLab’s $4 a month pricing plan will be a nice little saving each month. Not that I have to, as GitLab, like BitBucket, supports private repositories on the free tier.

And yes, I do know that if you were a GitLab user when a member of their staff managed to delete a database by accident you probably weren’t happy with them and moved on. I’m willing to give them a second chance.

 

Are you doing what you want to be doing?

The Journey

I knew today was going to be a hard day.

This morning I made the official announcement that one of my passion projects, a Gracie Jiu Jitsu club I opened in 2014, would be closing down. I sent out an email to all members and parents informing them of the news, and then made that post public. I knew I would be letting some folks down and that I would find it hard to do so. What I didn’t expect was how it would affect me personally.

As I read the article which was the inspiration for the opening quote of that post, I found the emotions become too much for me to handle. As I wrote the post it happened again and each time I’ve read it I find my self feeling sad. It’s been a struggle to focus on work or anything else other than a few small tasks I’ll complete today.

The upside is that each time I see the quote, mostly commenting on the associated Facebook post, I am less sad about the choice I made. I am less sad because it was the right choice to make for me and my personal situation. Often the right choices are the hardest.

So why blog about it here? Well I’ve often in the past blogged about what’s happening in my personal life, mainly as a form of catharsis but also as a way to share the news with anyone who cares. I’m not someone who lives his life in the public space, but from the 1st of May I’ll no longer attach the title ‘Gracie Jiu Jitsu instructor’ and some might wonder why.

Mostly it’s about sharing the news on a platform I manage where I can put it out on social media for folks to find out and avoid any future ‘are you still running your club’ questions.

But I’ve also realised it has something to do with choices we make in life and in business, how this has really helped me understand that the right move at the wrong time, is the wrong move, and how this effects the path we follow when it comes to work and personal life.

If you’re sitting on the fence about a hard decision in your life, be it in your personal or business life, I speak from experience that to keep doing something well after your interest or passion for it has waned, just because you don’t want to let others down, is going to end up eating away at your soul. If you find yourself hating something, often it’s better to figure out how to remove yourself from that situation than to worry about how others may perceive your so-called ‘failure’.

Being able to get up every morning and know that whatever is ahead of you for that day is what you WANT to be doing, not what you HAVE to be doing, is worth all the money or fame in the world.

 

 

Codeable reviews – the good, the bad and the ugly.

Codeable reviews, are they real and how happy are Codeable clients really?

If you have been following this blog you’ll know that I was accepted as a Codeable expert back in September of 2016. Since then I’ve completed 70 tasks through Codeable with an average rating of 5/5. You can even read some of the Codeable reviews my clients have left me at the bottom of my profile, but how real are these reviews?

If you visit the Codeable home page, you’ll see they quote a number of ‘989 of every 1000’ projects completed with a 5/5 rating. This calculates to a 98.9% rate of 5/5 rated projects. I thought it might be interesting to see how real that figure is, based on my own experience.

First, some facts.

Since I joined Codeable in August of 2016 I have completed 70 projects with an average rating of 5/5. It is important to note that not all 70 projects mean a different client. In some instances, I have completed multiple additional tasks for the same client. In fact, as of this year, I have not completed much new client work and most of my work through Codeable is from existing or repeat clients.

At the time I have been with Codeable I have earned a total of $17,983.67 with an average project size of $639.82. Most of the projects I work on are in the sub $1000 range, for personal and availability related reasons.

Bad Codeable Reviews

Let’s start with the bad. As a Codeable expert, I have been fortunate in that I have not received any bad client reviews. I have received 2 less than 5/5 ratings, one of 4 and one of 3. That works out to a 97% 5/5 rating. Not the same as average Codeable expert 98.9% rate but still pretty good in my books. In my own defence, the 3 star rating was from a project where I applied for a requirements gathering task, completed the requirements gathering, submitted the requirements document and then my estimate to complete the work required and the client opted to not follow through with the project. I’m not 100% sure why they then rated me 3/5, as I completed the task we agreed on. I can only imagine that they believed my quote was too high.

Good Codeable Reviews

It’s always nice to lead on from the bad news to the good news, so let’s take a look at my good Codeable reviews. On my Codeable profile, you can view the 15 most recent client ratings and reviews I’ve received. You’ll see that some clients choose to merely rate my work, some are happy to leave a review. This is entirely up to them, but I appreciate whatever they choose to do. Getting a 5/5 client rating or a great review really does put the spring in my step.

These are all real clients, who I’ve completed projects for, ranging from small tweaks to larger plugin customisations.

Ugly Codeable Reviews

There are always projects that go wrong. Again, I’ve been fortunate that I’ve only had two go badly wrong during my time at Codeable. Both times the same things happened. Codeable customer support stepped in, took over the project and either found another developer or refunded the project. In both instances, I was actually the second person to work on the project, the relationship with the client and expert having already gone wrong. In the first instance, the client was refunded and they were assisted by Codeable customer support to post a new project, with a better project description. In the second the client was refunded half of the project amount, as half of the project was completed. Both times I lost money but learned a valuable lesson and was impressed with how Codeable honoured their quality promise and money back guarantee.

Understanding why projects go south.

It’s important to note that in both of the above instances the main reason the project went south was a lack of understanding of scope. Project scope is defined as “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” To put it in Codeable terms, it is the agreed upon pieces of work that a Codeable expert will complete to deliver what the client has requested. More often than not, client/expert relations break down when the initial agreed upon scope is expanded on (new requirements added) during the course of project and there is a miscommunication or misunderstanding as to the fact that these new requirements will require additional time and cost to complete. In my personal experiences, this was the exact reason both projects went wrong.

Understanding Codeable reviews

If you’ve come this far you probably think this piece was meant as a strongly pro Codeable article. It was, but not for the reasons you think, I’ll leave that up to more experienced writers like Nathan Ello and Robin Scott. I am a Codeable expert because their customer service, quality standards, and unique developer community mean my clients will get a better service from me than what I could do on my own. However, if you are considering hiring a Codeable expert, it’s important to be able to read all Codeable reviews online and make up your own mind. I, therefore, wrote this to give you a little inside scoop and to help you understand how it all works and be more informed when making your decisions.

 

Everything you’ve ever wanted to know about dealing with Codeable.

If you have been following my blog you will know that I was accepted as a Codeable Expert in late 2015. I’ve since spent a fair amount of time espousing the advantages of working with Codeable.

Now, one of my Codeable colleagues, Robin Scott from Silicon Dales has written what is probably the most extensive tutorial on working for and with Codeable. As a developer and owner of his own development agency, Robin has the unique perspective of having seen both sides of the Codeable coin, both as a Codeable expert and client.

It really is an amazing read and not only describes the experiences of both a Codeable client and expert, but shares some common tips and pitfalls of hiring through Codeable as well as being hired as an expert.

If you are looking to hire a Codeable expert to help you complete your next project I highly recommend reading this article.

Introducing Boss Box – a WordPress ready development environment

Local Development

A modern, easy to configure, WordPress ready Vagrant box, perfect for local development.

As a developer, one of the most important pieces of technology I use daily is my chosen virtual server stack. Depending on your operating system of choice, there are a few solid options out there, but since discovering Vagrant I've always preferred it over other options. A preconfigured Vagrant box is, in my opinion, the closest you can get to a local, real world web server without actually building one yourself (and I've actually done that as well), all possible from a virtual machine that is just as easy to discard and replicate should you need to.

While there are many WordPress developer friendly options out there, from VVV to 10up's WP Docker, I found Scotch Box a little while ago and it provided me with the best combination of features and ease of use. I liked it so much I even customised it a little further and released that customisation on GitHub.

Why ScotchBox?

What I enjoyed the most about ScotchBox was how easy it was to get up and running for my existing workflow. I tend to work on a few client projects at a time so it means at any one time I have two or three web project folders I am busy with. All of the existing options tended to shoehorn me into a specific workflow/url mapping/directory structure and configuring them to fit my setup seemed like a lot of work. ScotchBox was different, I could just take the Vagrantfile, pop it into my project web root directory, start up ScotchBox and everything just worked.   

Why customise?

There were however a few things missing or not set up exactly how I would have liked it

  • It did not come with PHPMyAdmin installed and I like using PHPMyAdmin for quick data lookups.
  • While it offered the option to run multiple sites on one box, it required a little too much editing of the Vagrantfile to use the same base box for different projects at the same time.
  • It did not support Xdebug out of the box.
  • The MySQL root password was 'root', I always use 'password', meaning I had to edit each site's wp-config.php to change it.
  • Finally, I prefer my vagrant configuration files to reside inside a folder called 'vagrant', so that there is less clutter in my web root.

This is what lead to the customised version of ScotchBox I wrote about earlier.

Then why BossBox?

ScotchBox has served me well for the past year and a half but I've been yearning to create something a little more streamlined but meeting my specific requirements ever since I first released my 'tweaked' version of it.

Earlier this year ScotchBox developer Nicholas Cerminara updated the free version of ScotchBox and released ScotchBox Pro, which includes an updated server version (Ubuntu 16.04) and therefore updated versions of all the bundled software. The Pro version also included the install script that he uses to create the base ScotchBox in the first place.

This gave me the opportunity to not only build my own version of ScotchBox but also remove all of the software that I don't specifically need and add some additional software and settings that I do need, and so BossBox was born.

BossBox comes in two variants, one with Apache as the web server and one with NGINX. Besides that, both versions are identical, WordPress ready development boxes that are easy to set up and use. I invite you to take a look, try one (or both out) and leave your feedback, either in a comment on this blog post or, if you find a bug, as an issue in the respective GitHub repo. The BossBox Vagrant, configuration and setup files, as well as the box itself, is licensed GPL 2.0, so feel free to use it, modify it and customise it to your needs.

Enjoy.