Joining Alley

Team picture from the recent Alley retreat where I learned that I’m too old for three hours of sand volleyball.

I’m thrilled to announce that this week I’ll be joining Alley Interactive as the Director of WordPress Software Development. I’ve been a big fan of the work this talented team has produced over their impressive 10 year history and look forward to the opportunity to join in and learn from this group of people. Even in my short time getting to know the people at Alley, I’ve already come to appreciate the passion, dedication, openness and trust that I’ve seen exhibited by this group and feel lucky to be joining such a great bunch of colleagues.

One thing that I’ve learned over my career is how important it is to work alongside people who inspire, challenge, and support you—both personally and professionally. I’ve been very fortunate to have experienced that support at Human Made over the past three years and Washington University before that. To that end, it was bittersweet to say goodbye to my former colleagues at Human Made last week. I’ve learned an amazing amount during my time there and will always be grateful to Tom, Joe, and Noel for letting me be a part of the HM family. They’re an amazing group of people that have had a huge impact on me, and whom I expect to call friends for the rest of my life.

Here’s to new challenges and new adventures. I hope to learn every day and to be an open and supportive colleague. Should be fun!

Becoming Human

At the end of this week I’ll say goodbye to my Washington University crew to begin a new adventure as a Senior WordPress Engineer for Human Made.

Working in the shadow of Brookings Hall for the past six years has been an absolute privilege. I’ve been fortunate to work on projects that have been both professionally and personally fulfilling. Most of all, I’m grateful for the colleagues who continue to inspire and challenge me and with whom I’ve become great friends. Keep an eye on that team—I’m confident they’ve got some tricks up their sleeves.

As hard as it is to close the book on my time at WashU, I’m thrilled to be starting a new chapter with Human Made. The team that Tom and Joe have built over the last several years is nothing short of extraordinary. When I found myself with the opportunity to work alongside and learn from the folks who are literally inventing the future of WordPress, I couldn’t pass it up.

I also plan to be even more deeply involved in the WordPress project than I have over the past few years. Democratizing publishing, in my view, is a mission that is as critical as ever. By sharing our stories—and being open to others when they share theirs—maybe we can all become a bit more human.

Setting up WordPress tests with CircleCI and WP-CLI

CircleCI is a continuous integration platform that can be used to automatically build, test, and deploy software. It’s relatively easy to set up with any existing GitHub or Bitbucket project.

Setting up tests

WP-CLI includes a handy command for setting up WordPress tests for a plugin or theme using different CI services. To set up the tests for CircleCI, you can use either wp scaffold plugin-tests --ci=circle or wp scaffold theme-tests --ci=cirlce.

This will add several things to your project:

  • circle.yml – The configuration for CircleCI
  • phpunit.xml.dist – A configuration file for PHPUnit
  • A ‘tests’ folder containing:
  • bootstrap.php – A PHPUnit bootstrapping file that loads the WordPress tests along with the plugin or theme being tested.
  • test-sample.php – a sample PHPUnit Test class extending the WP_UnitTestCase class.
  • A ‘bin’ folder that contains the script for setting up the WordPress test environment, if you don’t already have one set up. Note that VVV is preconfigured to use the main development test environment.

With these files in place, you can now log into CircleCI and add the project, which will automatically set up a build next time you push a commit to your remote repo in GitHub or BitBucket.

Configuring CircleCI

CircleCI sets up builds in several configurable phases. Here’s what the default configuration from WP-CLI looks like:

 version: 5.6.22
 PATH: $HOME/.composer/vendor/bin:$PATH

 - sudo apt-get update; sudo apt-get install subversion

 - bash bin/ wordpress_test ubuntu '' latest
 - |
 composer global require wp-coding-standards/wpcs
 phpcs --config-set installed_paths $HOME/.composer/vendor/wp-coding-standards/wpcs
 - phpcs --standard=phpcs.ruleset.xml $(find . -name '*.php')
 - phpunit

For our purposes, we’re going to look at three phases: machine, dependencies, and test. Each phase has three event you  into:

  • pre – commands to run before this phase.
  • override – commands to run instead of the default commands.
  • post – commands to run after your this phase has finished.

First, the machine phase configures details so you can do things like changing the PHP version to match your production environment and set up environment variables.

The dependencies phase install all dependencies for the project. It loads dependencies from popular dependency configuration files in your project, like package.json, composer.json, etc.

In the default WP-CLI setup, the build installs subversion before loading project dependencies so it can checkout the WordPress test suite using svn during the test phase of the build.

In the test phase, the default setup installs the WordPress test suite using the bin/ script, installs the WordPress coding standards and registeres them with PHP Codesniffer. Once everything is set up, the test phase will run the codesniffer checks with phpcs and will then run your unit tests with phpunit.

