Updated 02.18.2015

How to install WordPress Plugins with Composer

What happens when you’re working with another WordPress developer, both developing a site locally, and someone updates the plugins on their local version? Their syntax and implementation may be different than yours if it was a major release. Suddenly, your local copy is broken. No fault of your own, just inconsistencies within the project.

What do you do? How do you prevent that from happening?

Let me present another scenario. Maybe this one will hit a little closer to home. Everytime you set up a WordPress site, you have to go through the same motions of downloading, installing, and activating a set of plugins. Maybe you’ve upped the ante a little bit and have a set of files on your local machine you just copy and paste everything over. Regardless, it’s still a pain when those plugins are updated. You have to visit each individual site, download the revised plugin code and replace the existing copy on your hard drive.

There must be an easier way…and there is!

Composer

I’ve started using Composer in my workflow, now most of those headaches have evaporated.


First things first

Let’s get Composer on your machine (COUGH Mac).

If you visit Composer’s site, it will explain your options in more detail. My preference, though, was to install it globally so that the composer command can be run anywhere on your system.

Open the Terminal and from the command line, run:

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer

NOTE

If the above fails due to permissions, run the mv line again with sudo.


On to the fun part…

Within your WordPress project directory, create a file called composer.json.

Wordpress Project Structure

As the extension suggests, this is a preference file, written in json that describes the plugins you’ll be installing and their version numbers.

Here’s my broilerplate. Feel free to copy it and use it as a stating point for your own projects.

Let me walk through it line by line.

The first few lines are pretty obvious. Name is the name of your project. You can replace ahaywood/PROJECTNAME with your information. Ideally, this should reflect your repo name.

Under authors, you can change “Amy (Haywood) Dutton” and “email” to include your name and email address respectively.

I’m going to jump down to line 27, where it reads extras. This defines the paths for both plugins and themes. As you can tell, I have a wp-content folder within the root that includes sub directories for plugins and themes.

On line 33, I’ve listed all the plugins that the project requires.

WP Packegist makes this easy. They mirror all the WordPress plugin and theme directories as Composer repositories.

What does that mean?

If you got to WordPress.org and find a plugin you want to implement, you can also find it on WP Packegist.

Take the first plugin I have listed: Backup WordPress. The part of the URL that comes after /plugin is the name of the WP Packegist repo.

Backup WordPress on WordPress.org

If you’re still not exactly sure what the name of the repo is, WP Packegist just implemented a search on their site. (Quick Note: I searched for “Backup WordPress,” first, and it did not return any results. But, searching for “backupwordpress” returned what I was looking for.)

Backup WordPress on  WP Packegist

Line 34 includes the full name of the repository: “wpackagist-plugin/backupwordpress”.

Screen_Shot_2015-01-08_at_6_27_33_PM

You can also see there are several other plugins from Wp Packegist that I’m referencing:

"wpackagist-plugin/backupwordpress" : "3.0.*",
"wpackagist-plugin/intuitive-custom-post-order" : "2.1.*",
"wpackagist-plugin/wordpress-seo" : "1.7.*",
"wpackagist-plugin/wp-help" : "1.3.*",
"wpackagist-plugin/user-admin-simplifier" : "0.6.*"

See the Pen Highlight WPackgist by Amy Dutton (@ahaywood) on CodePen.

The number following the name is the version number. The star serves as a wildcard. This means for Backup WordPress, versions 3.0.1 or 3.0.4 would both qualify. You also have the option of being explicit when you define the version number:

"wpackagist-plugin/backupwordpress" : “3.0.4”

NOTE

Just checking to see if you’re paying attention here. One of the cases I made for Composer was that it would lock down your plugin files. How does that work with wildcards and version numbers, obviously 3.0.1 and 3.0.4 are not the same. — For now you can just trust me or if it’s really bothering, skip down to the section where I talk about the composer.lock file.

The only reason that Composer knows to look at WP Packegist for these packages, is because it’s defined as a reference on line 11 and 12.

"type" : "composer",
"url"  : "http://wpackagist.org"

See the Pen Reference Wpackagist by Amy Dutton (@ahaywood) on CodePen.


