I ran into the following issue today: I created a site showing several Views blocks using view modes of content that are configured to use the DS 2 column layout. Also I configured the Views blocks to be cached per user (DRUPAL_CACHE_PER_USER). It turned out that when you clear the cache and visit a page showing the blocks, the required ds_2col.css file is loaded, but when you refresh (and the block is then cached), the ds_2col.css file is no longer loaded.

I just did a test with a clean 'standard' Drupal 7.16 install and got the same behavior. I used the latest DS 7.x-1.x-dev, Views (also the latest 7.x-3.x-dev) and the latest stable version of ctools.

To reproduce: configure the teaser view mode of a node type to use the 2 column layout and then use that view mode in a simple View with a block display showing content of that node type. In the block display set the cache to 'Cache per user'. Then enable block caching in the performance setting and place the block in a region. Now, visit the page showing the block (the css is included) then refresh (the css is no longer included).

NOTE: make sure that there are no other elements on the page you are viewing that somehow also include the required css (for instance the default /node page also loads nodes in the teaser view mode and will therefore load the required css).

I recently had a similar issue with a block from a custom module where I used drupal_add_css() instead of using render arrays. Apparantly using drupal_add_css() is not possible and causes the css not to load when the block is cached. Changing the block output to use a render array with #attached fixed the problem there. I don't know how DS adds its css though. I also don't know if the issue also affects the 7.x2.x branch.

If you need more info, let me know!

Comments

marty2081’s picture

marty2081 commented

Ah and NOTE2: test this as an anonymous user (as user/1 cache is ignored)

swentel’s picture

swentel commented

Hmm that's weird, I use attached when adding the css in ds.module, so I'm not sure what's going wrong here.
I still use drupal_add_css() in the forms or in the ds views fields plugin, but it looks like the report is about a simple ds layout.

  // Line 679 in ds.module in 7.x-2.x and line 792 in 7.x-1.x
  $build['#attached']['css'][] = $layout['path'] . '/' . $layout['layout'] . '.css';
marty2081’s picture

marty2081 commented
Priority: Normal » Minor

I see. So that's not the cause. Thanks for the fast reply. Do you think either Views or Core messes it up?

It is not such a big problem since you can just turn off the block cache for blocks using a DS layout in the selected view mode so I've changed the priority to 'minor'.

swentel’s picture

swentel commented

Do you think either Views or Core messes it up?

No idea to be honest, I'll have to do some testing myself, but it won't be before december 1, D8 feature freeze coming up :)

marty2081’s picture

marty2081 commented

I understand. ;)

aspilicious’s picture

aspilicious commented
Issue summary: View changes
Status: Active » Closed (cannot reproduce)

Closing this, I can't reproduce and I have no clue how to dig deeper.
Reopen with more info if you think it's needed.

grisendo’s picture

grisendo commented
Status: Closed (cannot reproduce) » Active

Sorry for reopening, but it's true.

I had the same issue time ago in a project, and fixed taking all ds layout's css I used and replicating it in my theme's main css. This was quite nasty but it worked.

Now, I reproduced it again in another project. Here is some information: configuration is quite similar to the previous project. I give here the configuration and some other information that might be important in order to reproduce it:

  • Block caching and page caching enabled. Minimum cache lifetime 1 day, expiration 1 day. Compress cached pages, aggregate JS and aggregate CSS enabled (core system, no thirdparty module). I think disabling CSS aggregation could fix it temporally (for a demo), but it didn't.
  • Manage display: Content type 'event'. Teaser uses "Two columns" layout, from Display suite module.
  • View: display block of events (nodes) with "unformatted list" format and display mode "Content" with "teaser" mode. No views caching, and no block caching (from this views ui page).
  • Block added with core system to a region. Show only in '<front>'. Block cache alter installed, and set this block as "Cache once for everything (global)".
  • First time ds_2col.css is loaded, and everything shown OK. Reload page: Next time, ds_2col.css is not loaded and page is not shown as it should be.

As I said, a temporary solution is to replicate each layout's used css into theme's css, but is quite difficult to maintain a project this way when adding new layouts. Also it's difficult to remember from one project to another, and maybe in some scenarios (depending on how CSS and HTML structure are defined), page won't be shown OK when CSS rules are added twice.

arun murugadoss - drupal geeks’s picture

arun murugadoss - drupal geeks commented

I had the same issue in one of my project. In my case I had installed block_cache_alter module and after I disable/uninstall the module, clear the caches and rebuild the registry(i.e: drush rr), It solved the css not loading issue.

grisendo’s picture

grisendo commented

Maybe is this related with views or something?

This is what I think it happens:

  • View gets executed. Each row-node is loaded in a given view mode. Layout CSS is added via #attached in display suite.
  • View renders output. But Views doesn't render it as a renderable array, but as string. Block is rendered and cached (as html string), and #attached are executed here with drupal_add_library, drupal_add_js and drupal_add_css.
  • Next time, block is rendered from cache, with all html but without drupal_add_css/drupal_add_js/drupal_add_library

Anybody can confirm same behavior?

jesse.voogt’s picture

jesse.voogt commented

I can confirm that I'm experiencing the same behavior. When block cache is enabled, display suite is not loading any of the js/css for the block. I have not investigated the module's code, but from the sound if it they are using #attached which is supposed to be block cache compatible...

I'd really like it if there was a workaround option to NOT load js/css conditionally whenever the block happens to render to the page, but to rather load the js/css *all the time* for everyone, both anonymous and logged in users. This might involve a slight rewrite of the js, depending on how it was written. One benefit to this approach would be that the css & js could get aggregated into the main set of style sheets, leading to less total HTTP hits. The users will just load all js/css one time for the entire site, no chance of it going missing,

gge’s picture

gge commented

I have the same problem using Display Suite 7.x-2.11. I think the priority of this issue should be bumped to at least Normal...

jim.m’s picture

jim.m commented

Hey,

I applied the patch #45 from this topic https://www.drupal.org/node/1460766 and it seems to work fine.
So, I think the bug is related to the Drupal core, and not to the current module

Tested on Drupal 7.44 and Display Suite 7.x-2.13