Git & WP-CLI on Windows

This short tutorial will help you get ready for WordPress development by setting up a localhost development environment with git and wp-cli on Windows.

The following tutorial / notes are for setting up a new localhost development environment in Windows.

1. Setup your Localhost Environment

  1. Download the Bitnami WordPress installer
  2. Follow onscreen instructions and Install!

That’s it~

I put my development environment in the D:/ drive

D:/Bitnami/WordPress

2. Prepare for git with VS Code

Gitbash (git for Windows) wants a default text editor – and while you could choose Nano or VIM or Notepad++, why not go with the (NEW!) option and get yourself a really great code editor while you’re at it~

  1. Download the Visual Studio Code installer
  2. Follow onscreen instructions and Install!

Learn about customizing Visual Studio Code for WordPress development.

3. Setup git with Gitbash

  1. Download the Gitbash installer
  2. Follow onscreen instructions and Install!
    1. Note: In the “Adjusting your PATH environment” screen, click “Use Git from the Windows Command Prompt”

4. Setup WP-CLI in Windows

Take a look at this walkthrough. I followed the steps outlined within it and made a few notes about the process for my particular setup.

  1. Download the wp-cli.phar file (right-click and “Save As…”)
  2. Create a new folder within your Windows user’s folder to hold all our executable files
    1. Create C:\Users\user\bin (where “user” is your Windows username)
    2. This is the ~\bin folder where ~\ indicates the user’s home directory
  3. In Visual Studio Code, create a wp.bat file with the following content:
@ECHO OFF
SET BIN_TARGET=%~dp0/./wp-cli.phar
php "%BIN_TARGET%" %*

This will execute the wp-cli.phar command from your command line (after doing a little more setup work).

  1. But, if you’re using Gitbash, Windows won’t recognize .bat files and their commands, so we need to create a separate file called wp (no file extension).
  2. In Visual Studio Code, you may get an error if you try to create and save a file with no extension, so just call it wp.sh for now.
  3. Later, in Windows Explorer you can remove the .sh.
  4. Paste in the following lines:
#!/usr/bin/env sh

dir=$(d=${0%[/\\]*}; cd "$d"; pwd)

