random posts about nerdy stuff

Handy Automator Actions

When building websites, I often have to make edits to images, filenames and other tasks that are quicker to do when automated. I use Automator to add Services to my contextual right-click menu right in the finder/desktop to perform some of these tasks. They're quick and simple to set up, and even easier to use.

Basic Image Edits

Perhaps I have some 12 megapixel JPGs that I need to upload to a CMS like Wordpress. If they're too big or the wrong format for a website, they'll need some edits before uploading. Simple solution: batch them before upload. All I have to do is right-click on the image or images and select my action from the Services menu and they're ready to go.

Resize an image to 50% it's original size

Maybe I have some photos sent to me as TIF, PSD or PNG and want them in JPG format:

Convert image to JPEG

Or PNG format:

Convert image to PNG

Or rotate one or more 180°:

Rotate image by 180°

Any of these Automator actions will make the change the original file, so be sure to make a backup first if needed.

Other Handy Actions

Let's say I have a list of files named "Screen Shot 2019-02-19 at 5.20.32 PM.png" and want them to be web-friendly (no spaces in the file name). I could rename them one at a time... or update them all with an Automator action:

Convert to Web Friendly Filenames

After that's done, all selected files are renamed to something that works better in a browser, like "Screen-Shot-2019-02-19-at-5.20.32-PM.png", which avoids those pesky %20's.

My Most Used Action

As I've noted before, I like to keep my desktop tidy. I have apps that open in the same size and position on my screen every time. If I need to move or resize it, with the following action I can easily snap it right back to where I want it.

Resize Window Postion

I have set positions for left, right, finder, chat window, among others. Each are set to an x, y, width and height to fit perfectly on my screen. You'll probably want to adjust the values for your setup/screen size. There are apps out there that do this for you, for MacOS and Windows, but I find it handy to define something more specific than "left side" and "right side".

Hope you find these actions useful. I recommend digging through the Automator app to see what other handy things it can do.

How to Create a Barebones Wordpress Site

There are many important steps when building any site that are crucial to ensure a successful end product.

  • design direction, either by a theme, comp or sample site
  • pages in the site
  • description for each page type
  • discussion with developer to determine ideal plugins to achieve scoped functionality
  • scope that brings it all together

Before development begins, the developer should know which sort of page templates may be required based on the design and scope.

Building the Barebones site

Start with a fresh, local Wordpress installation and create a child theme. A child theme builds upon the parent theme and can be updated separate from the child. If an override file does not exists in the child theme, it'll fall back on the parent theme's code. For this doc, we’ll assume the site will be for naming conventions.

Child Theme

  • Create a new folder in wp-contentthemes/ called ‘demosite’. This is where all of the base theme overrides will exist. Anything not overwritten in the child theme will use the parent theme’s code template.
  • Within that new folder, create an EMPTY style.css file, meaning there’s no other CSS in there, with the following CSS comment:
 Theme Name:
 Description:  Twenty Seventeen Child Theme
 Author:       [ primary developer name ]
 Author URI:
 Template:     twentyseventeen
 Version:      1.0.0
 License:      GNU General Public License v2 or later
 License URI:
 Text Domain:  twenty-seventeen-child
  • If the design is set, also create a screenshot.png file of the homepage in the child theme folder so that it shows up in the wp-admin > themes area
  • Log into the Wordpress admin and select the the theme. You are now using the demosite child theme on the front end.

Child Theme Directory Structure

As with any site, it’s best to keep code organized. I like to follow the standard organization structure that groups CSS, JavaScript and Images in their own folders.

Keeping code organized not only helps making things easier to find, but is handy when multiple developers are working on the same codebase to avoid two people working on the same file.

/css - unique CSS file for each major group. Plugin will combine and minify for us. Ideally, the child theme's style.css file is ONLY used for the theme setup comments as described above. Do not use @import unless a web font requires it.

  • demosite.css - primary CSS
  • responsive.css - media queries for all breakpoints
  • grid.css - whichever grid system is being used, e.g. bootstrap, skeleton, etc
  • forms.css - formidable styles
  • whatever.css - set of CSS for a particular widget or plugin element that should be self contained

/js - unique JS files

  • jquery.functions.js - the custom JS for this particular site
  • jquery.whatever.js - some third party element, widget or plugin

/images - all non Media images used in the template / theme the admin doesn’t need to manage. Good place for placeholder / fallback images and layout assets.

Copy code from the parent theme directory to modify as the site requires, which will include things like:

  • functions.php - site wide functions, admin limiting functions, define extra function files (more on that below), helpers, etc. Note, you should start with an empty functions.php
  • header.php
  • footer.php
  • page.php
  • 404.php
  • single.php

Organizing Functions and Shortcodes

Functions.php can become a huge file when not organized well. To better handle large amounts of code, I create a functions folder in the theme directory for things like:

  • rewrite.php
  • hooks.php
  • shortcodes.products.php - for product related shortcodes, others for each unique set of shortcodes

