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.

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.


WordPress SSL over HTTPS: Securing your blog’s administration pages


Although I really should be working on my next video, I am doing something totally different —getting my website’s admin area encrypted. Yes, I am easily distracted by little side projects and that’s why I can never get anything done quickly… but THIS is a worthy task.

Why should you secure WordPress using SSL over HTTPS?

What’s the point? Security, of course. Just think: You are blogging in a coffee shop using their open wifi —or even password-authenticated wifi— it doesn’t matter. As long as there is traffic going over the network, your website’s administrative data packets are being transmitted in the clear, including your admin username and password. You wouldn’t want your bank information visible to all in the ether so why would you trust your website management bouncing around unencrypted? Logging into WordPress and doing your business can be a fairly secure process after a few steps.

Getting it done— Difficulty level: Fairly easy

I’m approaching this with the assumption that you have access to change your web host’s Apache SSL configuration and WordPress plugins. Without this access, you may have other challenges.

Quick and dirty SSL certificates

Sure you can purchase an SSL certificate from an authority and install them at your hosting level but that would be way beyond the scope of this little project. For now, I’m doing this the easy way so you can get up and running with encryption. If you already have a valid SSL certificate with a matching Server Name then skip this step. Otherwise you’d better follow along or risk getting errors. On your Apache server:
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout \
/opt/bitnami/apache2/conf/server.key -out /opt/bitnami/apache2/conf/server.crt

The path and key/certificate filenames may differ depending on your server. The one quoted is for a Bitnami appliance on Amazon’s Elastic Cloud Computing infrastructure so using the exact syntax on a generic Ubuntu server may be totally different. This self-signed certificate should suffice for this project but be sure to note the certificate specifics before allowing your client browsers to accept the connection permanently. Fill out the certificate information, carefully following the prompts.

Adjust the Apache SSL configuration

The .conf file for SSL connections is usually separate from the main Apache .conf, and may be found in a subdirectory called extras. On a Bitnami WordPress appliance for AWS it might be called /opt/bitnami/apache2/conf/extras/httpd-ssl.conf. The enabled directives are few —and for good reason. However, for WordPress to resolve URLs properly while under SSL, some additions need to be made. Please audit your security after these modifications are performed.

Define the proper DocumentRoot and VirtualHost directives for your WordPress install. The directives mirror those that are defined by WordPress and allow the Rewrite module to behave properly in the Administration area if permalinks are enabled.

<directory "/opt/bitnami/apps/wordpress/htdocs">
    Options +MultiViews +FollowSymLinks
    AllowOverride None
    <ifversion < 2.3>
    Order allow,deny
    Allow from all
    <ifversion >= 2.3>
    Require all granted
    RewriteEngine On
    #RewriteBase /wordpress/
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . index.php [L]

You’ll need to restart Apache or reload the configuration for changes to take effect.

Prepare WordPress for SSL

To keep things simple, use the WordPress HTTPS (SSL) plugin by Mike Ems. Though you might be able to enable SSL logins in wp-config.php yourself, any canonical redirects you have in .htaccess may cause the HTTP redirect to fail. So stick with the plugin and save yourself some trouble! After activating the plugin and checking the box for “Force SSL Administration,” administrative pages in WordPress (including login) will be encrypted. You may want to bookmark the HTTPS admin URL for your website to avoid needless redirects. Voila, that’s all there is to it —enjoy!