Sass within WordPress [closed]

Question

I'd like to use SASS in one of my wordpress projects (which will be kind of a boilerplate for future projects). I wish to do this in a way that follows the following criteria:

• Passess sass-lint
• Follows Wordpress standards (e.g. theme headers)
• Clean, Consistent & Easy to maintain

I had a few ideas, but none of them follows the above criteria.

1. Remove style.css and solely use Sass

/index.php
/... other wordpress files ...
/assets/sass/main.scss
/assets/sass/...other sass files...

After running sass the style.css will be created in the root directory.

Pros:

• Consistency
• Easy to maintain

Cons:

• SCSS-Lint doesn't like the "WordPress theme header comment", since it prefers // comments
• Without compiling sass it's impossible to select the theme in the WordPress backend

2. Use the style.css and Sass simultaneously

/index.php
/style.css
/...other wordpress files...
/assets/sass/main.scss
/assets/sass/... other sass files...

Pros:

• Basically solves the cons of (1)
• Even it shouldn't be that way; quick changes can be easily added to the style.css without any tools

Cons:

• Inconsistency
• Redundancy
• Requires multiple CSS requests (one for style.css, one for the compiled sass)

Also my biggest problem here is: where to put the compiled SASS? Concatenating it with the style.css seems fairly odd.

Any ideas? Thanks!

Answer 1

Why do we need "style.css"?

Before I give my solution, I think it's important to go through the reason we need style.css in Wordpress

In Wordpress, the style.css file is required in order to view the theme information in the backend.

style.css is also used as the default output of get_stylesheet_uri(). However this can be customised using the stylesheet_uri filter.

In my opinion, the fact that Wordpress forces you to have your theme information in style.css is just bad design, as it adds approximately 1032 bytes. This is not a lot, but completely unnecessary; especially if it can be avoided, as the file size is perhaps the biggest factor impacting site performance.

This is unlike the Drupal CMS where your theme infomation is stored in a seperate file such as yourtheme.info, so is never exposed to the end user

---

Solution 1

Now we got that out the way, here is the solution!

The best approach in my opinion would be to:

