I’m trying to script the creation of a View such that when the client runs a build script the views are programmatically created. I’ve had success doing this with other modules but am having issues with Views. Any ideas if this can be done? Currently I’m trying:
$values = array();
$values['name'] = 'test';
$values['page_type'] = 'node';
$values['use_pager'] = '1';
$values['nodes_per_page'] = '10';
$values['page_header_format'] = '1';
$values['page_footer_format'] = '1';
$values['page_empty_format'] = '1';
$values['menu_tab_default_parent_type'] = 'tab';
$values['block_type'] = 'node';
$values['block_header_format'] = '1';
$values['block_footer_format'] = '1';
$values['block_empty_format'] = '1';
$values['field[add][id]'] = 'comments.subject';
$values['argument[add][id]'] = 'node_feed';
$values['filter[add][id]'] = 'comments.status';
$values['sort[add][id]'] = 'comments.timestamp';
$values['field[count]'] = '0';
$values['argument[count]'] = '0';
$values['filter[count]'] = '0';
$values['sort[count]'] = '0';
$values['exposed_filter[count]'] = '0';
$values['op'] = 'Save';
$values['form_token'] = '2820b7b619d6c9b0fd335c53ff2e093b';
$values['form_id'] = 'views_edit_view';
drupal_execute('views_edit_view', $values);

Any pointers would be helpful...

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Fixed

Yea. Don't go through the form. That is an exercise in pain.

And don't even put them in the database.

Just provide a module that provides default, exported views.

If you do need them truly dynamic and default views don't work for you (and default views can be dynamic as well; you can modify the view object itself) then at worst I recommend creating a $view object and running it through views_save_view().

byelle’s picture

byelle commented

Merlin,
Thank you for the pointer. I was in the process of trying _views_save_view() when I received your suggestion. That got me half the way there. I also had to call views_sanitize_view() immediately before save. So now, in my build script, I have:

$view = new stdClass();
$view->name = 'Talent';
$view->description = '';
$view->access = array ();
$view->view_args_php = '';
$view->page = TRUE;
....etc....
$view->exposed_filter = array ();
$view->requires = array(node);
$views[$view->name] = $view;

views_sanitize_view($view);
_views_save_view($view);

This appears to work correctly. Thank you again.

merlinofchaos’s picture

merlinofchaos commented

I still think, if at all possible, it is preferable to keep your views in code as default views, and not in the database. So I would highly recommend providing them in a module if you can.

byelle’s picture

byelle commented

Merlin,
I'm not sure I see the advantage of what you're suggesting...but I've only been using Drupal for a month and you're clearly very involved so it may be that I'm not explaining myself well...or I just don't understand the advantages of what you suggest. What I've been working on is a build script that if the DB was completely lost could be used to recreate the site sans content. So essentially, it starts by enabling modules, adding node types, roles, etc..., then creates the views. At this point I've used the export function to create the view objects and am now using the above code to recreate them on demand.

merlinofchaos’s picture

merlinofchaos commented

Right. What I'm saying is that Views has the ability to operate without the views ever being in the database.

So take a look at your basic views administration screen. Below the views you've created or imported, there are a list of default views. It should include at least 'frontpage', 'tracker' and 'taxonomy_term'.

Those views aren't in the database at all. They are provided by the views.module implementhing hook_views_default_views() which just returns an array of exported view objects.

Similarly, any module can provide default views, and many modules do, because it's quite easy to maintain this. When working on a site where you're concerned about the database, this is a very handy feature. Also, it saves you the effort of having to even bother putting your Views in the database at all.

And if you modify your views, they'll be put into the database...you can then re-export the view, put the updated view in code, and then remove it from the database.

Now, views don't have to be just exported objects. For example, the 'nodequeue' module creates a default view for every node queue it has; they're based on a template with only the changes needed for each queue (title, description, queue id; not much else needs to change). So you have lots of flexibility in making your views available...and the database never needs to be touched.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

DeeZone’s picture

DeeZone commented

Mr. Miles,

For what it's worth, your taking the time to explain this concept back in 2008 has helped myself and I suspect a pile of other who have come before me years later (2010). I just wanted to post a quick note to say "thanks" and hope that you continue to feel inspired to add goodwill like this to the Drupal community.