With all this in place, you can now add additional tests or configuration steps and get near instant feedback if a code change would introduce any problems to your codebase.

My Favorite Albums and Books in 2016

Another year is almost over, but not before recounting some of the best things I listened to and read this year.

Favorite Albums of 2016

Why albums and not songs? I’m not sure why, but I’ve always been more into albums than singles. I enjoy a full collection of songs from artists. Some things need not be questioned. Here are five of my favorites from this year in no particular order of importance.

Coloring Book – Chance The Rapper

Chance’s album is sure to be featured in many “best-of” lists this year. For me it was both a celebration of the magic of life and a lament for a world that is so obviously less than it should be. But David Dark sums this all up much better than I could, so just read him.

Blanco – David Bazan

David Bazan is a national treasure. We’re lucky to be alive while he’s here.

Real Emotion – Paper Route

This album is personal. Not just the writing, but because I’ve known 2/3 of this band for nearly half my life and shared some formative years trying to figure out how to make music that mattered together. For me, this album was an artistic triumph.

Choose Your Weapon – Hiatus Kaiyote

The whole vibe of this album is otherworldly. Such groove.

Spotify Sessions – Rayland Baxter

Something about this album stuck with me this year. The guitar playing, Americana, singer/songwriter vibe, laced with feelings of longing, nostalgia, and regret may just be my love language. And Rayland and his talented band deliver the goods on this live album.

Honorable Mention

Favorite Books of 2016

I keep finding that I end years without reading as many books as I would like. Even so, here are my favorites I read this year.

Hillbilly Elegy – J. D. Vance

Stating that this was one of the best books of the year borders on cliché, but here we are. Vance’s story touches on themes that I could easily identify in my own life and the life of my childhood friends.

Becoming Wise – Krista Tippett

If you’re not familiar with Krista’s podcast, On Being, then I suggest you remedy that situation quickly.

Life’s Too Short To Pretend You’re Not Religious – David Dark

Some will read the title and hope for a winsome attempt to evangelize the virtues of religion in an increasingly secular society. Others will read the title as yet another patronizing attempt at false equivalency by those who can’t come to grips with modern rationality. David Dark will have none of it. His suggestion that we pay close attention to what we pay attention to is one worth taking seriously.

View From Flyover Country – Sarah Kendzior

I’ve been a fan of Sarah’s writing since I first encountered it via a project I worked on at WashU. Seriously, follow everything she does and find ways to give her your money so she can do more of it.

Jayber Crow – Wendell Berry

This old book was recommended to me by my friends in Paper Route (see above). Could not recommend more.

Fin. Until the next year

Know of something that should have been on this list but wasn’t? I’m always happy to get suggestions.

This site now runs on HTTPS and PHP 7

WordPress recently made a few changes to its recommended requirements and now recommends using PHP 7 and HTTPS. I had some time this weekend and set out to upgrade my site and document some of the issues I ran into in the process.

For both of these tasks, I followed the tutorials at DigitalOcean, which were terrific. Even so, I ran into a few snags—some of which were specific to WordPress.

Setting up HTTPS

The first problem I encountered while setting up HTTPS was a result of upgrading my server configuration before changing my siteurl and home settings (in Settings > General ). Since WordPress was redirecting requests to the non-HTTPS URL, the server fell into a redirect loop and crashed.

I fixed this issue by using WP-CLI to update the relevant options from the command line, since I was locked out of my admin. I could have gotten this working by defining constants in my wp-config.php file as well, but it would be nice if WordPress detected this problem and showed some kind of “upgrade your site” page rather than sending 301 redirects.

Another difficulty I ran into was that the DigitalOcean tutorial told me to set the server block to listen 443 ssl;, when it should have been listen 443 default_server ssl;.  After making that change, I was able to see the site over HTTPS.

The whole process ended up being way easier than I had expected. That said, there were a few things that were broken because of mixed content errors.

Issues I noticed after upgrading to HTTPS

  • Chrome blocks oEmbeds and shows an “insecure content” warning in the address bar when the external site is not running HTTPS. It would be nice if WordPress detected this and blocked the embed to avoid browser warnings.
  • Images included in previous posts still retain the HTTP scheme, which didn’t surprise me. What was unexpected was that srcset attributes—which are dynamically created when the page loads—retained HTTP URLs unless the image was generated from a caption shortcode, which seems odd.
  • My user account on this site was using as the website. It would be cool if this was automatically upgraded when I made the switch to HTTPS, but nothing was broken because of this.
  • It would also be nice if links to local content within old posts could be upgraded.

I used Ryan Markel’s HTTPS-All-The-Things plugin to fix several of these issues in the mean time (though the oEmbed bug still exists).

Upgrading PHP 7

