Load modular style sheets

In-body modular style sheets means the developer defines when and where modular style sheets are loaded. Here, we go over how this is done and how you can make modular style sheets of your own.

The style sheets in WP Rig aren’t just modular in that they contain individual modules, like comments, sidebars and widgets. They’re also modular in that they load with the module they affect.

Meaning, if you have a page that has the sidebar, then the sidebar.css file loads; and if you have a page that doesn’t have a sidebar, sidebar.css does not load, because it belongs to that module.

In addition, these style sheets are loaded at the component level in the body element.

Take for example a page with some comments on it. If you scroll down to the comment section, and go to Inspect Element, you’ll see that right in the HTML, there is a call for the comment style sheet. The call sits in the middle of the body element, not inside the head element where you normally see link elements to style sheets:

It might look really crazy, because shouldn’t you be calling the style sheets at the very top?

Not necessarily. Modern browsers can do something with this that is completely new. In the future, when all the browsers are online with this, we’ll be able to call style sheets like this in the middle of the body, and then the browser will only load the style sheet if the user actually scrolls to that point in the document.

That means the style sheet, and the bandwidth it takes, will *only* be used if it’s actually in use in the browser. Until then, we can still add the style sheet like this and then preload it if we want to to make it so that the browser is aware of that style sheet and loads it. Either way, loading a style sheet like this in the body where the module is displayed improves performance.

So how does this actually work? Where is the style sheet actually being queued in?

To see that, we have to go down to comments.php itself. This is the template file that’s called any time there is a comment available on the page:

Here you can see at line 20 it says, is password required? If so, then do nothing.

Otherwise, it says at line 24: use wp_rig()-> print_styles(). It calls in the wp-rig-comments style sheet. This function is what actually calls in the style sheet.

When you start looking through the different template files, you’ll see this function appear again and again. For example, if you look at sidebar.php, you’ll see wp_rig()-> print_styles,() wp-rig-sidebar, and wp-rig-widgets because we need the widget styles in addition to the sidebar.

If you go to index.php, you’ll see at the top, there is wp_rig ()->print_styles, wp-rig-content. That means the content style sheet is printed before the actual content is displayed. And, as you build out your own template, you could then create a new custom template with some new custom content, create a custom stylesheet to go with it, and call that style sheet in only when that component is displayed.

So we’re actually using the template hierarchy in WordPress, using these different files to call in the style sheets they need. And that way, it’s conditional. It’s not on us to write some crazy conditional function. This way, we’re saying: if the template file loads, then load the style sheet that comes with the template files.

If the template file does not load, then no style sheet is loaded, because the template file is where that style sheet is loaded. This is really straightforward and it allows you to control exactly what happens in each template file without having to think of any of the other files in the process.

Google Fonts

WP Rig ships with preconfigured support for two Google fonts. Here, we’ll go over how the function works and how to change the fonts of your theme.

Typography and fonts play a major role in modern web design, and thanks to modern tools like Google Fonts, adding custom fonts to our web designs and our WordPress themes is easier than ever.

However, it is still a bit of work to get everything to work properly, especially if you want it to be performant. For this reason, WP Rig has a complete setup for Google Fonts ready to go, and configuring which Google Fonts you want is really straightforward.

Out of the box, WP Rig uses two Google Fonts to style its content: Crimson Text, which is a serif font for all the body text, and Roboto Condensed for the headings and other highlights. If you don’t like this look and you want to change to a different font, here’s how you go about doing that if you want to use Google Fonts.

If you were building a site from scratch and you were just writing the html, you might normally would make your selections in Google Fonts, and copy the link tag code to drop into your site header. Then you would reference the font family/families as needed.

However, when you work with WordPress, you don’t just add a link element like this into your code. You want to register the style, enqueue it at the right time and above all, make it as performant as possible.

WP Rig does several things to make this all happen. You just need to take note of the name of the font you want, and what font weights you want.

How it works

To set up a new font, you need to first register it in PHP. And that’s done by going to the “includes” folder, then to “styles” and opening “Component.php”.

Then, find the “get_google_fonts” function. From here, you can define which Google Fonts you want by simply adding to the array. The Google Fonts array declares the name of the font you want, and then the weights you want.

In this example, you could could copy and paste line 361 on to line 362. Then, you would replace Crimson Text with the font name you want, and the font weights with the font weights you want. (Each font weight number should be followed by a comma, until the last number.)

At this point, you can reference the fonts as needed in your style sheets, or you can add them into your custom variables.

The cool thing is, this is all optimized as much as is humanly possible. So this loads the fastest you can load Google Fonts. Of course you can make it faster by locally hosting your font. But if you’re going to use Google Fonts, this functionality makes it possible to just add in the fonts you want, the fonts weights you want, and then just reference as needed.

CSS custom properties (a.k.a. CSS variables)

