Could not compile the file desktop-first.scss & mobile-first.scss

formatting

add in infoz

redundancy

I was able to fix this by changing to 'COMPILED FILES PATH' under SASS Settings to sites/all/themes/. That seems a little fragile...

The CSS rendering is a little undesired because I have sasson under /sites/all/themes and my subtheme under /sites/all/aegir-themes/ (a github repo with multiple themes I keep on the same platform in aegir). It'd be nice to be able to choose /sites/all/themes/sasson and then /sites/all/aegir-themes/foobar, but that might be a bit of an edge case? I suppose my alternative would be /def/files/sasson if the rewrite URL worked correctly.

Checking " Rewrite URLs." brings up the:

Strict warning: Creating default object from empty value in sasson_get_assets_list() (line 228 of /sites/all/themes/sasson/includes/assets.inc).

Unchecking it and flushing cache takes it away. With that unchecked + compile path set to sites/all/themes/ it works for now.

Do you want me to keep on the previously released 3.x dev or pull from HEAD for testing?

Ok, I'll work off of head then, and make a comment of that when I post issues.

When I include a grid setting e.g. #block-block-3 { @include grid(12); } from salsa my subtheme scss file I get a similar compile error for that file:

An error occurred while running:
'compass' 'compile' '/private/var/tmp' '--output-style' 'compressed' '--boring' '--no-line-comments' '--images-dir' '~/Sites/erutan/sites/all/themes/erutan/images' '--config' '/private/var/tmp/assetic_compassY2zq9y' '--sass-dir' '' '--css-dir' '' '/private/var/tmp/assetic_compassWupdhi.scss'

