I am seeing something funny and maybe I'm misunderstanding how the CSS compression works, but I didn't find anything about this in your documents concerning the Adaptive Theme file generation system. You can observe this effect at http://store.bevelsmith.com/

Inspect the page using firebug, in particular the views slideshow

. There should be a background image below the views slideshow: flex-nav-container however it is not displaying because the path of this image is listed as url("/udmg81/sites/all/themes/bevelstore/images/slideshow-shadow.png") no-repeat scroll center bottom transparent

If I turn off CSS aggregation/compression (see http://stage-store.bevelsmith.com/ - I've turned css compression off on my staging site) you can inspect the same element and see that the path is correct - url("../images/slideshow-shadow.png") no-repeat scroll center bottom transparent; - so the image is displaying as desired.

Have you seen anything like this, or do you have any idea where this errant file path is coming from? Full disclosure here - the store.bevelsmith.com site is a multisite installation, where store.bevelsmith.com is the main site, and I create multisite installs using this as the base site. That said, there is no multisite install called udmg81 so I don't know if this is contributing.

Comments

Jeff Burnz’s picture

Category: bug » support

AT rewrites the paths for relative images when it generates the production version of the responsive styles, it actually uses the same mechanisms that Drupal core uses to parse CSS and replace the paths. When you turn on CSS aggregation AT switches from loading uncompressed responsive style sheets to loading a single optimized sheet - this is loaded from the files directory and therefor must have the image paths rewritten.

I don't know what is going on here to be frank, could be two things at least:

1) base_path() is being set as udmg81

2) _drupal_build_css_path is failing to remove all ../ from CSS image paths and otherwise munging the path, that is a possibility, but does not explain udmg81 in the url

I suspect #1 is the real issue, but as to why I have no idea. If you contact me through my contact form and give me access to your staging server I can probably debug this, to see where the wrong base_path() is coming from and why.

crutch’s picture

ditto, background image references in css are fine when css aggregation is off. When on, the compressed css goes back to using the references used in the development environment rendering the images not found on live site.

crutch’s picture

just poking around, in my case i've found that in the file location - ".../theme/mysubtheme/generated_files" folder that in the css file 'mysubtheme.responsive.styles.css' the image references retained an almost full path specifically @

/* swash */

.swash {
min-height: 200px;
background: url(/mylocaldevsite/sites/all/themes/mysubtheme/css/images/subfooter.jpg) center top;
}

/* footer */

#tertiary-content-wrapper {
background: url(/mylocaldevsite/sites/all/themes/mysubtheme/css/images/footer-bg.png) repeat-x left top;
}

which in the original stylesheets at "mysubtheme/css" the code is

/* swash */

.swash {
min-height: 200px;
background: url('images/subfooter.jpg') center top;
}

/* footer */

#tertiary-content-wrapper {
background: url("images/footer-bg.png") repeat-x left top;
}

How are these files generated? How would I prep them or alter them for live site from dev site?

I fixed by manually altering them outside of dev environment on desktop and them publishing to live site. Now when turning on css aggregation the live site properly includes those images.

crutch’s picture

...the global.styles.css background image references don't behave this way probably because it is not part of the generated_files folder.

I'm not sure of a resolution. If I am to upload the whole site file structure from dev to live then will encounter this issue again. Can't block writing of the file because it needs to be written if being generated.

What if the generated_file maintains the relative path but also copies the css/images folder over?

Jeff Burnz’s picture

Not really sure what you are asking here in terms of copy images/css folder.

global styles is not part of the generated files.

crutch’s picture

"Not really sure what you are asking here in terms of copy images/css folder."

../css/images the images folder in the css. ugh

The urls for images, in the generated_files folder, specifically in the css files, are getting changed, keep the images references the same and somehow copy the images folder to the generated files folder. This my suggestion but am not sure how that would be done. Just a suggestion to somehow circumvent the issue I'm experiencing and the person is experiencing in the original post.

I've adopted this theme for many projects and doing a lot of work so it is important to me and our organization. Apologies for not being clear but it seems there is an issue with the generated css changing the image references.

You cannot use CSS aggregation, when moving a whole folder structure directly from a development environment to a live environment.

Because those generated_files css files are rewriting the urls to using the development environment address and not getting rewritten or regenerated (how to?) in the live environment.

If this is not a concern then we will just need to keep manually editing the generated css files every time.

Nathan Tsai’s picture

Encountering this issue in 2017 & subscribing. Any progress?

I have transferred my subdomain site to a production site and would like to compress the files. However, when I do so, the url's are being changed to include the subdomain. What can I do about it?