Setting up a Premium WordPress Plugin (or a plugin on a private repository)

You’ll notice several other repositories are referenced on lines 14 – 25:

{
     "type" : "vcs",
     "url" : "[email protected]:ahhacreative/ahha<em>plugin</em>acf.git"
},
{
     "type" : "vcs",
     "url" : "[email protected]:ahaywood/ahha-gravityforms.git"
},
{
     "type" : "vcs",
     "url" : "[email protected]:ahaywood/ahha-wp-db-migrate-pro.git"
}

See the Pen Reference Repositories by Amy Dutton (@ahaywood) on CodePen.

and implemented on lines 39 – 41:

"ahaywood/ahha-gravityforms" : "1.8.*",
"ahaywood/ahha-wp-db-migrate-pro" : "1.3.*",
"ahhacreative/ahha<em>plugin</em>acf" : "5.1.*"

See the Pen XJpeYw by Amy Dutton (@ahaywood) on CodePen.

The reason these are different is because they are premium plugins and unavailable on WordPress.org. I still want to use Composer, though, so I’m hosting them in private GitHub and BitBucket repositories

First, I tell Composer what type of files they are (vcs) and where they are located (url).

{
     "type" : "vcs",
     "url" : "[email protected]:ahaywood/ahha-gravityforms.git"
},

See the Pen EaZwRq by Amy Dutton (@ahaywood) on CodePen.


NOTE

The URL is the SSH address, NOT HTTPS.

Then, I reference them as project requirements:

"ahaywood/ahha-gravityforms" : "1.8.*",

That takes care of our composer.json file. Woo hoo


Now let’s talk about actually getting that plugin set up correctly on your BitBucket, GitHub, Beanstalk, or whatever account.

Here’s what I do: Download the plugin code. Create a folder on my computer where this code can live. I actually have a folder called COMPOSER for this exact purpose.

Composer Files in Finder

Within the plugin folder, create a composer.json file

Screen Shot 2015-01-08 at 9.13.24 PM

This file is a lot smaller than before:

  • name is the name of the repository
  • type is the type of file it is. — It could be “wordpress-plugin” or “wordpress-theme”. (Remember, when we talked about installer-paths in our first composer.json file? We defined the install paths for both a wordpress-plugin or wordpress-theme. Line 29 and 30. It actually looks at this line to know what the type of file it is and to make sure it gets installed in the right place.)
  • require this line refers tothe version of composer we’re running, NOT the version of the plugin. (Can you tell I’ve gotten that mixed up before?)

Add this folder as a local repository. My app of choice is Tower.

Add a Local Repo in Tower

Run an initial commit.

Then, create a remote repository and link it to your repository.

Adding a remote repository in Tower

Now, you’ll also need to create a tag for your commit. This relates to the version number you’re referencing in your composer.json file. I like for my numbers to match the develpers’ release numbers.

In Tower, you can click on the branch, then right click on a particular commit. Select “Create New Tag from…” in the drop down menu.

Adding a tag within Tower

In GitHub, tags are referred to as releases. So, if you’d prefer to do it from their site, you can click on the Releases tab, then Draft a new release.

Release inside GitHub
Draft a New Release inside GitHub

Updating your plugin

When you get ready to update the plugin, simply download the latest release from the developers’ site, then replace all of the code in your local repository with theirs.

Commit it, tag it, and push it to your remote repository.


F-I-N-A-L-L-Y

Let’s download all these plugins and actually install them on WordPress.

Within the root of your project folder, inside the Terminal, run composer install.

Run composer install from Terminal

It might take a while, but when it’s done, you can go to the Plugin screen of WordPress and activate all your plugins.


Troubleshooting

If you get an error within the Terminal about not having the right privileges to download the plugins, it’s probably related to your SSH keys.

I actually wrote a blog post about Setting up a Site with SSH. I can’t tell you how many times I actually reference that post myself! The post refers to SpringLoops, but the same applies here. Scroll down to where it says, “First, you’ll need to check for existing SSH keys.” Once you copy the keys to your clipboard, you can go to your service of choice, find the section that says SSH keys, and paste them there.

SSH Keys within GitHub
SSH Keys within BitBucket


