This module is really awesome. I wanted to put forth the idea to make the Admin Views views exportable via features.
If the module is supposed to already support export via Features, then this is what I am getting (and should be retagged as a bug, or PEBCAC!).
If I attempt to add the view into a feature via UI, it shows that it is added by dependency and also adds in the dependency on admin_views, which is correct. However, saving the Feature at this point, the view does not get added, just the dependency.
The same thing happens if I run via drush: drush fe my_module views_view:admin_views_comment
The feedback from drush is that the export was successful, but like the UI export, it does not have the views file.
Thanks
Comments
Comment #1
damiankloip commentedThis module only provides default views, so this works no differently to any other view export. So this is equivalent to you creating a feature with view_x in, then creating another feature with view_x in....
I think the problem you are facing is that you are trying to re export the default views provided by admin views into a feature, which is exactly the same as bulk export etc...
So essentially you just have 2 view with the same machine names in code - So which ever module is called last will get the code export in the listing.
So basically, your problem is here, in features.ctools.inc
Comment #2
damiankloip commentedComment #3
bkonetzny commentedSo, it's impossible to export a modified view which has a default in code? How would one provide a modified version of the users admin_view via features? Will duplicating the view with a different machine-name work?
Comment #4
dazz commentedYou can create a clone of the default view, give it another name/machine-name and make the changes in the new view.
Just disable the default view to avoid conflicts.
You can add your custom view to a feature, don't forget to add the admin_views module as a dependency or your view won't work. It needs the admin_views for the System display plugin.
It would be nice addition to the module to be able to only enable the System display plugin so you can create your custom views.
Comment #5
damiankloip commentedWe could potentially have a setting to disable all default views... I have been contemplating the idea of that for a while OR... Just splitting the views plugins from the default views into 2 separate modules.
Comment #6
attiks commented#4 is right, clone the view and disable the original one. You can disable it using an install hook like this
Comment #7
himynameisseb commentedYou can use the following hook to update an admin view in code. HOOK_views_default_views_alter().
Your hook will override the admin view. Here are the steps I used to create my admin view:
1. Create a new module
2. Add the hook to the module
3. Update the admin view via the views page
4. Save the updated view
5. Click 'export view' (from the selection arrow at the top right of the view).
6. Copy ALL display settings for the view display from the export array EXCEPT the line that creates the display. Example below
7. Get display handler data ready to update. (Included in below example)
8. Add this to you hook
9. Wrap your hook in a check for that display (to stop any errors if the display does not exist). Example of hook is below
10. Repeat for all displays.
I hope this helps someone.
Comment #8
david.czinege commentedThank you sebanthony. Your code above is working for me.
I added one more row to the code, because when i added new fields to the views, and i rearraged them, the alter hook put the fields at the end of the fields list.
I wrote this row:
$handler->display->display_options = array();
after this:
$handler = $views['admin_views_node']->display['default']->handler;
Comment #9
leewoodman commented#4 worked for me and i included the update hook from #6...
Comment #10
Steff1985 commented#4 Worked for me.
Thank you !
Comment #11
amfranco commentedBefore install admin_views you can edit the files in admin_views_default folder, only changing one line: $view->disabled = FALSE; to $view->disabled = TRUE;
Then, install admin_views, clon the view and now you can export the view using features (remember, add the admin_views module as a dependency).
Comment #12
juampynr commentedThis worked for me and seems to be solid. Please correct me if I am wrong:
1. Disable admin views (user, nodes and files) through the web interface.
2. Clone them (the clones will be active by default).
3. Make all the adjustments that you need to these views.
4. Export these views to code with Features module.
5. Implement the following hook in the .module file of the module where you exported the cloned views:
6. When you push or pull this code to another environment, make sure that you do
drush updatedb && drush fra --yes && drush cc all.Comment #13
ladybug_3777 commentedjuampynr - I assume you intended for this hook to be added to my exported feature .module file and not added to a different custom module?
When I did that the view was not disabled automatically on the other environment, even after running the drush commands. In fact I encountered some strange user errors after enabling the feature.
For now I'm going to have to manually disable the view on the environment I'm moving to.
I'd love to see what was talked about in comment #5 be added as a new option. I think that would make the most sense and would be easier to use.
Comment #14
mrpauldriver commentedAgree with #13. It would good if there was an option to export modified views via features.
Comment #15
marcoka commented#7 works perfect. thank you for this detailed instruction.
Comment #16
markie commentedSo I tried #7 so I could add some filters. Alas, when I view /admin/content it still shows the default. Any ideas? I have tried clearing cache multiple times. (my function is not really called MYMODULE.. that's just to keep the client happy)
Comment #17
michaellenahan commented@markie I had a similar same problem to your one. My hook_views_default_views_alter() function was not being called.
In my case, I think it was to do with the module name.
At first I had:
zs_admin_viewsas the module name. This did not work.When I renamed my module to
zs_adminviewswhich is far less pretty, it worked.So, with:
... the function was not being called.
However, when I renamed the module, this function is being called:
Comment #18
RAWDESK commentedSame problem as #16 and #17
Sk8erPeter explained at this stackexchange a bit why it 's not working.
Therefore followed the offered alternative and implemented it inside a hook_update_N() inside a custom .install file :
As such it become part of the upgrade path and lifecycle of our application, rather then being hosted by a feature.
Not ideal, but in attendance of a contrib solution, an acceptable alternative i believe.