The functions.php file would include the main functions and require() lines for each of the functions/* files that are included in the site.

Building the HTML

As with any site, you are in full control over the front-end HTML and CSS. Just build it like you would any other site.

Pick a Grid system

Popular grid systems such as Skeleton: Responsive CSS Boilerplate, Grid by Example, Bootstrap · The world’s most popular mobile-first and responsive front-end framework., or my favorite Generate your own Grid with the Responsive Grid System calculator. can help get you started with a responsive CSS grid framework. All of these options let you customize the number of columns, margins and responsive breakpoints so that you can build the design as per comp. For the Grid System Calculator, I like using the :not(‘responsive’) CSS attribute to retain columns at mobile breakpoints.

Though it’s ideal that there’s only one grid system in use, some plugins might have their own. Be sure to review these plugins before use to reduce CSS bloat.

Plan your HTML

Throughout the site, there will be common elements that should be structured consistently to share CSS classes. It’s a waste of time to build unique CSS for elements that look and function the same across multiple places, all it takes is good planning to make sure the CSS file is organized and short.

For common elements that are close, but not exact across pages, use CSS subclasses for page-specific instances. Example, homepage might have a news listing grid where the title is 16px, but on a news detail page those boxes have 14px size titles. Simply have a main news-listing title CSS and a news-listing.subclass title subclass to handle those variants.

Build your HTML

However works best for you, build out your HTML comp cutups. You may prefer to do this directly within the Wordpress environment or as standalone .html files (my preference so that I can responsive test before implementation). Keep in mind that blocks of HTML should be written in such a way that they can be converted into shortcodes when pulling in dynamic Wordpress content.

Though a comp or expected design might have limited placeholder content, the client can always increase or decrease the amount of actual content. A responsive site design should be able to accommodate dynamic amounts of content and imagery.

Integrate with Wordpress

Take your header, footer, code blocks and page templates and get them into Wordpress.

  • header.php
  • footer.php
  • page-template.php
  • functions/shortcodes.whatever.php
  • etc.

Page Templates

Each page that might require a unique layout should be set up as a page template. Page templates are able to be selected by the admin on a per-page basis and are added to the codebase by creating a PHP file with a unique name and custom PHP comment at the top of the page.

That's all there is to it. Easy, right?

Design Consistency is Key

When designing, it's ideal to have an established style guide that outlines specifics such as font family, size, colors, etc. If the style guide is detailed and complete, a web project build is much easier to plan out. The developer can start building the CSS based on the style guid, creating assumed blocks of content, images, colors and fonts before any front-end HTML is written.

The Style Guide

The style guide sets the rules the design will follow, and details the specifics for each element such as font, color, size, etc. A detailed style guide should include HEX and RGB colors as well as alternate colors or treatments for any interactive elements such as buttons or links. For print media PMS and CMYK colors are important too. Find some great Style Guide Examples here.

A website design may have variations of common elements, such as a featured post that happens to be blue instead of gray. However, the element "post" would and should share much of the same style. These variations, when outlined in the style guide, makes it quick and easy to plan out in the CSS and HTML.

Example of two HTML blocks with CSS variations

The style guide can be made before or after the actual design comps are created, though having a thorough guide is useful for both designers and developers.

Use Symbols in Your Design App

Most design applications have tools in place that help keep your multi-page layouts consistent between pages. Apps like Sketch, Adobe XD, Illustrator, and Photoshop all have objects that can be reused and modified for each instance, and color pallets that help ensure you're using the same specific color on each instance. Using these tools, you can create one element that defines the base look, and change the content, color, image, etc. when used elsewhere. Cool thing about symbols is if you decide to change the base, those changes would auto update all instances of the symbol.


Sketch - Creating and Using Symbols
Adobe XD - Work with linked symbols
Work with Smart Objects in Photoshop

Writing Clean CSS/SCSS

So we have a style guide and some comps from Sketch or Adobe Illustrator and start building the website. First thing to do is look at all the common elements in the designs and write CSS classes for each of those blocks.

.block {
	background: white;
	border-radius: 6px;
	h1 {
		font-family: Georgia, serif;
		font-size: 24px;
		color: #666;
	p {
		font-family: Arial, sans-serif;
		font-size: 14px;
		color: #999;

Now that we've defined the default style for a .block element, we can create variations of that element with subclasses, perhaps in this case we want a dark background with light text while retaining the font and font size. We do that right within the .block CSS before the closing bracket.

	&.dark {
		background: #444;
		h1 {
			color: #fff;
		p {
			color: #ccc;

In our HTML, we can create a .block element or a .block.dark element that will look identical other than the background and text color. The block design remains consistent with a variant option set to match the designer's comp.

Design consistency makes styling HTML markup quick and easy.

If the site designs adhere to the style guide with consistent block margins, padding, fonts and colors, it makes it easier to reuse those blocks elsewhere simply by changing the contents. The design language is cleaner if there aren't too many variations to common elements. For example, if we have a quote on one page that's within a gray box with 20px padding around the text, it shouldn't have 8px padding on another page. The style guide defines what an element looks like wherever its used. Unless absolutely necessary, you shouldn't need 20 dramatically different variations of a basic element.