We have had issues on production where sometimes DS fields all over the site start disappearing (screenshot attached). We think it might be memcache related, although one of our developers is having this issue on their local box without memcache and clearing caches will not fix this issue. These are the only 2 environments where we can recreate the problem.

Can you point me in the right direction where this could be failing? Would this be a cache table? What cache bin specifically would I need to look at?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

swentel’s picture

Priority: Normal » Critical
Status: Active » Needs review
FileSize
1.11 KB
1.11 KB

Ok, so this is most likely a regression introduced by #1550678: Field titles get wrong translation - damnit. Can you test the attached patch ? I'm almost 100% sure that's going to solve it. I'll throw out new releases immediately if you can confirm this. Raising to critical because this is very annoying on multilingual sites.

drupalninja99’s picture

We definitely are using multi-lingual, I didn't realize that could be a factor. I will definitely try out this patch, thanks so much for your help! I have been pulling my hair out.

drupalninja99’s picture

! deployed the patch and cleared all caches via drush cc all. For the first time I did not see any funkiness. Before I was having to do some other stuff multiple times to finally get everything to work.

Now there are caveats:
1. When I enabled a module, the problem came back. When I disabled the module the issue went away.
2. Doing a flush all caches from the admin menu also triggers the problem

The workaround for now is that we can just use drush cc all. I am interested tho if there is anything that could be done to fix the issue when enabling a module? Also its interesting that I never get this on other environments, only on production.

swentel’s picture

When I enabled a module

