PHP CodeSniffer, Atom, and Windows

I’ve used linters before. Specifically for JavaScript. But this will mark the first time I’m using a linter to improve my code formatting on PHP. I had heard of CodeSniffer before, and I also already knew it’s bundled with VVV. So I thought: “You know, it may be easier if I can get this working straight in my IDE instead”.

The kicker, however, is that I do a lot of my development at home on a Windows machine. This generally means I have to jump through a few more hoops, use elevated command line tools, and abuse the environment variables system to get things to work properly. Luckily, getting the PHP CodeSniffer linter to work in Atom wasn’t that bad. Here’s what I did to get this to work and to get the WordPress sniffer rules in Atom.

Install PHP and PEAR

To start things off, you will want to install PHP and PEAR. In that order, since PEAR is a package library for PHP applications. PHP may already be installed if you’re running a local server installation like XAMPP or WAMP. If that is the case, you can skip it but do make sure you don’t forget to add it to your system’s PATH variable.

If you, like me, use Vagrant for your local server needs, then you will want to download PHP from You will want to download a VC build zip package and extract it somewhere easy to find (I tend to drop these things into a folder called “dev” on my C drive, ie. C:\dev\php).

Once extracted, you will need to add the folder to your system’s PATH variable so that you can use it on your CLI. If you’re not sure how to do this, please refer to this article on describes how to set up Windows system variables.

To confirm you did it right, open up the command line (Windows Key + R, then type “cmd” and press Enter) and then type “php -v” (without quotes). If this results in “php is not recognized as an internal or external command” then it’s not set up properly in your system path. Make sure that if you make any changes to that, to restart your command line tool.

If you see the version of PHP you have, then you’re ready to install PEAR! To do this, download the go-pear.phar file from It’s a large file, and will most likely open as a plain text file in your browser, so the easiest way to download it is to right click and hit “Save”.

Once downloaded, you can simply run php go-pear.phar in your command prompt from the folder you saved it in. This will start the PEAR installation process and it will ask you for a number of things before installing PEAR. The default settings it comes up with should work just fine, since it simply figures out where your PHP is installed. After it’s done installing, you will need to add the path it’s installed in to your system’s PATH variable. That way, you will also be able to use PEAR in your command prompt (remember to restart your cmd window after doing this).

Install PHP CodeSniffer and WordPress rules

With PHP and PEAR installed you will now be able to install PHP CodeSniffer with one simple command: pear install PHP_CodeSniffer

This will let you use the phpcs command from the command prompt. Go ahead and try it out on a PHP file you may already have (ie. phpcs my-php-file.php). Or just try printing the version (phpcs --version)

The WordPress rules can be found on Github at the WordPress Coding Standards repo. I’ve opted to use the Standalone installation, which is the simplest and lets you use git to update it in future. The final step of this, actually adding the sniff settings to your PHP CodeSniffer installation, is the most important. It’s also important to double up on your slashes. So, for example: phpcs --config-set installed_paths C:\\dev\\tools\\wpcs. If you don’t do this, it will successfully add the path, but it also will give you an error when you confirm your change with phpcs -i.

If everything went correctly, the command above should list WordPress, WordPress-Core, WordPress-Docs, WordPress-Extra, and WordPress-VIP.

Install Linter and Linter-PHPCS

With everything installed, you are now ready to set up Atom to start using PHP CodeSniffer to lint your PHP code. For this very purpose, I’m using the linter and linter-phpcs packages. You should be able to find both of these in the packages list in Atom’s built-in package manager (File -> Settings -> Install). Once they are both installed, click on “Packages” and find linter-phpcs. There should be a “Settings” button that you can click that will allow you to set the package up to use your newly installed CodeSniffer.

My settings look something like this, make sure to set the Executable path to where your phpcs.bat is stored:

My linter-phpcs settings. The executable path is set to C:\dev\php\phpcs.bat, and the Code Standard is set to WordPress.

Your settings should be saved automatically and you will now be able to use PHP CodeSniffer to lint your PHP code on the fly using WordPress coding standards. For existing files, you will generally hit Ctrl + S to trigger the initial pass on your code. But once it’s going on a file, it will automatically resolve issues it finds as you fix them.

And if your code is anything like mine when I first installed this: Enjoy your red dots of DOOM. There will be many. Good luck!

Orlando WordPress Meetup: Going Responsive with WordPress

So it finally happened. I did a talk at the local WordPress meetup, Going Responsive with WordPress. If you’re here because you saw my talk and are interested in more information or the slides, you’re in the right place! And also, thank you for coming! If you missed the talk, but still want to look at the slides, you’re in the right place too!

I’m using reveal.js for my slides, and they can be found here: Making Responsive Sites Accessible For Everyone (slides).

If you’re interested in reading more on the subject, here are some more resources:

