Drupalcamp 2016

Dynamic Portal Construction

User configurable listings

Carlos Carrascal - @ccarrascal77
[ ccarras6@its.jnj.com ] [ carlos.carrascal@gmail.com ]

johnson & johnson EMEA Development Center


  1. Introduction
  2. Automated lists
  3. Filtered lists
  4. Exposed filters for users
  5. Configurable exposed filters
  6. Thanks
  7. Questions?
  8. End of line

00. Introduction

  • 00.1 Who am I
  • 00.2 What are we going to do
  • 00.3 Why?
  • 00.4 One last thing

00.1Who am I

Carlos Carrascal Sánchez
[ ccarras6@its.jnj.com ] [ carlos.carrascal@gmail.com ]
[ http://www.carloscarrascal.com ]

Web developer

I have been working in IT since 1998, in different companies:

  • Coritel / Accenture
  • qarana solutions
  • Azertia
  • Indra

Mostly in Spain

Spain is cool

Usually doing web development or CMS related, mostly with Open Source tools and GNU / Linux

00.2 What are we going to do

We will develop a system that will allow our content editors, without any technical knowledge, to be able to create pages with lists in a simple and intuitive way, and with some degree of customization.

And more specifically:

We will use nodes that will display views showing other nodes, apply filters by content types, taxonomy terms, or any field values in those nodes.


Using the following components:

  • One content type to be listed: Plain and simple nodes (news, articles, etc.)
  • Another content type implementing the list: We will call it "X List" (Article list)
  • View: To display the nodes to be listed.
  • Context: Will relate the "X Listing" with the appropiate View
  • Feature: Used to glue all components together and have some code in the .module file

What do we need

A Drupal 7 install with these modules:

  • Views: For listing creation.
  • Context: For node and view association.
  • Features: For packaging our components.
  • Display Suite: Is not mandatory, but highly recommended.

00.3 Why?

Some advantanges are:

  • Managing content in the list pages: Our listings will be nodes, so we can use them the same way as any other content in our site, adding text, blocks, contexts, panels, etc.
  • Multilanguage: We can translate the content, the URL, fields, metatags, etc. We can also control if they will appear at all in a given language or not.
  • Simplify content management to the editors: It is easier for non-technical users manage listings in the way as any other page. We will also avoid lots of troubles by keeping those users away from view configuration.
  • Reduce number of views: For most projects this method will require to develop less views, so our project will be easier to support.
  • Increase quality: Or at least the perceived quality, by having sort options and filters by default in most listings.

00.4 One last thing

There is a contributed module to do almost the same thing that we are going to do by hand.


I would recommend to try it for something simple and easy, but for a bigger project, doing it ourselves will provide more customization.

Ok, ok ...

01. Automated listings

  • 01.1 Nodes and views
  • 01.2 Listed elements content type
  • 01.3 Listing content type
  • 01.4 The view
  • 01.5 The context
  • 01.6 Example

01.1 Nodes and views

Drupal has two basic functionalities for displaying content:

  • Content Construction Kit (CCK) used to manage content types, included in Drupal 7 core
  • Views used to manage listings, included in Drupal 8 core, availiable as a module for Drupal 7

Traditionally, content display is handled and developed separately from the content lists.

Views configuration usually is far too complex for any user without technical knowledge.

We are trying to ease content management, allowing the editors to create listings by creating a special type of node, that will include a relevant list automatically.

01.2 Listed elements content type

First thing to create will be the content type that we want to show in the list.

For example we could use Article, from the default Drupal installation.

We can add and configure as many fields as we need in this content type.

For now, there is no other special feature that we need to consider for this content type.

If we are using Display Suite, we will configure at least two modes:

  • Teaser: For listings.
  • Default: For full page display.

01.3 Listing content type

This is the content type used to display the list. As we are listing Articles, we could name it Article Listing.

For now we don't need to add any special field to this content type. We can have a Body field or not, if we want our lists to include some text.

Example: Content type Article Listing with default fields.

If we are using Display Suite, we will only need to enable Defautl or Full content modes, for the full node view.

It may be interesting to disable the option "Show in home page".

01.4 The view

Now we will create the view to display the actual list. In our example, it will list nodes of Article type.

  • Set the content type to display to Article.
  • Sort by creation date (or whatever)
  • Create a Block view. It won't be necessary to create a Page view type.
  • If we are using Display Suite, select Teaser mode to display the nodes.
  • We could configure any other options needed, as a pager.

Block view for Article content type.

01.5 The context

At last, we will use a Context to tie together the view and the Article listing node.

  • Select Content Type as condition, and set Article listing.
  • Remember to unset the Set on node form option, to keep it from activate on node edit.
  • Activate Blocks reaction in the context.
  • Add the view block, for the view that we have created in the last step, in the desired region.

Context conditions to associate the view with the content type Article listing.

Context reactions for displaying the view into the Article listing content type.

Now, whenever an Article listing node is displayed, our new context will include the view in the desired region of our theme as a block. If we have a Content bottom region, for example, we can have the list below the node content.

01.6 Example

List of nodes of Article type

02. Filtered lists

  • 02.1 Taxonomy
  • 02.2 Contents: Term reference
  • 02.3 List: Term reference
  • 02.4 View: Contextual filter
  • 02.5 Examples

02.1 Taxonomy

To be able to create a filter for our list, we are going to create a taxonomy filter.

We will include term references in both the contents that we want to list and the listing nodes.

We will use the default Tags taxonomy.

02.2 Contents: Term reference

Include a Term reference field in the Article content type, so we can filter them using the view.

We can configure the field with single or multiple values, autocomplete, check boxes, etc.

There is no mistery in adding a field to a content type.

02.3List: Term reference

We will also include a Term reference field in the Article listing content type, to use it as filter criteria.

Again, we can configure the field with single or multiple values, autocomplete, check boxes, or whatever.

No mistery here either, we have already seen this.

02.4View: Contextual filter

Add a Contextual filter of type Content: Has taxonomy term ID to the view.

This filter will only match when the article node has the same term that is set in the listing node.

These filters are usually passed to the view as a parameter in the URL, when the view is set as a page.

In this case, the trick is to specify a default value to be selected when the parameter is missing.

Using the option Taxonomy term ID from URL, we can set it to Load default filter from node page. By doing this, we are indicating the filter to look for the value in the node that is being displayed, that is, the value in the Tags field of the Article listing node.

This filter can be limited to a specific vocabulary, selecting one or more of them.

Another interesting option that will affect the results to display is using AND or OR as a condition when we have multiple terms to filter by.

At last, we can configure a value as an exception to skip the filter. When the view recieves this value, it will stop to apply the contextual filter, forcing it to display all results.

For taxonomy terms, we will need to use the term ID.


The following screen is an article list obtained by filtering with a taxonomy term.

03. Exposed filters for users

  • 03.1 View: set exposed filters
  • 03.2 View: set exposed sort order
  • 03.3 Examples

03.1 View: set exposed filters

We can also expose the filters we created to the final user, and they will be applied together with the contextual filter settings.

As we are displaying the view as a block, to work properly we need to enable AJAX option in the Advanced / Others section.

Set a filter in the usual way in the view, using the desired type: dates, field value, text, etc.

Expose the filter to the user. We can use Single, Grouped, or any combination we need.

03.2 View: set exposed sort order

We can also expose sort order criteria in the usual way, and let the user modify them.

03.3 Example

In this list we can see the exposed form that includes the filters and sort order to the user.

04. Configurable exposed filters

  • 04.1 The idea
  • 04.2 The Feature
  • 04.3 Modify exposed filters using code
  • 04.4 Examples

04.1 The idea

Now that we have exposed filters in our listings, we can add some logic to it.

One interesting possibility is let the content manager choose which filters or sort criteria will be exposed to the user.

For this we will need to add some more fields to our Article listing content type, and use them to control how the filters works.

We will use a Boolean field for each of the filters that we want to be able to activate.

04.2 The Feature

We should be already using Features module, but here we will use it to:

  • Pack together all our components: content types, view and context.
  • Use the .module file in the Feature to include some code to control the filter.

This is an example of all the components included into our newly created Feature.

04.3 Modify exposed filters using code

We will use a hook to alter the exposed filters form and hide the ones that we don't want to be shown, as selected in the listing node.

We can implement hook_form_FORM_ID_alter.

In our code we will need to access the current node, and the simple way of doing this is using the node_load function.

Lets see an example implementation of this.

function cc_publication_form_views_exposed_form_alter(&$form, &$form_state) {

	if ( $form['#id'] == "views-exposed-form-publication-list-block" ) {

		$node = node_load(arg(1));

		if ( $node->field_pl_expose_order['und'][0]['value'] == 1 ) {
			$form['sort_order']['#title'] =  'Sort by' ; 
		} else {
			$form['sort_order']['#title'] =  '' ; 
			$form['sort_order']['#type'] =  'hidden' ; 			

		if ( $node->field_pl_expose_author['und'][0]['value'] == 1 ) {
			$form['field_pub_author_tid']['#title'] =  t('Author') ; 
		} else {
	    $form['field_pub_author_tid']['#type'] =  'hidden'; 
			$form['field_pub_author_tid']['#title'] =  '';
			$form['field_pub_author_tid']['#value'] =  array() ;  // Use and array for multiple selection


		$form['sort_by']['#title'] =  '' ; 
		$form['sort_by']['#type'] =  'hidden' ; 




05. Thanks

Ignacio Sánchez Holgueras

Carles Saport

José María Carnicero

David Bernal

06. Questions?


Muchas gracias

Carlos Carrascal - @ccarrascal77
[ ccarras6@its.jnj.com ] [ carlos.carrascal@gmail.com ]
[ @ccarrascal77 ]

GitHub Repository

johnson & johnson EMEA Development Center