# See if we are running in Cygwin by checking for cygpath program
if command -v 'cygpath' >/dev/null 2>&1; then
# Cygwin paths start with /cygdrive/ which will break windows PHP,
# so we need to translate the dir path to windows format. However
# we could be using cygwin PHP which does not require this, so we
# test if the path to PHP starts with /cygdrive/ rather than /usr/bin
if [[ $(which php) == /cygdrive/* ]]; then
dir=$(cygpath -m $dir);
fi
fi

dir=$(echo $dir | sed 's/ /\ /g')
"${dir}/wp-cli.phar" "$@"

So the previous step (wp.bat) makes wp-cli available from the Windows Command Line, and this step (wp.sh) makes wp-cli available from Gitbash.

5. Add php and wp-cli to the PATH

Now, we have to make sure Windows adds both php and wp-cli to the PATH so we can use them.

  1. Open up the Windows Control Panel → System (or right-click “My Computer” on the Desktop and click “Properties”)
  2. Click “Advanced system settings” in the left sidebar
  3. Click “Environment Variables…” in the popup
  4. Click “PATH” from the list and then “Edit…”
  5. Now add the full path to your executable files. In my case:
    1. PHP: D:\Bitnami\WordPress\php
    2. WP-CLI: C:\Users\user\bin
  6. Now, “Sign Out” of your Windows account and Log back in to be sure Windows loads the new PATH variables
  7. You can confirm both php and wp-cli are working by trying out a few different commands in Gitbash or the Command Prompt:
    1. php -i
    2. which php
    3. php -V
    4. wp
    5. wp plugin install hello-dolly (from inside your Bitnami/WordPress/htdocs/wp-content/plugins folder)

Great! Now you can use git and wp from the command line in Windows! Happy coding!~

Downloads

  1. Bitnami WordPress installer
  2. VS Code
  3. Gitbash
  4. wp-cli.phar file

Coding an Advent Calendar: Day 9 (5 React Configurations)

This year, I decided to create an Advent Calendar website in HTML5, CSS3, and JavaScript. My hopes for the site are to showcase some of my frontend development abilities as well as make something fun, functional, and reusable.

Day 9

create-react-app
Yesterday I was having some trouble with my React code functioning properly with the in-browser Babel compilation. Notably, I kept running into this error:

which clearly isn’t very helpful for debugging my code.

For one thing, sometimes the error message seemed to point to an empty line! I’d read on StackOverflow (somewhere) that perhaps that indicated the error was actually in the line ABOVE it, but it wasn’t. And I still couldn’t find where there was a problem no matter how much I looked, nor how many times I rewrote the code.

Finally I decided enough was enough and I was going to have to include Babel and all the other dependencies inside my project to compile everything there, rather than continuing to import Babel via CDN and try to compile in the browser. I figured if nothing else, at least I’d get some better error messages with code that was pre-compiled before being loaded by the browser.

So, on the suggestion of the Lynda.com video series I’ve been watching, I decided to create a totally NEW folder and install create-react-app via npm to help out.

npm install -g create-react-app
create-react-app advent-calendar
cd advent-calendar
npm start

Fortunately, after installing it and running the npm start process to watch and compile my files, I was immediately greeted with a MUCH more helpful big, bold, and beautiful (descriptive) full-screen error message:

This allowed me to properly diagnose my problems, debug the code, and get everything running smoothly. At first.

React Storybook
Actually, the FOUR setups I tried are very different:

  1. React + Axios in a Codepen
    1. Incredibly painless as all the configuration is provided by Codepen
    2. Easy to get started due to the number and quality of samples available
    3. Only requires linking to some scripts (react.js and axios.js) and enabling Babel as your JS preprocessor
    4. DOESN’T actually teach you a lot about how to set these technologies up and use them in a real-world project
  2. React + Babel + Grunt
    1. It requires a complete manual setup (installing everything you want via npm)
    2. More difficult for a first attempt to get everything configured properly
    3. But allows more precise control over exactly what you include in the project
  3. React and Babel via CDN
    1. It’s as simple as copying in a few URLs as <link> tags
    2. Easy to get started, but provides horrible error messages that are little help
    3. Requires NO node modules nor unique file/folder structure – you could build everything out as a regular static page (index.html, style.css, and React scripts before the closing <body> tag)
  4. React with create-react-app and webpack
    1. Super easy installation and process to get things up and running via npm (see code snippet above)
    2. Much more helpful error messages (like the one in black above) that can help you easily diagnose and fix problems with your code
    3. Includes TONS of node modules – many of which you may never need
    4. Requires its own file/folder structure that may be confusing at first (all your .css files and React components are abstracted out into a /src folder that will be compiled into .css and .js files with a hash string appended to the end like a version number (app.d587bbd6e38337f5accd.js) and put in the /public folder when you do npm run build to get it ready for deployment)
    5. Requires digging deeper into more technologies you may or may not have ever heard of before. For example, for me, I’ve only now ever HEARD of:
      1. webpack
      2. flux
      3. redux
      4. storybook

I haven’t even visited the websites for webpack, flux, or redux yet, but storybook instantly had me interested because of what it allows you to do: “Developing Components in Isolation.” I knew immediately that this was something I’d want to try – since I have multiple Components I will be developing:

  • First of all, Test Components to help learn React better
  • Secondly, a Gift Component for my CSS gift shapes
  • Also, a Post Component for blog posts loaded with the WP REST API
  • Possibly also other Christmas Components – like a Santa, or tree, or reindeer

So, I set about the work of figuring out how to get Storybook up and running (for my 5th React setup). A few things I noticed about Storybook:

  1. React + Storybook
    1. create-react-app uses npm start to run a server though port :3000
    2. Storybook defaults to run a server through either port :9001 or :9009
    3. Adding static .css or .js files can be a pain because of the configuration and how Storybook compiles things. There are really only two ways to do it:
      1. Add Custom <head> tags
      2. Serve static files via imports or a directory
      3. I ended up just using the CSS @import rule to load my Google Fonts
    4. Storybook was designed to develop Components in isolation – and it’s really a great way to perfect individual parts before putting them all together again in the main App
    5. Adding in additional Stories is pretty straightforward once you get through the configuration
Update npm and node and figure out git  
One of my biggest issues throughout developing this project has been that I have two completely different setups to work with throughout the day:

  1. At work: Windows 7
  2. At home: MacOS

That means that no matter where I go, for half the day at least, my configuration is going to be totally different. So, whenever I spend a few hours in one location learning how to setup and configure some part of my setup, I must then (at least partially) repeat that process in the other location later that day. It can be a little monotonous, but honestly the repetition is probably really good for my learning (that, and blogging about it).

Three things that seem like they may be larger “speed bumps” than they probably should be are: npm, node, and git

  1. At work: after installing create-react-app and the various other parts I needed, I kept noticing that the Command Line was prompting me with warnings about my (outdated) versions of npm and node. I didn’t really think much of it, but noticed that the installation of those modules took significant time (I ate lunch during the process)
  2. At home: When I came home later in the evening, I started getting the same errors, but again thought nothing of it – until my Mac froze up (it happens sometimes when I have a bunch of programs and Chrome tabs open and I haven’t shut down in a month…) So, after restarting the Mac, I decided to immediately update npm and node and WOW! what a difference that made! The installation of create-react-app and the Node modules FLEW compared to earlier. Below is the series of (Mac) commands I used in the Terminal to update them:
npm install npm@latest -g
sudo npm cache clean -f
sudo npm install -g n
sudo n stable

Finally, git. At first, I was worried that with the two different setups on the two different systems that git would prove to be problematic. I was worried that I might have to either memorize the differences in files and setup between Windows and Mac, or create two separate package.json and other relevant files.

However, after looking over the config files from both my Windows and Mac setups (I set up two completely different folders with the files from each system), I no longer think that’s the case. They look nearly identical and a few minor version number changes in the dependencies won’t really matter (down a version number).

So… Day 9 was a LONG day (which is why this blog post is long – and why I’m “technically” publishing it on Day 10), but it was a good day – not entirely productive in code, but very helpful in my learning more about React and how to work with it.

Today, I’m planning to finish React.js: The Basics on Lynda.com, create some new Components, possibly add in Sass (again) to my create-react-app project, and possibly add some interactivity to my Christmas Gift Component. Stay tuned!~


Work Completed (to date)

  • December 9, 2016
    • Learn and use Create-React-App
    • Learn and use Storybook for developing React Components in isolation
    • Update npm and node and figure out my git process between Windows and Mac
  • December 8, 2016
    • Use React and Babel via CDN to get it working “locally”
    • Install React developer Tools for Chrome
    • Create very basic React.js pages to learn it
  • December 7, 2016
    • Pull post data with the WP REST API in WordPress core!!
    • Write structural code for the React Component to be rendered
    • Install and setup BabelJS to compile the React code
  • December 6, 2016
    • Add README.md
    • Add a GitHub Issue to hold usable images
    • Add LICENSE
  • December 5, 2016
    • Create a GitHub repository and full site files for easier management
    • Setup Grunt.js to compile my Sass into CSS
    • Begin blogging about the process
  • December 4, 2016
    • Countdown clock (JS Date class & jQuery Easing) with SVGs
    • Dynamic text output for Year based on the current date
    • CSS only slider (off by 5px each slide)
  • December 3, 2016
    • CSS bow & ribbon
    • Footer with FontAwesome presents
    • Hover, active, and “Christmas Day” styles for footer presents
  • December 2, 2016
    • React.js + Axios.js initial code structure
    • Color palette
    • CSS → Sass
  • December 1, 2016
    • Let it snow
    • Typography choices
    • CSS presents (first design)
    • Design notes menu

Coding an Advent Calendar: Day 5 (Maintenance)

This year, I decided to create an Advent Calendar website in HTML5, CSS3, and JavaScript. My hopes for the site are to showcase some of my frontend development abilities as well as make something fun, functional, and reusable.

Day 5: Maintenance

GitHub Repository
After coding for 1-2 hours each day for 4 days, I found my code getting quite long:

  1. HTML: 344 lines
  2. SCSS: 602 lines
  3. JS: 187 lines

This quickly starts to become a lot to manage within a Codepen – given that the 3 editors are all small boxes to the side of the screen. I prefer to work on bigger projects in a good code editor like Atom or Brackets (I use Netbeans for really big projects like WordPress themes or plugins). So, I decided it was a good time to upgrade the project to “bigger” and continue development primarily in Atom (which has a convenient Live Server package that really aids in development).

I’ll continue to update the Codepen with my code updates – at least for now.

Setup a Grunt Taskrunner
Codepens are nice in that the Sass, or Less, or PostCSS is instantly compiled and usable as CSS as soon as you write it. But, things don’t work like that in stand-alone projects. So my first step after pulling my files from Codepen and creating a GitHub repository for them was to start preparing to use Grunt.js as a taskrunner to watch and compile my Sass into web-browser-readable CSS. Here are the steps I took (which will be outlined in further detail in a later post):

  1. In the global environment
    1. Install Node.js (Windows)
    2. Install Ruby (Windows)
    3. Install Sass: gem install sass
    4. Install Grunt-cli: npm install -g grunt-cli
  2. In the project folder
    1. git init, commit, and push to remote repository
    2. npm init to setup package.json which keeps track of dependencies
    3. npm install grunt-contrib-sass --save-dev installs the package locally (without --save-dev it would be a global installation)
    4. npm install grunt-contrib-watch --save-dev
    5. npm install grunt-autoprefixer --save-dev to autoprefix the CSS
    6. Create the Gruntfile.js that controls grunt and the Sass file compilation
    7. Run grunt from the command line (in my project folder) to start the taskrunner and allow me to modify my Sass files (CTRL + C ends the taskrunner)

For more information on this process, check out Morten Rand-Hendriksen’s helpful Course @Lynda.com:

WordPress: Developing with Sass and Grunt.js

Begin blogging  
Finally, in order to begin attempting to get the WP-API running well on this site, I needed some content on a WordPress site to begin pulling from – hence the creation of this series of blog posts.

As mentioned previously, I’m also hoping to create a 25-day series for Advent that highlights my favorite typefaces. The goal is to allow users to switch the series of posts that the REST API pulls from. They’d be able to either load the “Coding an Advent Calendar” series, or the “Advent Typography” series.


Work Completed (to date)

  • December 5, 2016
    • Create a GitHub repository and full site files for easier management
    • Setup Grunt.js to compile my Sass into CSS
    • Begin blogging about the process
  • December 4, 2016
    • Countdown clock (JS Date class & jQuery Easing) with SVGs
    • Dynamic text output for Year based on the current date
    • CSS only slider (off by 5px each slide)
  • December 3, 2016
    • CSS bow & ribbon
    • Footer with FontAwesome presents
    • Hover, active, and “Christmas Day” styles for footer presents
  • December 2, 2016
    • React.js + Axios.js initial code structure
    • Color palette
    • CSS → Sass
  • December 1, 2016
    • Let it snow
    • Typography choices
    • CSS presents (first design)
    • Design notes menu