WP-SCSS Plugin Adds Sass CSS Preprocessor to WordPress Themes

sass

Last week we featured a plugin that adds the Less CSS preprocessor to WordPress themes. Several of our readers were wondering if there was a Sass equivalent to the plugin.

Although not structured entirely the same as the Less Theme Support plugin, which uses add_theme_support, the WP-SCSS plugin provides a decent Sass counterpart.

WP-SCSS compiles Sass using scssphp, a compiler script written in PHP. When changes are made to the SCSS files, the plugin compiles them to the matching CSS file. If a matching CSS file doesn’t exist, the plugin will create one.

Paths to the SCSS and CSS files can be configured in the plugin’s settings page (defined relative to your theme folder), along with error reporting, compiling options, and auto enqueuing.

wp-scss-settings

The best way to ensure the most accurate compiling is to have separate SCSS and CSS directories in your theme’s folder, i.e.:

Theme Directory:
|-css
| –style.css
| –ie.css
|-scss
| –style.scss
| –ie.scss

You’ll have three different modes as options for compiling when using the plugin:

  • Expanded – Full open CSS. One line per property. Brackets close on their own line.
  • Nested – Lightly compressed CSS. Brackets close with CSS block. Indents to match SCSS nesting.
  • Compressed – Fully compressed CSS.

The auto enqueuing should be used with care, because if you ever disable the plugin your CSS files will no longer be enqueued. By default, the automatic enqueuing will enqueue all the files found in the CSS directory that you define in the plugin’s settings, including any non-compiled CSS files that you may have in play. Obviously, if you utilize the plugin’s auto enqueuing feature, you should make sure that you’re not reenqueing them somewhere else.

The WP-SCSS plugin makes using Sass in your WordPress themes a more convenient possibility. It provides limited Compass and/or Bourbon support as well as a way to use @import subfiles. Refer to the FAQ tab on the plugin’s WordPress.org homepage for more information and troubleshooting tips.

8 Comments


  1. Not sure I like the idea of this, I’ve written SASS on a local install before and if the syntax is wrong it breaks the site if the compiler errors. I guess this would be ok on a local install but not on a production site.

    Report


    1. The plugin says that : “If you’re working on a live/production site, you can send errors to a log. This will create a log file in your scss directory and print errors there as they occur. Just keep an eye on it, because the css will not be updated until errors have been resolved.”

      So this isn’t really a problem :)

      Report


  2. I run something similar to this and errors during compilation shouldn’t be a problem if its coded somewhat intelligently. And compilation only happens when there have been actual file changes so its not doing anything special on a normal site visit.

    Report


  3. The scssphp page on Github says “It does not implement the SASS syntax, only the SCSS syntax.” I thought they were basically the same thing, but they’re clearly making a distinction — so it may be inaccurate to say it does SASS.

    Report


  4. I use the functions.php file to enqueue my compiled CSS file. Not sure why a plugin is needed for this if you properly manage your config.rb file?

    Report


    1. Hi Thad, How do you do that please?

      Report


      1. Something like this:

        function some_function_name() {

        wp_register_style( ‘screen’, get_stylesheet_directory_uri().’/PATH/TO/COMPILED/CSS/FILE’, ”, ‘1010’, ‘all’ );
        wp_enqueue_style( ‘screen’ );

        }
        add_action( ‘wp_enqueue_scripts’, ‘some_function_name’ );

        Report


  5. This is cool, and convenient for a quick fix but FTP commando has been around too long and needs to die. Production environments should never ever be live edited, there is just too much at risk to do that, it’s a bad practice, and it does an injustice to the end user.

    Report

Comments are closed.