Category Archives: WordPress Theme

How to Add Block Templates to Your WordPress Theme or Plugin Gutenberg

How to Add Block Templates to Your WordPress Theme or Plugin

While working on my Gutenberg Development Course, one of the hardest things I found to research was how to add block templates to your WordPress theme or plugin.

Example of a block template with and image and paragraph block

Example of a simple template with image and paragraph block

Block templates are a way to have certain blocks show up by default for a new post, page or custom post type.  You can also “lock” the template to prevent users from adding or removing blocks.

Thank You Matías and Riad For Showing Us How

I could only find two code example of how to write block templates.

One was by freezing Matías Ventura’s Gutenberg Demo from the State of the Word 2017 at WordCamp US.

Block Templates Matías Ventura.png

Blurry example but best I could find

The other was from a Gutenberg Custom Fields Plugin from Gutenberg core developer Riad Benguella.  If you reverse engineer that plugin you can see how templates are added.

How Block Templates Work

Templates are added as a parameter when registering a post type in WordPress.  Sometimes this is done for your own custom post type.  But it can also be done for existing and native post types like Posts and Pages.

The block template setting itself is an array of blocks that you want included.  There is also an additional setting called “template_lock” that can be set to true or false to lock down the template to users.

You can also add additional configurations like custom placeholder text for blocks or set the alignment.

An Example of Block Templates

You can add the code below to any plugin or theme to modify template setting for post types of your choice.

Some notes on this code:

  • Notice the conditional statement determining what post type to apply this to.  Can change for your own needs.
  • The template_lock argument determines whether users can add or remove blocks with this post type.
  • The name used for blocks is the name used when creating them.  See a list here of all default blocks, which you can use to lookup (or guess) the programatic name for a block.
  • You can add additional configurations like placeholder text, alignment, or other block attributes you want set by default.

Learn More About Gutenberg Development

To learn more about developing with blocks in WordPress, please check out my course Gutenberg Development Course.

How to set a custom block color scheme in your theme for Gutenberg

How to Add a Custom “Color Palette” to Your WordPress Theme

One of the cool things I picked up while working on my Gutenberg Development Course was how to set a default color palette for all blocks inside your theme.

Interestingly, as far as I can tell, defining custom color schemes is something only a theme should do and this cannot be set from within a custom block.

Block Color Palettes in Gutenberg

One of the features that blocks can have in WordPress is the ability change a color. For example, the core paragraph block has the ability to change the background and text color in the block inspector panel.

Screen Shot 2017-12-30 at 12.59.31 PM.png

Example of Default Block Color Scheme in WordPress

One of the cool things you can do as a theme developer, is set your own custom color palette for your theme.  This can help users choose colors that match the design of the theme.

Setting Custom Color Palettes in Gutenberg

To set a custom color palette (or color scheme) you would simply add add_theme_support( ‘editor-color-palette’ ) to your functions.php file and then continue to pass in the hexadecimal values for colors you want.

You can add as many colors as you like (I think), but I would suggest limiting the selection to colors that work well with your theme.

You will then want to hook that add_theme_support() into ‘after_setup_theme’.

What This Looks Like in Action

Using the color combinations set above, the default color options for blocks would now look like this.

Example of custom color scheme applied to WordPress blocks

Example of custom color scheme applied to WordPress blocks

I think that if you have a theme with a specific color palette that you should definitely take the extra few minutes to set a default color scheme for the blocks.

Learn More About Developing with Gutenberg

To learn more about building custom blocks or customizing Gutenberg with your theme, please check out my course on Gutenberg Development Course.

How to Add JavaScript and CSS to Gutenberg Blocks the Right Way in Plugins and Themes

How to Add JavaScript and CSS to Gutenberg Blocks the Right Way in Plugins and Themes

icon-256x256While working on my Gutenberg Editor Development Course I had a simple question early on: “How do I enqueue my block JavaScript and CSS to work with the Gutenberg Editor?

The short answer is there are two ways:

  • enqueue_block_editor_assets – For enqueueing JavaScript and CSS in the admin editor only.
  • enqueue_block_assets – Enqueues on both the frontend of the site and in the admin editor (unless !is_admin() is used then it just enqueues on the frontend only).

Enqueueing Block JavaScript the Right Way

In general, you will want to load your main block JavaScript using enqueue_block_editor_assets since your main block JavaScript code needs to execute inside the editor.

Once a block is saved as content, the editor JavaScript is no longer needed, so most JavaScript for building blocks only needs to execute in the editor.

On occasion your block may require JavaScript to run properly on the frontend.  For example, if you were building a slideshow or a form or some other element that needed frontend interaction.  In this case, you would break out that functionality from your main block JavaScript and load it separately using enqueue_block_assets.

Enqueuing Block CSS the Right Way

The general principal for styling blocks in the new WordPress editor is to make them look the same in the editor as they do on the frontend.  To accomplish this, we enqueue our main block styles using enqueue_block_assets.

There are some instances where you need to style blocks in the editor different from the frontend.  Some reasons for this are to help give users visual cues for what they can edit or there may be controls in the editor that need styling and do no appear on the frontend.  If there are ever styles you want applied only in the editor, you can break these into a separate CSS file and load it using enqueue_block_editor_assets.

On the chance that you have styles that should only be applied to the frontend and never loaded in the editor, you can load them using enqueue_block_assets and wrap your wp_enqueue_style call inside of a !is_admin() conditional statement.

Example of Enqueueing Block JavaScript and CSS in a Plugin

This example below would go in a main plugin file that needs to load blocks.  See how both enqueue_block_assets and enqueue_block_editor_assets are used.

