Theme Mason

With the recent release of the new WordPress Gutenberg block editor, one of the benefits of this new program is the ability to match front end styles with back end styles easily using WordPress functions. However, the issue with this is that you need to have two separate CSS files in your WordPress theme. You’ll need one stylesheet for the back-end editor and another to load on the front-end. For this task, you really should use a task runner such as Gulp.

Gulp is easy to set-up, simply follow their instructions on their website and you should be up and running in minutes. After you have Gulp setup, you’ll need to install and setup gulp-sass. Then it’s time to configure your workflow for your project.

For our projects, we use two separate root SCSS files: editor.scss and main.scss. This simply allows you to control both your front-end file and your back-end editor file to include the individual SCSS files you want for each file. For the editor CSS file, you’ll want to include any important global variable files (such as colors), utility classes, mixins, etc. Do not include any HTML reset files that could alter the over CSS of the WordPress backend. In addition, you’ll want to include any SCSS files for your content/blocks.

Gutenberg Stylesheet

Here’s a snapshot of what our editor.scss file looks like:

// variables
@import './_variables.scss';
@import 'partials/_base.scss';

#editor .editor-block-list__layout {
	// required partials
	@import 'partials/_utils.scss';
}

// blocks
@import 'blocks/**/*.scss';

You’ll notice that our utils.scss file is wrapped in a selector. This a great thing to use if some of your CSS may affect styles outside of the editor.

Creating both front-end and back-end stylesheets for your WordPress theme

Next, you’ll want to setup your gulpfile to create files for both the front-end and back-end of your WordPress theme. Here’s an example of how we compile both files into a css folder:

gulp.task('sass', function() {
    return gulp.src(["scss/main.scss", "scss/editor.scss"])
        .pipe(sassGlob())
        .pipe(sass().on('error', sass.logError))
        .pipe(sourcemaps.init())
        .pipe(sass())
        .pipe(autoprefixer({
            browsers: ['last 2 versions'],
            cascade: false
        }))
        .pipe(sourcemaps.write())
        .pipe(gulp.dest("css"))
        .pipe(browserSync.stream())
        .on('error', function(error) {
            console.error('' + error);
        })
});

You’ll notice we’re using some other modules for our workflow including sass-glob, autoprefixer, sourcemaps, and browsersync. I’d recommend at least including browsersync as this is almost a necessary module for creating WordPress themes.

Enqueuing both stylesheets using WordPress theme actions

Next, you’ll need to enqueue the blocks CSS file using WordPress enqueue functions. Here’s an example snippet of how you can do this:

// Enqueue WordPress theme styles within Gutenberg.
function theme_editor_styles() {
	wp_enqueue_style( 'editor-style', get_stylesheet_directory_uri() . '/css/editor.css' );
}
add_action( 'enqueue_block_editor_assets', 'theme_editor_styles' );

This snippet of code will only enqueue the CSS for the back end, so you’ll also need to enqueue your main.css file on the front-end:

// Enqueue scripts
function theme_scripts() {
	wp_enqueue_style( 'theme-style', get_stylesheet_directory_uri() . '/css/main.css' );
}
add_action( 'wp_enqueue_scripts', 'theme_scripts' );

Once you’ve added these lines of code to your functions.php file in your WordPress theme, you should be able to test your website to see both css files loading separately on the front-end and back-end with the same CSS styles. This functionality is great because you do not need to duplicate your code whenever you want to make a style change to an individual Gutenberg block. What’s also nice is that what you see on the back-end of Gutenberg will match what you see on the front. We’ve went even as far as matching the width of the blocks so you know exactly when a line of text will return on the next line.

This setup is excellent for users who want their back-end to match the front-end while using the Gutenberg WordPress editor.