Better Plugin Recommendations for WordPress

Nick Hamze, a collaborator and friend goes into detail about why the WordPress plugin ecosystem needs some proper curation. I couldn’t agree more, the new user experience for WordPress users, in this regard is just not that great. That’s why I was eager to work with Nick on building out a very simple plugin + API to power a better “Recommended” tab for the plugins page in your wp-admin.

The current API is pretty simple and simply pulls a curated list of plugins (literally powered by a text file) and fetches data for those plugins using the WordPress.org plugins API (which was probably the hardest part of this project, as it’s very poorly and sometimes inaccurately documented — perhaps I should blog about the pieces I was able to figure out on my own). However, if the idea is well received in the community, I’d love to expand on it further and include some plugins from outside the WordPress.org plugin repository in our recommendations, as I think there’s some great third-party plugins that new users should definitely know about.

If you work for a WordPress hosting company, Nick’s inviting you to get in touch and discuss adding the plugin to your customer’s installations. Both the plugin and the small API server that powers the recommendations are fully open source as well, so feel free to fork them to create your own set of recommendations.

Read more about this on Nick’s Secret Pizza Party blog post

Let me know if you have any thoughts in the comments 💭👇

Laravel Continuous Integration using Codeship

In my last blog post, I talked about how we test our Laravel applications. In this post, I’d like to expand on how we’ve set things up for Continuous Integration using a service called Codeship.

First of all, let me define the term. Wikipedia defines it as “In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day”. In practice, for us, it means that my team and I can create Pull Requests for our projects at any time, and our continuous integration will run on that branch and either give it a green flag, or point out any issues that might be happening.

We actually have two different CI services setup, Codeclimate, which we use for linting, coding standards and other code quality tools (I’ll have to blog about this later); and Codeship which we use to run all of our tests.

Part 1: setting up the world

The first thing you’ll do after signing up for a Codeship account is to connect it to your version control repository. For us that was Github, but they also support other providers. Next, you’ll be asked to configure your test pipeline(s). There’s two (or more if you have several test pipelines) steps to this. The first one is “Setup Commands” where you can setup the world. Basically, whenever Codeship runs the tests on your code, it’ll prepare a new fresh virtual machine with your latest code checked out on it. The setup commands are the commands that run immediately after that is done. Ours look like this:

# set php version
phpenv local 7.1
phpenv global 7.1
# node version
nvm install 7.6.0
# Install yarn
npm i -g yarn
# Install node-sass
yarn global add node-sass
# Optional GitHub auth for composer
composer config -g github-oauth.github.com [token]
# Install dependencies through Composer 
composer install --prefer-dist  --no-interaction
# set phpunit version
composer global require "phpunit/phpunit=5.*"
# copy env
cp -v .env.example .env
# generate key
php artisan key:generate
# front-end
yarn
npm rebuild node-sass
yarn build

I’ll break this down a bit:

  • First up, we setup the php and node versions that we want to use.
  • Secondly, I prefer working with yarn over npm as it is more reliable and locks dependency versions which prevents issues with version mismatches. So I install yarn. This part is optional if you prefer to use npm or don’t need to compile any front-end resources.
  • We use sass to write our css, and Codeship doesn’t come bundled with node-sass, so next up we install it.
  • Next, we optionally configure Composer’s GitHub auth with a token. This speeds things up a bit with composer installs, read more about it here. Then, we install Composer dependencies.
  • Next, we set the version of phpunit to be used, 5.x in our case at the time of writing.
  • Finally we do a bit of Laravel and project specific setup, copy our .env.example file, generate an application key, and run yarn to compile our front-end resources

Part 2: Unit & Feature tests

Screen Shot 2017-04-08 at 2.35.32 PM.png

By default, Codeship provides you with a single test pipeline, named “Test Commands”. We use this default one to run our Unit and Feature tests with phpunit.

The test command here is super simple:

php vendor/bin/phpunit

This just runs phpunit using the version that’s installed with composer locally for the project.

Part 3: Browser & JS tests

We use a second test pipeline to run our Browser (Dusk) tests and Javascript (jest) tests. This step does require a small change to Laravel’s default DuskTestCase to work correctly on Codeship.

We modified the driver() method in the tests/DuskTestCase.php file, like so:

/**
 * Create the RemoteWebDriver instance.
 *
 * @return \Facebook\WebDriver\Remote\RemoteWebDriver
 */
protected function driver()
{
    $chromeOptions = new ChromeOptions();
    if ($binary = env('DUSK_CHROME_BINARY')) {
        $chromeOptions->setBinary($binary);
    }
    $chromeOptions->addArguments(['no-first-run']);
    $capabilities = DesiredCapabilities::chrome();
    $capabilities->setCapability(ChromeOptions::CAPABILITY, $chromeOptions);

    return RemoteWebDriver::create(
        'http://localhost:9515',
        $capabilities
    );
}

