Last updated May 27, 2016. Created on September 2, 2012.
Edited by c_c_l, Francewhoa, steinmb, xamount. Log in to edit this page.

Should I use 3.x or 4.x?

Whether you should use Omega 4.x or Omega 3.x depends on several considerations:

  • Do you rely on the user interface for building layouts, or are you comfortable defining layouts in code in a tpl.php file? Omega 4.x does not include the elaborate layout definition UI that was a hallmark of Omega 3.x
  • Do you want to use a theme that is under active development, or are you comfortable with a theme that is minimally maintained? Omega 3.x is minimally maintained. In all likelihood, unless a new maintainer steps up to the task, Omega 3.x will not be upgraded to Drupal 8.
  • Are you comfortable with or willing to learn SASS, or do you want to stick with straight CSS? Omega 4.x does NOT require use of Sass but certainly is much easier to implement if you adopt Sass.

This issue is a thorough discussion of the changes in 4.x.

Looking for support? Visit the forums, or join #drupal-support in IRC.


alanom’s picture

There are quite a few things about Omega and SASS that the docs expect you to already understand. These tripped me up, and after reading many issues, questions, etc, it's clear I'm not the only one.

If you're new to Omega and SASS:

  • SASS simply creates CSS files. It's just a development tool. It's not so much "part of the theme" as a piece of software you're expected to run on your local development machine to make the coding process easier for you (or your front-end developer(s)).
  • Your Omega theme on your production server is expected to run without SASS. It doesn't need SASS and therefore doesn't need all the Ruby stuff (Compass, gems, bundler, guard, etc) that you are expected to install to use SASS. Don't install Ruby for Omega on your server, don't install gems, and ignore the content of your production subtheme's SASS folder.
  • You're expected to only install and use the Ruby / SASS stack in your local environment, and simply use it to generate CSS files etc on your development server or local machine, which you then plonk into the appropriate place in your production theme.
  • To not use SASS or to "disable" SASS, simply don't install all that Ruby stuff and ignore the contents of your theme's SASS folder. None of the SASS stuff does anything unless instructed to (by you directly telling it to compile from the command line with "compass compile", or by telling Ruby to watch the SASS folder and auto-compile from it using "guard" or "compass watch" or similar).

Using SASS basically just means you code the files in your SASS folder instead of the files in your CSS folder. The basic idea of SASS is much simpler than it is often made to sound:

  • It lets you breaks your files up into more manageable and logical chunks, e.g. you can keep all your forms-related CSS separate to your base CSS separate to your navigation CSS etc, and within these, you can keep your layout CSS separate to your typographic CSS, etc etc - or any structure that suits your needs. SASS then compiles all these files for you into normal CSS.
  • It lets you define variables so you can put in your brand colours, fonts etc once then reference them by name
  • It has some handy optional features to make working with grids, breakpoints etc a little easier
  • It lets you code CSS with hierarchies, which simply means you can do this:
.content { 
   p { 
      a {
         some: rule;
   ul { 
      some: rule; 

...instead of...

.content p { 
   some: rule;
.content p a { 
   some: rule;
.content ul { 
   some: rule; 
gbansal’s picture

Can i Use Ohm sub-theme for production ..
and i also want to share as a micro-theme

pkiff’s picture

Please focus your questions in one support area at a time. Support questions are generally better answered in the issue queue for the theme. I've replied to your similar question in the issue queue there: