Deploying a React App to Netlify

As part of the creating a headless React-based frontend for my WordPress site, I decided to try hosting my files on Netlify. They tout being super fast when serving a non-database site; a natural fit for a React project. Wes Bos’s React for Beginners course shows how to deploy to Netlify using the netlify-cli npm package. However, since completing that course, I updated to Node 10, which is not compatible with netlify-cli and Netlify recently deprecated it. In this post, I’ll detail how to deploy a site from the command line using their new command line tool: netlifyctl.

Sign Up for Netlify

If you don’t already have an account, head over to and sign up for an account. You shouldn’t need to create a paid account yet, so don’t worry about adding payment options.


First off, you’ll need to install the new tool on your computer. On OS X, it’s available through Homebrew and on Windows, it’s available through Scoop.


If you don’t already have Homebrew installed, open Terminal and enter this command, then follow the prompts:

/usr/bin/ruby -e "$(curl -fsSL"

With Homebrew installed, point to the netlifyctl tap:

brew tap netlify/netlifyctl

Next, install it:

brew install netlifyctl


If you don’t already have Scoop installed, make sure you have PowerShell 3 or higher installed, open it, then install Scoop using:

iex (new-object net.webclient).downloadstring('')

With Scoop installed, add the netlifyctl bucket:

scoop bucket add netlifyctl

Then install it:

scoop install netlifyctl

Deploying a React App

In this case, I’m specifically talking about a project created with create-react-app. If you aren’t using create-react-app, you will need to change some paths to match your project.

With netlifyctl installed, change directories into your project:

cd /myreactapp


Start by giving your app permission to access your Netlify account.

netlifyctl login

This will openyour Netlify account in a web browser and ask if you want to give the CLI permission to access your account.

Netlify grant permissions prompt

Click the Authorize button. Once it confirms the CLI has permission to access your account, you can close the browser tab/window.


If you haven’t already, run the build process for your app. For create-reat-app, that’s:

npm run build


Next, use this command to start the deploy process to Netlify:

netlify deploy

It begins by asking if this is a new site. Entering “no” allows you to search by name for the existing site. Entering “yes” creates a new site.

Either way, it then asks for the path you’d like deployed. For a create-react-app project, it is:


This uploads your build directory to Netlify and prompts you with the URL for your deployed app, which you can alt+click to view.

Last Things

That’s it! Your site should be visible on Netlify! A few last things: you’ll notice there’s now a netlify.toml file in your project. This file contains the settings you selected while deploying your app. Commit that file to your git repo to avoid answering those prompt again in the future.


If you forget how all this works, you can use:

netlifyctl --help

This lists out the commands available and how to use them. You can also use it with a specific command like:

netlifyctl deploy --help

Bonus Material

If you need to make changes to your app – say you’re like me and you forgot to run “npm run build” first so you deployed the default create-react-app build folder – and you need to re-deploy the project. Fortunately, it’s very simple:

netlify deploy

However, each time, the script prompts for the build path. This”feature” grows tiresome when you forget another thing, then another thing, then another thing and perform several deployments in a row (not that I would know from experience…). To avoid this, edit the netlify.toml file and add the build path. The default file includes your Netlify site ID and:

  Publish = ""
  Functions = ""

Add your build path in the Publish value between the double quotes:

  Publish = "./build"

Now, the deployment script uploads the files from the build folder and doesn’t stop for prompts each time.

Troubleshooting WordPress AJAX

I was working with some AJAX functionality a while back and started writing down the problems and solutions I ran across so they were all in one place. Basically, this post is for my future self. I hope you find it useful as well. 🙂

Specific Problems

Function Always Returns 0

If you’re getting a “0” as the response from an AJAX call in the admin, it’s most likely one of three things:

  • WordPress can’t find the function you’ve hooked.
  • You don’t have a wp_die() at the end of the PHP function.
  • The action isn’t in the data you’re sending to the PHP function.

403 Forbidden Error

Check the Nonce. You probably copied it from another function and it’s checking the wrong one.

Helpful Tip

The PHP function that processes the AJAX request has to echo something and should end with a wp_die() statement. You can use wp_die() to return something you want to see, like what data was passed to the function.

wp_die( print_r( $some_array ) ) is useful to check an array.

PHPUnit tests and WP-CLI

I recently discovered an easy way to add unit tests to my plugins. I’ve been using WP-CLI for years now to set up new local installs of WordPress and found out it has a command specifically for setting up PHPUnit for plugins. This post is partially for my future self so I can remember how to do all this. FYI, I’m on a Mac, so all the commands will be OS X-specific.

Install and Configure PHPUnit

Start by installing PHPUnit using Homebrew:

brew install phpunit

That installs the latest version of PHPUnit and makes it ready to use with the global keyword “phpunit”.

Next, use WP-CLI to setup the test suites and such needed for PHPUnit. I recommend running this command from the plugin’s directory.

wp scaffold plugin-tests my-plugin

Replace the “my-plugin” part with your plugin name.

If you aren’t already in your plugin directory, change to that now. Then you’ll run the installation bash script.

bin/ wordpress_test root '' localhost latest

Notes about this command:

  • ‘wordpress_test’ is the MySQL database created by this script and used for testing
  • ‘root’ is your local MySQL user
  • ” is where your local MySQL user password goes
  • ‘localhost’ is where you MySQL server is located
  • ‘latest’ changes the version of WordPress to use for testing.

Once you’ve run this script, you’re ready to start writing tests and running them using the ‘phpunit’ command. Here’s the rub though: the script installs WordPress and the testing suite in the /tmp directory. Why is that a  problem? On my computer, at least, the /tmp directory removes anything installed there upon reboot. Which means I need to re-run the tests bash script every time I reboot the computer.

