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.
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.
One of the hardest things about being a web developer is finding time to learn new things. We spend a lot of our mental capacity each day solving a multitude of problems and yet we still have the biggest problem to solve of all, finding spare time.
Task and Commit
For the longest time I struggled with finding time in between work and family life to do the things that I liked doing, while still being able to add new skills under my belt. It wasn’t until I started making a list of things I wanted to work and forcing myself to complete that list each week that I really started to make progress.
You don’t have to do anything special, even a 30-minute block of time can make a huge difference and starting small you can always increase those blocks by 15 minutes or so. Some nights I’ll spend a few hours working on something new, and on Sundays I am always going through Team Treehouse videos and making sure to complete a track section.
Don’t be afraid to take a break from your learning to have some fun time. Play some CS:GO or ride a bicycle. A lot of studies show that the only way to increase your memory and skills is to exercise as that adds new grey matter to your brain which in turn allows you to absorb more data.
Learning How to Learn
It is also important to know the styles in which you learn the best. I am a watcher doer so I have to either watch a video of someone working on a problem or I have to throw myself deep into it until I solve it. Knowing your learning methods is critical to effectively make use of your time. There is no point in watching a training lesson if it does absolutely nothing for you, if a book is the best way, then stick to that.
Make sure that what you are learning is something you are actually interested in. I can’t tell you how many times I have seen people get started on a new technology only to not progress simply because they did not enjoy the material. If it is something that doesn’t get your brain juices going, skip it and move to something else that does.
For a very long time I have always deflected any opportunity to do design work with the statement, “I don’t know how to design, I know how to code”. In all reality, we are all designers to some degree whether we chose to see it or not. We all have preferences for clothes, car colors, the type of bikes we ride, we are constantly designing our lives and the world around us. As someone who develops code for an internet which is quickly becoming more interactive every day, we need to have at least a minimal understanding of design principals. The benefits cannot be underestimated nor can they go ignored about any longer.
Responsive Design Means Coding A Changing Site
As more and more devices start accessing the websites we build, it becomes increasingly important to make sure we understand the important elements of a design we are given and how to compose them on the hardware that is viewing them. What might be important to a desktop user, might need to take a backseat to someone visiting the website on a smart watch or even a phone. Knowing how visual hierarchy works can allow a developer to make smarter choices about how everything fits together without compromising the design or brand identity.
Better Team Collaboration
Understanding why a designer is making certain design choices allows you to better empathize with them and as well as communicate possible technical considerations and work arounds. It empowers you to make a suggestion that might have been overlooked by others simply because they may not have an understanding of how something could work within the code. Drop down menus definitely come to mind, as that is something I rarely see considered or even comped up most of the time. This holds very true in agencies or groups that still use Photoshop to generate the designs, a process that often leads to impossible to implement shadows, borders, or other no-no’s (please start using Sketch). Having the ability to consult with your designer and offer a comparable solutions.
Less Time Waiting
Depending on how your team functions and how comfortable (and trusted) you are with taking on design responsibilities, having some basic design skills will allow you to make decisions without having to consult a designer every time. This doesn’t mean going rogue and changing everything, but understanding the brand identity and how style guides work will allow you do confidently create buttons, forms, and other elements without wasting time asking if they look ok.
Design Goes Beyond Looks
Any Knowledge Helps
While I feel like it is important for every front end developer to learn a little be of design, I don’t think that you have to “know it all”. Even a little bit of basic knowledge about topics like content hierarchy, color theory, space, lines, can go a long ways. Learn some of the Gestalt Principals too! They will make you a better developer because you will be more confident when you need to make decisions, and a better team player when you need to collaborate with others.