Is this for any module or a specific one ? I'm trying to think of situations or reasons why this might happen, but can't think of any at this point.
The admin menu flush is also very confusing as that is really clearing all cache tables. Is there any big difference between production or local ? (say memcache or so, although I can't see why that would start doing strange)

Anonymous’s picture

The patch is not working for me. I put the following line in ds_get_fields function.

module_load_include('inc', 'ds', 'ds.ds_fields_info');

Now i can see all fields at admin/structure/types/manage/CONTENTTYPE/display/full, but not all fields were rendered.

swentel’s picture

That's the thing, that module include shouldn't be necessary as this file should be loaded automatically by Drupal core because it's declared in ds_hook_info().

nuez’s picture

I´ve been having the same problem and I can confirm that #5 solution works...

Anonymous’s picture

I think this is not a problem with display suite. I have several issues after upgrading some modules.
- sometimes jQuery doesn't load
- pathautos admin interface is empty
- token is not working properly

nuez’s picture

Correction: i can see the fields now in the admin interface, but they don´t seem to render anymore...
I have the same issues as seitenmanufaktur, #8.

Anonymous’s picture

Maybe this is related http://drupal.org/node/1415278

nuez’s picture

Hate to spam again, just to let you know: but with the patch from #1 and the added code from #5 it seems to work. The reason i wasnt seeing it on a node, its because the specfic nodes' output was overridden by another module (tournament). tnx

drupalninja99’s picture

@swentel, my test was just enabling and disabling the devel module. It very well could be module specific if the module does anything extra when it's enabled or disabled. I would hope tho that there wouldn't be any disruption at all - maybe we need even stronger checking of the $cache variable either on the get side or the set side to make the data is legit.

Ya the mean difference is memcache. Still not sure why that matters.

Anonymous’s picture

Priority: Critical » Minor

The comments at #1267966: Pathauto patterns are not showing up helped me. I had an custom module calling drupal_add_js outside a function.

drupalninja99’s picture

@seitenmanufaktur, very interesting bc I have had the exact same issues. We might need to have a sidebar conversation. I will check out your link.

drupalninja99’s picture

I cleared caches today and the problem is still happening. I thought drush cc all worked but it is doing the same thing. I have to run this to get everything to work:

cache_clear_all('ds_fields:', 'cache', TRUE);
cache_clear_all('entity_info:', 'cache', TRUE);
cache_clear_all('theme_registry:', 'cache', TRUE);
cache_clear_all('module_implements', 'cache_bootstrap');

Bc I have these same issues:

- sometimes jQuery doesn't load
- pathautos admin interface is empty
- token is not working properly

I am starting to suspect that DS is a victim and that the victims are many and I can't figure out the root cause.

aschmoe’s picture

Version: 7.x-1.6 » 7.x-2.0

This does not seem to be specific to 7.x-1.x. A similar action to #5 has solved the issue of ds.ds_fields_info.inc not being included.

Frederic wbase’s picture

I can confirm that the solution from #5 is working.
We never had problems with this functionality untill we upgraded from drupal 7.15 to drupal 7.17.
After upgrading to drupal 7.17 and after clearing the cache we had the problem for the first time..

So maybe this issue isen't only related to display suite but also to drupal core or the way the both are working together?

sparker888’s picture

I'm having the problem on 7.16. Haven't updated yet as Acquia hasn't updated...subscribing.

sparker888’s picture

Can you plz raise to critical? Seems to be affecting enough users and patch isn't working. Thx!

swentel’s picture

Status: Needs review » Fixed

Committed both patches re: the language. Why those files aren't included, I have no clue because it doesn't make much sense to have to fix there.

Status: Fixed » Closed (fixed)

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

tjmoyer’s picture

Status: Closed (fixed) » Needs work

This is still an issue in the latest 7.x-1.x version (x). It looks like there's a known issue with hook_hook_info: https://api.drupal.org/comment/23983#comment-23983. And another comment on the hook_hook_info() api page says that this function if for modules that define a hook, not modules that implement a hook: https://api.drupal.org/comment/32908#comment-32908.

I think it makes the most sense to include a like michamilz stated in #5 https://drupal.org/node/1822168#comment-6660256. That works, because otherwise the ds.ds_fields_info.inc file is never included and Drupal doesn't see that DS actually implements the hook.

tjmoyer’s picture

Version: 7.x-2.x-dev » 7.x-1.7
FileSize
461 bytes

Here's the patch implementing the module_load_include() in ds_get_fields() for 7.x.1.x.

swentel’s picture

Version: 7.x-2.0 » 7.x-2.x-dev
Status: Needs work » Needs review

Mm that's not the right fix. I've been experiencing this at work now too where this suddenly popped up, but not for the DS info file but a custom module.
I'm going to debug some more this week. It's a core problem also, but I might figure something out to just let it work.

tjmoyer’s picture

I agree that this seems to be a core issue, as the comment for the hook_hook_info() function says it will automatically load $module.$group.inc. However, if you follow the first link I gave (x) to the link it notes about the core issue here: https://drupal.org/node/977052 you'll find a vigorous discussion of the issue in Drupal 8 and the possibility of backporting a fix to Drupa 7. But the left it last September, marking it as "closed (won't fix)". This may be a core issue, but it doesn't look like they're likely to figure out and implement a fix any time soon.

I think for the time being the best solution is to not rely on hook_hook_info() to find included files but instead to make sure the inc file is included where needed in any module's code that implements such a hook.

swentel’s picture

Version: 7.x-1.7 » 7.x-2.x-dev
Status: Needs review » Closed (cannot reproduce)

And I can't reproduce anymore. I'm going to wait until it pops up again and then try to debug it again.
Note patch in #24 only solves part of the problem.

zmove’s picture

I have the problem on DS 2.6. Tried to changes layout, clean cache, change layout again, clean cache again etc.... I cannot retrieve my custom fields.

zmove’s picture

Issue summary: View changes
Priority: Minor » Major
Status: Closed (cannot reproduce) » Active
Media Crumb’s picture

Not sure why this was closed, but I'm have this issue as well. Everything is load and enabled, but I see NO options for DS besides layouts at the bottom of Manage Display pages.

I have no options to create fields or anything else related to DS. What is going on? Seems like a big deal

aspilicious’s picture

This is annoying... Can you all provide a list of modules + version so we can find the cause of this?
I cannot reproduces and I never could reproduce it.

Also provide some data about php versions, server setup, ....

Can you also try the patch in #24 and tell me if it (partially) solves your problem...

hkirsman’s picture

Had the same issue on 7.x-2.6. #24 works

MsNingrum’s picture

I am using Display Suite 7.x-2.6 and having similar issue, patch #24 does not work for me.
By the way I just found out that one of configurations inside panel overrides the content display, I disable it, and it works now.

rolturn’s picture

Okay, so I have been dealing with this issue for the couple of months; finally happened upon this thread and I have to say #24 works and has been the only thing that I have found to stabilize these pages. I have found other treads around this issue and will share this page with them. Thank you tjmoyer!

adriancotter’s picture

I was having this self-same issue. I tried #24 it did not work for me. However, in playing with it, I noticed that the same problem occurred in the regular display -- but only after I had moved all my fields into what I thought was the proper place.

It turns out that the offending module was not DS, but conditional fields -- the dependee field needs to be present in the manage display in order for the dependent field to show up. See this issue.

The lesson: your problem may not necessarily lie in DS. The first thing to do in troubleshooting would be to change the display back to "normal" and rearrange the fields to be displayed (or not) as you had it on DS. If the problem is still occurring then you'll have to look elsewhere.

alexkb’s picture

Using Display Suite 2.6 and the latest Drupal core 7.26 we had the exact same problem as drupalninja99. #24 fixes the title and other fields not showing in the "manage display" tab. Also had to do a "drush cc all" before the changes took affect.

Also, if I use the clear cache tool via the admin menu, I get all sorts of weird results that appear to be javascript related - so I don't think that problem is Display Suite's fault.

mvwensen’s picture

Same issue here, several fields just disappeared. Tried to clear caches, run cron, removed and readded the view-modes but none of it worked.
The fix in comment #24 works for me too after a cache clear.

JJmonterey’s picture

I'm not sure that this addresses all the above concerns but if the field(s) are being generated by another module such as locations they will not appear in a DS manage display layout unless they are enabled under the "Enable Extra Fields" screen. Also if somehow the bundle (machine name) is renamed, it must be changed on the same screen. Attached screenshot. I spent a couple of hours sorting this out when using the location module and the fields would not show up when using a DS layout.

aspilicious’s picture

Status: Active » Fixed

This issue has become a garbage bin of different issues :D
#24 worked for some people (I have no clue why) but I added it as it doesn't hurt.

Thnx for all comments!

Status: Fixed » Closed (fixed)

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

aschmoe’s picture

Status: Closed (fixed) » Needs review

Re-opening as this issue is not fixed.

This issue has become a garbage bin of different issues :D

Absolutely agree, can we focus on "needs review" for #24, as this also solved the issue for me. Should probably re-roll the patch as well.

aspilicious’s picture

Status: Needs review » Fixed

#24 worked for some people (I have no clue why) but I added it as it doesn't hurt.

This is part of the dev release

aspilicious’s picture

Status: Fixed » Closed (fixed)