WordPress child theme in progress


A few weeks ago, I selected a WordPress theme based on a few factors important to my workflow:

  • Support for multiple post-types
  • Strong semantic HTML
  • Bootstrap framework (for syntax portability in design)
  • Active development anchored with Git

At the time I published this article, the not-named theme is not live but I’m ensuring that I’m deploying its basic framework using best practices, i.e. creating a WordPress child theme. After that’s done, I’ll proceed with the website redesign.

Why use a child theme?

WordPress allows you to install a theme from anywhere and you are allowed make modifications as you wish, in any method you see fit. However, as the adage goes, just because you can doesn’t mean you should. I was mainly concerned with theme updates and how changes by the original author would affect modifications by me.

Whenever you use an authored theme/template for any content management system, there most certainly will be updates released over time that address broken functionality, security issues, and feature enhancements. How you choose to make customizations to your website theme will ultimately affect how well (or poorly) your upgrade will happen. For example, if you dive right into the style.css file that is included with your WordPress theme, changes you make will be overwritten if you install any update from the original author.

With that in mind, child themes work well because you can, in most cases, keep your own custom tweaks to a WordPress theme when a theme update is installed. How is that possible? A child theme is a separate directory in wp-content/themes/ that contains overrides to the original theme you are using. Normally, this new directory will contain only a style.css and functions.php file. WordPress will first check your functions.php and use original theme’s code to render the website, while pulling in your style.css overrides on top of the original theme’s CSS.

For reference on how to do this yourself, check out the Smashing Magazine how-to article.

47ronin.com: AMI instance disaster!



Long story short: Be careful with your AMI instance

I wiped out my website again. January 29, I decided to SSH into the 47ronin.com AMI instance and upgrade everything —including the distro. Almost every server admin in the world will tell you, “if it ain’t broke, don’t fix it.” Yeah, well…

Short story long

I tried to upgrade from Ubuntu 14.10  to 15.x over a remote connection and oh boy did I screw things up. The EC2 EBS volume didn’t have enough free space and a big chunk of that was taken up by swap. I decided to reboot the instance, it got stuck, and I forced a restart from the Amazon AWS console. Except… it came up with no SSH nor web access. Locked out. Spent my entire weekend trying to revive the server salvage the data. Thankfully, someone named “Donald C.” at Amazon support walked me through how to properly connect a “marketplace” AMI EBS volume to another instance and rescue my stuff. I had to:

  1. Boot a new instance
  2. Relabel the boot device
  3. Configure GRUB to boot from the relabeled drive
  4. Shut down the instance and connect the corrupted EBS
  5. Boot the instance and voila! Just enough access to SFTP my website off the old drive
  6. Spin up a new WordPress AMI, import the website database, files
  7. Fix DNS to use the VPS elastic IP
  8. Reissue my SSL certificate and install onto the new instance

Lesson learned

Use an LTS version of a server distro and only upgrade to another LTS. In between those times, back up the db and filesystem regularly (I’ll figure out a proper way to do this easily). Oddly, I found no problem doing this with all the servers I was in charge of at the Port of San Diego (back when the intranet and public website ran on Joomla/Apache/PHP/MySQL). I ran a cron that ran every 12 hours and backed up the MySQL database, gzipped it, and FTP’d the daily snapshot file down to a local server. The cron also SCP’d an rsync of the public documents —would be silly to copy the whole repository over if only two or three files changed. Duh. However, with my own website I don’t have a local server (one with unlimited space, anyway). I don’t feel like filling up my local drives. So, for now I’m just making EBS snapshots and labeling them (primitive but my brain has been fried ever since the rescue). Big operations on Amazon AWS are stupid simple, I gotta admit. Love it.

Am I ready to dump proprietary marketplace AMIs? I was very, very close to switching to a community AMI but in the end— I don’t have the patience anymore to do everything from scratch.

Below was the post I was about to publish before I inadvertently trashed my server for a whole weekend.

