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

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.

WP Hacker Cast – the official launch post.

About a year ago (literally, I got the domain renewal notification two days ago) I came up with a podcast idea.  I had just finished reading “Milestones – The Story of WordPress” and I thought how awesome it would be to interview every single one of the core release leads, from Matt all the way up to Helen, and dive deep into the ins and outs of leading a WordPress release. I started by reaching out to two of the release leads, Drew Jaynes and Helen Hou-Sandi. Helen because she had just lead the 4.7 release and Drew because I’ve actually met him in person. Both were keen but had other things going on at the time. So I put it on hold until they were available. A few months later the idea resurfaced in my head, mostly because I had just helped Craig Hewitt launch the Seriously Simple Hosting extension for the Seriously Simple Podcasting plugin. I thought about all the WordPress developers I already know, both locally and internationally, who weren’t necessarily WordPress release leads but whose stories I would love to hear. So I decided to retool the podcast to focus on those folks I refer to as ‘WP Hackers’, people who use WordPress and write code with/for it every day. I’ve since recorded my first four episodes (3 of which are publicly available on the WP Hacker Cast website) and I’ve had good responses so far. I’m slowly learning about the extra things needed for a podcast, like a subscription option as well as submission to things like iTunes. It’s all a great learning process. I’m happy to anncounce that you can now subscribe to new podcast episodes via email, directly from the site. Use the ‘Subscribe to the WP Hacker Cast’ form in the sidebar to receive fresh podcast notifications in your inbox. The podcast is also now listed on iTunes and Stitcher, so you can consume the episodes using your favourite podcast player. Please feel free to comment on the episodes, or contact me directly with feedback, comments and suggestions. I’m always looking for WP Hackers to talk to or interesting topics to discuss.

Gutenberg day ??? – well that was hard!

I remember the first time I read about Jerry Seinfeld’s productivity secret. At the time it seemed trivial, but after trying to write a blog post per day for the month of September using Gutenberg, and then failing miserably at it, I can admit to the fact that planning to write something every day and actually doing it, are two very different beasts. Then I woke up this morning and saw that it has been decided that Gutenberg will no longer be using React. That’s a pretty big deal if you ask me. It also makes me realise that even one of the biggest open source projects in the world can make drastic changes to how it’s original goal was envisioned. So instead of trying to blog every day I’m just going to try and blog more, maybe once a week, with a better ‘check’ against myself to ensure it gets done. With Gutenberg still a long way from being merged into core it’s on me and everyone else who makes a living from WordPress to ensure that when it is officially released, it’s awesome, not just good.

Gutenberg day 8 – Contributing to Core

I’m attempting my first shot at contributing to WordPress core with ticket that was opened 8 years ago!

I feel like it’s small enough that I can get something done by the time the next release rolls around but useful enough that it will make peoples lives easier.

Feel free to follow the ticket to see how it pans out.

In other news, using Gutenberg today was a bit of a pain. Because I use Jetpack’s publicise functionality to share my content socially and Jetpack does not yet support Gutenberg (for obvious reasons) I have to write up the post in Gutenberg but not publish it and then edit the Post in the usual way and publish it. Today this lead to me loosing all my content and merely switching to the regular post editor. Fun times.

Gutenberg day 7 – New things

WP HackerCast
Today I'm especially excited to blog as I have a little news to share. The first episode of my new podcast has officially been published.
WP HackerCast – Episode 1 – Seagyn Davis
WP Hacker Cast is my way of talking to and learning from all the great WordPress developers I know and communicate with. I've got some great interviews coming up, but the first is always the most special. I hope you enjoy it.