CSS Custom Properties (aka variables) allow you to define a property once and use it many places. WP Rig enables CSS custom properties in a limited fashion via cssnext.

One major frustration when working with CSS is you often have to declare a property in multiple different rules, but you want it to stay the same. That could be a font family, or a color, or a margin, or a width, or something else. And any time you need to make an update to that font family, or color, or whatever, you have to make an update to every single instance of that property, which is just opening a door to a bunch of errors.

To get around this problem, preprocessors like Sass introduced variables. You declare the value once in a variable, and then you just call that variable later on. Then, if you want to change the value, you change it in the variable, and the change will propagate throughout the rest of the stylesheet.

Now, we have that same functionality in pure CSS, only it’s not called “CSS Variables”, it’s called “CSS Custom Properties”. But it’s exactly the same thing.

It’s pretty straightforward: you declare a new custom property by giving it a name, dash, dash, and then whatever name you want, and then you put whatever value you want in that custom property, next to it just like a regular property. Then, when you want to use the custom property, you call it saying “var” and then just call the name you declared in parentheses.

This works across all modern browsers. Anytime a modern browser sees this, it’ll replace the call to the custom property with a value in the custom property. However, this does not work in some older browsers. Older browsers will see this and just assume nothing is there. It won’t call an error, it’ll simply not understand it and just move on. That means if you want to use custom properties and you want to support older browsers, you need to provide a fallback.

The way we do that is by declaring the exact same property directly above. So in this case, background-color, and then put in the actual value. So the first color value here, which is the hex value. This introduces a bit of a roadblock for one of the cool features of custom properties, which is nesting and scoping, but if you want to have backwards compatibility right now, you need to provide these fallbacks, which sounds like a lot of work, right? You have to first declare it a custom property and then you also have to put in the hard-coded value.

The good news is in WP Rig, this is all handled for you. WP Rig ships with full support for custom properties and also uses custom properties extensively in the original theme. The custom properties themselves are declared in the custom properties partial. They’re all declared on root so that they apply to absolutely everything in the entire document. This is to counteract that problem of scoping and to ensure that fallbacks work properly.

It does limits what you can do. You can’t do scoping and nesting, but you can still use custom properties to do what you want to. These custom properties are used throughout the different stylesheets. You can see an example inside the Typography partial. There is a color custom property, the font family, the font size, and the line height. In _custom-properties.css, there’s a lot of other custom properties declared as well. The idea here is, instead of going through the entire pile of stylesheets and changing values anytime you want to change something, you simply go and change them here or add new custom properties in this file, and then you’d use the custom properties wherever they appear for consistency throughout the theme.

But, of course, there is the important question, what happens to older browsers? The build process in WP Rig solves this problem via Autoprefixer. For example, in the image below, there is the anchor element with the var(–color-link) custom property applied. That’s what’s active in Firefox because this is a modern version of Firefox. But directly above, there is also the hard-coded hex value.

This is what Autoprefixer has done to make my custom properties work in older browsers as well. So if I were using an older browser, instead of using the custom property here, it would just use that hex color value.

The reason why this is important, and the reason why you should use custom properties — even though you get this hard-coded fallback — is in the future, (quite shortly in the future) all browsers will support custom properties. Then, you’ll already have wired things up, and you can simply remove the custom properties fallback from Autoprefixer. Everything will then just work the way it’s supposed to.

There is another caveat: you cannot use custom properties to create media queries. There are some important reasons why that doesn’t work — but the reality is it doesn’t work. Which is unfortunate, because you would want to use variables in media queries, right?

In WP Rig, you can. Notice there’s another partial file called _custom-media.css. Here, we define custom media properties that work the exact same way as custom properties, except they’re for a custom media. The thing is, custom media properties are not supported by any browsers anywhere. This is so bleeding edge that it’s not supported at all, but we can still use it in the way it will eventually be supported in browsers right now in WP Rig, thanks to PostCSS and Autoprefixer.

So just like with custom properties, we also use custom media, meaning you define your media queries in this file, and then they get populated throughout all your CSS files.

How is this used? Well, if you go to global.css and take a look, there is a call, @media, and then we call for –narrow-menu-query. – -narrow-menu-query is defined in _custom-media.css, and it’s right here, –narrow-menu-query, and the value is, screen and (max-width: 37.5em).

So, custom properties and custom media can be used in WP Rig, and I urge you to do it because this is how we are going to write CSS in the near future.

Edit CSS

Working with CSS in WP Rig is a straightforward process. You go into Assets, CSS and Source Folder, and then just write CSS the way you normally would. The build process detects any changes you make, and compiles out new minified CSS files that are then served up to the browser.