I’m three weeks into the new year, and it looks like not much happened on the web-dev front here. On the contrary, a lot has been planned and painstakingly thought-out —in my head.


  • NGINX: I’m probably not going to re-do the website on it at this point because of my SSL configuration. I want to keep the project simple, and having to deal with re-working my encryption might be a huge chore. Besides, this Bitnami appliance was built with Apache. If I truly wanted to change everything, I might as well spin up an NGINX-WordPress-PHP7-MariaDB appliance and save myself the headaches.
  • PHP 7.x: I will likely do this first. From my experience, WordPress is right at home in this config and hopefully will be no more complex than `sudo apt-get install…` Getting NGINX and PHP7 on Mac OS X was a breeze using Homebrew and slightly modded version of this tutorial.
  • MariaDB: This one I’ll probably do second. It’s just a drop-in replacement from what I’ve read, and you know me —I’m always looking to get myself into trouble by fixing what’s not broken.
  • oEmbed: I’m really excited about WordPress embracing oEmbed. I just wish I could go back and fix my old posts  that are stuck using Embedly. In order to prevent odd behavior in future publishing, I may have to disable the Embedly plugin and live with old posts looking funky. We’ll see.

Other projects

It’s been a joy working with the talented folks at Open San Diego, my local Code for America brigade. I’ve been volunteering my time filming and publishing videos of their events, and I have been helping them out with their website and Github projects.

I had a great time shooting and editing these pieces. Hoping for better gear someday to improve the quality!

2016: Time for another 47ronin.com website reboot


After all these years, I haven’t figured out a focus.

What is this, the fifth… or sixth rework of my website? I’ve lost track. One thing’s certain.

After all these years, I haven’t figured out a focus.

47ronin.com must grow up… and I, along with it

I’ve carefully thought about seven key categories and a plethora of tags. Yet, many posts later I want to scrap it all and start over.

Simplification, then clarification. Efficiency, then future-proofing. Somehow these schools of thought have gone hand-in-hand, then turned around and destroyed my online “home.”

I want to talk about everything but keep the categories slim —but use a lot of tags… and simplify —don’t forget about SEO! But content is king… but content is hard. Just spill your thoughts… but I need to present it in a well-reasoned, detail-oriented presentation —but keep it simple!

Before I can type a single thought, the committee in my head has already argued about direction, design, and architecture; such that I can’t even… I CAN’T EVEN.

Before this becomes an endless rant about my perplexing thought process, I present this website’s 2016 plan.

Changes to 47ronin.com in 2016:

  • Yet-another redesign: Will likely be a static Twitter Bootstrap front-end with a blog to back it up. I’ll either use a theme or write it myself. I just want to keep it dynamic without a lot of hassle.
  • Switch from Apache to NGINX: Why? Because it’s badass, fast, and different. That is pretty much why I do a lot things!
  • Upgrade to PHP7: Why? See above. Key thing here is speed… and I love tinkering for performance. It’s either PHP7 or HHVM (which seems so much more interesting but magnitudes more complex from a deploy-from-scratch standpoint).
  • Switch from MySQL to MariaDB: Oracle owning MySQL is as scary a thought as Microsoft owning Ubuntu… I don’t see a true open source future there —should I just redeploy from a brand new Amazon EC2 appliance or upgrade everything myself? Hmmm…
  • Full-bore switch to oEmbed. I wanted this to be the “thing” years back but the technology and content weren’t in place for it to be viable. In 2016 all the players and pieces are in use, such that I can finally stop using Embedly on 47ronin.com (sorry guys, you were great for a long while).
  • Images in every post: Shouldn’t be a problem but I’ll need to think about how Asides are handled (default pics?) Twitter Cards better be robust in this scenario. Hopefully WordPress 4.4 has taken care of this…
  • Responsive imagery/video AND adaptive images: WordPress does responsive out of the box but adaptive may need a plugin. Who the heck wants to download a full-res image published to 47ronin.com, taken from an iPhone 6s+, on a non-Retina mobile device over 3G?
  • Tie-in with my 47ronin GitHub repository: I’ll figure out an elegant way to publish updates here.
  • Emphasis on writing… every day twice a week: Holy shit. I just challenged myself. CHALLENGE ACCEPTED.