WordCamp Johannesburg 2018 – Workshop prep

On Thursday the 25th of October 2018 I will be presenting a workshop titled “Turning your WordPress plugin into a SaaS”, where I will be sharing some insight into connecting a WordPress plugin to a Laravel App through HTTP requests.

As with most workshops, there is some preparation work required to attend. However because we are dealing with two different platforms, (Laravel and WordPress) setting it all up might take a bit longer than usual.

TL;DR – Requirements:

This article is aimed at folks who a) have never set up local development environments or b) have only ever used applications like WampServer or Mamp for their local development. If you already use something like Vagrant or Docker environment, you probably don’t need this article 😉 It would however be good to skim through it to make sure you have a set up that matches my own.

1. WordPress environment.

To participate in the workshop, you will need a local WordPress environment. Make sure you have the latest version of WordPress installed (4.9.9 at the time of this article).

If you use WampServer or Mamp, you should be fine, as long as the WordPress install can be accessed via a local IP address (we’ll get to that in a bit).

My recommendation would be to try something like Chassis.io, or my own BossBox. These are pre-configured WordPress ready Vagrant boxes that replicate a Linux server and any installed software you might need. If you already use VVV, this is also a good option.

To install any of these options you will need to install VirtualBox and Vagrant first. Each project has instructions on how to set up and run your WordPress install. Obviously I favour BossBox, because I built it and I know it works well out of the (ahem) box.

What I like about a Vagrant option is that you can configure each instance with it’s own IP address, which makes it easier to develop and test API end points on two different instances at the same time, which is what we’ll be doing in the workshop.

You will then need to download and install the base plugin we will be using, which you can download from this link.

For the purposes of the workshop, my WordPress environment will be using the default IP address which ships with BossBox, which is 192.168.33.10.

2. Laravel Environment.

Firstly you’ll need to follow the installation instructions to create a new Laravel project.

Then you’ll need to choose which local environment you use. There are a few options to for setting up a local Laravel environment, the two most popular being Laravel Valet and Homestead.

Laravel Valet as a Mac only option, that requires very little in the way of set up. The only downside is if you don’t own a Mac, you can’t use it. I develop on a Linux OS, so I can’t speak for if it will be sufficient for the workshop, but I don’t see why it wouldn’t. As with the Wamp or Mamp options I also don’t know if you can configure the Valet set up to a local IP address.

The option which I prefer is Homestead. Again, it is also a pre-built Vagrant box, so if you go with one of the Vagrant options for WordPress you already have the required software installed. If you do go this route, I suggest using the Per Project installation method, which is the one I’ll be using for this workshop.

For the purposes of the workshop, my Laravel environment will be using the default IP address which ships with Homestead, which is 192.168.10.10.

A note on Vagrant options: because these pre-built virtual Linux web servers, they can be quite large when you first download them. BossBox is around 750mb (the last time I checked) and the Homestead box is almost double that. So make sure you have a good internet speed and enough data to complete the downloads. If you only use mobile data, I recommend visiting an internet cafe or WiFi enabled coffee shop or co-working space. It’s also the reason I suggest you do this before you come to the workshop, as downloading everything during the workshop is going to take too long on conference WiFi. The upside is that once they are installed, you use the same installed base box for every other instance you set up.

3. Database Access

You will need some way to access the database for both set ups.

If you use the BossBox route for your WordPress setup, you can access the database via PHPMyAdmin, which comes pre-installed on the box. You will find details on how to do this in the project readme file. If you go with the Homestead route for Laravel, you can use an application like MySQL WorkBench. For the Laravel app the defaults are:

  • Hostname – 192.168.10.10
  • Port – 3306
  • Username – homestead
  • Password – secret

For which ever set up you choose, make sure you can connect to and view the database for both.

3. API Testing – Postman.

Postman is an application for testing software API’s. We’ll be using it to test the API end points we create during the workshop. To make sure your WordPress and Laravel environments are accessible to each other, test them via Postman.

In order to test them, you need to install Postman and create two new requests, one for WordPress and one for Laravel. Set the URL for each request to the IP address for both WordPress and Laravel. You should see some html data returned, which means Postman can send a request to either one.

4. Code Editor/IDE.

Obviously we’ll be writing code, so we’ll need a code editor. If you are already writing PHP code you probably have an editor you prefer, and that’s great. If you don’t I can recommend Visual Code Studio (free) or PHPStorm (paid). PHPStorm comes with a free 30 day trial, so if you’ve never tried it, now is a great time. I’ll be using PHPStorm in the workshop.

On Ubuntu 18.04, Installing MySQL Does Not Set the Root Password.

MySQL Root Password

One of the things I love about using Ubuntu as my primary operating system is that I can have quickly set up a ‘bare metal’ LAMP development environment. While I unusually run my client websites inside on of my custom Vagrant boxes, for working on personal projects or plugin/theme customisation everything’s much faster when it’s able to use the full power of the machine I’m working on.

After I switched back to a computer as my every day workstation, I came across a weird little issue with installing MySQL. Usually during the install process it asks me to set a root password, but this time it did not. This meant that I wouldn’t be able to access the database using the root user. Not a huge issue, as I could create another user to access any database, but as it’s a local install, connecting as the root MySQL user is just much easier.

As it turns out, on Ubuntu installs running MySQL 5.7 or later, the root  user is set to authenticate using the auth_socket plugin rather than using a  password. Thankfully the folks over at Digital Ocean have released an article which explains this information and provides the steps to switch the root user authentication from auth_socket to using a password.

UPDATE: As it turns out, this was not the only issue I was having, turns out the MySQL install was also corrupt somehow. Fortunately the internet is a wonderful place, and I found some instructions on how to completely remove all traces of MySQL server, and start again.

sudo dpkg -P mysql-server mysql-server-5.7
sudo apt-get autoremove
sudo apt-get clean
dpkg -l | grep -i mysql
sudo rm -rvf /var/lib/mysql
sudo apt-get install mysql-server

	

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).

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.

 

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.

Taking back ownership of the word ‘freelancer’

PHPSouthAfrica

Based on some prompting by Hugh I applied as a speaker at PHPSouthAfrica this year. Apparently they still don’t know how little I actually know as they accepted my talk submission 😉

I’ll be talking just after afternoon tea about a topic that has been on my mind since 2010, that of the common perception of the freelancer, specifically when it comes to developers.

A freelancer or freelance worker is defined as a person who is self-employed and is not necessarily committed to a particular employer long-term. Since becoming a freelance developer in 2010 I’ve discovered that there is a stigma attached to the word. I don’t know if it is developer specific, but every time I meet or take on a new client the fact that I am ‘freelance’ tends to inspire visions of horror, usually of poor deliverables, bad client support and just a general lack of responsibility. In my talk, I would like to unpack this problem and provide some solutions to it.

Here are the slides for this talk.