Recently, I’ve been using (and loving) the new Gutenberg editor in WordPress 5.0+. It’s a huge step forward in both what developers can offer, and what users can expect out of their content creation experience.
One of the new features of Gutenberg that I particularly enjoy is the ability to set an image as either “wide width” or “full width,” to allow it to break out of its container element in order to span a greater width of the screen.
Here’s a visual example of what I mean:
Most of the content is constrained to a fixed-width container, but wide-width and full-width images may expand outside that container’s boundaries.
Ordinarily, an image would be constrained to the content width (visualized by the dotted lines in the image above). Being able to allow images to break out of those confines is a powerful layout tool, as it allows content authors to add a great deal of visual interest and hierarchy to any page, post, or content supported by the new Gutenberg editor!
Adding Theme Support
Adding support for wide- and full-width images is up to the theme developer. Fortunately, from the backend, it’s dead simple; just add this line to the theme’s functions.php file (please be sure to use a child theme as appropriate):
//functions.php
add_theme_support( 'align-wide' );
That tidy little snippet will make two new options available for image blocks in the Gutenberg editor, in addition to the usual options: “wide width” and “full width,” highlighted in the image below:
“Wide width” and “full width” options, highlighted, appear in the Gutenberg editor if the active theme supports them.
When the user chooses either of these options, the <figure> element that appears on the front-end of the site (oh yeah—by default, Gutenberg puts images inside <figure> elements, so that captions can be added easily. Anyway, that element, i.e., the image’s container) will have either an alignwide or alignfull class applied to it (depending, of course, on which was selected by the content author).
That’s it for the PHP/back-end setup. Other than the snippet above, everything we’ve covered so far is fully automatic and just handled by WordPress for us.
However, we still need to actually implement these layout techniques on the front-end of the site, using our theme’s CSS. Otherwise, nothing will happen visually when a content author chooses the full-width or wide-with image option.
Front-End CSS for Full-Width Images
I wanted to write this post mainly to share one technique that I came across online, which I feel is particularly clever in this situation (and which is not at all exclusive to Gutenberg or WordPress):
Even though that bit of CSS above is very brief (only two properties!), I still want to be sure we cover what it’s doing, because it’s a pretty elegant solution for our needs.
The width property is pretty straightforward: a value of 100vw ensures that the image is always exactly as wide as the viewport, no matter what size that might be. (Remember, width: 100% might not work here, because percentages are based on the width of the parent element, not the screen, and our image’s parent element may or may not be as wide as the viewport.)
However, making the image 100vw wide on its own doesn’t do us much good on its own, because it would overflow the screen, as shown in this image:
Setting the image width is only part of the solution, since it will overflow the screen unless it’s repositioned.
That brings us to the margin property, which is the clever part. This is where the real CSS magic happens:
margin-left: calc(50% - 50vw);
In case you’re new to the calc function, in essence, it lets you do math to set CSS values. It’s most commonly used in responsive design to, say, let your image take up a quarter of the available space, minus an 8px margin (which would be width: calc(25% - 8px);).
But calc has many other uses, and can crunch numbers on any dynamic or static values, even between two different units of measurement (as in the previous example, to subtract pixels from a percentage).
Back to our fullwidth image: in order to make the image the full width of the screen and position it properly, we want to set a negative margin. And as you’ve probably guessed, we’ll need calc to help us, because the distance between the side of our container and the left edge of the screen is responsive, and always changing.
So how do we determine how far the image needs to shift to the left? Answer: we don’t. 😎
Instead, we’re going to send our image halfway to the right. That’s the 50% portion of our calc formula:
Setting a side margin of 50% on the image puts its left side directly in the center of its parent element.
Now we can begin to see the full picture (no pun intended)!
Since percentage values are calculated based on the parent element’s width, a margin of 50% sends the image exactly halfway across the parent element. And since our parent element is already centered on the screen, that means our image is now exactly halfway across the viewport, no matter how wide the viewport is!
Now that our image’s left side is directly in the center of the screen, the rest is just subtracting50vw from the left margin—which is the other half of our calculation. Thus, calc(50% - 50vw) gives us exactly the full-width image we’re looking for!
A left margin of 50% – 50vw gives us the perfectly centered, fullwidth image we’re looking for.
There’s one small issue here, which is: we don’t take into account the possibility that our .alignfull element might already have a right margin. If it does, it will actually be taking up more than the full width of the screen, and that’s no good.
Plus, we probably want space above and below our fullwidth image, just to make it stand out a little more. So really, instead of setting just a margin-left property, we’d most likely be better off setting all four sides at once:
margin: 2rem calc(50% - 50vw);
This way, we’ve made sure all four sides of our image are accounted for while also giving the image a little breathing room.
And if you’re wondering (or just wanting to get super technical): yes, this does mean that both sides of the image get brought in by 50%, then are each pulled back out 50vw. If you didn’t have the - 50vw part of the CSS above, the image would effectively be 0% wide (since it would have a margin of 50% on both sides). Interesting! 🤓
Lastly, as you probably realized: this post assumes the content container is already centered on the screen. If your content is not already centered in the viewport, this specific CSS won’t work for you, and you’ll need to do something a little more creative to get your images full-width.
Front-End CSS for Wide-Width Images
Wide-width images work similarly to the above, but naturally, we don’t want to make them the full width of the screen; otherwise, there would be no difference between wide-width and full-width (and that, of course, would just be silly).
How wide the image should be, exactly, as well as how to achieve the effect, is ultimately up to the theme author. However, I find something like this bit of CSS works quite well:
Our wide width image spans the 100% of its parent container, plus an extra 20 viewport width units.
You might notice that in this case, I chose not to use negative margin, and instead, opted for a negative value on the left property (paired with relative positioning). Why’s that, and what’s the difference?
For the “why,” it’s mainly because: I wanted to illustrate that there’s more than one technique available here.
As for the difference…well, to be honest, which works better will probably depend on your use case, and the environment you’re working in. None of this CSS exists in a vacuum (hopefully).
If your images already have a side margin, then overriding that with a negative margin will probably work better (or, alternatively, you could just be aware that you may need to remove the side margin if you’re utilizing relative positioning).
There are undoubtedly posts written on the advantages and disadvantages of both techniques, and I don’t feel the need to retread that ground here. Some developers avoid negative margins like the plague; I think they’re fine in a situation like this, and as long as you’re not just using them to avoid changing a different part of the CSS, or as a hacky way to get around something that should just be fixed on its own.
Another note here: unless you’re ok with your wide-width images bleeding off the page at smaller screen sizes, you’ll need to either use a media query, and/or replace the 10vw with a value that doesn’t exceed the side padding/margin around your main content container.
(For example: if your main content container element, whatever that may be, has a padding or margin of 32px on each side, you’d want to make sure your .alignwide class had a width of no greater than calc(100% + 64px)).
I eventually landed on something like this for my personal use on wide-width images; they’re fullscreen up to a certain screen size (since they may as well be on mobile), then differentiate themselves starting at a certain @media breakpoint (likely the same one, or just above, where your content container element stops expanding and centers itself at a static width instead):
It’s been a goal of mine for a very long time to completely redesign my WordPress theme from scratch. Finally, that goal is a reality!
The first time I built my own site, back in (I’d guess) 2013, I used Adobe Muse, which was a good fit for my lack of skill at the time, but a tool that lost relevance as I learned to code.
In 2014, I launched a portfolio site that I coded (mostly) from scratch. Looking back at it now makes me cringe a bit; knowing how to make something work and how to build it correctly are two very different things.
I built a WordPress site on the Divi theme roughly three years ago. At first, it was built entirely on Divi’s visual page builder, and that was handy for creating new layouts quickly. But the more I learned about WordPress (and child themes in particular), the less necessary it was to have the parent theme around. It was extra bloat for mostly features I didn’t use at all. So for a very long time, starting over with my own theme, built from scratch and completely personalized just for this site, has been a goal—and now I finally get to check it off.
About the theme
Rather than beginning with a parent theme or a starter theme like Underscores, I wanted this theme to be built completely from scratch. No borrowed or pre-written code at all; 100% original.
For building, I began with Local by Flywheel. Yes, I work for Flywheel, but I honestly don’t believe there’s a better tool for running WordPress sites locally—particularly given that my live site is hosted on Flywheel already, which means that pulling a copy of my live site to my local machine for development (and then pushing it back live when ready) was all as easy as a click of a button, thanks to the Push to Flywheel feature.
I also implemented CodeKit, for minification, auto browser refreshing, and Sass compilation. Bonus: CodeKit works with Local seamlessly.
Speaking of Sass: it’s invaluable. During theme development, I set up variables for breakpoint widths, colors, some font families, and created a mixin for flexbox settings.
(That’s the ColorHelper Sublime extension creating the color boxes, by the way.)
I also got to take the opportunity to finally learn and implement Timber. I’d been hearing too many good things for too long to ignore it any more.
I love the way Timber makes template files so much cleaner, abstracting output code to bare minimums and eliminating the need to deal with the loop directly. Like any framework, though, there’s a little bit of a learning curve, particularly for some of WordPress’s more complex functionality, like comments and pagination. It’s very well documented, though. I would recommend it, and look forward to using it again. I’ll have to add it to my essential tools for WordPress development.
The theme runs mostly off a single index.php file which dynamically pulls in the appropriate Timber .twig files based on context. In fact, aside from the index file, the theme’s only PHP template files are the footer and header, the functions file, and a sidebar file.
Advanced Custom Fields + CSS Grid
I also took this opportunity to use CSS grid on a project for the first time—specifically, on the design page. It turns out, CSS grid mixes really well with Advanced Custom Fields, particularly the Pro Repeater field. I set up fields for images, height and width, to control the size of images in the grid:
The width and height have max values, and a Sass loop (and a media query) sets CSS for those values with classes:
New Logo
I’ve been using the same logo for myself since I was in school. On a whim, I decided to create a new one that more closely matches where I am now; more focused on development and applying design principles to the web.
As in the header, the logo’s “icon” form simply removes the lettering, leaving only two sets of brackets, implying code (particularly delving into objects or arrays), with the middle two characters highlighted and in the vague shape of a “J” and a “C” (my initials, of course). I like to think it also hints at my own duality of designer/developer.
The fonts
I’ve owned AmsiPro for years, and I’ve been waiting to use it on a project since I first saw it. I finally decided its personality was right for this project. It’s bold and friendly (particularly the ultra weight used for this site’s headers), but completely utilitarian and readable at lighter weights, as body copy.
I wanted to keep the font load fairly light, so only occasional splashes of Sagona Book Italic are used in places to highlight text. I’ve liked Sagona for a long time. I appreciate the hints of happiness in this Clarendon-esque serif, and I feel that makes it pair well with Amsi Pro.
Thanks for reading! It’s a personal goal to blog more this year and share some of the things I’ve learned over the past few, so this should just be the first of many new posts in the new year. Happy 2018!
What follows is a list of software, in some form, that I feel is useful, recommendable or indispensable when developing WordPress sites.
Some of these apps, resources and tools aren’t directly WordPress-related, or even necessarily development-related; some have to do with productivity or just make life a little easier. That’s by design. Part of being a developer is learning to work and use your tools as efficiently and with as little wasted time and mental energy as possible.
This is a list of the things that help me toward that goal. If you handed me a brand new MacBook and told me to get to work on building your WordPress site, everything on this list would most likely be in my dock, browser history and/or plugins list by the end of the day.
dropbox.com | Up to 2 GB free; 1 TB $9.99 per month.
You’re going to need somewhere to store your files, and Dropbox syncs beautifully with all your devices. You can also set up synced folders, so that anything you save in a particular folder on your machine is available on any machine, thus creating both a local and cloud copy. It can also automatically save screenshots, upload pics from your smartphone’s camera for safe storage, and send/receive client files easily.
lastpass.com | free to start; $12 per year 1password.com | $5 per month for families or $64.99 one-time fee for a single user
I don’t have a strong preference between the two, but there’s no excuse for not using a password manager in this day and age. Odds are good you’ll have at least two usernames and passwords to remember for every single site you work on—maybe more—and repeating the same one or making it easy to type and remember is an awful idea when you’re using the world’s most popular CMS. Saving brain power is making your life better and your workflow more efficient. And besides, these are extremely affordable apps; LastPass is only $12 per year. Make like Nike and just do it.
Honestly, it doesn’t matter all that much which text editor you use, as long as you know how to use it well. But I love VS Code because it just works.
I used to be on the Sublime Text bandwagon, and I won’t deny that Sublime runs slightly faster in some cases. But unlike Sublime, VS Code just works in the ways you want it to out of the box. Emmet comes pre-installed, as does git. There’s also no package manager to install; extensions are native, and easily available. VS Code comes pre-configured and you can customize from there in some amazing ways.
I highly recommend the following extensions, but you can mix and match your own as well (and by the way, this list used to be several entries longer; VS Code just automatically handles a lot of the things I was installing packages for in Sublime Text):
Close XML/HTML tag (for quickly adding closing tags; a feature of Sublime Text this package adds)
highlight-matching-tag (Shows where the closing tag is for a selected opening tag and vice versa)
WordPress Toolbox (for auto-completion of many WordPress PHP functions; a real life-saver)
generatewp.com | Free unlimited basic generators; premium starts at $7 per month
There’s a ton of PHP to remember in WordPress, the difficulty of which is compounded by the fact that many of the functions WordPress provides us are either confusingly or extremely similarly named. (Somehow wp_enqueue_script and wp_enqueue_scripts are totally different things.)
GenerateWP does the work for you in generating blocks of code. You just fill out some fields telling the site what you’re after and it will spit out the code for you to copy and paste in the appropriate PHP file. Everything from custom WP_Query loops to defining custom post types and much, much more can now be handled by checking some boxes and filling out a few fields instead of peering through the WordPress Codex trying to remember the difference between get_header() and wp_head().
Developing locally is always preferable to developing on a live server, for lots of reasons that I won’t go into here. There are a lot of programs and processes available for that; I used to use MAMP to make that possible. But ever since its release, Local has blown the other tools out of the water in my mind. It’s a phenomenal tool for WordPress development, allowing you to spin up and run sites locally. It also couples with CodeKit (below), which makes it even more awesome. Cowboy-coding—i.e., altering the code on a live site—is a bad habit; break it with Local (and save yourself a lot of FTP upload/download time in the process).
The most amazing thing about Local, though: you can actually give a link to your local development site to your client, and as long as Local is running on your machine—no matter where they are—they can see the site. That’s a total game-changer.
Quick disclaimer: I do work for Flywheel, but I’d be writing this even if I didn’t. With MAMP, I had to actually download WordPress, spin up a database, configure and run the install manually. Local does all of that automatically with a click of a button. (Plus the links thing above.)
It’s very hard to explain what CodeKit does in a way that makes it sound as indispensable as it actually is. Maybe that’s just because it has so many features it’s easy to drown the message. But even if you don’t use it for anything else, it’s capable of auto-refreshing the site you’re working on every time you save your code, seamlessly compiling your SASS files every time you save them, checking files for errors and allowing you to watch your site on multiple devices at the same time. (Yes—you can browse the site on your desktop and watch the exact same interactions happen on your smartphone at the same time, and vice versa!)
That alone, to me, is well worth the low $32 price tag, but that’s really only scratching the surface. It can grab external libraries for you, plus concatenate and minify your files so you’re ready to go to production with a lean, efficient set of CSS and JS files, and so much more. I promise you that if you give CodeKit a real shot, it will become an indispensable part of your workflow.
There may be no better way to spend $100 in the WordPress development world than on a developer license for ACF. It’s quite possibly my favorite plugin of all.
Sure, the free version of the plugin is still amazing, but its most lacking exemption is the repeater field. You won’t be developing sites for too long before you run up against a client variable: a situation in which you’re not exactly sure how many fields they might need. And allowing the client to account for that contingency on their own is well worth $100 in saved headaches. But even if a Benjamin is enough to make you balk, ACF has a wonderfully user-friendly pricing structure: you can buy a single-site license for $25 instead, and have that $25 apply to your $100 purchase later if you decide you’re ready for the developer license.
Aside from that though, ACF is perhaps the single most important piece of making WordPress sites ready for any client to use. Most clients can’t (and shouldn’t) be trusted with the full WordPress editor window, particularly where layout and media may vary. ACF allows you to build a fluid, automatic machine that takes care of all of that for you and your client when they simply fill out the fields and checking the boxes you’ve provided.
In short, ACF makes the experience of using the WordPress site you’ve built for them less like trying to cobble a page design together in a word processor, and more like using an elegant custom app constructed exclusively for the user. (And it has the bonus effect of preventing the client from screwing things up too badly, too.)
Your choice of browser is less and less relevant these days, but Chrome is still the industry standard for both its robust dev tools and the ability to add extensions to make your development life easier. I personally am a huge fan of:
Snatchr – allows you to see the type and color styles in CSS of the page you’re viewing neatly and easily
Pocket – saves pages and articles to read later (even saves them offline)! This is honestly a tool so handy it probably deserves its own entry
Web Developer – Does tons of useful things, like show the current page in several device sizes
Website IP – View the IP address of the site you’re viewing. Helpful when dealing with DNS changes and site migrations
Type Sample – Hover over text in the browser to see its font-family and -size, and click to type your own phrase in the selected typeface. Neat!
I like version control and having a repository of my code changes, but I really dislike using git from the command line. GitHub Desktop is a nice, app that gives you a more straightforward (for git, at least) experience with updating your code and pushing/pulling from GitHub.
Git and version control can be a bit intimidating, but GitHub Desktop does a nice job of abstracting the fear about as much as possible and making it simple.
If I’m being honest here, I couldn’t give you much of an elevator speech on why Transmit is that much better than its free alternatives like Cyberduck or FileZilla. A little more polish and maybe a better user interface, but we’re still talking about moving FTP files around here, so there isn’t a whole lot of room for distinction.
Still, Transmit is the industry gold standard in FTP clients, so there must be some reason for that (and the $34 price tag). I guess I just haven’t used other FTP clients enough to really know the difference, so if you’re into cutting cost, this might be a good place.
alfredapp.com | Free; Powerpack for extended functionality £17.00
Alfred is Mac software that doesn’t have anything directly to do with development, really; it’s just an incredibly handy little piece of software that can do lots of things to make your life in OSX just a little easier.
The “spotlight” feature (see what I did there?) is that Alfred can search for and open files and folders for you with a very quick and efficient search, so you don’t need to waste time digging through files structures or trying to remember where you put a particular document. You can configure this search to be very specific and to include/exclude whatever you like. Plus it does math, opens programs, defines words, runs system commands, opens browsers, and can be configured to do powerful things like keep clipboard history, run workflows, expand snippets and even open Terminal to run commands there.
It’s one of those tools that you won’t realize you ever wanted until you try it and realize you can’t live without it anymore. In fact, there’s a very good chance it would be the very first thing I installed on a new computer.
Even if you’re good at using workspaces and key commands, you probably spend more time than you realize in your day moving windows around your desktop: get the browser out of the way to use FTP, change the Finder window to be smaller so you can drag something from it to another window (which you also had to move), set the browser back to fullscreen, then move it again so you can see the desktop and open another window to copy some text before moving that window back out of the way—
Sound familiar?
Spectacle is a delightfully simple little app that allows you to assign keyboard shortcuts to resize and move windows for you. No more dragging; just hit the command you’ve defined and poof—your window is now on the left half of the screen. Or the upper-right quarter. Or the lower third. Or on the next workspace. Or fullscreen. Hit the shortcut again to put it back, if you need to.
Gallons of wasted time and effort are accumulated a drip at a time. Spectacle is one of those apps that helps stop the drip.
Amazingly, I just learned that TinyPNG is not only a website where you can compress the fatty megabytes out of your image files for free (often at gigantic reductions in both size and page loading time); it’s also a WordPress plugin! Install it and follow the steps in the plugin settings to get set up with an API key you can use to compress either new uploaded images, existing images, or both.
Like every compression plugin that I’ve found, at a certain threshold, TinyPNG does start charging by the image. That threshold in this case is 500 images per month, which may sound like a lot, but remember that every image file you upload to WordPress may get converted to any number of differently sized individual files, depending on your media settings. So one image upload may mean many compressions, and they can go fast.
The good news, though, is that the overage fee is 9¢ per image (which, again can stack up), although you don’t necessarily have to input a payment method to use the plugin, which will just cap you at your allotted 500 compressions until the next month. Neato!
Of course, if cost and limits are a factor, you can always manually drop your images into TinyPNG.com before uploading them to WordPress as much as you like for free.
[EDIT: While ClipMenu is still a wonderful tool, Alfred includes clipboard history as well, in case you’re an app minimalist like me. I’ve switched to Alfred for this particular functionality, but left this here in case you like the idea of keeping clipboard history but don’t need everything Alfred offers.]
You might not find this as handy as I do, but how many times have you copied something, and before you can paste it where it needs to go, accidentally copied something else?
Or how about this: how many times have you gone through the tedious process of changing back and forth between windows copying and pasting one thing at a time into place?
ClipMenu stores a history of your clipboard so that you can paste from dozens of the last things you’ve copied. No more going back and forth or accidentally copying something new, and no more worrying that you accidentally got rid of something you meant to keep on your clipboard. ClipMenu can be configured to store anywhere from a small number to dozens and dozens of the things you’ve hit command + c on.
wunderlist.com | Free for basic use; Pro $4.99 per month
It doesn’t take very long in development before you’re trying to keep track of lots and lots of tasks that need to get done. You might have a project manager who’s monitoring all of that for you, and they might be doing so through an app like Asana or Trello. That’s cool. But you also have personal to-dos, and shopping lists, and ideas to remember, and so on. That’s where Wunderlist is great.
Wunderlist is really just a simple list-making app, and that’s about it. But its elegance is in its simplicity and its ability to seamlessly permeate your life where needed and slide away into the background until then.
It’s a desktop app, a smartphone app and a browser extension, so you can make lists, add to them and check items off from anywhere and have the changes sync everywhere. Plus, you can set due dates and reminders for individual tasks, and you can share lists with other users. If you’re at all like me, you’ll see your productivity and reliability jump when you start making lists in Wunderlist.
And, of course, there’s that whole conserving mental energy thing I’m a big fan of.
You might know it as Calypso, the new WordPress.com, the WordPress.com app, Jetpack, or maybe even something else, but the (amazing) combination is just the same: manage all your WordPress sites together, in one tool, for free.
Let’s backtrack: in 2016, WordPress.com announced an all-new dashboard interface, codenamed “Calypso.” This new, elegantly simple JavaScript-based app could be used to manage the main features of all of a user’s WordPress.com sites—posts, plugins, themes, etc. This was fantastic news for owners of sites hosted on WordPress.com, but for the rest of the world, self-hosting their own WordPress sites, Automattic (the company behind WordPress, run by WordPress co-creator Matt Mullenweg) offered a way to connect as well: through their already mega-popular plugin, Jetpack.
So in short, Calypso—AKA the WordPress.com app—allows you to connect all your sites together to manage them in one simple dashboard. To do this, you’ll just need to sign up for a free account on WordPress.com, if you don’t have one already (and odds are good if you’ve been using WordPress for any length of time that you already do). Then you just install the Jetpack plugin (which has many of its own excellent features already, including a mini image CDN) and enter your WordPress.com credentials.
You’ll have access to one app dashboard to manage all your sites. The major key feature for me: you can update plugins and themes remotely, so you don’t have to sign in to each site individually. On its own, that’s fantastic, but the icing on the cake is: you can even set plugins and themes to update automatically. (Or should I say: automattically?) It’s a beautiful thing, and we haven’t even scratched the surface of all the other cool things Jetpack can do on its own.
It may seem completely unrelated, but I can’t tell you how handy it is to have an open playground for HTML, CSS and JS available at your fingertips at any time. I’ve learned lots of tricks, skills and shortcuts from trying things out in CodePen or looking at other users’ code to see how they built their neat-o creation. It’s also handy, when in lack of another solution, as a JavaScript linter and a debugging tool, or as a place to save code snippets for work or demo later. But more than anything, it’s a sandbox. And you can learn a lot by building things in it.
Photoshop also works, if you have access to it. So do the wide range of free or cheap Photoshop replacements. But at some point when you’re doing development work, you’re going to need to crop, scale or alter an image, so you’ll need some kind of photo manipulation software for that. I chose Affinity Photo as my recommendation because next to Photoshop (the general industry standard) it’s comparably robust but at a shrinking fraction of the price: at $49.99, Affinity Photo will cost you once what a Creative Cloud subscription will cost you every single month.
It may not quite have all the features of Photoshop (though it’s pretty close) or be quite the photo editing ninja that Lightroom is (though it’s no slouch), but to replace the two apps together for a comparably low price tag, I feel the tradeoff is more than worth it.
A Great Premium Theme
(If you’re not developing your own, anyway.)
Let me get this out of the way right away: many premium themes are bloated and inefficient, at best. Ideally, you’re building a custom theme for each client. But the world of ideals and the world of client work only have so much overlap.
Obviously building a client something personalized from the ground up is the ideal goal. It will likely run faster and almost certainly be more idealized for their purposes—those two go hand-in-hand. But ideal goals often conflict with the reality of deadlines and budgets, and in that situation, you need a lot of power that you know how to wield quickly and efficiently. That’s where a robust premium theme comes into play. Much like a framework, a great premium theme will allow you to get up and running in record time.
Personally, I’m a big fan of Divi by Elegant Themes (though I should mention it requires a vigilant eye, as it updates frequently and vulnerabilities have been discovered in older versions). But there are lots of other premium themes out there—Genesis, X, and many more—that will give you all the tools you need to get a site working quickly and easily.
On projects with lean budgets, I often implement custom developed pages and templates where needed—usually for the crucial and unique areas of a site—and then (with a child theme, of course), use a premium theme’s built-in tools to quickly assemble lesser static pages and content that don’t need any custom fields, one-off template files or other special treatment.
In short: when you need to build quickly and on a budget, you need a framework to reach for. Maybe that’s in theme form; maybe not. But having one that you know handy is essential for client work.
getflywheel.com | Single-site subscriptions start at $15 per month; bulk subscriptions (10+ sites) start at $100 per month.
Full disclosure: I work for Flywheel. But I still wouldn’t have another host even if I had the choice. The collaboration and client handoff tools are top-notch, the dashboard features (like a development mode, logs access, staging sites, cloned sites and others) are amazingly handy, and the performance is solid. Plus there are no headaches with things like keeping backups or restoring; it’s all handled. The support’s not too shabby, either. 😉
Other plugins:
Just a few of the modestly handy plugins I find myself using frequently:
WP Rocket
Concatenating and minifying your CSS and JS files is essential to optimizing page speed. There are free plugins to do this (like W3 Total Cache and Better WP Minify), but WP Rocket is worth the premium price tag to make the process simpler and easier. Ideally, you’d be handling all of that manually at the development level, but if that’s not an option, WP Rocket gets my vote for the best post-development fix.
Ninja Forms
Gravity Forms and Caldera Forms are also both fine choices, and I have no doubt there are others, too. I just like how easy it is to get Ninja Forms up and running for free.
WPS Hide Login The internet is full of bots looking for your WordPress login screen, but they can only find it if you keep it at the same URI as everybody else (/wp-admin). Change it.
Custom Post Types UI
Although I do enjoy defining custom post types on my own, CPT UI is admittedly the easier way to do it. Just make sure you don’t have a client who likes to go poking around where they don’t belong when you turn the site over to them.
Essential Grid I’m usually not much of a fan of Envato Market and its ilk because I disagree with some of their business practices and have had bad experiences with some of their plugins, but this particular paid plugin, at $26, offers the ability to get any kind of gallery up and running very quickly and easily on any site or page.
Yoast SEO I’m not a big SEO guy, but this plugin will help you write better content so that your viewers can find it when it’s relevant to them.
Enable Media Replace Super simple, but allows you to replace a media file and keep its metadata (URI, alt, title, etc.) intact rather than having to delete it and upload a new file every time there’s a change.
Show Current Template More of a debugging tool than anything, but it’s extremely helpful to be able to tell whether you’re bucking the WordPress template hierarchy successfully, and which PHP template files aside from the main one are being loaded on the page.
Insert PHP Handy if you need to run some PHP code from a WordPress content field. (Most developers will of course have ways around this, and it’s presented here as more of a hack than a recommended way to do things. But in a pinch it works remarkably well.)
Force Regenerate Thumbnails If you change your media upload size after you’ve already uploaded some images, you’ll want to run this.
Captcha There are many kinds (with many levels of intrusiveness), but since Captcha secures all forms, it helps keep bots out of your comments, contact forms, and your login screen. Those are all really good things.
Akismet It’s almost not worth mentioning because of its ubiquity and the fact that many WordPress users don’t even allow comments on their site to begin with. But if you do allow comments, activate Akismet, get an API key, and and put the API key in place.
That’s it! I hope you’ve found something useful here. Happy developing, WordPressers.
One lesson a lot of WordPress novices learn the hard way, just like I did, is that if you want to customize anything about your theme itself—whether that’s editing the CSS styles, adding functionality like a custom post type, changing the header code or creating a custom page template—you need to be using a WordPress child theme.
(There are of course plugins to handle all of the above tasks, and if you want to go that route instead, that’s fine. I personally prefer minimizing plugins since each one active is a slight drain on page load speed and one more thing to worry abut updating, but it’s a matter of personal preference.)
When you’re just starting out with WordPress, it’s easy to think that you can just make edits by opening up the main theme’s included files (like style.css or header.php) and making whatever alterations you see fit. And that will work—at least for a while—but it won’t be a good idea.
Why? Because themes update. As improvements are made, bugs are fixed and issues are patched, your theme will most likely be altered by its author, who will push an update. At that point, you’ll log in to WordPress and receive a notification that your theme has an update available, and should you click it, any custom changes you may have made to your theme’s code will be overwritten, replaced with the fresh new version.
This leaves you in the unfortunate predicament of choosing between redoing all of your file changes every time an update is issued (which, depending on the theme, could be many times a year) or making sure you (and your clients) never update the theme at all.
Neither of those are good choices, obviously. You need efficiency, and you need to be updating your theme(s) for optimal security and performance. But fortunately, you have a third option: create a WordPress child theme. Then all your problems are solved and the above issues can be safely and easily sidestepped!
So what is a WordPress child theme?
A WordPress child theme is kind of like an add-on extension of the main theme. A child theme borrows everything it can from its parent theme, but exists independently apart from any files you want it to share. A WordPress child theme allows you to add files to supplement those of the parent theme, taking precedent over the parent’s files without the risk of being overwritten.
A WordPress child theme is kind of like an add-on extension of the main theme. A child theme borrows everything it can from its parent theme, but exists independently apart from any files you want it to share.
To put it in simpler terms: any time WordPress needs a theme file (say, for example, header.php), it will look inside the child theme folder for the named file. If there is a file by that name in the child theme’s folder, it will use that file. But if not, it will look for a file by that name in the parent theme’s folder instead, and will borrow that file from its parent theme.
This works perfectly for any file in the WordPress template hierarchy, but you might be wondering: what about my CSS?
In the case of our stylesheets, we can set up a child theme to use all of the parent theme’s styles (because we likely chose our main parent theme in part due to its appearance and don’t want to be forced to start from scratch), but then to load a custom child theme stylesheet afterward, which we can use to override and replace certain existing styles as we choose.
The process of setting up a child theme can seem a little intimidating, particularly if you don’t spend much time in FTP or WordPress’s file structure, but it’s actually pretty simple. Let’s walk through the steps.
Step 1: Create a New Theme Folder
If your site is already up on a live server, you’ll need to connect to your site via FTP in order to do this. (If you’re not sure how to do that, check with your host, and if you need an FTP client, I consider Transmit to be well-worth the price, though there are free options available.) In any case, you’ll head to the wp-content/themes/ folder.
Inside that folder, you’ll see a list of themes on your site, probably similar to this:
Here, you’ll simply create a new folder and name it whatever you want your child theme to be named. Usually, this is a hyphenated version of the parent theme name, such as with “enfold” and “enfold-child” in the screenshot above. This naming convention exists so that anybody looking at the list of themes can immediately tell which themes rely on others, but if you’d rather, the name can be whatever you want.
Step 2: Create a style.css File
Open the child theme folder you just created. Inside it, make a new file and name it “style.css”.
It’s important that you give the file this exact name. If you’re not familiar with the inner workings of WordPress: it looks for files based on their name. WordPress expects to find a style.css file in the active theme’s root folder; it’s programmed to know that’s where to find info about a theme. So it won’t automatically find and load it if it’s not specifically named “style.css” and placed inside the theme folder. (You could load it other ways, but that’s just making extra work for yourself.)
As far as the file itself, you can either create it in your FTP client and then open it in a text editor to make changes; or you can use a text editor to create and save a style.css file locally, and then upload it afterward. It’s up to you; just as long as the style.css file gets in the child theme folder, you’re good.
Step 3: Add the Following to style.css
If you look at the Codex entry for child themes, you’ll find the following snippet of code to copy and paste into your child theme’s style.css file. Don’t copy and paste this just yet, though; I’m only giving you the full list of things you might see at the top of a theme’s style.css file:
/*
Theme Name: Twenty Fifteen Child
Theme URI: http://example.com/twenty-fifteen-child/
Description: Twenty Fifteen Child Theme
Author: John Doe
Author URI: http://example.com
Template: twentyfifteen
Version: 1.0.0
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready
Text Domain: twenty-fifteen-child
*/
It looks scary, but I’ll let you in on a little secret: almost none of the above is actually required for your child theme to work properly. In fact, most of it is there for people who intend build a new theme and distribute it.
If you’re creating a theme to distribute publicly, you’ll want to fill out every line of the above snippet as accurately as possible. But if not—if this is a child theme that’s only going to be used by you or your client on your site alone—you can safely skip most of the above (though you should still include some of it).
At this point you might be wondering: isn’t this just a comment? Why do I need to include it? Aren’t comments supposed to be read by humans and ignored by computers?
WordPress finds, reads, and understands what to do with a file based on its specific name and the comments at the top of the file.
You’d be mostly right, but actually, browsers and servers do read comments. (Otherwise, how would they know when the comment was over?)
In the case of WordPress files, comments are frequently used to pass WordPress information about themes and plugins. Just like the file’s name is important, having the above comment snippet at the top of your style.css file is also important; it’s how we can pass certain important pieces of information on to WordPress about our theme! But from a purely functional standpoint, most of that info up there is actually not crucial at all for a WordPress child theme to function.
In fact, if you want to save yourself the hassle, here’s all you’ll really need to worry about:
/*
Theme Name: Your Theme Name
Template: parent-theme-name
Text Domain: your-theme-name
*/
Even of the above three lines, the Template line is the only one that’s strictly necessary for the child theme to function, but you’ll want to fill out the others too. Here’s what each one does:
Theme Name:The human-readable version of your child theme’s name. This is what will appear in your themes list within WordPress itself. Can be anything you want, and can include capital letters and spaces. Doesn’t have to be named something relative to the parent theme, but probably should be just for clarity.
Template:As mentioned, the only mandatory line. This should be the name of the parent theme, written exactly as its folder name is written within the themes directory. This tells WordPress where to find the parent theme files when it needs to.
Text Domain:The “sluggified” version of your theme name (in other words, your theme name without capital letters or spaces). This is how WordPress refers to your theme in code. It has to do with localization.
Though the above three are the main functional pieces of the puzzle, it’s still good practice to include at least the Author and Author URI lines as well, so that anybody who might be working on the site after you’ve done your work can figure out where this child theme came from and whom to contact if they have any questions. Description is always nice too—it’s the paragraph that shows up on the Theme Details page in WordPress, so it allows you to share some added info with any admin who might be using the site. But those are optional and not related to the actual functionality of the WordPress child theme. The rest of the lines we haven’t talked about hold info that’s shared by theme developers when they release their themes publicly.
All of that is a long way to say: it’s just a simple process of copying and pasting the above snippet of code to the top of your WordPress child theme’s style.css file, and replacing the pertinent details with your own (and optionally deleting anything you don’t need). It looks a bit complex, particularly if you aren’t familiar with WordPress file comments, but it’s actually very simple: just replace the part after the colon on each line with your own info!
Now that you have a properly commented style.css file in your WordPress child theme, you can add all your CSS to it, below the opening comment!
You should know that the CSS won’t actually take effect yet, however. Later, in step 3, we’re going to tell WordPress to load the parent theme’s stylesheet first and our child theme’s stylesheet second. This way, because of the way that CSS works, any styles that you add to your child theme’s style.css file will load last, and will therefore override the parent theme’s CSS so that you won’t need to delete or alter anything in the parent theme’s stylesheet. Huzzah! (This is assuming, of course, that the child theme’s styles are of equal or greater specificity. If you’re not sure what that means or if you could use a refresher on CSS specificity, check this article out.)
But until we do that, our CSS in this file won’t actually work. WordPress assumes we’ve put our theme info at the top of our style.css file, but it won’t assume we want to actually use it as a file for our actual CSS styling. That will come shortly, when we use functions.php to enqueue our parent theme’s stylesheet, and then our child theme’s.
…any styles that you add to your child theme’s style.css file will load last, and will therefore override the parent theme’s CSS so that you won’t need to delete or alter anything in the parent theme’s stylesheet.
This way, the parent theme is free to update all it wants, but your styles remain intact and unaffected. Your site stays up-to-date and secure, while your styles stay safe from unintended alterations.
(Side note: if you want to create and use other stylesheets, too, you can do that; you don’t necessarily need to put all your styles in this style.css file. But since every stylesheet has to load separately, it’s generally best to use just the one CSS file unless you have a good reason not to.)
Optional Step: Add a Screenshot
While this step is completely optional, it’s fun, and it helps your child theme feel a little more professional.
To give your theme an image that will appear on the theme selection screen, just save a .png inside your child theme’s folder (the same place you saved the style.css file above) and name it “screenshot.png”. WordPress will try to work with pretty much any size, but an image with a 4:3 ratio works best, with the recommended resolution being 880px by 660px.
While this feature exists so that you can show potential theme users what their site will look like if they activate this theme, if you’re working on a child theme, you can add that extra little something special by making screenshot.png your logo or your client’s logo.
Step 3: Create a functions.php File
In the last couple of steps we created the style.css file for our child theme, but we still need to tell WordPress to include (or “enqueue”) the parent theme’s stylesheet as well as our new child theme’s stylesheet, in that order.
In just the same way that you created a new style.css file inside your child theme’s folder, you’ll now create a new file named “functions.php” in the same place, i.e., your child theme’s folder. (You can create it with your FTP client and then edit it, or make it on your local machine and then upload it. Up to you.)
Again, however, it’s critical that this file is named “functions.php” exactly (mind the plural); otherwise, WordPress won’t know that it’s the file containing our child theme’s unique functionality and won’t find and run it automatically.
What is functions.php?
When any given WordPress theme is active, any code in that theme’s functions.php file will run every time a page on that site is loaded (as will its parent theme’s). So our child theme’s functions.php file (and its parent theme’s functions.php file) will load and run every time a new page loads, as long as our child theme is the active theme.
You can think of functions.php a little like a custom plugin specially made for your theme.
This is true in both the WordPress admin area and the front-facing portion of the site. That’s why things like styles, custom post types, navigation menus, theme features, and other “always-on” bits of functionality are generally added to functions.php. You can think of functions.php a little like a custom plugin specially made for your theme.
Step 4: Copy the Enqueuing Function to functions.php
If you’re not familiar with (or intimidated by) PHP, don’t worry—you don’t have to make any changes to the above code, or even understand it, really. You just need to copy and paste it into your WordPress child theme’s new, blank functions.php file. (Technically, it would be best practice to change the two instances of “theme_enqueue_styles” to reflect your custom theme name in order to avoid any potential conflicts, but it’s not strictly mandatory.)
There are other ways to code the enqueueing of parent and child stylesheets, but this way is straight from the Codex, and ensures that the child theme’s stylesheet loads after the parent theme’s (which is what we want).
By the way: you’ll want to be sure you have the opening php tag (“<?php”) at the beginning of your functions.php file, but the closing tag at the end isn’t strictly necessary, especially if you plan on adding more code later on.
Just make sure your style.css and functions.php files are both saved inside your child theme’s main folder, then there’s only one more simple step!
Step 5: Activate the Child Theme
You’re done with file editing now. All you need to do is sign into WordPress on your site and head to Appearance > Themes from the admin sidebar. You should now see the child theme you created in the list of available themes for your WordPress site (with the screenshot image showing if you took on the optional step above). Just click the “Activate” button and you’re good to go!
If you previously had the parent theme active, you probably won’t see any visible changes on your site. You’ll notice a difference, though, when you start populating your child theme’s style.css file, adding to functions.php, and/or adding custom page templates to your child theme (though that’s a topic for another time).
That’s it!
You’re done! You’ve created a WordPress child theme, and can make all the changes you want to your site’s appearance and functionality—through style.css and functions.php, respectively—without any worry of your code being overwritten when the parent theme updates. Go, you!
Have anything to add? Did I miss anything? Feel free to let me know in the comments below.
If you’re like me, you’ve probably spent some time wondering (and Googling) about the differences between various popular format types commonly used for graphic design applications. I’ve found out I used or exported the wrong kind more times than I care to admit, and I’ve asked or been asked the difference between a jpeg and a tiff on countless occasions. Even now it’s difficult sometimes to remember whether certain file types support things like CMYK color or transparency, and so I decided I’d create a resource that’s hopefully a handy reference on the matter of discerning file type supports and behavior.
Someday I intend to update this into a browser-rendered chart, but for now, due to time constraints, it will just have to exist as a graphic.
A few notes about the chart and its summary:
.jpg tends to be the best format for a photo or image with many colors where image size is a concern (especially on the web).
.tiff is the ideal format for photo and raster applications where quality is the priority.
.tiffs and .jpgs each support both RGB and CMYK, but this does not mean that a single tiff or jpeg file can be used for either application. In other words, .tiffs and .jpgs can exist as either CMYK or RGB files, but not both at the same time.
.png is ideal for transparent raster images on the web or for web images with a low number of colors where compression may degrade quality (e.g., logos at fixed sizes or illustrations with large areas of flat color).
.svg files (as their name implies) are designed for getting vectors to function and render on the web, as well as dynamic web animation. Ideal for logos on the web and other images that may need to display well at multiple sizes.
.eps and .pdf have mostly the same functionality, and if you have the right software at your disposal they’re largely interchangeable. However, .pdf is much more universal. This makes .eps a great choice for embedding or editing individual images (though .pdf also works for this purpose) and pdf better for outputting content for the end user to view or read. Regardless, they’re both pretty much your only option for Pantone/spot colors, outside of Adobe’s native file formats (.ai, .indd, etcetera). For more on that topic, see my post Pantone®, Color, and What I Wish I Had Known.
.gifs are still out there, but aside from animation, there’s nothing a .gif can do that a .png can’t do as well or better.
If you don’t know this already, if there’s an X in the CMYK column above, don’t use that format for print (unless you’re printing a screenshot for some reason).
You may have noticed that .jpg is the only format above not capable of supporting transparency. Don’t waste your time trying to create a clear .jpg (or exporting an all-white Photoshop document as a .jpg without inserting a dark background first).
Not shown in the chart but important: screens have a native resolution of 72 dpi, while print has a native resolution of 300 dpi. Thus, an image that’s 1800 pixels wide in web resolution will likely be larger than your screen can display at full size, but will only be five inches wide at print resolution. Keep this in mind when working with raster files.
It’s increasingly rare (thankfully) that a client would request a .wmf; I just included it on this chart in case it happens.
If you have any questions or comments, please let me know!
