Join

Main navigation

Optimising configuration forms in Drupal 7

When you're creating a module in Drupal 7, most likely you'll end up creating some kind of configuration form for your module. In Drupal 7 the easiest way to do this is through variables.

09Mar2017

Dalibor

Senior Drupal Architect, Team Lead

Tags

Drupal 7

Planet Drupal

How-to

Share

When you're creating modules in Drupal 7, most likely you'll end up creating some kind of configuration forms for your module. In Drupal 7 the easiest way to do this is through variables.

Since this is the easiest way, most people use them but don't overuse them since they're loading on every page load, which is why we don't want to have many variables in the variables table.

How to create configuration forms in Drupal 7

There is a bad way and a better way to create configuration forms in Drupal 7, and I'll use both ways to show the difference. First let's start with the bad way, which is to simply create a form with each item having its own variable.

As you can see each item has it own variable. In the process you could also do something like iterate through some of your system items and generate configuration for them. That would probably result in about 100+ variables or as many config items as you want the configuration for in the variable table. Of course, this is a bad practice and it will result in slow page load since variables are loaded on every page load. The form looks ugly, and you'll have a bunch of variables to delete afterwards on uninstall. Also if your variable is related to some items that gets deleted you end up having to delete it on appropriate hook into your process.

Now there is a better way to do this. So If you need to have configuration create a fieldsets and use #tree property. For example:

This will result in only ONE variable which will be only one row in variable table and that is comparison_table_settings which will be updated when you save config form. If we take a look at dump from variable we see how the unserialised variable looks like. So only one unserialize() function will be called. If you load your items from something in your system you don't have to hook anywhere to delete variables because you only have one.

Our new form looks better, it's grouped by fieldsets and we only have one variable for all configuration items.

So once we want to uninstall the module we can perform only one variable_del in hook_uninstall and it will delete our complete configuration.