cannot track view with features

Question

I'm using Features to create a feature called foo which tracks content types and views so they can be described in code, committed to my repository and eventually pushed into the staging and production servers.

Some modules (e.g http://drupal.org/project/nodequeue, http://drupal.org/project/views_bulk_operations, http://drupal.org/project/admin_views) create some views as part of their functionality. The problem is that I can't include those views into my foo feature. So for those specific views I have to repeat (by hand) any customization I did locally to the staging and production servers.

Any ideas?

What I've tried:

1) I tried manually adding the view name in the foo_features.info file:

features[views_view][] = admin_content_node

but when I do drush fu foo_features -y that line is removed and the .info file and the view definition is not being included in the foo_features.views_default.inc file.

2) I had a look into the database:

mysql> select vid, id, display_title, display_plugin, position from views_display;
+-----+----------+---------------+----------------+----------+
| vid | id       | display_title | display_plugin | position |
+-----+----------+---------------+----------------+----------+
|   3 | default  | Master        | default        |        1 |
|   3 | page     | Page          | page           |        2 |
|  30 | block    | Block         | block          |        2 |
...
|  46 | default  | Defaults      | default        |        1 |
|  46 | system_1 | System        | system         |        2 |
+-----+----------+---------------+----------------+----------+

That last row (vid: 46, display_plugin: system) seemed suspicious so I've changed (directly via SQL) system to page. I then did drush cc all and retried the process at [1] for including the view into the feature but without luck. I tried this because I thought that "system view displays" (whatever that means) cannot be included in features.

Answer 1

This is bypassable by cloning the views you need from the four views that the module provides, disabling the original views, and doing all your work in your clones which are 100% trackable.

Answer 2

As suggested by magtak, this is circumventable by cloning the Views. They will need to be stored under a different name for this to work; exporting and importing a View (as suggested by Varshith) will only work if you do so while changing the machine name of the View. Cloning will have the same result as export/import, except that it will enforce the machine name change, and encompasses less actions.

The reason you need to do this is that these modules add Views not by entering them into the database, but adding them through code, much like what happens when you add a View to a Feature. Features will check if a View already exists in code and will not offer it for adding it to your Feature if it does. (Incidentally, what happens when you change a View that is defined by code through the interface, is that Views takes a copy of the View and enters it into the database. That's where it stores your changes. This is why you might find Views defined by modules in the database anyway; this would happen the moment you make changes to them. This is also what happens when you revert an overriden View, either from Views itself or from Features; the copy in the database is ditched and Views defaults back to the code).

One downside to the clone approach is that from that moment on, you are on your own maintaining the View that was originally added by the module; your clone is completely independent of the original, so if there are module updates that add nifty new features, you'd probably not find out. If you did, you'd have to add those changes to your clone by hand. An alternative is using hook_views_default_views_alter() to add your additions in code. However, this is completely unsupported by Features (you can add this code to a Feature; if you do so in the .module file for the Feature, Features will leave it alone when regenerating the feature). You will need to know what you are doing defining Views in code by hand. You can get a long way by comparing an export of your customized View with the original code in the module (which would be found in themodule.views_default.inc), but it is still not for the faint hearted (and may turn out to be less maintainable than just doing the clone thing).

As an aside, for Nodequeue you can certainly use the Views it adds by default, but it is hardly worth the effort to go and clone a nodequeue View. All it is is a View of Nodes, with a mandatory relation on the nodequeue, sorted by the nodequeue weight. It is probably about the same effort starting from scratch as it is cloning the default View and then making your changes.

Answer 3

I am having a similar issue too. What I am doing currently is exporting the views I need one by one and import it back and then create the feature so that you can include them as well.

Answer 4

I'm a little late to the party, but FYI, you may have luck getting it in Features if you uncheck "Automatically create one view per queue" on the Nodequeue settings page /admin/structure/nodequeue/settings then go back to Features and try to Recreate again.

Also, track that you unchecked that checkbox in Features. If you forget to uncheck it on prod, it won't work right.