Managing Drupal Views, the proper way
One of the most powerful and most useful modules on Drupal is Views. With one screen you can build custom pages & blocks based around your content, select the exact fields you need, add filters and arguments, and relatively easily customize the display, and that's just scratching the surface. In fact, Views is so flexible that I've built sites which have 90% of their architecture based solely around taxonomies and Views.
The main trick to making using Views manageable is to save them out as files and load them through a module. It sounds really easy, and it is really, but there's a few steps to it.
The first step is to have a per-site module specially for holding these kinds of things, a general bucket for your random chaos.

The second step is to go to each View in turn and export it to a file in your new module's directory. To do that, go to your site's Views list page and for each of the custom ones you've built or modified, click the Export link next to it to bring you to a page with the view's code listed out:
What you need to do next is save this text out to a file. By default all of the text is selected, but you're not ready for that yet. You first need to create the file to store the text. I like to use the following filename structure:
view.[viewname].inc
This both groups all views together and makes them easy to identify at a quick glance. Going by this, the above view would be saved with the filename:
view.taxonomy_term.inc
Now, just copy all of the code from the Export page into the newly created file. Simple, huh? Well, there's a little gotcha - you need to add "<?php" to the top of the file otherwise the next steps won't work right, e.g.:

Well, we're not done yet, we still have to tell the site that there are views in this new module. This involves two further steps..
The first part is to tell the system that this module uses the Views API by adding some lines to your module:

The last part is to load the views into the system. To do this you must add another file to your module directory named:
[modulename].views_default.inc
Then add the following to the file:

And now you're done!
Well, almost. Your site is still going to load the view that's already in your database rather than the one in your module. To fix this just go back to the main Views list page, find the view you just exported and click the "Revert" link to revert it from the database-stored version to what was in your file; don't be afraid when it says "Are you sure you want to revert the view?" because yes, that's what you want to do. So do it.
And now you really are done. Enjoy. And make sure you save it into your site's SVN server promptly.
Learning Exercise:
To make more of this, and to test your PHP skills, try changing funkychicken_views_default_views() to automatically load all files named 'view.[something].inc' instead of having to manually list each one.

Delicious
Digg
Reddit
Facebook
Google
Yahoo
Technorati
Comments
5 comments postedThanks for the info Damien. I'm still learning Drupal and your tips is highly appreciated...I could surely use them and add them to my knowledge, and I do agree with you when you said that the most useful and powerful modules on Drupal is Views.
Great tutorial. Exporting views into a module is essential for smooth deployment.
I am thinking that I will implement my module in a very similar fashion as you have outlined, but I will have the _views_default_views function loop through all .inc files which start with 'views.' so that I don't have to manually write in the include every time I export a new view into code.
Also, I think it would be better if you post your code samples as code instead of screenshots.
HI,
I have implemented this thing long time ago.. but now days am working on performance optimization and while looking at queries i am continenously getting this query "SELECT * FROM views_view WHERE name = ?" which means whether we have views declared in files or DB still we cannot reduce no. of query as mentioned above.
or i am doing some thing wrong.. technically views should not look in to DB table to get details of any view because that table is empty as all views were declared in my views module.. any thoughts?
My biggest disappointment with the Ipad was that I didn't have full access to edit views. I could access all the major areas and could edit a view if it existed but if I tried to create a view I couldn't access all options available. Anything that required me to scroll through a list was out. So I could select the first few node options but not anything past the first screen. That really bugs me.
@anonymous, I haven't noticed that, but I haven't specifically looked either. It sounds like it is checking to see if there are any overridden views to match the one that is loaded via the default_views hook. Do you have caching enabled on your site?
Post new comment