• Compile all your sass files into a single file (such as style.min.css), by using imports and partials (see http://sass-lang.com/guide#topic-5). Feel free to name it something else.
• Leave all your wordpress theme headers in style.css.

For example like so:

style.css

/* Theme Name: Twenty Thirteen Theme URI: http://wordpress.org/themes/twentythirteen Author: the WordPress team Author URI: http://wordpress.org/ Description: The 2013 theme for WordPress takes us back to the blog, featuring a full range of post formats, each displayed beautifully in their own unique way. Version: 1.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: black, brown, orange Text Domain: twentythirteen  Use it to make something cool, have fun, and share what you've learned with others. */ 

style.min.css

p{color:red;}h1{color:blue;} ... 

You can then make sure that the new stylesheet in added on every page of the frontend using the following code in your functions.php file:

function theme_name_stylesheets() {     wp_enqueue_style('style-name', get_template_directory_uri() . '/style.min.css'); }  add_action( 'wp_enqueue_scripts', 'theme_name_stylesheets' ); 

See: https://codex.wordpress.org/Function_Reference/wp_enqueue_style for more infomation

Thus when your run wp_head() in your head of your document, it will add the correct CSS file automatically.

Then you can run sass-lint on your sass files, but still have your theme information in your style.css, giving the best of both worlds.

Advantages

• Passes sass-lint, as none of the sass files contains comments of the form /* ... */, as the theme headers are in style.css NOT style.min.css
• Smaller file size for the stylesheet, as the style.min.css no longer contains the theme header information, as this is stored in style.css
• Better site performance: As all your SCSS files are compiled into a single CSS file, the number of HTTP requests sent to your server reduces, thus improving your overall site performance.

Disadvantages

• Two CSS files. Not really much of a disadvantage, as the user on the front-end is only sent the style.min.css, NOT the style.css
• Can confuse users in the Wordpress community. Most Wordpress users expect your styles to be in style.css. However, I doubt this will be much of a problem (especially if you're not publishing your theme) and also can be rectified by a simple comment.

Solution 2

Another solution to your problem is to temporarily disable the scss-lint Comment rule using the following:

// scss-lint:disable Comment /*! Theme Name: Twenty Thirteen Theme URI: http://wordpress.org/themes/twentythirteen Author: the WordPress team Author URI: http://wordpress.org/ Description: The 2013 theme for WordPress takes us back to the blog, featuring a full range of post formats, each displayed beautifully in their own unique way. Version: 1.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: black, brown, orange Text Domain: twentythirteen  Use it to make something cool, have fun, and share what you've learned with others. */ // scss-lint:enable Comment p {   font-size: 16px; } 

Also note the use of loud comments (i.e. /*! ... */ instead of /* ... */) . This basically means that this comment should not be removed in the minified versions of sass.

Advantages

• One CSS file
• Less likely to confuse users in the Wordpress community
• Passes sass-lint, as the comment rules is temporarily disabled!
• Better site performance: (same reason as Solution 1)

Disadvantages

• Larger file size for the stylesheet, as the compiled CSS file contains the theme header information. This is only a small increase however.

What about end-users who are not using Sass or Grunt/ Gulp?

From another comment you mentioned, you said you want users to be able to change minor things without installing sass or a build automation tool.

This does not mean that YOU can't use a build automation tool. It just means that your compiled CSS file from solution 1 or solution 2, should not be minified, as users cannot easily edit the file! Unfortunately, this means your site will be a lot larger in file size and thus slower as a result.

Alternatively you can have two files:

• website.min.css: the minified version of the compiled SCSS
• website.css: the expanded version of the compiled SCSS

[Again, name them as you wish]

Then if the user wishes to make quick changes without sass or Grunt/ Gulp, then he/she can do so to website.css (however, the user also needs to change the file that is being loaded in functions.php)

Also, experienced users who DO have sass experience or users who don't want to make any changes, don't have to compromise, as they still can take advantage of the fast minified website.min.css version!

The best of both worlds!

Answer 2

How about using styles.css to output your sass? This is what I do and it has solved many of your problems:

• Make sure you are working in a child theme.
• You may want to work on a local installation of wordpress instead of on a server. This link will help you with most of this process. This is a good way to get around selecting the right theme. You can use he compiler to path the output to the right file. I use Koala, but there are a bunch of great ones out there to choose from.
• create your scss files in partial form (i.e. _theme.scss, _responisve.scss, _animate.scss, etc).
• create one styles.scssfile.
• inject as many scss resources as possible instead of using their css. For instance, Bootstrap has it's own scss, and so does Font Awesome and Animate.
• @import all of these partial files in your styles.scss and direct the output to style.css or preferably a minified (compressed) version rather - styles.min.css .
• Clean up your header.php from all enqued stylesheets you are already importing in your new scss file.
• Check and clean your function.php for the same.

And it really there isn't much else left.

EDIT

Should your designers lack experience in SCSS, they can code in CSS inside the SCSS file and it will still compile as a style.min.css. Naturally, it is much better to take advantage of the SCSS features but that is a problem related to having required experience and knowledge. The seamlessly compilation of SCSS into one file (style.css) is still achieved.

CREDIT TO cale_b - "you can create a "custom.scss" file, which is intended for your designers to work in (and they can use vanilla CSS), and is imported LAST, so that it's styles override any other scss rules"

Answer 3

I use gulp with sass and wordpress, I output the compiled sass into style.css here is my normal workflow:

gulpfile.js

var gulp = require('gulp'),
    gulpLoadPlugins = require('gulp-load-plugins'),
    wiredep = require('wiredep').stream,
    $ = gulpLoadPlugins(),
    browserSync = require('browser-sync');
    p = require('./package.json');

gulp.task('sass', function (){
    return gulp.src('scss/**/*.scss')
    .pipe($.sourcemaps.init())
    .pipe($.sass())
    .pipe($.concat('style.css'))
    .pipe($.autoprefixer())
    .pipe($.sourcemaps.write())
    .pipe(gulp.dest('.'))
    .pipe(browserSync.reload({
      stream: true
    }));
});

gulp.task('sass-prod', function (){
    gulp.src('scss/**/*.scss')
    .pipe($.sass())
    .pipe($.cssmin())
    .pipe($.concat('style.css'))
    .pipe($.autoprefixer())
    .pipe(gulp.dest('.'))
});

main.scss

/*!
Theme Name: example
Theme URI: http://example.com
Author: xxxxxx
Author URI: xxxx
Description: xxxxx
Version: 1.0
*/

@import 'vars', 'typography', 'header', 'layout', 'proyectos', 'forms', 'libs';