My Development Environment

The Best Laid Plans…

One of my favorite oxymorons is, “change is the only constant.” The origin of this saying is generally attributed to the Greek philosopher Heraclitus. This project (srcCraft) has reinforced this truism for me.

When I started this project, I thought I’d probably just use the tools and techniques that I’d picked up over the last 20 or so years. More specifically, I thought I’d be using:

WP Bootstrap Starter as my base WordPress theme
Dropbox to contain my project folder
Apache2 on Ubuntu in a VirtualBox VM as my dev and test server
Apache2 on Ubuntu in a Digital Ocean Droplet as my live server
iThemes’ BackupBuddy for deployment from dev to live server
JetBrains IntelliJ IDEA for all “development activities”
GitHub for online repository storage (all private until I have something worth sharing)

WordPress Theme Selection

I like Bootstrap – I’ve experimented with it a few times for “learning exercises” and found it to be approachable because of its good documentation. So, when I started this project, I searched for articles or blog posts about integrating Bootstrap with WordPress. There are many such articles, all of which described approaches that seemed like they would work well. During this search, I also ran across references to WP Bootstrap Starter Theme. That sounded exactly like what I wanted, so I initially planned to use it. However, serendipity would intercede in the form of an email from Rob Howard, of Howard Development & Consulting and new CEO of Understrap.

I had heard about Understrap before, but when I looked at its page (I think it was on WordPress.org) it had not been updated in some time. So, I dismissed it from consideration, because I was looking for something that (1) incorporated the latest version of Bootstrap, and that (2) was being actively developed. Rob’s email indicated that he had acquired Understrap and that he and his team were working to update the theme and reinvigorate the community. In a subsequent email, he offered a steep discount on their upcoming Understrap training course for developers. The price was too good to pass up, so I jumped in with both feet.

The course, Instant Understrap from Understrap Academy, has proved to be excellent. One of the early lessons explained the development environment that they’d be using in the course, which included Local as the WordPress “server.” Local keeps each project in its own environment, and allows access to the actual source files, so this seemed like it would work well for me. Another of the lessons showed how to combine Node.js and NPM with tools like SASS to automatically rebuild CSS files whenever a changed file was saved. Maybe everyone else already knew about all this, but I didn’t, so that alone was worth the cost of the course to me.

I was on a roll and cooking with gas… or so I thought. Sigh.

Dropbox, Node.js, and NPM… Oh My!

I have a couple of different computers I use for development work, and I switch back and forth between them not frequently, but not too infrequently either. So, my general approach for project work over the past few years has been to store the project folder in Dropbox (which I have on all of my PCs) so that both of my dev machines are always up to date. This has worked well for me in the past.

As it turns out, installing packages with NPM tends to create lots of folders, sub-folders, sub-sub-folders, etc., in a relatively short amount of time. This appears to be a challenge for Dropbox. I’m not exactly sure what the problem is but using Node.js and NPM with Dropbox just doesn’t work. After grudgingly coming to grips with the fact that I’d have to abandon Dropbox for storing project folders, I experimented with storing them on my file server and accessing them over the LAN, but that didn’t work very well, either.

In summary:

The NPM “node_modules” folder seemingly gives Dropbox fits. Even when telling Dropbox to ignore the folder.
First, NPM would have an error installing a package, and the next time it would work!
Users on Stack Overflow report that Dropbox has issues with synchronizing the possibly thousands of files in NPM packages.
If it’s not reliable, it’s not usable.
NPM also seemed to have issues with network drives – doing “npm install” after deleting the node_modules folder resulted in errors.

Faced with the above constraints, I created a “Projects” folder on the data drive in my PC and created a home for this project there. At the same time, I installed automatic backup software on my dev machine to avoid loss of files due to drive failure, accidental deletions, or accidents (note that my fileserver already had continuous online file backup configured, which was one reason I hoped it would work to host the projects folder).

So, with all that out of the way it should be smooth sailing ahead, right? Yeah, right.

Servers

I’ve used – and been very happy with – VirtualBox for over 10 years, since well before it was purchased by Oracle. Over that time, it has gotten easier to use, gained useful new features, and been very reliable. I like that it lets me create an independent environment for each project. It also lets me move that environment from one machine to another, even if that sometimes takes a little tweaking on the new hardware. However, there are three main drawbacks to this approach.

First, VB’s virtual machines (VMs) can take up a lot of space, particularly if there are several of them on a single machine. I use the dynamically allocated option to keep the “drives” as small as possible, but they still tend to grow quickly. At one point I had enough ongoing projects that the VMs were consuming about 75% of a 2 Tb drive.