Let’s look at an example to see how this all fits together. If we take a look at the layout CSS for the current starter theme, you’ll see if we scroll up a bit there’s this div with id page and class site. This div has a grid layout applied to it. Display grid and in Firefox you can use the overlay grid to actually see that grid in the browser. Now, this grid currently has two columns, one that takes up three portions of the available space, and one that takes up one portion of the available space. This was defined here, grid template columns 3fr and 1fr, and all of this is defined inside global.css on line 81.


I want to change this mark up so that I can use grid template areas and position the different elements that way, because that makes it easier if I ever want to change the layout, maybe place the sidebar on the left-hand side instead of the right-hand side and so on.

Because I’m going to do development now, I’ll spin up my development process. That way, any changes I make in CSS files or any other files will automatically be detected and new files are generated by the build process.

Now I go to global.css and find the rule in question. It’s right here, has-sidebar.site, and here we have display grid and then grid template columns 3fr 1fr. I’m going to change this here first to say repeat and then four, 1fr. That gives me four equal width columns. Then I’ll set up grid template areas and here inside the areas, I’ll give the different areas names. So in the layout I first have a header that takes up all the available columns, so I’ll say header header header header. Then, I’ll set up the main area, so main main main and sidebar. And then finally the footer so footer footer footer footer and end it all with a semicolon.

Now I can use these grid areas to position the different elements. When I save global.css, the build process detects that something has changed in this file. The style process runs again, and the browser is updated. You’ll see the build process detects a change in the style, runs the style process again, the new style sheet is built out. Any change you make in any of the CSS files, either the main style sheets or the partials, including custom properties and custom media, will automatically be detected by the build process, the build process will take those changes, run through the entire styles build and create new minified style sheets that are then served up to the browser automatically.

CSS file structure and partials

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.

CSS in WP Rig

In WP Rig, CSS rules are distributed across multiple files. This improves performance and allows you to work at a module level.

The CSS in WP Rig is architected around three core principles:

  • Modern standards
  • Modularity
  • Performance optimization.

What does this mean for you as a developer? First off, modern standards. You can safely use all the latest modules and CSS techniques, including CSS Grid, custom properties (aka variables), the calc() function, nesting, and more, right in your style sheets.

Most of these features work in modern browsers, and all of them will work in your theme, even in older browsers, thanks to the use of PostCSS and Autoprefixer in the build process.

To put it simply, you write modern, forward looking CSS, and the build process makes it work for everyone.

Second, modularity. Traditionally, WordPress themes ship with one massive CSS file with all the style rules stored in the style.css file. This is inefficient in several ways. For one, it means the entire style sheet is loaded for every view, even if only a small portion of the actual style rules are used. And for another, if a change is made to a rule, the entire style sheet has to be reloaded by the browser, wasting resources.

To remove these problems and modernize developing and loading CSS, WP Rig has split the CSS into separate modular level files which are loaded only when they are used. This means the good old style.css has no actual style rules in it — just a comment telling WordPress about the theme.

The rest of the style sheets are found under assets, CSS, and source. Here you’ll find separate style sheets for the front end and the editor, component level style sheets, and even partials which are included from the component level files. All these CSS files are loaded conditionally on use. (And we’ll talk more about all of this later.)

Finally, performance optimization. Like we talked about earlier, in WP Rig, CSS files are loaded only when they are used. To further improve performance, CSS files are loaded in body at the module level, meaning modern browsers will only load the file if the user scrolls to where that module is.

This is completely different from how things have been done in WordPress themes and most of the web.

And it has a significant impact on performance. WP Rig has custom functionality, allowing you to preload select CSS files when a view is loaded to give your site an additional performance boost. (We’ll talk more about this later, as well.)

All this said, the core goal of WP Rig is to make writing CSS as easy as possible with the help of all the things mentioned here, combined with style lens and prettier, keeping your code clean and in line with coding standards. You write standards-based modern modular CSS…and WP Rig makes sure it meets requirements and loads at lightning speed.

Configure Browsersync SSL

BrowserSync allows for local SSL certificates and communications through HTTPS, but it requires a bit of set up. This is important because WP Rig is optimized for the HTTP/2 protocol, and HTTP/2 requires SSL.

So if you want to test these advanced features in a proper encrypted environment, you need BrowserSync to use SSL. For this reason, WP Rig can generate SSL certificates for you automatically. In this video, we will show you how to get this to work.

Build, activate, and test your new theme

Now that both WP Rig and the Editor are configured and ready to go, we can run the development process and build out the theme for the first time.

The starter theme that ships in WP Rig isn’t a full-fledged theme yet. It doesn’t actually work inside WordPress. For that theme to work, it needs to be built out by the development process so that we get all the files optimized and everything strings together properly.

Before spinning everything up, make sure your local WordPress environment is up and running properly by checking it in the browser. Go to the URL for the site, reload it, maybe navigate around a little bit just to make sure things are working.

