My approach to building websites with WordPress

Barring a few different naming conventions and her use of Foundation rather than Bootstrap, Amy’s method and reasoning is identical to the way I build WordPress websites. I love how repeatable this method is, not just within one project, but across many. It provides the website owner with the tools they need to manage, add and re-arrange new content.

My imposter syndrome has receded just a little today. Thanks for writing this Amy.

Switching from MAMP to Vagrant for local WordPress development

While reading about the WordPress JSON API, and how to send WordPress data between sites, I was again reminded of how cool Vagrant sounds. I had been ignoring its lure but today I was directed to a system called VVV (Varying Vagrant Vagrants) that works with Vagrant, and VirtualBox, to create a local virtual linux server and install everything necessary for a WordPress site. From there I read about Variable VVV that will let you quickly create new WordPress sites to your custom specifications.

Was that enough links for you? No? Well here’s another one about getting started with Vagrant.

It took me most of the morning to get everything installed, commands run, and my first Vagrant machine up and running.

So why the hell is this worth a morning of effort? Well with Variable VVV I have to run one command – vv create – answer a few Y/N questions about the install and in seconds I have a new WordPress dev site up and running.

You can also use a “blueprint” to automatically install themes, plugins, options, or constants that you typically use on a project. Off the top of my head I would have it install underscores, Bootstrap, Advanced Custom Fields (although I don’t think there is an ACF Pro repo), Developer, Jetpack, and WP Sync DB. Again, just one command to do all this after it’s set up. Another option would be to build your standard wp-content folder out in a Github repo and then reference it’s location using the command – vv create --git-repo – this is starting to make the most sense to me.

I’ve been a user of MAMP and MAMP Pro for many years now and version 3 looks better, is much faster and works every time but I have yet to successfully use their automated WordPress install feature, which is still referencing 4.0 when 4.1 is the current stable build, and as far as I can tell that install can’t be customized like with Variable VVV.

I’ll use Vagrant on my next build for the same reason we choose to use Flywheel for staging and production servers: little to no set up and fiddling before you’re doing the work you want to be doing.

Transfer a large WordPress website using two tools

Those two tools were Transmit & WP Sync DB

I’m sure there are more efficient ways of doing this (tar or rsync commands) but I wanted to have some of the fine-grained control that comes with a GUI and that elude me when using the command line.

I don’t get to use Transmit enough on my Mac and that felt like reason enough to use it. Plus it’s nice to look at and the iOS version has been one of my favorite new apps for front-end work on an iPad (can’t wait for new Diet Coda).

I know Transmit can simultaneously transfer multiple files but I didn’t realize that when copying a folder (like the /wp-content folder) Transmit would treat it as one file and, therefore, download/upload each file within the folder in order, one by one. So a ⌘ + a later I’m dragging and dropping 3K+ files at a time, folder by folder.

It took some babysitting but it was super fast.

With all the media files transferred it was time to import the database from the old site to the new. I have used BackWPup Free before for this task. It downloads a .sql file for you to import to the new database using phpMyAdmin or similar. While looking for better tools to keep local, staging and production databases in sync I found WP Sync DB which appears to be a free fork (albeit slightly modified) of WP Migrate DB Pro. I wanted to give it a try and I was happy I used it here.

The Github page gives you all the instructions so I won’t repeat them. I chose to use the push method from the current live server to the new server. It ran for about 8 minutes. When I reloaded the new server everything looked identical to the old server.

Four years and 13GB with of website moved in about four hours of actual work time.

On my profession

During a past episode of Back To Work Merlin called himself a web whacker in reference to his previous jobs. I had been saying that I build websites for years rather than affixing a professional title like Front-End Developer or UX Designer to my name, even though I could probably pass for either today.

I did not study computer maths or design in college and my first paying web job in 2006 was building email templates. I had a working knowledge of 2001 era HTML (perfect for the email templates) and I didn’t know a thing about CSS – View Source was my best friend.

I had many job titles in many different roles between 2006 and 2014. Some were in IT, some in sales, one in commercial real estate. My last job title, 3D Application Specialist, was one of my favorites. The entire time I freelanced as someone who builds websites but I never claimed it as my profession. It was, however, an addendum to my explanation of how I earned a living.

Today my profession and what I do for a living are one in the same. I work for a small agency and I’m involved with anything that doesn’t have to be printed. My title is Digital Director and I’d say that 80% of my job is building websites (from concept to live site). I’m able to be a technology consultant, an IT person, a sales person, an account manager, a coffee brewer, a researcher, and a student the remaining 20% of the time.

Unfortunately, Digital Director is ambiguous and I don’t want to list 10 things every time some one asks what I do for a living. This takes me back to “I build websites.”

Text file naming convention

Most of these come from the naming convention described by Merlin Mann during MPU Ep. 46

I take a lot of notes on anything I think I may need to refer to again in the future. I keep them in Dropbox and access them through a combination of nvALT, Byword, Drafts, and Editorial.

runx [title] – any text file that will be edited and appended on a regualar basis. Examples of file names are “runx blog ideas”, “runx media list”.

refx [title] – a mostly static text file that contains information I would like be able to refer to later. Eg. “refx markdown syntax”, “refx GTD Fast notes”.

blogx [title] – a text file of a blog post I’m working on that moves from outline format to full post. Eg. “blogx spray on tans for beginners” or “blogx Macramé made easy”.

webx [title] – a text file that relates to a Webster specific project or meeting.

ideax [title] – a text file that expands on a thought or idea that I have. These sometimes turn into blog posts or projects or sometimes they remain ideas and put on a Someday/Maybe list.

pplx [person] – a text file about a person I care about containing facts or conversation points that I want to remember.

clx [checklist] – a text file of a checklist that I want to be able to refer to when preparing for something. Eg. “clx camping trip”, “clx cleaning house”. I’m using Clear or Reminders in place of this most of the time

randx [title] – a text file that contains random thoughts when I just let my mind wander. These are often created after a few drinks.

tempx [title] – a text file that I use as a temporary scratch pad, a draft for an email or text that I want to move from one place to another