Second, it takes some amount of time to start them up when I want to work on a project, and then again to stop them gracefully when I’m finished for the day or want to switch to another project. As an aside, I decided early on to configure the VMs to all have the same MAC address for the primary network adapter, so that they’d all get the same, reserved, IP address from my LAN’s DHCP server. I did this so that I did not have to remember all the different IPs or host names – it just made things a little bit easier. Because of working this way, I had to shut one down before starting any of the others.

Finally, this approach required me to configure my IDE (Integrated Development Environment, more on that later) to make an SSH connection to the server to automatically upload files, which I set up to happen whenever there was an explicit save of a file. While this worked, it seemed a bit kludgy to me; I’d much rather be able to work directly on the source files (which I could have done if I’d also set up my IDE to run on the VM, but then there were performance considerations to that as well – using JetBrains’ IntelliJ IDEA running on the VM via an X Server on Windows is not nearly as fast (in my experience) as running the IDE directly.

So, I wanted to find another solution, and I began by searching for “wordpress development environment on windows.” This yielded lots of sites to look at, most of which recommended one or another of the various LAMP (Linux, Apache, MySql, PHP) stacks such as XAMPP or MAMP, or, for those working only with WordPress, one of the WordPress-specific options such as DesktopServer or Local.

As I mentioned in the previous section, the new purveyors of Understrap used Local for the developer’s course, and I began using it, too, thinking that it looked like it would work well for my environment. And it was working really well. Right up until it was time to test my deployment approach and move my initial site – complete with plugins and some media files (but no real content, and only the rudiments of my landing page) – to what would become my production server.

As you’ll notice from the list at the beginning of this post, I use iThemes’ BackupBuddy for backing up WordPress sites, and it includes a facility to deploy a site from a dev/staging server to a production server. This would save me a lot of the time, trouble, and possible (probable) errors of manually moving the files and database. The first time I tried this, I ran into the problem that would cause me to go back and look for another local development environment solution. The database transfer was flawless, but the source files for my child theme and the media files failed.

As it turns out, BackupBuddy is really intended to do Linux-to-Linux deployments, and the difference in the directory path separators (a backslash (“\”) on Windows, and a forward slash (“/”) on Linux) was an issue that could not be overcome. I have a developer license for BackupBuddy, so I contacted support to find out if they had a workaround. Kudos to the excellent folks at iThemes for helping me even though I did not have a current support contract (the “perpetual” license only includes one year of support, which I think is perfectly fair). The help was to let me know that while this was something they’d heard about, they did not intend to investigate it because most of their customers were developing on Linux and deploying on Linux, so it wasn’t a big problem in their minds.

Once again searching for blog posts or tutorials on creating a local WordPress development environment on Windows, I found two excellent articles:

While both were informative, the first one, by Andrew Schmelyun, is the one I basically followed to set up my system. Installing Docker on Windows required me to install Windows Subsystem for Linux version 2 (WSL2), which in turn entailed selecting a distribution (Ubuntu 20.04 LTS, in my case). Everything worked smoothly, and, after an easy learning curve, I soon had a “DevEnv” that allowed me to work the way I want to and make periodic deployments to my “live” site using BackupBuddy.

Often Go Astray (continued from “The Best Laid Plans…” above)

After all the above, this is what I’m actually using:

Understrap as my base WordPress theme, with the “official” Understrap Child Theme to customize
A subdirectory in my “Projects” directory on my data drive for this project
WordPress and MySql (official images) on Docker for dev and test
Apache2 on Ubuntu in a Digital Ocean Droplet as my live server
iThemes’ BackupBuddy for deployment from dev to live server
JetBrains IntelliJ IDEA for all “development activities”
GitHub for online repository storage (all private until I have something worth sharing)

Final Maddening Quirk

Finally, I quickly learned that I wanted to turn off browser caching during development. CSS changes were not being applied in the browser, even though I knew the files had been updated. A bit of investigation showed what was happening – the browser was helpfully caching the CSS (and probably the JavaScript, too) instead of reading the file on a page refresh. The solution was to turn off caching in the browser (I’m using Chrome, your browser of choice might be different) as follows:

Open the “Dev Tools”
Select the “Network” tab
Click “Disable Cache” checkbox
Leave the Dev Tools windows open (I use it a lot anyway)

And, no, I did not figure that out on my own. The following two links were instrumental: