1

I'm troubleshooting an odd issue on my Drupal 7 site where it seems that old versions of our aggregated CSS & JS files are used some amount of time after a cache clear. How this is playing out is that I'll make some update to our CSS or JS, then clear the cache via drush cc all (I've also used the UI to manually clear the cache). I get an updated version of the CSS / JS for a while. At some point (typically I've noticed it a few hours later), the page serves the old version of the aggregated file.

I've pulled mysqldumps of the site, and can see that the values in the variable table for drupal_css_cache_files, for example, contain a reference to the old aggregate rather than the new.

I found this issue on drupal.org (and I'm not sure it's exactly the same thing), but one of the suggestions involves deleting all files in <root>/cache, which I don't have. Would this be the same as deleting the files in sites/default/files/js/?

Another part of this that may or may not be related is that I see in my site logs "page not found" requests for old aggregated files that don't exist anymore.

I'm hitting a wall in troubleshooting, since it seems like the actual database value for the new aggregated file is being reverted. Anyone know what might be going on here?

Improve this question
2
  • Have you given drupal.org/project/advagg a try?
    – mikeytown2
    Apr 6, 2017 at 21:43
  • I haven't on this site. Looks like it's your project? I may try it out in the future, but at the moment I'd like to debug the issue with core asset aggregation before adding in another factor.
    – nkanderson
    Apr 6, 2017 at 21:46

1 Answer 1

Reset to default
0

Couple things to look into. An external cache (Varnish/Boost/etc...) could be referencing the old files. This issue will help with the variable_set's with css/js aggregation https://www.drupal.org/node/886488#comment-9668583. Also see this issue: https://www.drupal.org/node/1014086. I'd guess it's an external caching issue based off of what your describing but I can't say for sure due to the flaws in core that have still not been fixed.

In all honesty advagg will fix these issue for you. Drupal.org uses it due to issues with deployments https://www.drupal.org/node/1412130 https://www.drupal.org/node/2446971

Improve this answer
5
  • We're not using an external cache. The value in the database is actually returning to a previous version, as I mentioned above. I may end up going with advagg, I'd just like to find an active issue specific to what I'm seeing before adding in a new module.
    – nkanderson
    Apr 6, 2017 at 23:36
  • drupal.org/node/886488#comment-9668583 is the most likely fix
    – mikeytown2
    Apr 6, 2017 at 23:40
  • Maybe I'm not getting how this is being referenced there, but I'm not seeing anything about database values for the aggregated files being updated and then reverting?
    – nkanderson
    Apr 6, 2017 at 23:55
  • 1
    By putting a lock around variable_set the odds of 2 different processes overwriting it has been reduced; this doesn't fix the problem 100% only reduces the probably of it happening. Using variable_set to do css/js aggregation is flawed as the entire variable gets replaced instead of just changing the parts that actually changed. Not sure why it'd revert several hours later but this is the best shot at fixing the issue outside of replacing core with a 3rd party aggregator.
    – mikeytown2
    Apr 7, 2017 at 0:05
  • Thanks for explaining! This is helpful, as I'm trying to get an understanding of what's happening, rather than just get a copypaste solution / patch to implement.
    – nkanderson
    Apr 7, 2017 at 16:01

Your Answer

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

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