Comments On Code

Jan 12, 2018

Refining my Process (Part 1)

As my youngest is only three years old, my business load has been low-volume, the majority of which is the maintenance of current clients. Building out new sites has only been one at a time. Given that, I didn't give much thought to setting up my environment, other than setting up a locally hosted WordPress for the sites on which I run WordPress, and a cross-platform capable text editor (my hardware consists of an iMac, out of family traffic, and a laptop running dual-boot Windows and Linux Mint installations, for portability and diversity of OS).

I am expanding into WordPress Plugin development. Knowing that occasionally Themes and Plugins do not play nicely together, I wanted to create a set up into which I could install as plain a starter theme as possible, and keep it purely plugin focused. It wasn't until after I set up the second local WordPress, that I realized I had a pain point that would amount to a large scaling problem once I try to kick my business into second gear. Until now, I would set up a new project on the existing installation, add new posts and pages that reflect a particular client's needs, install the theme or build it up, customizing it as I go. New client, all the previous gets reset, and the new project begun.

Obviously, this is completely unworkable for working more than one site at a time. On the occasion that I have had to return to a project to make adjustments, it is a large hassle to manually revert everything the way it needs to be for that project. I often end up making some modifications directly to the live site, then save them back to my github repository, which is a hazardous way to develop. It leaves me wondering and second guessing whether I remembered to update my repo properly. Thankfully, I have not yet had a crisis, but it really is only a matter of time.

I began pondering my current set up. What if I could set up a project and leave it set up? What if I could just spin up a new install for each new client/project? Duh! That is a multisite environment. Ah-ha.

I have never worked with multisite and set about to figure out how to install it. I discovered that decisions needed to be made right off the bat. Do I want subdomain structures? Or subdirectory? The first would complicate set up, but the second seemed prone for more confusion down the road. The first would require a fresh install, while the second would allow me to continue using my existing set up. The first would require me to look up more tutorials on how to set it up, since the tutorials I had found tended toward the second (to avoid the rabbit trail of Apache customizations). In the event I had multiple sites open at once (always), I want the URLs to be obvious at a glance, so I went with the first.

There are really only a few steps: 1. edit the Apache hosts file, 2. install a fresh WordPress and turn on multisite, 3. select the subdomain option, and 4. insert a new subdomain into hosts for every subdomain. The fourth one can be set up to be automatic in older Linux environments, using wildcard DNS, but it looks like my newly upgraded Mint, running on Ubuntu 16.04, doesn't have a simple way to do that. Another problem for another day. I found both these tutorials helpful,

How to Setup a Localhost WordPress (Sub-domain Multisite) Environment and The Ultimate Guide to WordPress Multisite. I found a slight complication in my personal set up, because I do not solely work in WordPress. On my Linux system, my local Apache folder contains other sites in addition to my WordPress installation. I originally had WordPress in a secondary directory. That set up did not work with the subdomain installation, although it worked just fine with the subdirectory based multisite. Once I chose the top level directory for the installation point for WordPress, the steps proceeded smoothly. I combined all my non-WordPress projects into a new directory, which I can still navigate on my localhost, and step out of the WordPress environment.

Since I had an existing WordPress installation, I found this tutorial to help guide my process through converting that site into the new multisite set up: How to Move a Single WordPress Site into a Multisite Network.

Unfortunately, I have not had a chance to dig into my new environment, set up all my clients' sites, and pat myself on the back about my own brilliance. In the process of trying to make myself a little reminder dashboard plugin, so that weeks down the road when I can't figure out why my new site won't come up in the browser, and then remember that I have to add the new subdomain in hosts, I stumbled into a much larger issue, with more adventurous rabbit holes, that stoked the "maybe I really should get a Comp-Sci degree" fire, because then maybe I'd be able to understand what the heck happened. Continued in Refining my Process (Part 2).