Since we developers prefer not repeating ourselves, here’s how to configure things for a more permanent solution.


What I’m advising here is to move the stuff installed in /tmp to somewhere else, then fix all the references so they still work. So, run all of the above, then navigate to your /tmp folder. Move the /wordpress and /wordpress-tests-lib folders to another location outside the /tmp folder. I moved mine into a directory called unittests in my Dropbox folder.

Go to your Home folder and either open or create the .bash_profile file. You’ll probably need to tell Finder to show Hidden files first. In your .bash_profile file, add the following line, using your new directory location:

export WP_TESTS_DIR="/Your/New/Folder/Location/unittests/wordpress-tests-lib"

This line tells the PHPUnit bootstrap.php file where to find the test WordPress install and test suite files.

Now, go to the wordpress-tests-lib directory and open the wp-tests-config.php file. Edit the ABSPATH constant to the ‘/wordpress’ directory you copied over from /tmp earlier. Something like:

define( 'ABSPATH', '/Your/New/Folder/Location/unittests/wordpress//' );

Save the file and reboot your computer. Now, the tests setup by WP-CLI know where the testing WordPress is located, it doesn’t disappear when you install updates or reboot, and you can create and run PHPUnit tests for your plugins!

How to Change the Featured Image Labels

When creating a site for a client or creating a plugin, I’ve found its helpful to customize things as much as possible to the intended usage. This is especially important for client work since most clients have an internal language, or terminology they use for things. In the case of Featured Images, the site or plugin might be using the featured image differently than how one might use it on a news or blog post.

I’m currently writing a plugin with a custom post type and using the featured image as a headshot for an employee. While “featured image” may work fine, “headshot” is more specific and makes more sense in this context. I haven’t been able to find anything recent about how to change the labels on the existing Featured Image metabox. The most commonly referenced code only works some of the time. Specifically, when one removes a featured image, the label for the link changes back to referencing “featured image” instead of the customized label.

I dug through the core and found the post_type_labels_{$post_type} filter, which was added in version 3.5. This filter makes customizing the featured image labels super easy:

* Changes strings referencing Featured Images for a post type
* In this example, the post type in the filter name is "employee"
* and the new reference in the labels is "headshot".
* @see
* @param object $labels Current post type labels
* @return object Modified post type labels
function change_featured_image_labels( $labels ) {
$labels->featured_image = 'Headshot';
$labels->set_featured_image = 'Set headshot';
$labels->remove_featured_image = 'Remove headshot';
$labels->use_featured_image = 'Use as headshot';
return $labels;
} // change_featured_image_labels()
add_filter( 'post_type_labels_employee', 'change_featured_image_labels', 10, 1 );
view raw gistfile1.txt hosted with ❤ by GitHub

The labels are in an object and we then reset the values of each specific item to what we want. Then return the object.

Child themes for WooThemes

I’ve been using child themes for several years now, but I’d never used one with a theme by WooThemes. Most of my clients needed simple customizing, so I used WooTheme’s backend options to make the changes.

A recent client needed a bit more than I could do through their backend though. I started off making the customization directly in the theme, which is never a good idea. Catching my mistake, I decided to throw my changes in a child theme and work from there. However, reloading with the child theme activated, everything was borked. Looking at the source, I noticed how the stylesheets were loading because my child theme stylesheet should be last in the cascade, therefore overriding all other styles. There were two files from the parent theme loading after mine. I tried several solutions, hoping a newer one using wp_enqueue_style to load the parent stylesheet instead of @import would work, but that didn’t affect the other two stylesheets.

Thankfully (before pulling my hair out), I found this page in the WooThemes support docs. What they don’t spell out on the page (not helpful WooThemes!) is that you don’t actually make CSS changes in the child theme style.css. You make a second CSS file called custom.css and make your changes there. The custom.css file is loaded next-to-last, only followed by styles put into their custom CSS field on the backend forms, and therefore overrides all the other stylesheets.

Subversion, Coda, and WordPress

I’ve been using Panic’s Coda to develop my WordPress plugins and manage my sites and I love it.  When I published my first plugin, it took me quite a while to find any real resources on using Coda with WordPress’s Subversion servers.  It’s fairly simple stuff really, but updating plugins baffled me for the longest time and I’ve finally figured out the proper steps to do it without errors or partial uploads (as evidenced by the version 0.32 of ArtistDataPress plugin that didn’t include the widget, css, or images folders…).

Random tip: when developing, use the trunk files.  These files aren’t the ones given to the public and if you have more than one developer, this is where each of checks out the files you’re working on.

For those using Coda and wanting to develop for WordPress, these are tested instructions for updating a plugin:

Make changes as needed to your plugin files.  Be sure to update the stable version number in your main plugin and readme files.

Go into the tags folder.  Duplicate the latest tag folder in there.  When it asks if you want to update, say yes.

Change the name of the folder to the latest version number.  Say yes to updating.

Copy the updated files from the trunk folder into the newly-created tag folder.  At this point, there should be a green A next to that tag folder.

After all the files have been copied to the tag folder, click the green A.  This will add this folder to the SVN repository.  Coda will ask you to type in notes about the changes – make them as detailed as possible, this is the only thing people in the future will see when looking at why the plugin was changed to a new version.

The new tag folder and all the updated files should be added to the SVN repository.  Wait about fifteen minutes and you should see the changes reflected on the plugin’s page in the WordPress plugin directory.

If the steps above don’t work or you start getting odd errors (like you need to force an update), copy your trunk files to your desktop and remove the site.  Then add the site back and check out the repository again.  Then follow the steps above.  I just ran into this today (2/11/2012) and this worked for me.