1

I tried to set up SASS as part of an Omega 4 theme on a VPS server, but I'm now drowning in Ruby permissions and versioning issues. It's causing far more sysadmin type work than a CSS generator is worth for this project.

The Omega 4 docs repeatedly state that SASS is helpful but not essential to Omega 4 and that you can simply write CSS the old-fashioned way, which is what I intend to do - but they don't say anything about how to stop Omega trying (and failing) to apply SASS all the time.

How can I completely disable the SASS element of Omega 4?

I can't find anything relevant in the theme settings. I've tried simply removing / renaming the sass folder in my subtheme and clearing caches, but I'm still getting Ruby / SASS related errors that look like this:

Error: File to import not found or unreadable: singularitygs.

I want it to completely stop trying to do anything related to SASS.

From reading around, it sounds like it's common to have a Drupal production server run Omega 4 with no SASS, and for people to have SASS on their development server then upload the CSS output to production when they're happy with it. Sounds sensible. But how what I can't find is, how do they stop the production server from trying to run SASS and access all that Ruby stuff all the time?

Improve this question
2
  • I've tried creating a new blank subtheme and not running bundler on it - so far I seem to be free of SASS and Ruby related headaches. No idea if this means it's disabled or just silently failing in the background though, but it's an improvement on endless error messages.
    – user56reinstatemonica8
    Commented Aug 22, 2014 at 1:32
  • I don't use Omega but I am sure there must be a .rb file in the theme sass root that you can change settings in. Also, don't set compass to listen, and then just ignore the sass files and add a custom css file to info.
    – J. Reynolds
    Commented Aug 22, 2014 at 3:53

2 Answers 2

Reset to default
0

But how what I can't find is, how do they stop the production server from trying to run SASS and access all that Ruby stuff all the time?

There seems to be a major misunderstanding here.

Compilation of SASS is invoked by you, it's not an automatic action that a server will just take upon itself to perform. Your remote VPS will not be set up to try to auto-compile SASS into CSS unless you, or someone else with access to the server, has set it up like that. The very fact that you've had to setup and install ruby on the remote serve should hopefully make that obvious.

Having that stuff on your production server is wrong anyway, you should prepare your distribution locally (read: compile SASS, minify/uglify js, etc), and sync that. That way you can never have any problems.

Your comment below the question is correct: if you don't want to compile SASS, then simply don't run bundle exec guard, compass compile, or whatever other method you're using to instigate the compilation.

If you haven't told any process to watch/compile your SASS files, then no process will be able to do so. The power is yours.

Improve this answer
5
  • That's reassuring to know that none of the many, many dependencies in the Ruby/SASS stack will do anything unless told to by guard, compass or other direct action. If there's one thing I've learned from researching Omega 4 issues, it's that I'm far from the only person with major misunderstandings! And in my defence, I found out that it's expected to only run SASS locally only after following all the steps in the documentation, which all talk about the Ruby/SASS stack as if it's simply part of the theme. I'll add a comment to the docs.
    – user56reinstatemonica8
    Commented Aug 22, 2014 at 10:35
  • Yeah it's just one of those things I guess - the first time you realise "ahhhh, there's nothing magic going on here" it becomes 2nd nature and you never think of it again. But getting to that point is sometimes a bit of a strangled route
    – Clive ♦
    Commented Aug 22, 2014 at 10:41
  • "strangled route" - very much so! Especially when there are 15+ mysterious libraries rattling around... I've added a line or two to the first doc page to talk about installing SASS clarifying how it's expected to be used, so no-one gets led down a wrong path like I was, and a comment to the first Omega 4 docs page, so hopefully people new to SASS aren't left wondering what and why it is. Not sure if this is the standard approach to documentation but hopefully someone can tidy it up if it's not.
    – user56reinstatemonica8
    Commented Aug 22, 2014 at 11:34
  • Wow, you'd responded to my follow-on question before I'd even finished commenting to tell you it was there! Cheers :-)
    – user56reinstatemonica8
    Commented Aug 23, 2014 at 17:14
  • @user568458 It's half time, I'm bored ;)
    – Clive ♦
    Commented Aug 23, 2014 at 17:21
-1

If you've used drush omega-guard, it's not so simple.

In the end, two Drupal.SE and two StackOverflow questions later, the only way I could get Omega 4 to behave and stop freaking out trying to run Ruby every time I touched any directories was brute force, deleting every ruby-related file in the subtheme directory.

Uninstalling Ruby didn't help, so it can't have been something in Ruby. Rebooting didn't help, so it wasn't a process left running. Copying or renaming the subtheme folder didn't help, so it wasn't some system thing set to watch a directory by name. Renaming the guardfile didn't help, so it wasn't a process scanning for guardfiles, so it seemed it must be something in the subtheme folder.

I think deleting the guardfile is enough, but am not sure.

I don't know which file was the one that finally fixed it, but the only non-directory remaining files after my purge were:

enter image description here

Or, the short answer is, don't use Omega 4 theme and its drush commands if you're a themer. Omega 4's drush commands make system-level changes without an option to undo them: system-level changes are for Linux sysadmins, not Drupal themers.

After lots of research and two SO questions I think that the omega drush command makes these changes by accessing the inotify Linux kernel library from the PHP command line which can only be turned off by writing your own PHP CGI script to access the same api. Either that or it modifies .bashrc. If you're a themer whose skillset doesn't stretch that far into sysadmin territory, I'd advise against using the drush commands bundled with Omega 4 - at least until someone writes a drush omega-unguard script.

Improve this answer
6
  • Sorry but I have to strongly disagree with your conclusions here: you made a mistake when you set up your server (installing the dev stack on your production box). Then you messed up removing it (only you can know how you set up the file watchers, the theme can't do it for you, that's not possible, they're dumb files). That has nothing to do with the Omega theme, and it most certainly does not mean Omega is for sysadmins only. I'm not being rude but that statement could not be more wrong, as 99.99% of people who use Omega, and followed the instructions to set it up, will tell you
    – Clive ♦
    Commented Aug 24, 2014 at 11:19
  • I followed the installation docs, the "file watchers" or whatever they are were created by drush omega-watch which offers no option to undo the changes it makes. Editted to be clearer.
    – user56reinstatemonica8
    Commented Aug 24, 2014 at 11:39
  • Replace "sysadmin" with "developer" and consider my objection withdrawn...nothing we're talking about here is a sysadmin's job. Setting up a development environment is a job for, well, the developer. It might sound picky, but the insinuation that you need a sysadmin to set up a Sass stack is too far removed from reality for me to leave alone
    – Clive ♦
    Commented Aug 24, 2014 at 12:20
  • My problem was never setting up the stack, which is easy, it's removing it: specifically knowing what the drush / bundler / etc scripts did that needs undoing, and how to undo them. The drush script did something to my server at a system level: but even helpful, world class drupal experts like yourself don't know how to undo whatever drush omega-guard did. It seems my options are reverse engineer it (requiring more knowledge of Linux apis like inotify than I have), flush the server and start again, or ignore it and hope.
    – user56reinstatemonica8
    Commented Aug 24, 2014 at 12:47
  • You wouldn't need to touch unix stuff, guard is controlling all that...I just checked the code for omega_drush_guard() (not trying to labour the point, just want to get to the bottom of this so if I'm wrong about how this works I can learn), and it does nothing system-level, it just invokes a single process, once. However, if you pass the --screen option it runs it as a daemon. So what I think has happened is that you have a startup script somewhere that's invoking omega guard with the --screen option. While you were setting this up do you remember adding an init script or similar?
    – Clive ♦
    Commented Aug 24, 2014 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.