Problem/Motivation

I have one site with less module and 7.x-2.7+45-dev worked well with it, then upgrading to the latest advagg 7.x-2.7+94-dev and none of the less CSS loads.

Less module version: 7.x-4.0+2-dev

Here's the debug output from ?advagg-debug=1 :
Before: https://gist.github.com/2a8c6593b47804b0c469
After: https://gist.github.com/ea0cdca140a797923a1f

Diff debug output: https://gist.github.com/b3fc50666e4e456eb7e3

Proposed resolution

Remaining tasks

User interface changes

API changes

Follow-up to #2412093: IE CSS Selectors limiter doesn't work with less module

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joelpittet’s picture

Title: Less module not working with advagg » Less CSS Preprocess module not working with advagg
Issue summary: View changes
joelpittet’s picture

Issue summary: View changes

Added the diff between the Latest and the Old (working version). Sorry the diff is backwards in time.

mikeytown2’s picture

The diff does show it quite well; thanks for taking the time to do that :)

Thinking that inside the advagg.inc file around line 1,000 I would change this

  // Fix for things like LESS which write dynamically to the public file system.
  $scheme = file_uri_scheme($new_filename);
  if ($scheme) {
    $wrapper = file_stream_wrapper_get_instance_by_scheme($scheme);
    if ($wrapper) {
      // Use the wrappers directory path.
      $new_filename = $wrapper->getDirectoryPath() . '/' . file_uri_target($new_filename);
    }
    else {
      // If the scheme does not have a wrapper; prefix file with the scheme.
      $new_filename = $scheme . '/' . file_uri_target($new_filename);
    }
  }

to this (only top 3 lines changed)

  // Fix for things like LESS which write dynamically to the public file system.
  $scheme = file_uri_scheme($new_filename);
  $ext = strtolower(pathinfo($path, PATHINFO_EXTENSION));
  if ($scheme && $ext === 'css') {
    $wrapper = file_stream_wrapper_get_instance_by_scheme($scheme);
    if ($wrapper) {
      // Use the wrappers directory path.
      $new_filename = $wrapper->getDirectoryPath() . '/' . file_uri_target($new_filename);
    }
    else {
      // If the scheme does not have a wrapper; prefix file with the scheme.
      $new_filename = $scheme . '/' . file_uri_target($new_filename);
    }
  }

Going back to the original issue and it has to do with the .less file having more than 4095 selectors in it. Looks like I need to install the module and create a big less file to truly fix this

joelpittet’s picture

I'm guessing where you put $path you meant $uri_path?

There doesn't seem to be a difference except the hash between the latest and that quick fix extension check.
After with fix in #3: https://gist.github.com/9700cc22985a069cd9fe

mikeytown2’s picture

Status: Active » Needs review
FileSize
4.22 KB

Can you test this out?

joelpittet’s picture

There was no change after the patch was applied unfortunately and no change in the debug output (other than hash like #4)

The change that effected this I believe came shortly after the version stated in the IS. I can give you a revert patch to help test the before and after if that helps?

mikeytown2’s picture

Looking into this more and I think it has to do with the less 3.x vs 4.x code; playing around with hook_element_info_alter now.

joelpittet’s picture

Issue summary: View changes

FYI I'm using 7.x-4.0+2-dev of Less.

mikeytown2’s picture

fairly certain that this will fix it. Think you'll have to cc all to test.

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

That fixed it! thanks @mikeytown2. Is there any unnecessary changes in that patch that could lead to technical debt or is it all cool with you?

mikeytown2’s picture

Status: Reviewed & tested by the community » Fixed

Issue was independent from #2412093: IE CSS Selectors limiter doesn't work with less module; the other changes are there to ensure that .less files are treated like css files.

I appreciate a good bug report; makes fixing it a lot simpler!

  • mikeytown2 committed 967d07e on 7.x-2.x
    Issue #2449989 by mikeytown2, joelpittet: Less CSS Preprocess module not...

Status: Fixed » Needs work

The last submitted patch, 9: advagg-24499809-9-less-fix.patch, failed testing.

The last submitted patch, 5: advagg-2449989-5-less-fix.patch, failed testing.

mikeytown2’s picture

Status: Needs work » Fixed

Silly testbot; patch has already been applied.

joelpittet’s picture

Status: Fixed » Needs work

Sorry @mikeytown2 client called and some how over time this fix didn't hold up... it seemed to fix it in the direct test but somehow it busted over time (cron related maybe?)

Setting to needs work, lmk if there is anything I can tell you on this. Though I'm about ready to convert LESS to SASS and call it a day:P

mikeytown2’s picture

Try disabling the IE 4095 fix in advagg. I think it is related.

Any steps to reproduce the new bug?

joelpittet’s picture

The only step I have at the moment is 'time' which is the least helpful of all the steps...

"Prevent more than 4095 CSS selectors in an aggregated CSS file" is unchecked already.

joelpittet’s picture

FileSize
136.03 KB

joelpittet’s picture

Issue summary: View changes
FileSize
110.51 KB

Clearning cache and it's back up and working... so it's kinda like the cache gets stale or something...

mikeytown2’s picture

Is the compiled less file gets deleted, could that cause the issue you've been having?

http://cgit.drupalcode.org/less/tree/less.module#n240 - Look for less_clear_css_cache();

It call this
https://api.drupal.org/api/drupal/includes!common.inc/function/drupal_de...
which will remove any file if it was modified more than 30 days ago.

This function only gets used for core's css/js aggregation. I would increase this variable. AdvAgg piggybacks on this variable; thinking it should be independent now. You can change this under Cron Options under "Delete aggregates accessed/modified more than a set time ago." should be 1 month by default.

joelpittet’s picture

That seems like a probable cause for sure, nice sleuthing.

It's been ~14 days since I applied the patch though and the cache was cleared, and probably a while (few months) before that when the CSS was actually changed in the less file.

Is it this option maybe? "How long to wait until unaccessed aggregates with missing files are removed from the database. " It is set to 2 weeks by default.

joelpittet’s picture

Tried manually flushing the LESS cache, but it's still working. I'll give it a day and see if I can reproduce.

mikeytown2’s picture

You'd have to remove the generated less files manually in order to see if it's the issue. The function will only delete the file after it's older than 30 days.

joelpittet’s picture

Ahh thanks, so I manually deleted the folder /sites/default/files/less
Then refreshed the page and they got correctly created again.

mikeytown2’s picture

Hmmm so it sounds like that is not the issue as the files do get regenerated.

joelpittet’s picture

It was a bit tricky to debug, was without my computer and had to disable advagg through ssh on my phone to get the site working again. And after dumping the latest dev up there and flushing cache things are working again...

I'll let you know if it happens again, may be a while though.

mikeytown2’s picture

Status: Needs work » Postponed (maintainer needs more info)

I'll set this to needs more info for now.

mikeytown2’s picture

Any news on this?

joelpittet’s picture

Status: Postponed (maintainer needs more info) » Fixed

I've had it on aggressive for a month and no complaints.

Status: Fixed » Closed (fixed)

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