Update January 26, 2015

I just moved all my Composer plugins off of GitHub to BitBucket. I had some problems. I kept getting an error everytime I ran composer update:

composer_update_error

I was finally able to get it to work, but I had to change the version number within my main composer.json file to dev-master. In context:


"require": {
     "ahhacreative/ahha_plugin_gravityforms" : "dev-master",
     "ahhacreative/ahha_plugin_wpdbmigratepro" : "dev-master"
},

Then, within each individual plugin’s composer.json, I had to add a version and dist parameter:


{
  "name": "ahhacreative/ahha_plugin_wpdbmigratepro",
  "version": "master",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "v1.0.6"
  },
  "dist": {
        "url": "[email protected]:ahhacreative/ahha_plugin_wpdbmigratepro.git",
        "type": "git"
    }
}

Update February 18, 2015

I just ran into an issue when I was trying to deploy my site via capistrano: No submodule mapping found in .gitmodules for path.

No Submodule Mapping Found

Fortunately, this article pointed me in the right direction. Within my root directory, there’s a file called .gitmodules, I opened it up and all that was listed was the WordPress submodule:

[submodule "wp"]
	path = wp
	url = git://github.com/WordPress/WordPress.git

I added the following lines:

[submodule "ahha_plugin_acf"]
 	path = wp-content/plugins/ahha_plugin_acf
 	url = [email protected]:ahhacreative/ahha_plugin_acf.git
[submodule "ahha_plugin_gravityforms"]
 	path = wp-content/plugins/ahha_plugin_gravityforms
 	url = [email protected]:ahhacreative/ahha_plugin_gravityforms.git
[submodule "ahha_plugin_wpdbmigratepro"]
 	path = wp-content/plugins/ahha_plugin_wpdbmigratepro
 	url = [email protected]:ahhacreative/ahha_plugin_wpdbmigratepro.git

Problem solved.


composer.lock

You’ll also notice that now, in addition to your composer.json file, there should be a composer.lock file. This file locks things down. It records the exact version of the file being installed.

If you want to update your site, simply go to the composer.json file, update the version numbers and then go to your project folder, inside the Terminal, and run composer update. Yep! That simple.


This seems awfully complicated…

Like a lot of things in the dev world, it can be a lot up front. That’s the learning curve talking. But, once that’s mastered, things go a whole lot faster. So, here’s my process now:

  1. Create a WordPress project using Yeoman.
  2. Within the root folder, create a composer.json file, copying and pasting my own GitHub boilerplate gist.
  3. Go to my project in the Terminal and type cu (I have Oh My Zsh! installed with the composer plugin activated.)

That’s it! 3 steps!



Posted 01.07.2015

The Lazy Smart Programmer’s way to set up a WordPress Site

Coding

When you get ready to set up a WordPress site, typically your process looks something like this:

  1. Download the latest version of WordPress from wordpress.org
  2. Unzip it.
  3. Copy and paste the files into a local directory (you are developing locally, right?)
  4. Create a MySQL database.
  5. Run the 5 minute WordPress install.
  6. Download your starter theme.
  7. Unzip it.
  8. Copy and paste the theme file into WordPress’s theme directory.
  9. Find your base plugins that you know you’ll need. Download each of them individually.
  10. Copy and paste the plugin files into WordPress’s plugin directory.
  11. Start your custom work.

That’s 11 steps, at least! I know, if you do it enough times you could probably get that down to a 15 minute setup, and that’s probably only if you have local versions of your boilerplate theme and plugins that you can quickly copy and paste into the respective directories.

But, why? Why would you even want to waste your time doing such mindless work every time you start a project when you could be spending that time designing and developing something beautiful and original?

What if I were to tell you that you could cut down that down to two minutes…on a bad day? Interested?

If you can hang with me for the length of this post, we can get you set up and you can start being more efficient.


Remember in English class, how they told us to (1) say what you’re going to say, (2) say it, and then (3) say what you said. I always remember thinking, “That sounds redundant.” Well, I’m going to take a lesson from Mrs. Nooks. I’ll tell you a little bit about the tools we’re going to put in our tool chest, then I’ll show you practically how to use them. It may get a little technical from time to time, but try to stick with it, it will be worth it.


