Problem/Motivation

I have a couple Views that I may need down the road. I disabled them to keep them in the Feature I created. I went to check the Feature, expecting it to be overridden with the disabled Views, and it was not.

Proposed resolution

Make Features aware of disabling a View and export it out in the code of the Feature.

Remaining tasks

Patch needed

User interface changes

Mark the Feature as overridden if a Feature contains any View that has been disabled.

API changes

None proposed.

I did not find any when searching.

Comments

komlenic’s picture

If you edit my_feature.views_default.inc, I believe you can set the view to be disabled. There are comments that say "Edit this to true to make a default view disabled initially" next to $view->disabled = FALSE;

Functionally, it would seem that the expected behavior would be as the original poster describes. Is there a historic or logical reason why Features does not track the enabled/disabled state of a view?

steinmb’s picture

Title: Features 7.x-1.0 does not export disabling a View » Features does not export enabled/disabled state a View
Version: 7.x-1.0 » 7.x-2.x-dev
Category: bug » feature
Priority: Minor » Normal

Editing $view->disabled = FALSE; changes nothing. I'm I missing something here or is it really not supported?

steinmb’s picture

Category: feature » support

Never mind. These settings is stored in the variables table. You need strongarm and then you can control disabled/enabled state and other suff belonging to Views. Here is a paste from my info file in case anyone is interested.

dependencies[] = ctools
dependencies[] = strongarm
dependencies[] = views
features[ctools][] = strongarm:strongarm:1
features[ctools][] = views:views_default:3.0
features[features_api][] = api:2
features[variable][] = views_block_hashes
features[variable][] = views_defaults
features[variable][] = views_devel_output
features[variable][] = views_devel_region
features[variable][] = views_exposed_filter_any_label
features[variable][] = views_no_javascript
features[variable][] = views_show_additional_queries
features[variable][] = views_skip_cache
features[variable][] = views_sql_signature
features[variable][] = views_ui_always_live_preview
features[variable][] = views_ui_custom_theme
features[variable][] = views_ui_disable_live_preview
features[variable][] = views_ui_display_embed
features[variable][] = views_ui_show_advanced_column
features[variable][] = views_ui_show_advanced_help_warning
features[variable][] = views_ui_show_listing_filters
features[variable][] = views_ui_show_master_display
features[variable][] = views_ui_show_performance_statistics
features[variable][] = views_ui_show_preview_information
features[variable][] = views_ui_show_sql_query
features[variable][] = views_ui_show_sql_query_where
mpotter’s picture

Status: Active » Closed (works as designed)

Also, just a reminder that Features does not control the exported data...that is controlled by the module itself (in this case, Views).

tunprog’s picture

Issue summary: View changes

You can disable views programmatically in D7 like this:

/**
 * Disable nodes and comments views.
 */
function YOUR_MODULE_update_7000() {
  // A list of views to be disabled
  $viewnames = array(
    'admin_views_node',
    'admin_views_comment',
  );
  // Grab the list of views that are already disabled
  $views_status = variable_get('views_defaults', array());
  // Add our views to the list
  foreach ($viewnames as $key => $viewname) {
    $views_status[$viewname] = TRUE;
  }
  // Reset the variable with the new list
  variable_set('views_defaults', $views_status);
  // Empty cache
  if (function_exists('views_invalidate_cache')) {
    views_invalidate_cache();
  }
}
donquixote’s picture

The hook_update_N() has the advantage that it can target a specific view instead of exporting the full list.
This way it can be handled from a dedicated feature which only contains this one view.

The strongarm would have to be in a centralized / global feature.