Next, we create a separate .env.dusk.testing file for dusk specific environment configuration. In order to get Dusk running correctly on Codeship, you will need to specify the APP_URL as [http://lvh.me](https://documentation.codeship.com/basic/continuous-integration/using-subdomains/%5D so that Dusk has a URL to hit.

Finally, we can go back to the pipeline in Codeship and add the following commands:

# don't start chromedriver automatically
export DUSK_START_CHROMEDRIVER=false
export DUSK_APP_PORT=8000
# use correct version of chrome (57 )
ln -sf /usr/bin/google-chrome /home/rof/bin/chrome
export DUSK_CHROME_BINARY=/home/rof/bin/chrome
# startup chrome driver manually
nohup bash -c "./vendor/laravel/dusk/bin/chromedriver-linux 2>&1 &"
# boot up the larval app
nohup bash -c "php artisan serve --env=dusk.testing 2>&1 &" && sleep 4
# run dusk
php artisan dusk
# run our javascript tests
yarn test

First we setup some environment variables to overwrite the Dusk chrome driver auto-start, and set the port. Then we set the correct version of Chrome to use (by default Codeship uses chromium with an outdated version that doesn’t work with the latest webdriver…). Then we boot up the chromedriver, and the Laravel app using the built-in artisan php server.

Then we run our dusk tests, and finally our jest tests.

Putting it all together

As a last configuration step, we need to set environment variables using the Environment settings tab for the project in Codeship; this will set the correct settings to use for testing.

Screen Shot 2017-04-08 at 2.44.25 PM.png

These should hopefully be self-explanatory and are documented in the Laravel docs. We do also set the COMPOSER_HOME value so that Composer uses its internal cache to speed things up.

That’s it, from now on, whenever you push code to your repository, Codeship will run tests and notify you if any tests fail!

Screen Shot 2017-04-08 at 2.51.46 PM.png


Have you setup CI for your projects? Any struggles or tips you’d like to share? Let me know in the comments 💭👇.

Test Driven Development with Laravel

At Spark Consulting, we put a great emphasis on automated testing of our code. Doing so has a bunch of benefits:

  • we can ship things with confidence knowing they won’t cause any regressions or unintended side effects
  • it makes it easier to review changes because I can easily see how a piece of code is intended to work by reading the test; tests essentially act as developer documentation
  • allows developers to catch mistakes in their code before committing/deploying
  • it keeps code quality high by ensuring we all follow the same sets of conventions
  • it’s actually fun; it’s a really great and rewarding feeling to see the following whenever you run your tests after writing some code:

[f5141f4250a86c6936323c1f4cc645be]_Image202017-04-0820at201.07.0320PM

  • stress-free deployments, knowing that the chances you unintentionally broke something are pretty low

Our development framework of choice, Laravel has a bunch of awesome testing tools built-in which make all of this really easy.

Our tests are organized as following:

Screen Shot 2017-04-08 at 1.17.51 PM

From bottom to top:

  • Unit contains our unit tests; most projects actually have very few of these. We mostly use unit tests to test a few key pieces of custom functionality and relationships between Models. Unit tests don’t generally load the entire Laravel application. Almost everything else in the php codebase is tested as a Feature test.
  • React (sometimes also just named js depending on the project) contains tests written using the jest test runner and in the case of React, the enzyme test helper . These tests are meant to test front-end Javascript functionality, such as React components and Javascript helpers/utilities that we’ve written for the front-end.
  • Feature contains tests that ensure that our php codebase works as expected by loading the entire Laravel application and performing full Http requests. These are primarily API tests to ensure our API endpoints work as expected, but anything that is php-driven and requires the application to test would be a Feature test in my approach.
  • Browser contains end-to-end integration tests that test the web application in a browser directly, using the new Laravel Dusk testing utility. We use these to test individual pages at a pretty high level and ensure that key data and key functionality works as expected.

Having these different levels of testing allows us to ensure the application works correctly from different angles, and covers all of our bases. Think of Browser tests sort of being the super zoomed-out view, where we can ensure that the main pages and functions of the site work as expected, and then we slowly zoom in with feature tests, js tests and unit tests ensuring that each piece of our codebase works as expected.

With this setup we end up with three different testing commands:

  • phpunit which runs both our Unit and Feature tests
  • php artisan dusk which runs the browser tests
  • jest (which we alias in our package.json so we can run npm run test or just yarn test using yarn) to run the Javascript tests.

If you’d like to learn more about Test Driven Development with Laravel, I highly recommend Adam Wathan’s Course. Even though I already grasped the basics, Adam’s course really cemented some best practices and showed me a better way of thinking and approaching tests.

In the next blog post, I’ll go through our Continuous Integration setup and explain how we automate all of this testing so that each Pull Request/deployment gets automatically tested.

The blog is back 🆒 🆕

After too long of a hiatus, almost a whole year (and let’s face it, it was pretty sporadic before already). I’ve decided to bring this blog back and try to share a bit more about myself, my business and the technologies I work with. I think putting things out in public is a great exercise in growing as a developer and a business founder.

Going forward, you can expect blog posts related to Laravel, WordPress, running a business and other tech-related topics.


I thought I’d start with sharing what’s been new with me and my business in the last year:

  • I left Automattic last June; after four years with this incredible company, and an amazing set of people, I felt it was time for me to experiment with things on my own once again and grow beyond the confines of any single corporation (awesome as that one is).
  • I founded Spark Consulting which is a small and nimble software and web development company. We operate as a collective of developers, designers, project managers, and copyrighters. At first, it was just me, and stayed as such over several months, but we’ve grown to a team of ~7 people since then (~ because none of us are technically employees, and we form teams between us on a per-project basis). It’s been challenging and super rewarding to grow the team.
  • Our biggest client has been The Image Salon, which is a team of 50+ photo editors who work on professional photographers’ images, saving them a ton of time. It’s also owned and operated by my brother and his wife. Lots of people have reservations about mixing business and family, but it’s been really great to work with my brother on this; and lots of fun to integrate myself and the rest of the team into their company, as we build out a ton of technology tools for them and their clients.
  • I’m working with several junior developers, and it’s been a lot of fun to mentor them, teach them and see them grow into better and better developers.
  • It seems that the spring is when everyone wants a new website or web application built, after several months of fairly occasional requests, we’re now seeing a large volume of incoming requests, which is great!
  • I’m back in Vancouver full time but still enjoying travelling close and far and exploring the beautiful local BC area.
  • While I still work with and love WordPress, I’ve gotten way more into Laravel, React and Vue lately, and am really enjoying the workflow with these 3 technologies (we don’t mix React and Vue in the same projects though!).
  • I’m experimenting with two different SASS ideas to launch as little side businesses to complement the client work. Excited to share more about that in the future as well.

— That’s it for now, more to come. And if you’d like subscribe to the blog using the menu on the site, or follow me on twitter @jkudish.

PS: it’s kind of fun to return to several tools I helped build for WordPress.com over a year later (Calypso Editor, Sharing, etc.). Some of these are really polished now. Nice work ex-colleagues

WooCommerce Connect

For the last few months, I’ve been working on a new project within Automattic. I’m pretty excited that we announced the alpha testing phase for it today. It’s called WooCommerce Connect, and it’s a new way of delivering services to extend WooCommerce, the e-commerce plugin for WordPress.

With Connect, we’re simplifying the way that shop owners manage various services. Starting off with shipping today but eventually with various types of extensions, we’re bringing a better UX, less configuration, faster integrations and a modern codebase to the WooCommerce ecosystem.

You can read more about it in the official announcement, and help us shape the future by testing it out on your test or staging site today.

And if you’re a developer or just curious about the code, we’ve open sourced the plugin, which will eventually be included in WooCommerce core, so you can read it, get inspired and maybe even contribute to it. It does set a bit of precedent from a technological stack point of view as it uses React, Redux, Webpack, and other Javascript projects and integrates with Calypso components. You can read more about it in our developer blog post.

Make sure to sign up in the announcement post to get updates as we get closer to a final release!

I also gave a presentation about this and other tidbits about WooCommerce at WordCamp Vernon just a few days ago, the slides are at slides.jkudish.com and the video recording will be up in a few weeks.

What is code?

Bloomberg Businessweek recently released The Code Issue, a special double issue containing a single essay by writer and programmer Paul Ford. It’s a great insight into the daily lives of programmers. A bit technical in some parts, but I think the vast majority of people will understand most of the article. It’s long but well worth the read.

A really valuable insight for my friends and family who wonder what it is that I actually do. Minus the part where the author sort-of dissed WordPress 😉 — though that’s certainly a view of the programmer community as large and something we’re working on changing.

Pick up the actual magazine as I did (to read on the plane), or read it online here: http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/

Automattic acquires WooCommerce

Pretty exciting day in the WordPress world as Automattic (the company I work for) acquires WooCommerce. I’m gaining 55 new coworkers today which is incredibly exciting but also slightly terrifying. It’s getting harder and harder to keep up with everything and everyone and even harder to meet everyone. Look forward to the chaos at our next all-hands company Grand Meetup. It’ll be great to see us democratize ecommerce over the next years in this newly joint venture.

Read up about the acquisition on Matt’s blog: http://ma.tt/2015/05/woomattic/

PS: if you’d like to join the chaos, we’re hiring just as much as ever 🙂

PPS: if you’re reading this post on Facebook, via twitter or another social network, then it came to you via an all new Publicize codebase, which I’ve personally been working on for a few months. Excited to get it released to all WordPress.com and Jetpack users shortly 🙂