Node.js

A lot of services are built on Node.js. If you visit the Node.js site it says it’s built on Chrome’s JavaScript runtime. Just know, that means f-a-s-t.

If we’re going to use it, we have to install it. Fortunately for us, this is easy. There’s a big green “install” button their site. Click it.

Node.js

Once the package is downloaded, unzip, and double click on the package to install it. Hooray!

Node successfully installed!

NOTE

Grunt and Gulp also run on Node. (Blog post for the future.) Just know, for now, we’re set up for success!

 

Yeoman

Yeoman is a project generator. It can do quite a bit, setting up sites and scaffolding (and not just for WordPress). We’re going to take the easy way out and use a generator Wesley Todd has already created specifically for starting a WordPress project: YeoPress.

NOTE:

To run YeoPress, Node is the only thing that is required (which we just installed), however, Wesley encourages you to have git and SASS installed, too. If you don’t, no worries, it’s pretty straightforward too:

git

You can go to the git website, download the file, unzip, and double click on the package to install it. Done and done.

SASS

SASS is a Ruby gem. If you’re working on a Mac, it comes with Ruby already installed. All you have to do is open up your Terminal (GASP I know, it will be OK.) and run the command:

gem install sass

If you get an error, chances are you need to run the sudo command:

sudo gem install sass

Sudo forces your computer to run the command. It will ask you to enter your computer’s password.

If you want to check to make sure everything was installed correctly, you can run:

sass -v

You should see it return Sass 3.4.9 (Selective Steve).

Now, for installing Yeoman (yo) and YeoPress (at the same time). Within the Terminal run:

npm install -g yo generator-wordpress

npm just means that it’s a node command.

Easy.

Now, within the Terminal, we just have to navigate to the folder we want to install WordPress inside of.

If I lost you at, “within the Terminal,” it’s OK.

For the longest time, I was uncomfortable inside the Terminal, too. But, I promise, the more you use the more comfortable you’ll become. As soon as you see the benefits that the Terminal provides your workflow, it will eventually become something you can’t / won’t want to ignore.

You can get started with the Terminal here.

Now, run:

yo wordpress

You’ll see the WordPress logo appear and it will start to ask you a series of questions about how you want to set up your WordPress install:

WordPress URL
If you’re doing local development (as you should), enter that URL in.

Running yo wordpress within the Terminal

Table Prefix
This is the table prefix for your WordPress database. By default it’s wp_. Stay with that. It makes it easy when you’re looking at your database to be able to tell which tables are related to your WordPress install.

Table prefix when running yo WordPress within the Terminal

Database Host, Name, User, Password

Entering Database credentials when running yo wordpress

I use a free app on my Mac, called Sequel Pro to manage my databases. But, if you’re using MAMP, you can do everything through PHPMyAdmin.

MAMP will also list all the credentials you need (host, user, and password) on the WebStart page.

Webstart Screen in MAMP

Use Git?
More on this later, too, but for now, take my word and just say “Yes”…err, rather “Y”.

use git inside yo wordpress

Would you like to install WordPress as a submodule?

There are people that sit on both sides of the fence on this one, people for and against.

My personal take?

First, let me explain what a submodule is. Submodules are a “Git thing”. It’s essentially an external Git repo that your repo references. Think of it as a nested repo that you can update it independently.

When you think of it in those terms, it makes sense to implement WordPress as a submodule. I don’t manage the WordPress core, so why not make it seperate and reference the actual WordPress repo itself?

If you implement WordPress as a submodule, you’ll using the following commands to update WordPress later:

cd wp
git fetch && git fetch –tags
git checkout 4.1
cd ..
git add wp
git commit -m “Updated to WP 4.1”
git push

Not too shabby.

NOTE:

If you get an error, when you try to update WordPress, like: Your local changes to the following files would be overwritten by checkout. Try forcing the checkout:

git checkout -f another-branch

So… “Yes” install WordPress as a submodule.

Wordpress as a submodule

WordPress install directory
My personal preference is “wp.”

This means when I log in to the admin panel, the address will be: http://SITENAME.dev/wp/wp-admin