Looks like it’s working properly. All right, that means we are ready to go. Developing a theme in WP Rig requires the development process to run in the background, so the theme can be generated, and anytime you make a change the code is updated to reflect that change. All this is done in the terminal, automatically.

To generate the starter theme and start my development process, all I need to do is type in npm run dev. Now watch what happens. The build process spins up and goes through a bunch of different tasks to clean the CSS, and clean the JavaScript, and check the PHP, and compress images, and run scripts and everything else. It all gets merged together.

We jump over to the browser, and now Browsersync spins up a new version of our site. You can see the URL to this Browsersync instance is different from the local one. So here I have my local install, WPRig.local, and here I have the Browsersync version, which is not currently logged in. So we don’t have the WordPress tool bar at the top, but what’s cool is now if I go and make changes in the code, in WP Rig, and save those changes, they automatically take place in the browser right away. And that’s not all. If I go to my terminal, you’ll see down here at the bottom, it says Access URLs. And here we have access URLs for the local computer, so localhost:8181. And external, so that would be if someone is on the network and went to log in, and we also have access to the UI for Browsersync itself. So that means I can now take this URL here, and open it in a different browser, let’s see, maybe we’ll open it in Chrome as well… So I’ll paste it in, open it in Chrome, and watch what happens now. If I scroll in Chrome, you can see it also scrolls over in Firefox and if I had a cell phone or tablet, or anything else, and I logged in to that external URL and started scrolling on the cell phone or tablet, it would see all of these instances scroll at the same time. That’s why it’s called Browsersync, it quite literally syncs your browser, not only to your dev environment but also all the browser instances to each other, so you can do multi browser and multi device testing all at the same time, which is really really useful.

But we’re not quite done yet. Now that the theme is up and running, I need to go into the logged in version of my site, go to the backend and go to themes. And here, you’ll find our theme. It’s called WP Rig, and even though it changed the configuration files, it’ll stay named as WP Rig all the way until you’re done and you build the theme out. But that’s for later. For now, we’ll activate the theme, jump back to the front end… And here you see WP Rig up and running on my site. It’s working the way it’s supposed to, it has all the default styles for the theme and we can now start working.

Configure VS Code workspace settings

WP Rig can be configured to fit any workspace requirements. In this video, see how WP Rig works with VS Code to help you write better code.

VS code has extensions that are really helpful. They are:

  • ESLint, which Lint Java Script and ES next
  • PHPCS, the PHP code sniffer which looks for errors in PHP
  • Stylelint, which lints CSS
  • Prettier, the code formatter which auto formats code.

Configurations of all these tools already exists in WP Rig, and they almost work out of the box, but to take full advantage of all the automation available to you, this video goes over how you wire them up in the application settings.

Run the WP Rig installer

Getting the build process and code linting up and running requires installing all of WP Rig’s Node and Composer dependencies. This is done from the command line.

In VS Code, there is a built-in terminal, and you can open it either by hitting CONTROL + backtick on your keyboard both on Windows and Mac OS, or go to the Application menu, select View, and either Terminal on Windows or Integrated Terminal on Mac OS.

If VS Code is open to the WP Rig folder, you are now navigated directly to that folder in terminal and you’re ready to go.

From here, you can now run one of two commands: either

  • npm run rig-init – This installs both Node and Composer dependencies.
  • OR, if you already have your Composer dependencies installed, you can also run just npm install.

It’s important to note the difference here. If you already installed WP Rig in this folder, you’ve worked with it, and you just want to update your Node dependencies, then you run npm install.

But if this is your first setup of WP Rig, new project, you just set it up, just configured it, and everything is ready to go, say npm run rig-init. Now your computer will go onto the internet, find every single dependency for both Node and Composer, pull it all down into your project. And notice I execute this command on my computer, downloading all these dependencies can take some time depending on your internet connection and available processing power, so this might be a good time to hit pause and take a short break.

When the install process in the terminal is complete, you’ll see two new folders inside your WP Rig folder: node_modules, which holds all the Node dependencies and vendor, which holds all the Composer dependencies.

The cool thing is, none of these require any configuration on your part, but they’re necessary for WP Rig to work properly. Oh and one more thing, if you get an error during this process, it’ll be very obvious, it’ll be lots of red text inside the terminal, it’s probably because you don’t have Composer installed.

Almost all the errors I see in the install process is because of Composer not being on the computer in the first place. If you’re unsure if you have Composer installed, it’s really easy to check. Just go to your terminal and type in composer -v. If Composer is installed, you’ll get a message that gives you information about Composer, its version number, and what you can do with it.

If it’s not working and you get an error, it means you need to install Composer and then go back and run npm run rig-init again to get everything installed. The good news is, you can run npm run rig-init as many times as you like, it’ll just keep reinstalling the same stuff on top of the existing folders. So you’ll never run into a risk here of double installing anything.