Output:
    error assetic_compassWupdhi.scss (Line 126: List index is 2 but list is only 1 item long for `nth')
   create assetic_compassWupdhi.css

I have my subtheme (erutan) directly in sites/all/themes instead of sites/all/themes/aegir-themes.

since this started happening I also lose my css for admin_menu - I can clear cache to get it back but then it goes away again next refresh. existing page styling still appears just fine. disabling admin_menu doesn't fix anything (aside from me being annoyed slightly less).

Yeah - I reinstalled Sasson before and no change, I'll rebuild my subtheme again soon and see if that does anything.

I wonder if it has anything to do with me using a VirtualDocumentRoot for my local dev setup + assetic. ~/Sites/foo maps to foo.dev, I switched off of MAMP a while back but certain apps don't like VirtualDocumentRoot - Chive gives me 500s etc.

Wow - that solved the desktop-first and subtheme scss issues.

I got the old:

Strict warning: Creating default object from empty value in sasson_get_assets_list() (line 228 of [~]/sites/all/themes/sasson/includes/assets.inc).

When I went to /admin/appearance/settings/subtheme, but that's the only time any errors have shown up. update: yeah, it's only within that certain path that the 228 shows up.

admin_menu is still being weird, but I disabled it again... I've had a similar problem with it ~a year ago.

http://drupal.org/node/1064128 old old issue. must be some malformedness from assetic builds that is making it fussy.

desktop-first.scss occasionally pops up on error message:

Output:
    error assetic_compassnQnaBv.scss (Line 12: Invalid CSS after "...ia (max-width: ": expected expression (e.g. 1px, bold), was "$large) {")
   create assetic_compassnQnaBv.css

I've tried this with a subtheme override and base _settings.scss - luckily at this stage I can deal with default settings. No rhyme or reason I can see as to where this pops up, maybe every 20th or so page load. _settings.scss isn't being loaded before _sasson_large.scss so the latter doesn't know what to do @ line 16.

I don't think so - the menu bug is most likely just a side effect of either the assetic line 228 error or desktop-first.scss occasionally not wanting to recompile, it was fine until a certain point then kept on having the unstyled behaviour. I'm just back to the standard toolbar for now...

It's odd that the line 228 only shows up in the GUI for editing subtheme options in admin. I'm going to migrate the site to a new environment, I'll see how that impacts the errors (now non-critical) I've been getting.

It might be because it's calling an earlier version of Ruby on my dev machine. I have RVM and 1.9.3 installed, ruby -v, echo $PATH, echo $GEM_PATH, etc etc all point to that. Latest stable RVM and Compass - I'm running OS X 10.8 locally.

I got this error message on trying to compile desktop_first.scss:

Output:
    error assetic_compassamFaOs.scss (Line 10: File to import not found or unreadable: settings.
Load paths:
  /private/var/tmp
  /Library/Ruby/Gems/1.8/gems/compass-0.11.7/frameworks/blueprint/stylesheets
  /Library/Ruby/Gems/1.8/gems/compass-0.11.7/frameworks/compass/stylesheets

I noticed some of the assetic files seem to be pointing to /usr/bin/ruby - private $rubyPath; & private $rubyBin; which in OS X 10.8 symlinks to the default install of /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby. Some symlinks /usr/bin are signed by an apple cert, yay, including ruby. It could also be that I need to use a wrapper (I've tried RVM and standard ruby builds).

http://stackoverflow.com/questions/8979956/sass-broken-after-install-wit... is related.

===

Also on my dev server (Debian Squeeze) I get the message that it didn't find a compass. Manually setting some symlinks in /usr/bin upped me to

Error Output:
/usr/bin/env: ruby_noexec_wrapper: No such file or directory

FYI this is how I set those up:

hq:/usr/bin# which compass
/usr/local/rvm/gems/ruby-1.9.3-p362/bin/compass
hq:/usr/bin# ln -s /usr/local/rvm/gems/ruby-1.9.3-p362/bin/compass compass

settings[sasson_compiler_destination] in the .info file has some relation to:

assetic:
    filters:
        cssrewrite: ~
        sass: 
            bin: /var/lib/gems/1.8/gems/sass-3.1.7/bin/sass
            compass: /var/lib/gems/1.8/gems/compass-0.11.5/bin/compass

via: http://symfony2admingenerator.org/installation.html (search for sass).

I think we're going to need more compiler destinations - and ideally it'd be nice to be able to set one for local/dev and one for server/prod (have a toggle in the admin UI?) so we wouldn't have to touch the .info file to change those tokens on the server each time a change is pushed.

update: this is my first time digging into ruby beyond installing some gems and sass --watching. looks like I do need to symlink to wrappers. http://www.lamolabs.org/blog/5397/how-to-use-rvm-installs-of-ruby-in-she... + http://www.bradlanders.com/2011/09/02/simple-wrapper-for-ruby-scripts-ru... look good.

Given the "out of control / issues that don't seem related" I figured things could well be impacted by my local dev environment, hence attention to that. On local/OS X it compiles my subtheme.scss all the time now, and webfonts.scss, but I've been getting constant errors on desktop_first.scss due to settings.scss. I was trying to get ruby running on Debian so I could compare the errors against my local dev environment and ran into a different set of issues.

My understanding so far is that since Assetic isn't a ruby app it can't run standard ruby, it needs a wrapped version ala ruby_noexec_wrapper, which isn't sourced and/or symlinked to in /usr/bin by default. In Debian the Assetic in Sasson respect path (hence it looking for /usr/bin/env/, though it also wants more /usr/bin stuff which RVM doesn't setup) - I'll treat this as a "standard" environment vs my OS X which is a mix of what came with the system, homebrew, rvm, some semi-funky apache wildcard stuff, etc which is why I spent some time trying to dig deeper into how it all worked.

/usr/bin/env/ looks similar to http://stackoverflow.com/questions/12127603/usr-bin-env-ruby-noexec-wrap...

In retrospect, it's likely that Assetic respects $PATH on OS X as well and I just temporarily had a messed up RVM/ruby when I was tweaking things, so it went further down $PATH to hit the /usr/bin/ruby which is 1.8.

Any progress on the theme settings error which is caused by the call to sasson_get_assets_list('js', 'jquery') from theme-settings.php?

The admin_menu issue goes away when I don't have the theme compile SASS (e.g. on server).

I still get:

Output:
    error assetic_compassoVz2Yi.scss (Line 12: Invalid CSS after "...ia (max-width: ": expected expression (e.g. 1px, bold), was "$large) {")
   create assetic_compassoVz2Yi.css 

I've been using Seven for the admin theme.

Ok - that error has gone away. It wasn't one I was particularly worried about myself either.

Any idea re: #23 / something you'd want me to look into?

I've worked around it by just combining relevant files into a resp.scss I'm including in my subtheme, but the issue is if I choose a theme to be responsive I get that assetic error for desktop-first and desktop-first and they don't compile. It seems odd as I've tried a few different dev builds of v3 and this seems obvious enough that someone else should have had the same issue if it's truly just the base theme loading files out of order. Both of the files do have the @import "settings" statement before they @import their sub files.

Assetic is loading settings.scss (if I move the file out of it's default location, either in the subtheme or the basetheme it tells me that it isn't found), but it obviously isn't applying the contents of it to the foo-first.scss files hence the variables give compile errors. Someone else has this issue as well.

What I've done to get around this is to copy desktop.scss to my subtheme and just load the partials that I need into it and keep the variables for breakpoints all in that same file. It's the simplest way to avoid whatever hiccup is in the compile system.

update: copying the contents of settings.scss into desktop.scss in my subtheme still gives me the compile error re: $large. I wonder if assetic is ignoring my $PATH and $GEM_PATH set via RVM and using my default 1.8 ruby install that comes with OS X. pre SASS 3.2 you couldn't pass variables through media queries right?

update2: I feel it has something to do with me assuming $rubyPath was supposed to override all the /usr/bin stuff in Assetic - Assetic isn't meant to gather information from $PATH, but to have these paths defined in a config.yml. Since there is no config.yml it seems like these settings should be tokens we can enter via the .info file or theme UI - it seems like you're using sass.inc to path that info in a drupalish manner(sasson_compass_path, etc), but I'm not much of a PHP guy.

I've tried tweaking the settings in the following files from usr/bin/foo, judging by stack overflow posts they should work, but no dice yet.

ScssFilter.php
SassFilter.php
	/Users/erutan/.rvm/gems/ruby-1.9.3-p385/bin/compass
CompassFilter.php
	/Users/erutan/.rvm/gems/ruby-1.9.3-p385/bin/sass
SprocketsFilter.php
	/Users/erutan/.rvm/rubies/ruby-1.9.3-p385/bin/ruby
	/Users/erutan/.rvm/gems/ruby-1.9.3-p385/bin/ruby_noexec_wrapper

Interestingly enough even after changing the paths in Assetic it still defaults to 1.8 if I give it an invalid import.

Output:
    error assetic_compassrCeRVq.scss (Line 30: File to import not found or unreadable: wtfbbq.
Load paths:
  /private/var/tmp
  /Library/Ruby/Gems/1.8/gems/compass-0.11.7/frameworks/blueprint/stylesheets
  /Library/Ruby/Gems/1.8/gems/compass-0.11.7/frameworks/compass/stylesheets
  /Users/erutan/Sites/erutan/sites/all/themes/aegir-themes/erutan/sass
  /Users/erutan/Sites/erutan/sites/all/themes/aegir-themes/erutan/stylesheets
  /Users/erutan/Sites/erutan/sites/all/themes/sasson/sass
  /Users/erutan/Sites/erutan/sites/all/themes/sasson/stylesheets
  /private/var/tmp/sites/all/themes/aegir-themes/erutan/sass
  Compass::SpriteImporter)
   create assetic_compassrCeRVq.css 

I rebuilt my OS X after a failed logic board (I used my time machine backup data for all my media/files/content, but my system was getting really boggy). After messing around with rvm, passenger, and a bunch of other shit I realized it wasn't just apache not pulling in the right path... I ran a little script that echoed getenv('PATH'); after editing /System/Library/LaunchDaemons/org.apache.httpd.plist and my correct path was being processed by Apache. Before this on my old machine I had been compiling via compass/sass fine locally and at one point had switched from the default old ruby-1.8 that comes with OS X to a custom one that worked fine in the CLI / fire.app, etc.

After trying to recreate that and having it repeatedly say it couldn't find compass despite the edits to httpd.conf, /System/Library/LaunchDaemons/org.apache.httpd.plist, a working path otherwise, I gave up and imploded rvm / cleaned up my bash profile then and gave sudo gem install compass a try.

Works flawlessly.

Moral of the story, unless you really know your way around Ruby / are coding some actual projects, just stick with the default OS X install. ^^