0

Problem: I'm trying to add Views Filters to this display, but I cannot see any of the fields attached to this Content Type.

Question: How may I create exposed filters on these two fields Showcase City and Showcase Field (shown below) if views does not see them? How do I begin to debug a situation like this?

Managed Fields tab of Content Type enter image description here

Manage Display tab of the Content Type: Manage Fields tab of the Content Type

But I cannot see them as options in Views...

Filtered for all Content Fields: enter image description here

I also attempted to package them into a Feature to move along the Dev-Stage-Prod chain: enter image description here

Updates based on additional information from answers or comments

Based on a suggestion below I created the following hook:

/**
 * Implements hook_field_views_data_alter().
 */
function debug_field_views_data_alter(&$result, $field, $module) {

  $string = implode(',', array_keys($result));
  $filtered = strstr($string, 'showcase_headshot');

  if (strlen($filtered) > 1) {
    //dsm($filtered);
    dsm($field);
  }
}

Which allowed me to see this: enter image description here

jQuery Update Module settings:

enter image description here

Export of the view:

$view = new view();
$view->name = 'nominal_showcase';
$view->description = '';
$view->tag = 'default';
$view->base_table = 'node';
$view->human_name = 'nominal Showcase';
$view->core = 7;
$view->api_version = '3.0';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Master */
$handler = $view->new_display('default', 'Master', 'default');
$handler->display->display_options['css_class'] = 'theatre-nominal-showcase-wrapper';
$handler->display->display_options['use_more_always'] = FALSE;
$handler->display->display_options['access']['type'] = 'perm';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['pager']['options']['items_per_page'] = '12';
$handler->display->display_options['pager']['options']['offset'] = '0';
$handler->display->display_options['pager']['options']['id'] = '0';
$handler->display->display_options['pager']['options']['quantity'] = '9';
$handler->display->display_options['style_plugin'] = 'default';
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Content: Title */
$handler->display->display_options['fields']['title']['id'] = 'title';
$handler->display->display_options['fields']['title']['table'] = 'node';
$handler->display->display_options['fields']['title']['field'] = 'title';
$handler->display->display_options['fields']['title']['label'] = '';
$handler->display->display_options['fields']['title']['alter']['word_boundary'] = FALSE;
$handler->display->display_options['fields']['title']['alter']['ellipsis'] = FALSE;
/* Sort criterion: Content: Post date */
$handler->display->display_options['sorts']['created']['id'] = 'created';
$handler->display->display_options['sorts']['created']['table'] = 'node';
$handler->display->display_options['sorts']['created']['field'] = 'created';
$handler->display->display_options['sorts']['created']['order'] = 'DESC';
/* Sort criterion: Content: Title */
$handler->display->display_options['sorts']['title']['id'] = 'title';
$handler->display->display_options['sorts']['title']['table'] = 'node';
$handler->display->display_options['sorts']['title']['field'] = 'title';
/* Filter criterion: Content: Published */
$handler->display->display_options['filters']['status']['id'] = 'status';
$handler->display->display_options['filters']['status']['table'] = 'node';
$handler->display->display_options['filters']['status']['field'] = 'status';
$handler->display->display_options['filters']['status']['value'] = 1;
$handler->display->display_options['filters']['status']['group'] = 1;
$handler->display->display_options['filters']['status']['expose']['operator'] = FALSE;
/* Filter criterion: Content: Type */
$handler->display->display_options['filters']['type']['id'] = 'type';
$handler->display->display_options['filters']['type']['table'] = 'node';
$handler->display->display_options['filters']['type']['field'] = 'type';
$handler->display->display_options['filters']['type']['value'] = array(
  'nominal_showcase_page' => 'nominal_showcase_page',
);