Upgrading to PHP 7 was also a fairly painless process, save for a dumb mistake on my part, which was kind of funny:

Turns out I mistyped the location of PHP7.0-fpm.sock in my nginx config, which crashed my site 🙈.

PHP 7 began working once I fixed my configuration, but the site threw a fatal error because my debug-media plugin called gd_info(), which wasn’t available. Installing GD fixed this right up and I quickly modified the plugin, which helped me realize that I also needed reinstall ImageMagic to take advantage of cool features like PDF thumbnails.

The JetPack Publicize module displayed an error because I didn’t have multibyte support enabled nor the XML extension for PHP 7. I install those extensions manually and now things seem to be working ok.

Automated WordPress coding standards checks using Atom

After being frustrated by missing simple coding style errors in my WordPress contributions, I finally decided to employ some tooling to help automate the process of checking my code. This is how I set up my machine so the Atom editor will automatically check code for WordPress Coding Standards.

Install PHP CodeSniffer

PHP_CodeSniffer is an automated tool for checking for coding style based on a set of defined standards. I followed the installation instructions on the project’s GitHub page to download the .phar files and then I moved them into my /usr/local/bin/ directory like this:

mv phpcs.phar /usr/local/bin/phpcs
mv phpcbf.phar /usr/local/bin/phpcbf

If everything went well, you should be able to type phpcs --version in the command line and see version information returned.

Install WordPress Coding Standards rules

The WordPress Coding Standards project is maintained on GitHub. I followed the standalone installation instructions to clone the project to my usr/local/bin directory and configure phpc to make use of the WordPress coding standards with the following command:

phpcs --config-set installed_paths /usr/local/bin/wpcs

Configuring the Atom Editor

Finally, to be automatically notified about WordPress coding style issues in my editor, I followed the setup instructions for Atom on the WordPress Coding Standards GitHub page using the linter-phpcs package for Atom.

From now on, I hope to spend less time worrying about any coding standards issues with my code and be more confident in the overall quality of the work that I’m doing.

Responsive Images in WordPress 4.4 – A personal story

WordPress is made by those who show up.

I’m not a super web developer. I don’t have any qualifications that would make someone ask me to help implement a new web technology on a quarter of the websites in the world. But nobody told me not to either, so here we are. Earlier today, WordPress 4.4 was released, including native support for responsive images. This is a brief account of how I accidentally became a lead developer of a new WordPress feature.

A few years back, a group of web developers noticed a problem. Web page sizes were getting larger—mainly so images would look good on new devices with fancy screens—making it harder for people to access websites on slower connections. The thing is, when you notice a problem, you have a few choices. You can either shrug and say, “I wish someone would fix that problem,” or you can roll up your sleeves and try to fix it yourself. Thankfully they chose the latter, and responsive images were born.

In early 2014, as I was learning about this cool new technology, I shared what I was learning at WordCamp St. Louis. Around the same time, I figured out how to submit a bug fix to WordPress and began making small contributions to the project. When I heard that the same group who helped to create responsive images were going to try bring those tools to WordPress, I decided to see if I could help.

Turns out, a guy named Tim Evko had created a WordPress plugin that automatically added responsive image support to WordPress and the group had decided to see if it could be used as a starting point for bringing responsive image support into WordPress by default. I installed the plugin to test it out and noticed a small bug. Since the plugin was being developed on GitHub, it was relatively easy for me to submit a bug fix (here is my first commit to the project), and I was immediately hooked when my code was accepted. Within a year, I had mounted up over 120 commits to the project and was writing blog posts on during the release cycle for WordPress 4.4.

I was extremely fortunate to get involved in a popular feature, because I didn’t need to do much selling to get it included in a release. There were several times where the amount of work looked overwhelming, but I decided I’d rather see the project fail because the lead WordPress developers voted it down, and not because I didn’t show up and do my part. Several talented people ended up getting involved to make this feature happen, and each time our small committed team didn’t have the expertise or bandwidth to move something forward, somebody from the community showed up and either pointed the way or contributed code to fix the issues we were having.

I’m extremely grateful to Tim and Jasper for being amazing teammates, for Mike and Andrew, who gave advice and/or completely rewrote sections of the code to make it perform better, and to Mat and the RICG for their support.

At WordCamp NYC 2014, Boone Gorges gave a great talk about the benefits you receive by contributing to WordPress. This has definitely been true in my experience. By working on this project, I’ve learned a ton about the internals of the WordPress image functions and benefitted from having my code reviewed from some of the best WP developers in the world.

This experience also reinforced my belief that a lot can be accomplished by simply asking what needs to be done and then giving yourself permission to work on a solution. There are many more ways to make the web (and the world) just a little bit cooler, and I’m looking forward to seeing how I can help.

Image credit: Mel Choyce