This issue required the development of a small module and fixes which have been committed to AT Core.

https://drupal.org/project/at_tools is the module, just install it, you can turn it off when you are really really finished developing your CSS code. This module will re-submit the settings forms for each enabled AT sub-theme, forcing the CSS files to be re-written.

Orignal Issue:

This one is hard to pinpoint as to the cause, but after turning on Drupal's CSS and Javascript aggregation/compression setting, I noticed that blocks in a region that was set to "hidden" for mobile (but not tablet) were randomly appearing on smartphones. Flushing the cache (all caches) repeatedly seemed to fix the issue, but not consistently (not on all pages and not permanently). Sorry I can't provide more info, but thought I should log an issue in case others encounter this strange behaviour.

Comments

jessehs’s picture

Priority: Normal » Major

I just ran into an issue where it appeared that an older version of my mobile css code was being applied, instead of any of my changes. This only happened when aggregation was enabled.

I am pretty miffed about this, let me confess, since I just spent close to 2 hours debugging it!

Long story short, the problem was that Adaptive Theme appears to be doing a "pre-caching caching" of the compiled css files in the sites/default/files/adaptivetheme/ directory.

The way to get the aggregated files to actually build is to clear all caches and immediately save the theme's settings form at /admin/appearance/settings/[themename], then do another cache clear, just for good measure.

I would conisder this a *major* bug in the theme. drush cc all should actually rebuild aggregated css files from the css files in the theme!

Cross-linking this issue, as it may be related: #2002940: Turning on css aggregation is loading desktop css for every breakpoint.

Jeff Burnz’s picture

Title: Adaptivetheme should recompile aggregated mobile CSS during cache-clear without theme-settings resave » Mobile regions misbehave when CSS Aggregation/Compression is enabled
Priority: Normal » Major
Status: Needs work » Closed (works as designed)

[EDIT: Removing rant}, it was not helpful, we can do this in a module as proposed below.

jessehs’s picture

Category: bug » feature
Status: Active » Needs work

Sorry Jeff, I think I worded my post a bit offensively. On second thought, I don't think this is a *major* bug like I said, but a problem, no less. I'll look into writing a patch to re-build these files during cache clearing. While an edge-case, I think this would help prevent problems when deploying CSS changes to a production site. I'm marking this as needs work, and I'll update the task title to suit the feature request. EDIT: Oh, I guess I can't edit the title :-)

Jeff Burnz’s picture

He he, no I am not offended, just I know its a hard problem to solve, I have looked into it, but admit I have never sat down and written code to achieve it. Basically, afaict, there is no way to detect when the cache is being cleared, such as a drupal_flush_all_caches or just the CSS cache being cleared - aka no theme or module knows when the cache might be cleared, unless you check a cache table or file is missing on the first page load after the cache is cleared (then rebuild it etc), which is what AT does on many other occasions with various cache tables. But in this instance no file is missing, and how to delete one anyway (say for example delete the adaptivetheme_subtheme.responsive.styles.css file on cache_clear_all and drupal_clear_css_cache. If the user just clears the CSS cache then cache_clear_all is not fired, aka so no way to clear a cache table (something to use to detect and fire a file rebuild) - in essence so far I have not seen a reasonable hook or or other way to achieve it, however that does not preclude rethinking how this how idea/system in AT works to begin with, which might be more profitable to consider.

jessehs’s picture

Title: Mobile regions misbehave when CSS Aggregation/Compression is enabled » Adaptivetheme should recompile aggregated mobile CSS during cache-clear without theme-settings resave
Priority: Major » Normal

Heehee, I went on a wild goose chase yesterday, trying to implement hook_module_implements_alter, and adding adaptivetheme to the flush_caches hook there. Alas, for some reason, this must be done with a module, not a theme, even though a lot of hooks can be modified this way... (hook_flush_caches simply does not register inside adaptivetheme_module_implements_alter, although it does inside a custom module's implementation of it.)

It seems that perhaps a helper module (think omega_tools) might be useful here. Has a helper module been proposed before? It seems like it might be useful in other situations as well, given Drupal's limitations for themes. (A custom module wouldn't even need the workaround of the alter function... it could simply implement hook_flush_caches.

Jeff Burnz’s picture

I'd be pretty happy if that could work - so what are proposing here, let me get this strait:

- remove AT's current file generation/compilation of the responsive stylesheets
- replace with a module that does this

So without the module AT would always load those 5 or 6 responsive stylesheets, and if you want them aggregated (http request saving) then the module would do that and always update it when the cache is flushed?

jessehs’s picture

I was thinking that rather than removing anything from AT, the new helper module could listen for any cache-clear event, and trigger the regenerating of the compiled css files in the files directory. I wouldn't want to remove this performance boost for any sites that don't currently have the helper module installed.

Jeff Burnz’s picture

OK, I am easy either way really.

RobLoach’s picture

Just ran into this. Was expecting all caches to be cleared when clearing all caches. Was surprised Adaptive Theme's cached files still existed. Is this something we could sneak into function adaptivetheme_flush_caches() ?

Jeff Burnz’s picture

I did this in a module, aka:

function at_tools_flush_caches() {
  global $theme_key;

  // Nicked strait from commons_install(), but uses $theme_key,
  // which we hope is the active theme.
  foreach (array('adaptivetheme', $theme_key) as $theme_name) {
    $form_state = form_state_defaults();
    $form_state['build_info']['args'][0] = $theme_name;
    $form_state['values'] = array();
    drupal_form_submit('system_theme_settings', $form_state);
  }

  drupal_set_message(t('Cached CSS files rebuilt for !themename', array('!themename' => $theme_name)), 'status');
}

Wondering if we should wrap the above in if (variable_get('preprocess_css', '') == 1) {} etc?

Then at the end of the theme settings submit function we clear the CSS cache - despite this not being discussed it's really part of the overall issue of files not updating when you think they should:

  // Clear the aggregated file caches to update changes
  drupal_clear_css_cache();

So...

1) The module will clear, rebuild and cache aggregated styles when the cache is turned on and you clear the cache,

2) The drupal_clear_css_cache() fired at the end of theme submit will update aggregated/cached CSS files when the cache is on. This is important because you might change something like the responsive layout of a Panel in the theme settings, and updates will not show in the site until the cache is cleared (right now you kind of get a cryptic message in the CSS vertical tab, if you just happen to look there...), this should be automated.