Some notes on the example above:

  • We have a file /assets/js/blocks.js with our main block JS code.  This is being loaded with enqueue_block_editor_assets into the editor.
  • We have a file /assets/css/blocks.editor.css with our editor only styles.  This is also being loaded in the same function call as our JavaScript, which hooks into enqueue_block_editor_assets.
  • Then we have a file /assets/js/blocks.shared.js with additional JS code that needs to be loaded on the frontend and backend.  This is being loaded with enqueue_block_assets into the editor and frontend.  Note, you may or may not need JavaScript loaded on the frontend depending on the type of blocks you build.
  • We also have /assets/css/blocks.styles.css, which is our main CSS file.  This will load on the front and backend since we have it hooked into enqueue_block_assets.
  • The final file /assets/css/blocks.frontend.css is wrapped inside of the !is_admin() conditional statement so it will not load in the editor as is usually the case with enqueue_block_assets. Note, you probably don’t need a frontend only stylesheet.  It is also recommended to use editor only styles to override shared frontend/editor styles rather than this approach demonstrated here for example purposes.

This should cover the basic use cases you will have for loading block JavaScript and CSS into your plugins.  Let me know if I missed something you find useful!

Example of Enqueueing Block CSS in a Theme

In general, you should NOT build blocks inside of themes.  Custom blocks should generally be built inside of plugins.  However, it is perfectly acceptable for themes to customize block styles, both in the editor and on the frontend.

The example below shows how to load CSS in your themes to override default block styles.  This code would go inside of  or be included into a theme’s functions.php file.

Some notes on the code above:

  • We are not including any block JavaScript since that should generally go in a plugin.
  • We have a file /assets/css/blocks.editor.css with our editor only styles.  This is being loaded using enqueue_block_editor_assets.  Note, there is a chance you may not need editor only CSS.
  • We also have /assets/css/blocks.styles.css, which is our main CSS file.  This will load on the front and backend since we have it hooked into enqueue_block_assets.
  • The final file /assets/css/blocks.frontend.css is wrapped inside of the !is_admin() conditional statement so it will not load in the editor as is usually the case with enqueue_block_assets. Note, you will likely not need a frontend only stylesheet.  It is also recommended to use editor only styles to override shared frontend/editor styles rather than this approach demonstrated here for example purposes.

A Note on File Organization and Compilation

The examples above show including only a few final JavaScript and CSS files all within ‘/assets/js’ and ‘/assets/css’.  It is likely that you will break your JavaScript and CSS into smaller files and compile them using a tool like webpack.

If you bundle your final JS and CSS into a different directory structure than the ‘/assets/js’ and ‘/assets/css’ structure used above, you may need to make some changes to the examples.  Same goes for how you name your files.

The examples above do not offer insight into how you should organize your modular JS and CSS or how you would setup a tool like webpack to handle compiling it all.  I do have some thoughts on these matters and you can see my course below or wait for upcoming blog posts on these topics.  However, in general, try to follow modern best practices.

To Learn More About Developing with the New WordPress Editor

If you would like to learn more about developing blocks with WordPress, please check out my course Gutenberg Development.

How to Redirect to Custom Page After Completing a LearnDash Course

One of the features I recently finished for the my redesign of my JavaScript for WordPress site was to have users taken to a special page once they complete a course.

You can do this a number of ways, but here is how I did it:


1. Setup Congratulations Pages for Each Course

The first thing I did was create a parent page called Congratulations with the url of “/congrats.”

Then I created Child Pages, one for each course.  Those pages looked something like this.

Screen Shot 2017-06-02 at 2.29.43 PM.png

You can see the badge displayed and the number of points earned (I use BadgeOS and BadgeOS LearnDash Add-on).

The most important thing I did was give each page the same slug as the course it is tied to.  If I didn’t do this, then the next step wouldn’t work as coded.


2. Add This Code to Your Functions.php

The next step was to find the LearnDash hook that fires when a LearnDash course completes.

Luckily there is a learndash_course_completion_url hook that let’s return a URL and the redirect happens automatically.

This code gets the slug for the completed course and then creates a new URL string of “/congrats/course-slug.”

NOTE: This will only work if you you did these two things from Step 1.

  • Create a parent page with the URL slug of “congrats”
  • Create child pages for each course using the same URL slug as the course


Hope this Helps!

If you have a LearnDash account you can access the list of Action and Filter Hooks here.  Since that page is password protected, thought I would share this snippet with you.

Hope it helps!

Learn How I Built the JavaScript for WordPress Master Course and Teaching Site on the “How I Built It Podcast”

“If you’re looking to setup an online course just grab this podcast!”

I love hanging and chatting Joe Casabona.  Naturally, I was excited when I found out he wanted to chat with me on his How I Built it Podcast about how I built my JavaScript for WordPress Master Course.

A lot of folks have asked me content related questions about the course, but this is the first time I really go in depth about actually building the course, from researching content, to building a team, to picking an LMS, all the plugins I used and several of the snags I hit.

It was really fun to talk about all of this and I share a lot of information.  If you’re interested in how things are built and the behind the scenes technologies, I would definitely recommend listening to this episode.

Students may particularly appreciate what has gone into the course.

Episode 9: Zac Gordon & Javascript for WordPress


$100 Off My WooCommerce Development Workshop at WooConf 2016

Screen Shot 2016-03-05 at 10.36.22 PM.png

I’m super excited to head out to Austin on April 6-8 this year for my 2nd WooConf.  This year I will be doing a workshop based on a WooCommerce Theme Development Course I did at Treehouse.

Thanks to the folks at WooCommerce, I have an unlimited coupon code “WOOCONFZAC” for $100 off for anyone who wants to attend the conference for Woo work.

Check out the trailer for the course to get an idea of just some of what we will get into.


Of course we will also talk a little about JS and API work with WooCommerce 😉