A CaveMan WordPress Workflow

In the continuing efforts to share workflows of other developers(Windows/Ubuntu, Tooling & Workflow) I’m happy to introduce Welling Guzman. Welling was passionate about sharing a portion of his workflow with the internets regarding WordPress. I’ll let Welling take it from here.

To be clear this is NOT a super fancy workflow, but it’s one I’ve been using and the most comfortable with for quite a bit now.

When I start a new WordPress site I grab a new copy of the latest version from http://wordpress.org/latest.zip and save it under /Sites in my Dropbox folder. All that looks like this…

$ cd ~/Dropbox/Sites
$ mkdir newsite
$ cd newsite
$ curl -O http://wordpress.org/latest.zip
$ unzip latest
$ rm latest.zip
$ cd wordpress
Fig. 1.0 | grabbing a new copy of WordPress via cli

Then using MAMP, I create a virtual host pointing to the new site path created from our previous step and manually create the database using PHPMyAdmin. Once those steps are completed I then proceed to install WordPress.

Once my WordPress install is completed I create a local config file called wp-config-local.php that’s a copy from the wp-config.php WordPress just created, but I add these lines at the top of my wp-config.php that looks like the following…

if (file_exists('./wp-config-local.php')) {
require 'wp-config-local.php';
return;
}
Fig. 2.0 | local wp-config file detection.

I initialize a git repository while ignoring these items via a .gitignore file:

.htaccess
wp-content/uploads
wp-config-local.php
Fig. 3.0 | ignored file listing for repository.

Next, I push this repository directly to my server where all my WordPress sites are hosted. After the first git push I just ignore everything that is part of WordPress and handle it directly on the site so it becomes easier to put the site under maintenance before any major changes. This is what that looks like in our updated .gitignore file…

.htaccess
wp-config-local.php
wp-content/*
!wp-content/plugins/
!wp-content/themes/
Fig. 4.0 | updated ignored file listing for repository.

If I desire to push all the core again for any reason I stop ignoring and create a maintenance file or use a maintenance mode plugin.

All the static theme and development files such as Sass and Assemble (if they exist and aren’t hard coded) are outside the WordPress directory and auto copy to my WordPress theme directory using the Grunt Contrib Copy task magic.

Sometimes I just do all this without the git push to the server step and use Coda and ftp directly. Yes, ftp…drag and drop!

I don’t always have the power over the server I’m going to work on, or there are times when the client wants to mess directly with ftp and the theme editor (you probably know what I’m talking about. lol!).

Finally, to migrate the database from production to local I use an application called BackupBuddy.

Raw summary:

  • Create a local WordPress Installation.
  • Push it to the server to (test/production).
  • Ignore the core.
  • Do FTP when it’s the option.
  • Use BackupBuddy.

Welling Guzman

C.S. Web & Software Developer • PHP/JavaScript/C/C++/Objective C/SQL • I also like to reinvent the wheel sometimes • Hola. Great Plains DominicanRepublic. http://wellingguzman.com. Follow me on Twitter.

Leave a Reply

Your email address will not be published. Required fields are marked *

show formatting examples
<pre class="language-[markup | sass | css | php | javascript | ruby | clike | bash]"><code>
…code example goes here…
</code></pre>

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Comment Preview

  1. John Doe shouted this comment preview:
    2014/08/04