WordPress content directory
I go with “wp-content.”

Directories for WordPress Install

Install a custom theme?
I choose “no.” But, I think this would be a good area, in the future, to streamline my process even more.

Does this all look correct?
It’s always comforting that it asks you to double check. “Yes.”

yo wordpress - all correct?

Boom! It will download WordPress for you and set up your config file. Granted, the set up may sound a little verbose, but we just condensed that 11 step process into a few lines of code.


For future reference:

If you clone your repo and the wp directory is blank (WordPress is a submodule, remember), run:

git submodule init && git submodule update

Also, if you need to update YeoPress, it’s as simple as running the following line:

npm update -g yo generator-wordpress



Posted 01.05.2015

Posted 01.05.2015

How to Overcome your Fear of the Terminal

Getting Started

For years, I’ve been afraid of the Terminal. I was scared that I would erase my entire hard drive with a single typo.

But, then I started using grunt. I found it to be so much faster and allowed far more task automation than the tools I had been using previously. IMHO, anything that will speed up your workflow is worth investing in (whether that’s time or money ).

Once I started spending more time in the Terminal, I became more comfortable and confident. Trust me, I still prefer a GUI (graphical user interface), but I’m no longer afraid I’m going to delete my entire harddrive. — And let’s be honest, you could delete your entire hard drive with a GUI too. Drag your harddrive to the trash and click “Empty Trash.” But, nobody in the right their mind would do that. Similarly, you’d have to type a very specific command in the Terminal to delete your entire harddrive and nobody in their right mind would do that either. — Plus if you have a typo in the Terminal, it will tell you and the command won’t run.


So, here are the commands that I’ve found to be the most useful:

NOTE:

When you see examples of command lines in the Terminal and you see a $. Don’t copy the $, it just signifies that it’s the beginning of a Terminal line.

cd stands for change directory. Similar to the Finder where you click on the folder, in Terminal, you just type in the directory that you want:

$ cd Sites

You can type cd .. to go up a level or cd ../.. to go up 2 levels. cd / will take you to your home directory.

The Terminal also supports tab auto completion. So you could type cd De<TAB> and it will fill in cd Desktop for you. Handy!

ls will list all files and directories in your current location.

pwd will show you the current file path to your current location.

mkdir FOLDERNAME will create a folder named FOLDERNAME. mkdir stands for “Make Directory.”

Anytime, you hit the up arrow on your keyboard, it will fill in the last command you ran. Hit it again and it will cycle to the command before that. The down arrow cycles in the opposite direction.

Just to give you an idea of how these commands are used together: when I first open the Terminal, I might type ls to see what my file / folder options are. Then:

$ cd Code/GIT/
$ mkdir NEWPROJECT
$ cd NEWPROJECT

This navigates to the GIT folder and then creates a new directory for a project. Then, navigates inside the folder I just created.

If this is still making your head spin, here’s a WYSIWYG way that I saved until the end: Open up your Terminal type in cd . Then, open up Finder, navigate to the Folder you want to open in Terminal and drag that folder from the Finder onto your Terminal window. It should enter the location for that file path for you. Now, hit <RETURN>. — You’re welcome.


If you’re feeling ambitious, a few other tips and tricks:

I use iTerm2 instead of Mac’s default Terminal. It has a little bit more functionality. My favorite feature, I have a shortcut set up so that any time I hit ALT + Cmd + Space, the Terminal overlays my entire screen. Using the same command sequence will toggle it off. This is great for quickly checking on a grunt or gulp task.

