Attending WordCamp 2016 was a huge motivator to get started in helping within the WordPress community. The most experience I had as a contributor for any open source project were primarily discussions on Github with various frameworks I used. Since I use WordPress just about every day of my life, I figure I owe it a lot, after all it does pay the bills.
Slack Is Fun
The forums tend to be the most obvious place to start when looking to contribute to WordPress or so I thought but as it turns out, the Slack group is full of opportunities. Signing up and getting started is a simple as signing up for the forums and then registering on the Slack Page. Once you are logged in you can enter various channels that pertain to specific parts of WordPress such as Core, REST API, Forums, and much more.
The WordPress Community Is Very Supportive
It can always feel daunting at first when you talk to people who have been working on a project for years, often with very high level understandings of the inner workings of WordPress. Don’t be afraid though, the people who work with WordPress are very receptive and helpful. I remember being embarrassed at first because I found some typos in the documentation and was asking the best way to get those fixed, but it was as simple as someone telling me to do a simple pull request. Since I don’t normally work on Github, I had to figure out how to do a PR but it was as simple as forking the repo, making the change, and then submitting it. I survived, it was accepted.
There Is A Lot Going On
One of the first things that stood out after being on Slack for a few days is the sheer amount of talk happening about so many pieces of WordPress. Most of us only hear about what makes it to new releases of WP but there are some larger projects such as the REST API, Fields API, and numerous game changing UI conversations. It really gives you a perspective and insight into just how much WordPress is growing.
Get Started Today
Words cannot describe how happy I am to have joined the Slack group and the motivation is has given me to write my own plugin for testing the REST API, as well as work more and more to help with taking WordPress to the next level. If you have ever wanted to start contributing but didn’t know where to start, hop on and check it out. You don’t even have to write code, documentation is what makes software great, so fix some typos!
If you are not familiar with the WordPress Command Line (WP-CLI) you should really check it out. There are a lot of uses for it, and I think some of it’s power comes in the form of what it can do for you when you are developing a website locally. While there are a number of plugins that can also do the same thing, they don’t offer the flexibility the command line offers and you still have to install, manage, and then remove the plugins later.
Generating Content to Use
When you are working on a blog roll, list of user profiles, or any other feature that rely on have a lot of content to make sure it is styled correctly, the CLI is here to help. There are several commands that come in handy for creating on the fly content.
For example, say you need to generate 100 users:
wp user generate --count="100"
This will create one hundred subscribers. You can also assign them to a specific role instead by using the –role flag.
wp user generate --count="100" --role="administrator"
To show your new list of users all you need to do is enter:
wp user list
Another command that I have found particularly helpful is for generating posts. Just like with the user command, you can specify a lot of information, just looking at the full command list you can get an idea for how powerful it is.
wp post generate [--count=<number>] [--post_type=<type>] [--post_status=<status>] [--post_author=<login>] [--post_date=<yyyy-mm-dd>] [--post_content] [--max_depth=<number>]
There are quite a bit of parameters here, besides the obvious count, post date, and status, you can also set the post type (page if you need a page) and max_depth which is the number of child posts you need to make as well. You can generate 5 generic posts by simply providing a value for the count flag:
wp post generate --count="5"
In addition to automatically creating numerous posts, you can also create them using a file. This can be extremely useful if you have the content you need for the pages and want a quick way to populate them, or if you simply have boilerplate ipsum text you’d like to use.
wp post create [<file>] [--<field>=<value>] [--edit] [--porcelain]
As you can see there are only a few base commands for creating a post however, you actually have the ability to do far more complex interactions. You’ll notice the field flag, here you can enter associative arguments that correspond to their parameters in wp_insert_post(). For example you can use –post_title to set the title of the post.
For me the most interesting thing that you can do with post create is supply it with a file to fill in the content. I’ve only began using this to input the content but someone with far more skill could probably integrate this into a function to pull content from a source like Google Docs.
In this example I created a plain text file on my desktop and feed it to the function, creating a new post in the process.
wp post create /Users/lukepettway/desktop/ipsum.txt --post_title="A Post From A File"
This will create a post with the title A Post From A File and use the ipsum text in that file to fill up the content. Pretty flipping cool right? Listing out your posts is as easy as typing in:
wp post list
One of the things I constantly find myself having to do when working on sites is regenerating thumbnails. Whenever you add a new image size you typically want to do this, there are plugins that handle it as well as programmatic ways to do it as well. WP_CLI provides a quick way to do this:
wp media regenerate
You will be prompted to confirm the command and then it will execute (use the –yes flag to bypass the confirmation). A list of changed files will show you what has changed.
Aside from regenerating thumbnails you can also import files too, it works similar to how you use a file to populate a post:
wp media import /Users/lukepettway/desktop/ipsum.txt
Hey it worked! This isn’t really any faster than dragging a file to upload to WordPress but again, that is where the scripting power of the command line can come in really handy, you could easily feed in boilerplate files without having to log into the admin.
Another super handy dandy command you might want to use are the plugin commands. You have the ability to update, delete, install, activate, and deactivate.
Deleting a plugin is as simple as typing in the name
wp plugin uninstall hello-dolly
Sorry Matt! Now that we feel bad about uninstalling it, all we have to do to make up for this tragedy is run the install command.
wp plugin install hello-dolly
Things are now how they were before. But what if we are using a plugin that isn’t in the WordPress plugin repo? No worries because we can specify a url or file from a path:
One of the biggest annoyances of working with any database is making a backup. It’s not hard, but it’s a lot of clicks to do something so simple yet so important. With the command line, you can create backups in a snap:
wp db export
This will create a database dump at the root of your site. For anyone working locally, you might need to add the path of your mysql bin in terminal (on AMPPS I did this export PATH=$PATH:/Applications/AMPPS/mysql/bin). One of the most powerful features, while not part of the db command, is search-replace. Just by the name you can probably guess what it does. It is a rather jam-packed command:
The biggest use you are going to have with this is when you need to migrate a database. Most of us are probably used to doing a SQL query in phpMyAdmin to update our sites which isn’t really so good of a practice. There are times when data is serialized or in weird tables, and sometimes those queries don’t always get everything. Search-Replace can manage to get all of that data safely and update it. It is pretty straightforward too:
By default, this is only going to run on core tables, however there are two flags, –all-tables-with-prefix and –all-tables, which specify whether to run on all tables in the database with or without a prefix.
The commands that I have covered are the ones that come stock with WP_CLI, there is actually a whole community dedicated to writing all sorts of awesome things, and you can even extend it yourself. Some of the notable additions include super-cache for managing W3 Total Cache, acf for working with Advanced Custom Fields, and any-ipsum a content ipsum generator.
There are a lot of uses for the WP-CLI, especially when it comes to working on a site locally. While some of these commands may offer more utility than others, a lot of the power lies within scripting these beyond their default usage. Sure some local dev setups especially those using VVV with VV to auto-install can import your plugins during the build process, for the rest of us not using those environments, we can right simple scripts to pull in frequently used plugins directly from our computers or on a file server.
Recently I was given the opportunity to attend WordCamp US which was the first national WordCamp. One of the topics that kept popping up was working locally and people would ask recommendations and you would hear all sorts of answers. It seemed like VVV (Varying Vagrant Vagrants) came up a lot but was also met with concerns about complexity, overhead, ease of use, etc.
As someone who has been an advocate for working locally for years and has always been the first person everywhere I have worked to push the initiative and make it happen, I think that we might be making a huge mistake by trying to push VVV as the only option or at least the best option. There are many options out there such as MAMP, AMPPS, XAMPP, DesktopServer, or even setting up your computer itself to serve the files.
So Many Dependencies
My primary argument against starting off with VVV when someone is completely new to anything with the command line is that it has such a huge overhead. What I mean by that is the average user who is simply trying to build a small website locally has to install Virtual Box, VVV, Homebrew, and then VV to really get the most of what they are going to need. That is a lot of stuff to simply install a WordPress site locally and then work on it. In addition to all the dependencies you still have to rely on the command line to operate the server, set up new installs, reboot everything etc.
But Having to Use the Command Line For Everything Is Good, Right?
Well, yes and no really. Sure we could make the argument that this is a great learning opportunity for everyone because they HAVE to use the command line to do every little thing but we forget in our infinite wisdom that this is a horrible way to teach someone. Can you imagine if when you were in school you were taught addition, multiplication, subtraction, all at a once and then tested on it? Most people would have a hard time keeping up and that is where the real issue lies. When someone is learning git for the first time, they shouldn’t have to worry about what Vagrant Up does, or how to create a new site through terminal, they should be learning about add, commit, push, pull, and all the other important commands.
If I tried to get my coworkers to use VVV while learning Git, Gulp/Grunt, SASS they would definitely tie me up to one of the support beams in our glorious office and use me as a human dart board. Many of us make these recommendations without thinking about the hurdles we overcame, we understand things but only because we have worked through many trials and errors long forgotten. A few years ago when I was showing a coworker how to use a theme boilerplate that uses node, grunt, and SASS we ran into an issue where we kept getting errors when compiling. After some digging it turned out that there was an issue with node-sass and the newest version of node that was out at the time. Needless to say he was frustrated and quite frankly didn’t even want to touch the theme anymore. Luckily I was able to get him squared away and I haven’t encountered any issues like that anymore.
What I learned from that experience was that even under the best circumstances, there are so many unknown variables that can make even the simplest of tasks profoundly harder and without the experience or knowledge to troubleshoot the issue some people will simply give up and move on thinking that the tool itself is broken.
Less Is More
When it comes to teaching it is better to stay as focused on one task or as few tasks as possible. The more steps you add increases cognitive load and makes it harder for someone to memorize and understand exactly what they are doing and why. Someone learning git for the first time already has their mind full of what commands they should be using, and should be focused more on how to manage their commits and deployments, not worrying about why their VM won’t boot.
By lowering the barrier of entry and making it easier for someone to focus on a smaller set of instructions we also limit Imposter Syndrome. It can be devastatingly discouraging when someone can’t grasp concept A because concept B isn’t working properly, for example their dev environment isn’t loading correctly. Just like in the example I gave with that theme, you can’t make a really smart person feel completely useless by giving them too much to take on.
Use Whatever Works Best For You
Start off with what works best for you even if it isn’t the best tool out there. More importantly don’t knock people down for using MAMP or other similar tools. I’ve used AMPPS for a while now, and if it weren’t for it I couldn’t have gotten convinced the rest of the team or several friends to work locally. With all that being said, Vagrant is really really awesome. You can create blueprints (with VV) to install whatever theme you develop with, install plugins, create fake content. the list goes on and on. So use Vagrant if you want or use MAMP. As long as you can get up and running to get started with the tools that really matter such as Git then that is all that matters.
The holidays are finally here! That means it is time to find some gifts for the people who we truly care about. Here are some of my personal favorites and recommendations for the web developer and designer in your life that likes to read.
Designing for Performance by Lara Hogan – This book is awesome! Performance is such an important part of web development and design but it is often overlooked. Lara does a great job of showing the various tools and methods your team can use to make your websites snappier and happier.
Soft Skills: The Software Developer’s Life Manual by John Z. Sonmez – Every now and then you come across a book for programmers that isn’t about programming and this is one of the best I have read. You should be working on your career and life goals and this book aims to help you learn the in’s and out’s of various topics such as finance, job seeking, and personal health.
Responsible Responsive Design by Scott Jehl – Another must have book for the front-end dev. When we talk about responsive design we always talk in it within the context of how fluidity, how it looks on every device. Rarely do we ever consider the impact of the bandwidth we have available to us and Scott makes a lot of great arguments about why we need to factor that in as well. Most of us think that the internet is really fast but in reality it is average at best and we are the exception to the rule. Most people have limited connection speeds and we need to make sure we build our sites with that taken into consideration.
Smashing Book #5 – No list would be complete without mentioning a Smashing Book. This one is thick (2″ or so) and chocked full of all sorts of vital information. One of the best sections of this book talks about SVGs which are becoming an important part of the web. The design of the book itself is very vibrant and each section is organized with a different color.
The Uncertain Web by Rob Larsen – Anyone who works on the web knows that there are numerous decisions that happen when choosing which technologies to use and what devices to support. Something that we build today needs to work for devices tomorrow and Rob does a great job at looking at the web today and how it may look tomorrow while providing examples of how technologies have evolved and how they handled certain obstacles. Instead of leaving us worried about how we are going to support such uncertainty, we are left embracing the nature of the web because this uncertainness is the result of the power of having an open web.
These books are the top 5 I have read this past year and they will make an excellent addition to anyone’s read list.
Now that we know all the tools we should have in place, the next step is using them to create a WordPress site, version control it, and ultimately get it onto a server. There are numerous other articles explaining various methods to do this, so keep in mind that you may want to do things a little differently and that is okay. You are probably going to make mistakes along the way, I know that I did, it only serves to make you a better programmer.
1. Create a new site in AMPPS
The first step is going to be creating the site in AMPPS. To do this, log into the control panel by clicking on the application followed by the house icon. Under configure there is an option to add a new domain.
This will create a folder in AMPPS www directory, which is where your site will be. I typically terminal to that directory and remove the cgi-bin folder because Git doesn’t like non-empty folders but you can also remove it using SourceTree or Tower.
2. Setup Git in Beanstalk/Locally
Now that we have a working web directory on our server, we need to have a git rep set up before we install WordPress so that we can track all the changes. Log into Beanstalk and create a new repo, don’t worry about the deployments for now, only focus on naming it something cool.
When you are done setting up your Beanstalk repo, it will provide you with the details on how to set up your new local repo. There will be a path such as:https://lukesaccount.git.beanstalkapp.com/site.git.
You have several options to clone this repository, using the command line to clone the repo or using a program like SourceTree. We will use the later since it is more visual and probably less error prone to start off with.
Open up SourceTree and click on the New Repository Button, then choose clone from URL.
Using the path of your repository that Beanstalk provides you, copy the URL into Source URL field. Once that is done you can use the button beside the Destination Path to locate the directory of your website you want to use git with. This by default is /Applications/AMPPS/www/site-folder when you are using AMPPS but will vary on whatever local server setup you have. Before you set the destination path, you can use that window to delete the cgi-bin folder as I mentioned you could do before. You cannot initialize git in a non-empty directory.
Once you complete cloning the repository, any changes you make will be recorded, however you will still need to remember to do standard git commands or use SourceTree to stage, commit, and then push the files.
With SourceTree this will be the workflow:
Change a file
SourceTree sees you made a change
Check the files you wish to stage in the commit
Using the commit message field, type a message for your commit and press Commit
At the top press the Push button (alternatively there is an auto-push button below the commit message field)
With Terminal here is your workflow:
Change a file
In terminal type git add .
Next type git commit -m ‘enter a message here’
Finally type git push beanstalk master (beanstalk may be origin instead)
Now that you have a basic workflow going, your files will be pushed remotely to your Beanstalk repository. Pretty neat right?
3. Get WordPress Going
The next step is going to vary depending on exactly how you like to set up WordPress. For me, I prefer to use the built in install in AMPPS, which is located on the left admin menu inside the control panel. Simply click on WordPress followed by install, select the domain (aka the domain you set up), use either a root or folder install, and the rest is pretty much straightforward.
Once the installer is complete you should be able to browse to your site. Viola! You’re not done though. There are a lot of things inside of WordPress that you do not want to copy over into your repository. Don’t forget to push your files! Some people don’t like/disagree with keeping the WordPress install in the same repo as everything else, with many opting to submodule or ignore everything other than theme files. I prefer do track everything because in the end, it makes deploying sites so much easier.
4. Wp-Config for Version Control
So now that you have your WP site synced up, we need to do something about the difference in database credentials. Although we don’t have the code on a remote server yet, it will be there soon, and we don’t want to use the same DB credentials (local servers means crappy passwords for ease of use). There are several ways to handle this by by far the best way I have found is modifying the wp-config.php file to use a local or dev file unless the site is a production server. This has the benefit of making it easier to work with multiple staging/dev servers as well as keeping extra crap we don’t need out of our code.
Below is a gist that I use when setting up my WordPress config files:
As you can see, we are simply replacing the default lines of code that define the database and wrapping them in a simple if statement that looks for a wp-local-config.php or wp-dev-config.php file and if neither are found it defaults to what is in the else statement. I use the local config file on my local system and the dev on my dev/staging environment. Those files are just a simple php block with the database information, collation, db user, etc. You’re probably wondering how we deal with the local config file since it is inside of the repository. Won’t it get staged and render our neat little hack useless? Technically if we do nothing you’d be correct however git has a handy utility called .gitignore which tells the repository to ignore that file and any changes made to it.
5. Ignoring the crap you don’t want.
Since we have a file that should not be tracked in the repository, we need to ignore it. Just like with the other commands in git you have two options, you can either use the command line or SourceTree. I find it easier to ignore files in SourceTree. It really is as simple as opening the program, looking at the unstaged files section, right clicking on the wp-local-config.php file and selecting Ignore.
If you accidentally tracked a file and need to remove it, there is also a Stop Tracking option as well, although I believe you need to remove it after doing that otherwise the file will still be there remotely in Beanstalk. Depending on your requirements there will be other files you wish to avoid tracking. Most of the time these will come in the form of images, build files using grunt/gulp, or entire directories. I strongly recommend ignoring the uploads folder in WordPress. Images are generally not supposed to be tracked as they cause repositories to get HUGE, same with Node modules and other build files.
Here is an example of a .gitignore file I’ve used on a project:
6. Set up the Remote Site and Deployment.
Everything is almost in place. The next step is getting the code into place. Since I work with WordPress mostly and because most websites today have some sort of database, you will want to copy that over first. I’ve been experimenting with WP-CLI and hope to cover that soon once I am more comfortable with it. WP-Cli is a command line for doing cool stuff with WordPress but I see it’s best use for doing a database migration as it can do URL replacement. For now though just copy your DB over however you’d like.
Once your database and dev site is set up the first thing you will need to do is log into Beanstalk. Select the repository you are creating the deployment for and press the deployment button, then you will need to create a new environment.
For this next part, I have my own process which you can feel free to copy or create your own. I will prefix the name of my deployment with the type of server it is going to such as DEV – Lukes Site. Then I will set the color of the repo to green if it is dev/staging and red if it is production. All of these exist as safeguards to help mitigate mistakes.
Next we need to decide what type of deployment to use, I always use automatic on staging and dev but Never EVEREVER use anything but manual on a production environment. This will help prevent you shipping code that you find out breaks the site.
After selecting the type of deployment you will need to select the protocol that the connection uses such as FTP, SFTP, etc. This is going to vary depending on your environment setup. Now we get to enter all of the good stuff, host names, usernames, passwords. One thing to remember is that since we are deploying to a remote server we want to make sure our code goes to the right place.
I typically open up Filezilla and SFTP to the server and check the remote path. It almost always looks like /public_html/www/siteroot or /public_html/www . This is important because sometimes the way some FTP programs connect will vary slightly and it makes sense to double check (I learned this the hard way).
With all of the information entered, you can pretty much bypass the rest of the steps, Beanstalk will do a connection check and if all things are good, you should be able to tell Beanstalk to deploy the code. As long as you used the automatic method, your code should end up on the server after the next commit or if you manually deploy.
For your production environment, the setup is exactly the same just remember to use manual deployment to prevent any Uh-Oh moments from happening. You can add as many servers to this as you’d like. There are also a lot of cool post deployment options as well that you should check out.
7. That’s a Wrap.
Whew! That was a lot to take in. I spent a good part of a year looking up various methods to handle deploying code because I grew tired of wasting time being an FTP commando. I’ve gone through just about every article I could find on this topic and while none of them were step by step guides, combining a lot of what they did in addition to my workflow specific needs, I was able to create a setup that I believe works quite well.
Hopefully this article helps others make sense of such a massive and complicated topic that is still being researched, talked, and argued about. I’m definitely far from using every best practice but this is definitely a solid starting point for WordPress version control and deployment.
I’d like to give a shout out to Issa Diao for helping me get started with Git, as well as the team at Beanstalk for being awesome folks who created an awesome tool.
Today’s web developer works with many technologies. Gone are the days of building a site using only HTML and CSS. Teams are also getting larger and as a result it is becoming increasingly common to see multiple people working on one website at the same time.
Version control and deployment are very hot topics within the WordPress community right now and they aim to solve these problems. While many of us have heard of these terms and participated in conversations involving them, there are still a small number of people actively using these tools.
Working with so many sites on a daily basis, I found myself wasting a lot of time moving code via FTP or needing to revert changes back after I had made a change to a website. Combine that with CSS Pre-processors, grunt, as well as numerous other tools, and you have a recipe for disaster. This is where a version control based workflow coupled with deployment tools comes in handy.
First I’ll explain the pieces of the process and why I’ve chosen them. Once you have a firm understanding of each part we can then get started with the setup and execution of the workflow. There are a couple of options and approaches which will be covered as well.
This whole process would be pointless if we weren’t building websites on our own machines and we do so for several reasons. First and foremost the speed at which you can work with your code can be pretty dramatic. Even with a fast internet connection you still have longer wait times than what you may realize. Working offline also means that if you lose internet or are without it, you can still work with a dynamically rendered site. If you are using tools like SASS or Post-CSS they are much easier to use locally as well.
As with anything involving technology, there are a million different opinions on what the best local server setup is. There are purists who will say that you should simply install Apache/MySQL/PHP, MAMP/XAMPP/AMPPS/etc users who will tell you that their way is best. Some will even say that you should use HHVM.
So which should you use? I think that it is up to you because really anything will do. Each program and method has pros and cons. While I can only speak from experience about what I have used, I think that you should try out a few options and see what you like.
I’m currently using AMPPS as my server. Initially I used MAMP but I like having the extra installers that come bundled with AMPPS although now you could technically use WP-CLI along with MAMP to achieve similar functionality.
No modern workflow would be complete without some method of source control. There are many options out there. I prefer using git mainly because I feel like there is more documentation available and most of the tools I use have git repositories. Just as important as deciding which technology to use, we also need a place to actually store the code. Github, Bit Bucket, and Beanstalk are all examples of git repository hosts and ones that I have used.
Depending on how you are interacting with your code, specifically database credentials, you will most likely want to opt for a service that has private repositories. This will prevent people from having passwords to your websites. All of the perviously mentioned services have private options although Bit Bucket is the only one to offer free (as in root beer) private repos.
I use a mix of Beanstalk which also serves as a deployment tool as well as Gitlab to host code internally where I currently work. The reason being that we have so many clients and so in an effort to keep costs down we have been building our own continuous integration system, but more about that later.
Moving Le Code
So you’ve got your code version controlled, you’re working locally, and then you realize that your code still needs to get onto the server. What do you do? This is where deployments come in. There are numerous blog posts about this topic, many of them are going to tell you to use git post-receive hooks to merge the code into a repository on the remote server. I’m not going to do this.
When I first set out on my path to find a way to “launch” my code I was stuck like many other people. I had just learned to use git. I wanted an easy to understand way to get my code on a remote server. Manually doing that was a pain in the rear and trying to use git to merge the code into a remote repository seemed like another hassle, especially with the amount of work I do on a daily basis.
This was all before I discovered Beanstalk, a tool that works as both a repository host as well as a deployment application. Beanstalk provides you with private repositories and also has the ability to move your code to a server using several methods including FTP/SFTP. There are also built in collaborative tools and code reviewing features.
Although Beanstalk is my go to tool for getting my code on whatever server it needs to be on, the costs can add up pretty quickly. Recently I’ve started rolling out my own deployment system using Jenkins, a continuous integration tool. The documentation on it wasn’t great but I was able to find a plugin for it called Publish Over FTP which can do just about everything Beanstalk does, although it isn’t for someone who doesn’t like a good challenge.
Next – WTF to do with it all
Now that you know what tools you can use to accomplish version controlling and deploying a WP site, the next step is actually doing it. Next week I will cover the whole process as well as provide some tips and tricks.