Introduction to Understanding WCAG 2.0 Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile Finger-Friendly Design: Ideal Mobile Touchscreen Target Sizes How Do Users Really Hold Mobile Devices? Common Misconceptions About Touch HTML5 input fields CodePen demo.

And as a bonus, this YouTube channel provides some interesting insights in how blind people tackle “menial” tasks in life. There are a number of iPhone videos in it that are particularly relevant to the subject. TommyEdisonXP’s YouTube channel

One of the questions was about resources that I’d recommend for further reading. The WCAG Overview is a good place to start. Furthermore, the talented people at the Paciello Group write a lot about the subject of accessibility. You’ll be able to find most of them on Twitter as well. Other blogs to follow are Simply Accessible, Usability Geek blog, and Joe Dolson’s blog. I’m sure there are more of them out there, so feel free to share them!

All WordPress pages but the homepage give a 404 error

More and more often I keep seeing posts asking about what’s going on with their site when only the homepage seems to be working. Even developers are sometimes caught off-guard when this happens. This little quick tip should help you out in roughly 99.99999999% of the time.

So how would you fix this? Simple. Just re-save the permalinks. That’s literally all there is to it.

A screenshot of a portion of the admin menu, highlighting Settings and Permalinks.

To do so, what you’ll need to do is head over to the “Permalinks” settings page. You can find this page by hovering over the “Settings” option in the left sidebar of the admin and then selecting “Permalinks”.

Once the page loads, you don’t even have to touch any settings. Simply click the blue “Save Changes” button that is near the bottom of the page.

Now, it may be cause for alarm when your site has been running great for a while and suddenly your subpages don’t work. In those situations, re-saving the permalinks will also work but you will also want to look for the root cause of why they broke. Otherwise, you may end up re-saving them every other week. In general, you’ll want to consider what plugins you installed last, and what plugins have been updated recently.

If re-saving your permalinks doesn’t fix this issue (I can almost guarantee that it will, but you never know), find me on Twitter and I’ll help you figure it out.

WordPress involvement: 0 to plaid in a month

Disclaimer: This post is a bit humble-braggy. You’ve been warned.

People that know me will know that I’m comfortable in my little shell that allows me to do my thing in the background. Like a Roadie (by Tenacious D).

Since finding and fixing my first WordPress bug (told you, humble-brag), I’ve been mainly lurking in Slack and not getting involved very much (mainly time related, to be fair).

Until, in early February, I noticed that the WordPress accessibility team was calling for testers. This has been a catalyst in getting involved more, especially since testing doesn’t need much more than experience with WordPress. Screen reader experience and experience navigating with the web with just a keyboard are nice to have and will allow you to test more. But really, accessibility is more than just that, being able to understand what’s going on and how to interact with WordPress functionality is also a very big part of it. If you’re at all interested in contributing, sign up to become an accessibility tester and get started today!

But I digress.

My testing contributions quickly put me in a place where I could help more, leading to getting more involved in the accessibility meetings, test results, ticket reporting, and ultimately get added to the Make Accessibility blog to help in posting test and meeting summaries.

None of this would have been possible were it not for the awesome Andrea Fercia and Rian Rietveld, who have both been really helpful.

In the mean time, Adam and I have geared up to start writing plugins in our spare time. We finalised the development and got our very first plugin ready for release this week. I’ve used it on my website, and I can obviously recommend it if you’re interested in having your post series organised. You can download it from the Our Post Series Manager plugin on WordPress Plugin Repository.

Where will this go from here? Who knows. More plugins, surely. Hopefully I will also be able to find more time to help Andrea with developing patches for the bugs we find.

But for now, #humblebrag over. Carry on.

Dealing with White Screens of DOOM in WordPress

WordPress Logo

We’ve all been there. Happily writing our PHP for some template or another. But then you save your file and refresh the page and…the screen stays completely white.

So why does this happen? Most likely you’ve made a syntax error somewhere. Like, say, forgetting a semi-colon or curly bracket. Another reason is that you’ve reached the memory limit of your server. The latter will usually happen when you enable a particularly poor plugin or theme.

The reason this comes up as a white screen of DOOM is because your errors are being suppressed.

While this isn’t necessarily a bad thing on a production server (though, you do test your code before pushing it live, right? Right?), it can be very inconvenient while you’re developing a new template or WordPress plugin.

To get rid of this inconvenience on a development server is fairly simple. All you need to do is open up your wp-config.php file and locate the line that says: define('WP_DEBUG', false);. Change false to true and you should be good to go. If it’s not there, you can add it anywhere above where it says /* That's all, stop editing! Happy blogging. */.

Should this not work (it’s somewhat unlikely, but it’s possible), you can also set PHP’s error reporting on the fly.

And there’s that. My first quick tip. I’ll most likely post more of these in the future. If you’re still having issues with errors plaguing your WordPress website, drop me a line and we’ll figure it out together.