Website Redesign: Setting Up My Development Environment

Now that I have settled on a general look and feel for this site, I’ve been working on setting up my development environment to make it happen.

The last I worked on this site, I heavily relied on CodeKit to handle my development. It was a wonder back then because it was so simple to configure Sass for writing styles, integrating Foundation for the framework, and compiling everything from JavaScript to images. It’s still a wonderful app.

I’m going a different direction this time around because I plan on having fewer dependencies. For example, buh-bye Foundation! Not because it’s bad or anything, but because I was only using it for the Grid anyway and CSS Grid is more than up for the challenge of replacing it. That should be a huge performance gain for me since I don’t have to import hundreds of kilobytes just to lay stuff out.

I chose Gulp

So, I’m using Gulp for the first time. I had been using Grunt on projects, but have been convinced that Gulp is a little faster at compiling assets, despite finding Grunt easier to configure. Gotta learn something new, right!

I wasn’t really sure where to start with Gulp. I looked at some projects I’ve worked on where it was used but couldn’t find a configuration that I love. Chris recently shared his Gulp setup. I was tempted to copy his approach because (1) he’s a smart dude and (2) he rolls with a WordPress site as well.

But I remembered editing a post by Ali Alaa in 2018 that has a pretty nice flow. While it’s not 1:1 with what I’m looking for, I was able to fuss with it a bit and it to be something that works… at least for now.

Sass setup

The hardest part of any job for me is naming things but that’s sorta what setting up is all about. I’m breaking my Sass files up into partials, of course, but I’ve always tortured myself over how to organize the files. There are so many opinions and approaches and I’m finding myself non-committal.

I still haven’t really settled on something, but decided to divide things out a little bit, like a folder for global elements (e.g. body, header, footer, etc.), one for components (e.g. navigation, posts, etc.), another for variables (e.g. colors, custom properties, typography, etc.) and so on. It looks like this so far.

Again, probably not perfect, but it’s making senes so far and I’ll improvise as I go. That’s the benefit of a personal site — I can do what I want!

WordPress setup

Not too much to add here. All I’m really doing is working with an existing WordPress installation and developing a new theme for it.

One difference is that I’ll be using the Gutenberg Block Editor instead of the Classic Editor. I’m a fan of the new editor even if it has some serious needs. It’s the first time that WordPress like a content management system in the sense that I no longer need to hack around with HTML in the editor because blocks make it so much easier to customize the layout of any page or post.

In other words, I can focus more on content and less on development.

I’m using Local by Flywheel to serve my local development. That’s a change from the last time when I used MAMP Pro. Local is ridiculously user-friendly and offers an interface for things that took manual configuration in MAMP. I still love MAMP. But the future looks much more like Local to me.

Mind you that Local is purely for a PHP server. My Gulp setup uses Browsersync to live-reload the browser when saving changes to any file. I found that Local and Browsersync tend to step on each other’s toes. Browsersync wants to run at localhost:3000 while Local sets my domain to geoff.local. The .local TLD seemed to be the major culprit and changing it to .dev appears to have fixed things up so Browsersync actually does its job. The Local domain still doesn’t “work” because Local apparently prefers it’s default TLD, but I’m OK doing all my work from localhost.

One thing that usually takes a second to think about: the style.css file. It’s required for any WordPress theme because that’s where the theme is registered. But compiling Sass into that file is often crappy because it requires an additional Gulp plugin to generate the text that WordPress requires at the top of the file. I’ve decided to generate my own style.css file, store it in a /dist/css folder and enqueue my custom file:

/**
 * Enqueue scripts and styles.
 */
function geoff_graham_scripts() {
  wp_enqueue_style( 'geoff-graham-stylesheet', get_template_directory_uri() . '/dist/css/style.css', array(), '1.0.0', 'all' );
}
add_action( 'wp_enqueue_scripts', 'geoff_graham_scripts' );

That means my WordPress CSS file will remain empty, except for those required comments, and my custom file will hold the site’s styles.

Nitty-gritty stuff

In case you care, I’m using VS Code as my IDE, Sequel Pro for database stuff, GitHub for the repository (and, yes, I’ll open-source this thing) and Tower to push to the repo. I actually plan on using the command line a little more to get a better handle on it, but I’ll lean on Tower for the branch management stuff that’s usually over my head.

Next steps

I’m going to tackle some of the global elements first, like the site header and the navigation. I’ll also spend some time on the homepage. I also have to start creating and naming my Sass variables and CSS custom properties. Naming things is hard!