If you want to set this up:

  1. Download and install iTerm2.
  2. Go to iTerm > Preferences. Click on the “Profiles” tab.
  3. Click on the + button in the bottom left. I labeled my profile “Hotkey Window”

    iTerm Preference Window

  4. In the Window tab, I tweaked the transparency, checked Blur, changed the Style to “Fullscreen”, changed the Space to “All Spaces.”

    Screen_Shot_2015-01-02_at_10_26_51_PM

  5. Then, under the Keys tab, check “Show/hide iTerm2 with a system-wide hotkey. As I mentioned, I’m using ALT + Cmd + Space, but do whatever works best for you.

    Screen_Shot_2015-01-02_at_10_27_54_PM

  6. Also check “Hotkey toggles a dedicated window with profile:” and make sure “Hotkey Window” (or whatever you named your custom profile is selected from the dropdown.

Lightning Round.

I’ve always wondered how people were able to customize their Terminal to be all kinds of cool colors.

Then, I was introduced to Oh My Zsh = Awesome.

Even if you could care less about Terminal colors, there are other short cut codes packaged within Oh My Zsh that make Terminal life even better.

I took a leap of faith and trusted Robby Russell and simply ran his automatic installer via Curl. Just copy and paste the following line into your Terminal (remember you don’t need to copy the $ sign):

$ curl -L http://install.ohmyz.sh | sh

Then, you can start Zsh by simply restarting or opening a new command window.

There are plenty of themes to choose from. I went with the agnoster theme and then the colors in my Terminal to use the Solarized theme.

Slow down

Sorry.

To change the theme for Oh My Zsh, copy and past the following line into your Terminal:

$ nano /.zshrc

nano is a simple text editor that runs within the Terminal. So, we’re simply telling it to open our preference file in nano.

Go to the line that’s called ZSH_THEME=“”. Change that line to the name of the theme you want to use, in our case agnoster.

Screen_Shot_2015-01-02_at_10_49_10_PM

Then, type Ctrl + O for “Write Out” (also save). It will ask for the file name, just hit enter to keep the same file name.

Then, type Ctrl + X to exit.

To install the Solaraized theme, click on the download link on their site (also available on their GitHub page).

Unzip the file. Navigate to iterm2-colors-solarized.

Double click on the Solarized Dark.itermcolors file. It should launch iTerm2 with a pop-up message explaining that the color scheme has been loaded into the iTerm2 Preferences (Preferences > Profiles > Colors > Load Presets).

Screen Shot 2015-01-02 at 10.53.41 PM

Make sure your “Hotkey Window” profile is selected and choose “Solarized Dark” from the Load Presets… doprdown.

Screen_Shot_2015-01-04_at_10_29_59_PM

As you begin using the new theme, you may notice some of the characters are not appearing correctly.

I’m using Menlo for Powerline. You can go to their GitHub repository, download, and install the font. There are some other options in the Powerline font repo.

If you’re using a font manager like Suitcase, be sure to mark the font as permanent.

If you’re still having trouble, check the Text tab within iTerm2 and make sure the appropriate fonts are marked.

Screen_Shot_2015-01-02_at_11_01_19_PM

UPDATE JANUARY 25, 2015

Menlo for Powerline stopped working for me. So, I ended up downloading these Powerline fonts from GitHub and installing Meslo, using the same process as described above.


Tripe Bonus.

As I mentioned earlier, “Oh My Zsh” has several shortcuts included. For example, if you’re running Composer, instead of typing composer update, you can simply type cu. Instead of git status, gst. Still not convinced? Here’s one of my favorites: you can type stt and it will open the current directory within Sublime Text. These might not sound like much, but the more you live in the Terminal, the more time it will save you.

All of these shortcuts are considered plugins. You can check out all the ones that available on the Oh My Zsh’s wiki page.

Once you decide which plugins you want to use, you can activate them similar to setting the theme.

$ nano /.zshrc

Find the line that says plugins=()

Include the plugin name within the parenthesises.

Mine reads:

plugins=(git sublime sudo laravel4 Composer bower npm osx)

Last trick.

I have an alias set up so that anytime I type projects into iTerm, it will go directly to my projects folder, where I keep all my code. Essentially, it’s the same as typing cd ~/Code/GIT/ (just in case you were wondering the ~ references your home directory. If you’re not sure what I’m referring to, just type cd ~ and then pwd or ls in the Terminal. You’ll see.)

If you still have your preference file open (nano ~/.zshrc ), look at the bottom. There are a few examples already set up, but commented out (the # in front means the line is commented out). Add a line at the very bottom, below the examples, that reads alias projects="cd ~/Sites".

Then, write out the file (^O) and exit (^X). Restart iTerm2 (or open a new command window). Test it out. Nifty!