The only dubious bit about this I can see is that when you clear the cache you actually fire drupal_clear_css_cache() twice, once unnecessarily - not sure if this is really an enormous problem for most situations.

Do you guys think this looks like a viable solution?

kristiaanvandeneynde’s picture

Title: Mobile regions misbehave when CSS Aggregation/Compression is enabled » Adaptivetheme should recompile aggregated mobile CSS during cache-clear without theme-settings resave
Priority: Major » Normal
Status: Closed (works as designed) » Needs work

Just like the OP it took me two hours of debugging before I found the cause of the problem (and thus this issue). Could someone please document or fix this "serve stale css" behavior?

Jeff Burnz’s picture

It is documented, in the theme settings for your sub-theme, where you make settings for CSS files etc, it tells you how this works. Its also documented here: http://adaptivethemes.com/documentation/css

And less bitching please, perhaps reviewing #10, yes I want to get this fixed but I need help with testing and reviews, with so many sites running this now I am pretty shy of doling out wholesale changes, even if that means recommending a module etc.

kristiaanvandeneynde’s picture

Hey Jeff, I didn't mean to come off as bitchy. I was using a Commons install and was banging my head against the wall for hours about why the front page wouldn't pick up the recent css changes. That kind of situation tends to make you write short answers or miss important paragraphs in the documentation.

I've reviewed #10 and it looks great. I would indeed wrap it with an if-statement and perhaps even put a notice on the theme page saying something along the lines of: "If you're using Adaptive Theme, it is recommended to also install Adaptive Theme Tools to ensure your CSS caches are always cleared in an expected manner."

Jeff Burnz’s picture

OK, I hear you on the frustration bits, am there now with D8 development, but at least its a learning experience.

Agreed about a warning for in the theme settings to use the new AT Tools module for cache control, hopefully I will wrap up the D8 prototype theme this weekend and can shift focus back to D7 and get the new version out and push this module to git and release etc, I am pretty keen to get this resolved.

Bogdan1988’s picture

I should mention that for me #10 example doesn't work. It worked only when I added some fixes. Here they are:

function at_tools_flush_caches() {
  global $theme_key;
//We need this hook to submit form settings button programmatically.
    $form_state['build_info']['args'][0] = $theme_key;
//Need this settings to avoid notices from validate callback.
    $form_state['values']['global_default_layout'] = 'smartphone-portrait';
//We need this setting to determine where files should be generated.
    $form_state['values']['global_file_path'] = 'theme_directory';
    $form_state['values']['bigscreen_layout'] = 'two_sidebars_right';
    $form_state['values']['tablet_landscape_layout'] = 'two_sidebars_right_stack';
    $form_state['values']['tablet_portrait_layout'] = 'two_sidebars_right_stack';
    $form_state['values']['smartphone_landscape_layout'] = 'one_col_stack';
    $form_state['values']['bigscreen_sidebar_first'] = 300;
    $form_state['values']['bigscreen_sidebar_second'] = 300;
    $form_state['values']['tablet_landscape_sidebar_first'] = 40;
    $form_state['values'] = array();
    drupal_form_submit('system_theme_settings', $form_state);

  drupal_set_message(t('Cached CSS files rebuilt for !themename', array('!themename' => $theme_key)), 'status');
}

So that's probably all. All values could be find here admin/appearance/settings/your_themename when we debug submit function.

Bogdan1988’s picture

Issue summary: View changes

Updated description to reflect further testing results - i.e. flushing the cache repeatedly does not permanently resolve the issue.

Jeff Burnz’s picture

Component: Mobile » CSS/HTML
Category: Feature request » Bug report
Issue summary: View changes
Status: Needs work » Fixed
kristiaanvandeneynde’s picture

Commit f255bae I assume.

Jeff Burnz’s picture

Yes, the actual change to the theme is very minor, the more important aspect is the AT Tools module.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

wlftn’s picture

I was having trouble with this, and the instructions in #1 didn't work for me: "The way to get the aggregated files to actually build is to clear all caches and immediately save the theme's settings form at /admin/appearance/settings/[themename], then do another cache clear, just for good measure."

Eventually I had to delete the file at

"~/[public files]/adaptivetheme/[ThemeName]/ThemeName.responsive.styles.css"

then follow the instructions above. That worked for me. Just wanted to leave a note here for anyone stuck with this. I hope it helps.

kristiaanvandeneynde’s picture

Download the module in #18 and then clear caches.

Hanpersand’s picture

I just had a nightmare with this issue, all related to the fact that I needed to get debug blocks out of my Sass/CSS, because respond.js wouldn't work with them in, and I couldn't figure out why they were still there with caching turned on after compass clean/compile/drush cc all. Just in case anyone else ends up here for the same reason, here's the related GitHub issue for respond.js: https://github.com/scottjehl/Respond/issues/274

And yes.... AT Tools on, recompiled CSS sans debug blocks, caches cleared, respond.js working. Phew.