Picture
Jon Skulski Senior Drupal Architect
June 27, 2011

One of difficulties of Drupal is the fragmentation of administration interfaces. Chapter Three addresses this difficulty by customizing the administration experience by championing the Panels as The Administrative Interface.

A Real World Example

Note: I wasn't able to record audio to this video, the 'click track' is a bug from my video capturing software. The video shows me changing the view's style plugin via a customized Panels interface. One of our clients wanted the ability to decide if their data would show in a one, two, or three column display. We had three options:

  1. Train the user on the Views to change the display setting to grid
  2. Make more view displays to go with the options (requiring more than 50 displays, in this case)
  3. Customize the administration process to allow this feature

On this particular project, option three was the right choice. We were already exposing the Panels interface, so we could reuse what we already had. We decided to change the view based on a panel setting.

Three Easy Steps

  1. Make sure you have Content Pane view displays to play with
  2. Use hook_form_alter() to offer the option in the Panels settings form
  3. Use Views' alter hooks to pragmatically change the view depending on the options

1. Creating Content Panes

Creating content panes is out of the scope of this post, but it’s easy. The cool kids at Node One have a video tutorial walking you through the process.

2. Offering The Option

This step is a straight forward use of hook_form_alter(); 'select', '#options' => array( 1 => t('1 Column'), 2 => t('2 Columns'), 3 => t('3 Columns') ), '#default_value' => $conf['view-columns'] ? $conf['view-columns'] : 1, ); // Add our submit handler to capture our option $form['#submit'][] = 'c3_example_views_content_views_pane_submit'; break; } } ?> We also need to make sure we are storing our option in pane configurations:

3. Changing the View

Now we act upon the set options. The life stages of a view are handy to know:

  • Initialize sets up the the view object
  • Build builds the query
  • Execute executes the query
  • Render renders the results into HTML

Views follows the Drupal event model and allows modules to alter the view during this lifecycle. Depending on the options you are supplying, you figure out where in the lifecycle you want to change the view. Anything you can do in the Views UI is programmatically possible. Any option in the Views UI can be exposed to your client. In our example, our column option doesn’t change the SQL query so we can interrupt the view after it has been executed but before HTML is rendered. We write code that programmatically sets the view style to Grid and sets the number of columns. You’ll notice that we have access to the pane configuration in $view->display_handler->options[‘pane_conf’]. That is what using Content Panes display type gives us. display_handler->options['pane_conf']; // Now change our view based on the pane configuration // In the case, we set the display plugin to ‘Grid’ and set the appropriate number of columns if ($conf[‘view-columns’] > 1) { // We have to reset the style_plugin since init_style() has already been called. // TODO: There maybe a more appropriate place to attach to alter the view. unset($view->plugin_name); unset($view->style_plugin); $view->display_handler->set_option('style_plugin', 'grid'); $view->display_handler->set_option('style_options', array('columns' => $conf['view-columns'])); $view->init_style(); } } ?> This is just one example of what you can do with Panels setting interface. We really like the one-to-one metaphor of Panels and Panels In Place Editor. We think it's smart, accessible and the future of website building.