/* Display: nominal Showcase Block */
$handler = $view->new_display('block', 'nominal Showcase Block', 'block_1');
  • 1
    What module is providing those fields? – Alfred Armstrong Feb 9 '15 at 17:10
  • @AlfredArmstrong, This was a new Content Type that I created. I am trying to transfer it up through dev-stage-prod via features. – Rick Feb 9 '15 at 21:17
  • 1
    I think you misunderstood my question: what field type(s) are they? – Alfred Armstrong Feb 10 '15 at 9:42
  • 1
    OK, thanks. In that case it looks like there is indeed a problem when views data is being built. I was wondering if these field types were ones from a contrib module that might not have full views support but that is not the case. – Alfred Armstrong Feb 10 '15 at 15:59
  • 1
    can you post the export code of your view. I would like to take a look at it. – No Sssweat Feb 11 '15 at 2:46
1
+50

If you're running on a dev environment which uses memcached for caching then views can occasionally not display all the fields because of caching issues.

Possible solutions are to:

  1. Set: $conf['cache_class_cache_views'] = 'DrupalDatabaseCache';

This means views will no longer use memcached for a cache bin.

  1. In views Views 7.x-3.7+ disable views data caching in the advanced menus.

This will probably heavily impact your performance if you're relying on views caching.

  1. Run the older memcache extension instead of memcached.

This was the solution I ended up using by accident because I was already running memcache and so managed to avoid the issue on my live machine and only run into it on my dev machine.

The Drupal thread is here.

|improve this answer|||||
  • Specifically Number #2 – Rick Feb 11 '15 at 21:44
  • Glad it helped, if you find it's hitting performance and still want to stick with solution two, you can turn views caching back on when you've finished dev. Only editing the view seems to cause the errors (although I'm not entirely sure why). – Dominic Woodman Feb 11 '15 at 22:01
  • The beautiful part.. This is a dev machine. I build here, package in features, and upon a successful test-deploy on stage, only then does it go to Production. I'm not too concerned with speed on this particular box. Thanks again! – Rick Feb 16 '15 at 19:21
1

Data about eligible fields is compiled and cached by Views using hook_views_data() and hook_views_data_alter().

Since your "Content:" group is showing only base properties and no fields at all, that leads me to believe that the problem you're seeing happened during the views_data compile process.

Views module implements "field_views_data()" on behalf of Field module to read that information. That would be a good place to start debugging. Put debug breakpoints or dpm() calls inside that function and clear all caches, then revisit the edit interface for the view. See if you can figure out why the function may not be returning any $data.

|improve this answer|||||
  • Thanks for the suggestion. Upvoted. To clarify, should I create a throw away module with hook_field_views_data() { dpm($data)}? – Rick Feb 10 '15 at 15:56
  • hook_views_data() doesn't get passed a $data parameter, but that would work in hook_views_data_alter(). I was actually saying that you could add that code directly in that Views function, though. Temporarily hacking core or contrib is perfectly fine for debugging purposes (as long as you put everything back the way it was when you're done). – Les Lim Feb 10 '15 at 19:08
  • Oh, you were asking about hook_field_views_data() -- that's a different hook, and not the one that would give you the correct information, I think. – Les Lim Feb 10 '15 at 19:11
1

Any chance that there's some jquery bug involved here? I remember times, when just things like that happened with the wrong jquery version...

https://www.drupal.org/node/1869988

|improve this answer|||||
  • Nice thought. Upvote. I am running jQuery Update with the Default jQuery version at 1.10 and Admin running at "Default jQuery Version". – Rick Feb 10 '15 at 21:46
  • Please try a lower version for the admin theme. With your settings my Views UI isn't usable... – Volker Feb 10 '15 at 21:56
  • 1
    @rgchi If you set JQuery version for admin as 'Default jQuery Version", that means it is the same as the version set for default, which in your case 1.10. Views UI doens't work well with newer jQuery versions. Try to set it to a lower version for Admin. – Елин Й. Feb 11 '15 at 8:59
  • @ЕлинЙ. -- Would you recommend either '1.5' or 'Drupal Default Version'? – Rick Feb 11 '15 at 19:39
  • I'd start with 1.5 and stepwise try higher versions for the admin theme. Try also to lower the Jquery version itself, unless you absolutely need 1.10... – Volker Feb 11 '15 at 20:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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