Open source software and things
Web development/WordPress/CakePHP
My friend Nathan over at the WP Builds podcast had the opportunity with chat with Matt Mullenweg about the pending WordPress 5.0 release and Gutenberg.
Worth a listen if you are worried about the 5.0 release.
While you are there, take a listen to the chat I had with Nathan regarding the GPL. Probably not as controversial as Gutenberg but interesting nonetheless.
I stumbled across Car Masters: Rust to Riches on Netflix this past week. As a bit of a petrol head I’ve always enjoyed a good car restoration show and I found the ‘upgrade and trade’ business model that was central to the series story line extremely interesting.
Watching the team from Gotham Garage upgrading and transforming old cars into new, it got me thinking about my own recent upgrade project. I like cars, but I’ll never be the type who restores an old one in my garage as a project. I like cars that are new and shiny and go fast now. What I do like doing for fun, is fixing and upgrading computers.
This is, in part, what lead me to upgrading my old gaming pc and turning it into my current development workhorse. This is also what lead me to finally get something I have wanted for many years, a proper multiple monitor setup.
A few months ago I purchased a new Dell 27 inch LED monitor, and the Zotac graphics card I purchased has support for up to 5 screens. I still have a Samsung 23 inch monitor my wife purchased for me over 7 years ago for the original desktop build, and a few hours of scouring local online classifieds, led to me picking up a Phillips 24 inch monitor to complete the set.
I was able to work on a three monitor setup very briefly using my old Dell 17 inch laptop, which had both an HDMI and VGA output, and I found it very productive, so being able to work this way for the past few months has been amazing.
I don’t think I’ll be doing any upgrades to this set up any time soon, as for now I really feel like I’ve upgraded to my perfect development workstation.
Is the Codeable Expert Developer certificate worth the weight of the digital paper it’s printed on?
In 2016 I certified as a Codeable Expert Developer. I’d already spent a number of years working with freelance platforms such as Upwork and Freelancer but Codeable has stepped out from this crowd to become my preferred platform of choice.
Why?
There are quite a few reasons why Codeable is the kingdom where every developer should hang their hat and here are six of them…
Entering into the Codeable world isn’t as simple as filling in a few forms, locating the perfect profile pic and waiting for the work to come to you. The application process tests you on your development knowledge, ability to handle difficult clients and skills in managing complex situations. For Codeable, technical knowledge is essential but customer service is critical.
Experts have to pass stringent tests to gain access to Codeable – tests that are improved upon daily by the Codeable expert community. You have to know the web, WordPress and development inside and out before you can even be considered. You also have to demonstrate the ability to manage expectations and a willingness to engage in open communication and collaboration.
Codeable Experts are project managers, quality testers, customer relationship managers and so much more. This assures Codeable Experts that they will be connected with genuine clients and it assures clients that they are going to get connected to incredibly talented experts. And everybody knows that this level of skill doesn’t come at cost price.
The Codeable process may be rigorous and complex, challenging your skills and your experience, but it is worth every hurdle and hoop.
The founder of Codeable, Tomaz Zaman, jokingly refers to Codeable as the Tinder for WordPress. It’s easy to see why. It connects the best WordPress experts to the best clients and everybody walks away happy and in a new, fulfilling relationship.
This is primarily driven by Codeable’s commitment to making both the customer and the Codeable expert happy. A commitment that’s clear from the moment you apply. Codeable gives every applicant personal attention and team members take the time to explain each part of the application process. They also provide immediate feedback when sent questions or concerns. I dealt with people who cared and who understood that sometimes life got in the way of the application.
Once you’ve been accepted, you need to spend some time getting to know the Codeable process. The entire platform has been designed to provide you with a really strong support structure so you can quickly learn about how to engage with customers and how to deliver the ideal Codeable customer experience.
There is a very delicate balance between the needs of the client and support for the experts and Codeable manages this perfectly.
There are three things that define a great customer within the Codeable universe:
Codeable doesn’t limit you to the Codeable workroom system. Once a project has been funded you can use any communication tool that you and the customer prefer. That said, the Codeable workroom system has some nifty tricks and treasures hidden in its depths that add enormous value to client communication.
There is one thing that Codeable doesn’t have…Expert Wars. On this platform the experts aren’t competing, they’re helping. It’s more like a distributed family that steps in to ensure that clients always get the best out of their chosen expert.
Codeable is the first platform I’ve experienced that has captured the true heart of the community-driven ethos of the open source platforms we use.
The fact that we, as Codeable Experts, are not in competition with one another makes this one of the best platforms in the world. The expert community is perhaps the biggest reason why I am passionate about Codeable and its potential. We help one another on projects, give each other advice when entering into pre-hire discussions, and share expertise on the forums. It is open access to the most impressive group of WordPress experts in the world. You are constantly surrounded by intelligent people who can teach you something new every day.
Last year I had the opportunity to meet up with a group of my fellow Codeable Experts at WordCamp Europe 2018 and it was like meeting up with old friends.
Codeable has also taught me that the knowledge and experience I have is invaluable. If you work with the right clients you don’t have to kill yourself to make a living. Since joining Codeable in 2016, my income potential has doubled and I have been able to do things I’ve never done before. I built the perfect development workstation, I took time off without worrying about my next project and I learned new technologies while taking on exciting new projects.
If you want to enter into the world of Codeable, then here are four top tips that will help you get in, get involved and get insight from brilliant Codeable minds…
The slides from my freelancing talk at WordCamp Johannesburg
I learned a valuable lesson yesterday, if your workshop prep requires a lot of involved setup, you might want to reconsider your workshop.
Anyway, for those who want to try and replicate the workshop process at home, here are my slides and the workshop notes I used. You should also be able to followed the numbered branches on each of the GitHub repositories.
The WordPress plugin GitHub repo
If you have any questions about the process, you can usually find me in the WP South Africa Slack.
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.
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.
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.
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.
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:
For which ever set up you choose, make sure you can connect to and view the database for both.
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.
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.
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
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:
The best three themes:
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…
(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.
sudo pear install PHP_CodeSnifferI 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.
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/StandardsIn 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.gitI 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
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 phpcsMine 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).
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:
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.