Language: English

Watching this course, you’ve gotten an in-depth intro on how to build themes using WP Rig. Now that you’ve gotten your bearings, it’s time to push yourself and WP Rig to its limits and make new progressive themes for WordPress.

Your journey to learning has only just begun. We have a long list of courses on LinkedIn Learning that dive deeper into WordPress theme development, front-end performance optimization, content management, and a myriad of other topics that relate to the art of building progressive websites.

LinkedIn Learning does require a paid subscription, but you may be able to login for free with your local library card. More information here: https://www.linkedin.com/help/learning/answer/107121/linkedin-learning-for-library-patron-faq?lang=en

Once you start using WP Rig to develop your own themes, you may have questions, comments, suggestions and feature requests. You may even want to add or change something in WP Rig itself. In that case, there’s good news: WP Rig is open for contributions! 

The purpose of WP Rig is to give the WordPress community a robust theme development rig to build modern, progressive, performant themes. That is only possible with the contribution of people like you. 

Consider this your invitation to contribute back to the project in whatever way you want by: 

• Filing or answering issues on the Github repo.
• Writing documentation, tutorials or blog posts for the official site, or any other site.
• Making video tutorials.
• Doing conference talks, or in-person workshops.
• Using WP Rig, and showing it off in the footer of your theme.

Whatever you like, WP Rig is your tool! It’s built by and for the people who use it, like you, and you can play a part in its future. 

Contributors welcome!

For advanced users and advanced uses, there are some additional build processes. You can find them under package.json all the way at the bottom under scripts. 

Here we have all the different processes you can run using the “npm run” command. If you’ve followed the course, you should be familiar with two of these commands already: “npm run dev” and “npm run build”

“npm run dev” – This is the process that builds the entire theme, then spins up a browser sync and watches all of your files. 

“npm run bundle” – This bundles out the theme, and creates a separate folder and separate zip archive for when you’re done building. 

“npm run build” – This runs the entire build process without running browser sync and watch. So if you just want to spin up the theme once to see what it produces, you just say “npm-run build”, and you have “npm run gulp” if you want to target specific Gulp processes. 

You have the option to run any of the Gulp processes that sit inside the Gulp folder. Most of these processes are being run automatically in the other scripts, but if you want to target a Gulp process specifically, you can do this by running “npm run gulp [script]”. For example, to run the images Gulp processes, you will run “npm run gulp images”. Or to run the PHP process to check your code against current PHP coding standards, you’d run “npm run gulp php”.

These are advanced features which are for advanced purposes, but they are available to you. They’re also a good path into understanding how WP Rig works better. 

So if you’re ever curious about what’s going on, go check out “package.json” or the folder “/gulp” and see how the Gulp processes are built together to make everything work properly.

After all this work, you’re ready to bundle up your theme and either ship it to another user, or place it on a site. In this video, we will show you the build process specifically for this purpose. It will create a new folder for you in the “themes” folder of your current live site.

You will end up with a live version of your new theme sitting inside your theme folder that you can test right away, and you will also have a zipped archive that you can ship off to either the WordPress theme directory, or hand over to someone else who wants to use it.

The final piece of our Related Posts component puzzle is the style sheet.

At this point in the process, we are generating the actual content when people scroll down, and the functionality is there — but the user experience needs work.

In this video, we’ll be adding some CSS to make the component look good, and also be functional. In the exercise files for this movie, you’ll find a new style sheet called “related.css” under assets/css/source.

By the end of this video, you’ll see we’ve made a completely new component, built from scratch, using the standard methodology of WP Rig.

Now that our component works, and we have our Java script enqueued, we can start customizing the functionality of this particular component to make it work exactly the way we want to.

Out of the box, WordPress has a series of image sizes — but what happens when none of those image sizes really fit with what you want?

Creating new image sizes is a standard thing we do in WordPress themes all the time, so in this video, we’re going to generate our own custom image size, and do it inside the component.

The related post component we’re building will use JavaScript to query the WordPress Rest API, then output the results when the users scroll down to that section. 

(In the exercise files for this movie, look for the “related.js” file under assets/js/src. This will eventually become the full JavaScript we’re going to use.)

In this video, our goal is to get this file enqueued *only* on single posts, so that we can actually see these results. Once the file is enqueued, we’ll be sending requests, and getting responses through the WordPress REST API.

(Note: click here to download the exercise files referenced in this video.)

In this video, we will walk you through building a basic component that exposes a template function we can use to pull in some content. We’ll create a component folder and file; then, you’ll see where and how to pull and build from existing components in WP Rig, so you are not rebuilding the wheel from scratch.

What we need to start is a *different* component that does something *similar* to what we want to do. And there are several options available here. We’ll be using the Comments component, because it does the two things that will be useful for you to see and learn:

-First, it exposes a function, so it creates a new template tag that is used somewhere else in the theme.

-Second, it enqueues a script: in action_enqueue_comment_reply_script(), it enqueues a script. (Because the functionality is going to be Javascript-based, we need to be able to enqueue a script.)

Watch and follow along as we get started building a basic related posts component.

 It’s one thing to get a full breakdown of how a starter theme works. It’s quite another to actually use the starter theme to build something, especially when that starter theme does things in new and different ways.

So, in this chapter, we’ll build a new component together from scratch using PHP, JavaScript, and CSS.

That way, you get hands-on experience on how all the things we’ve talked about up to this point actually fit together and work in production.

For this chapter, there are exercise files you can download here. For each movie, there’s a beginning branch marked “b” and an end branch marked “e”. You can open them up and follow along.

In this chapter, we’ll build a “Related posts” component that sits below the main post content:

This component is powered by JavaScript, uses the Rest API, and has some really snazzy features.

First of all, it finds the categories of the current post, and displays the three latest posts in any of the same categories. That’s why it’s called a related post component: it displays content that’s related to the current one you’re looking at.

Second, the related posts are only loaded if and when a user scrolls down to the related post section. If they don’t scroll that far, the query never happens, and the user saves that data.

Finally, the related post component uses the Rest API and JavaScript to make this query so it’s fully dynamic, which is pretty cool. We’ll get started in the next video by building a basic component.

Out of the box, the JavaScript files in the /assets/js/src folder are compiled and minified before being placed in the /assets/js folder and served to the browser. This is sort of similar to what happens with CSS, but with some crucial differences.

First: all your JavaScript (and especially modern ES 2015 and ESNext) runs through Babel, which re-compiles it to work with older browsers. (In other words, the script that’s served to the browser is not the same as the script you wrote.)

Second: JavaScript minification is not just about removing spaces and commas. It actually involves rewriting the scripts to make it as small as possible, which makes it pretty much unreadable for humans — even if you un-minify it.

This is important, because in some rare cases, the script you write doesn’t work as expected once it’s gone through the Babel compilation, and you need to be able to figure out what’s going on in the compiled script.

For this reason, you can configure WP Rig to -not- minify JavaScript files during the build process. This is purely for development purposes, but it can be a useful tool for JavaScript debugging.

In this video, we review where and how to turn off JavaScript minification.

(Hint: it is similar to turning off minification for CSS. You can find the settings in config.default.json…but you cut, copy, paste and adjust those settings in your config.json file.