To work with CSS in WP Rig, it’s important to first know how CSS in WP Rig works. Let’s break down the file and folder structure, what the different files do, and how they work together, starting with style.css found in the root.
style.css is a placeholder in WP Rig
Traditionally in WordPress themes, style.css is the style sheet for everything in the theme, meaning all style rules are compiled into this one file. In WP Rig, it’s the exact opposite. Style.css is purely a placeholder. The comments tell WordPress, “Hey, this is a theme. It has the name “WP Rig” and all of the details about the version of WP Rig that you’ve downloaded.” WordPress then takes this information and displays it in the themes page on the admin panel so that people can see information about the theme before they install it.
This comment is required for WordPress themes to be recognized as themes by WordPress itself. Without it, WordPress won’t know there’s a theme available in this folder. This comment must sit in a file named style.css. However, this is the only piece of information that needs to be in style.css for the theme to work, so WP Rig places all the actual style rules elsewhere. You’ll see where and why as you read further.
As you start working on your own theme, it’s a good idea to edit the comment in style.css right away since it holds the information WordPress will display in the theme selection admin page. (You can change this information to anything you want and you can always change it later because it’s just dynamic information WordPress uses.) The theme I’m going to be building in this course will be called “New Rig”, so I’ll put that name in there for now. Then at the very end of the course, we’ll revisit this file and make sure everything is still correct.
Location of editable CSS
The actual style sheets you will be working with are found under /assets/css/src. This is the editable portion of the style sheet. This is where you actually edit the code, and then the build process will take the contents of the “src” folder, compile it, minify it and build it out, and place it into the root CSS folder. That’s what you will see once you’ve run the build process. You will have comments.min.css, which is the minified version of comments.css and so on. Inside the “src” folder, you will have the core files which include the regular modular style sheets (like /assets/css/src/comments.css) and also partials (like /assets/css/src/_blocks.css).
Block Editor (Gutenberg) CSS files
The “editor” folder contains the WordPress Block Editor styles (/assets/css/src/editor/editor-styles.css). These are styles that only apply to the Block Editor (also known as the “Gutenberg” Block Editor). These styles are only there to make sure that the editor looks the same as the front end. When you run the editor, it actually imports all the styles from your regular style sheets. These are just custom things that need to be in place because in some cases, the editor does some odd stuff. You’ll notice the style sheet here is really small compared to what’s actually happening in the overall styles.
Core CSS files and partials
Looking closely at the files inside the source folder, you’ll notice there are two types of files. We have the files that just have regular names, and then we have the files that have an underscore (_) at the front of their name. If you’ve ever worked with Sass or LESS, you’ll recognize these as partials. They work the same way as partials do, only they do so in pure CSS. There’s no Sass or LESS here. In fact, WP Rig does not support Sass or LESS. This is just pure CSS. Like I said, works the same way.
How does the CSS build process work?
Let’s look at global.css first. At the very top of global.css, you’ll see there are all these @import rules that call for these partials. If you’ve worked with CSS before, you’ll probably say, “Hey, @import inside a style sheet? That’s not good performance because now you’re making a bunch of calls to the server.” This is where the magic of the build process comes in.
Thanks to PostCSS, these @import calls actually turn into real code when the code is compiled out, meaning when we compile out the code, PostCSS goes and finds the contents of custom properties in place of this @import call inside global.css. Then it’s the same for _reset.css, _typography.css, _elements.css, and _links.css, meaning when we compile out global.css, global.css will contain the contents of all of these partial files. This only works with partials and it only works for the @import rule during the build process.
/*--------------------------------------------------------------
# Imports
--------------------------------------------------------------*/
@import "_custom-properties.css";
@import "_reset.css";
@import "_typography.css";
@import "_elements.css";
@import "_links.css";One important caveat; you can do this as much as you like, but you have to add these @import rules at the top of your style sheet BEFORE any actual style rules. If you try to add them further down, you’ll get an error from PostCSS saying, “Hey, hey, hey! You’re doing something you’re not supposed to be doing.” There are various reasons for this, but basically any time you use a partial, it needs to be called at the very top of the document.
Because style.css doesn’t contain any actual CSS, you’re probably wondering, “Where is the CSS that controls the overall layout and look of the site?” The answer is, that’s this file: global.css.
Main style sheet = global.css
/*--------------------------------------------------------------
>>> TABLE OF CONTENTS:
----------------------------------------------------------------
# Imports
# Custom properties
# Reset
# Typography
# Elements
# Links
# Accessibility
# Layout
# Forms
# Header
# Main navigation menu
# Content navigation
# Footer
# Infinite scroll
--------------------------------------------------------------*/
/*--------------------------------------------------------------
# Imports
--------------------------------------------------------------*/
@import "_custom-properties.css";
@import "_reset.css";
@import "_typography.css";
@import "_elements.css";
@import "_links.css";Global.css is called for every view, every post, every page, every index, everything else. Global.css is the main style sheet for everything. It is where you find the core components of a regular view.
In the comments, “TABLE OF CONTENTS” section, at the top of the global.css file (see above code snippet), you can see what styles are contained in the file. You will see the “Imports” (including Custom properties, Reset, Typography, Elements, and Links). We also have the required “Accessibility” styles that do things like hide text. We have the overall “Layouts” for the views and then the “Forms”. Then the “Header”, because the Header will always be loaded no matter how you load a Page. Inside “Header”, we have “Main navigation menu” styles. Then we have “Content navigation”. That is “previous” and “next” post, or “previous” and “next” posts, and indexes. And finally, the “Footer” and “Infinite scroll”. These are relatively sparse styles that only style the outer layers of the theme.
CSS files for non-global styles
Everything that happens inside a Post or inside a Page or anything else is kept in a separate file from global.css. You can see all of those files in /assets/css/src/. In addition to global.css, we have comments.css, which is only loaded if comments are actually present on the page. We have content.css, so that would be the content of Posts or Pages. We have front-page.css, which is only loaded if the front page template is used. We have sidebar.css, which is only loaded when a sidebar is in use and then widgets.css, which is only loaded if widgets are present on the page.
Now that you see the structure, I hope it’s clear why it’s built this way. By splitting out all of these different styles into separate components, it becomes much easier to work with.
If you need to make some changes to Post content, you go to content.css (see code below taken from content.css), and there you find the styles just for what’s in the content. For example, if you scroll down, you’ll find all the custom block colors for the theme. At the very top, you will see the @import for the _blocks.css partial. Blocks are the actual blocks that are built by the Gutenberg Block Editor. There you can customize the block pieces and so on.
/*--------------------------------------------------------------
>>> TABLE OF CONTENTS:
----------------------------------------------------------------
# Imports
# Blocks
# Media
# Captions
# Galleries (Legacy)
# Post and page content
# Alignments
# Custom block colors
# Custom font sizes
--------------------------------------------------------------*/
/*--------------------------------------------------------------
# Imports
--------------------------------------------------------------*/
@import "_blocks.css";
@import "_media.css";
/*--------------------------------------------------------------
# Post and page content
--------------------------------------------------------------*/
/* Custom rule for sticky posts:
.sticky {
}
*/
.entry {
margin-bottom: 1rem;
}Discovering where different styles are becomes much easier, and it also becomes much easier to control exactly when things load. It also means, as you build out your own custom style sheets and custom partials, make sure that they stay modular so they’re easy to understand and easy to apply only when they’re required.