Skip to main content

A recipe for editing & translating over 100 fields

CM Drupal Contribution Challenge 2020
An article from ComputerMinds - Building with Drupal in the UK since 2005
14th Jul 2020

James Williams

Senior Developer
Hey, you seem to look at this article a lot! Why not Bookmark this article so you can find it easily in the future?

This year, a bunch of us at ComputerMinds are challenging ourselves to make a Drupal contribution every single month. We'll be making patches, helping solve problems, providing translations, discussing issues and more! In this article series, we'll be writing about our favourite and most-interesting contributions, and making some loud noises in support of the amazing Drupal community.

Read more

I recently released a new contributed module to aid translation on Drupal 7 sites: Entity Translation: Separated Shared Elements Form (ETSSEF). Yes, it has a convoluted name! It finally resolves a suggestion from years ago in an Entity Translation project issue, to allow editing untranslatable fields separately to translatable ones. One of our clients has a multilingual product database site with a few hundred fields on their content, so anything like this that could reduce the size of their editing forms is useful. I figure the best way to demonstrate this is with a recipe that blends it together with some other super (but generally obscure) modules. I hope you can spot parts that may be helpful for your projects!

Screenshot of the top of an edit translation form, including Shared tab and Add fields to form widget

The Recipe
 

Ingredients

Take a look at each of these project pages linked above for a flavour of what each module will bring to the mix.


Recipe Difficulty Rating: Intended for experienced Drupal cooks only; others may prefer to try our takeaway service.
 

Method
  1. Enable each of the modules listed above, and set the admin theme to be used.
     
  2. Configure the various Field storage modules. Try to understand what each of these is doing, and adjust appropriately for you if necessary:
    // Turn off storage of revision info for your content type that has many fields.
    $bundle = 'farmer';
    variable_set('field_sql_norevisions_entities', array(
      'node' => array(
        $bundle => 1,
      ),
    ));
    // Default to using Blob storage (1 table instead of 1000s).
    variable_set('field_storage_default', 'field_sql_blob_storage');
    // Relabel the options in the UI to make the distinction clear.
    variable_set('field_storage_ui_relabel_options', array(
      'field_sql_blob_storage' => 'Retrievable only',
      'field_sql_storage' => 'Sortable & Filterable',
    ));
    // Load default-sql-storage fields in batches of 20 (instead of 1 at a time).
    variable_set('field_sql_storage_group_load_max_fields', 20);
    
     
  3. Set up your content type with many many fields. Choose 'Retrievable only' for the storage type for any fields that don't really need to be used for querying against, or sorting/filtering in lists. This will improve performance, as all the field data for those is stored together in a 'blob' column in the database so can be loaded (& unserialized) in a single go, rather than requiring select queries from so many different individual database tables.
     
  4. Configure nodes of this type to use entity translation (field translation) and head to the entity translation settings at /admin/config/regional/entity-translation. Set their 'Shared elements on translation forms' setting to 'Only display on their own separate forms':
    Entity translation settings showing Shared elements configured to show on their own forms
    This ensures that untranslatable fields are just edited on the initial Edit tab (in a 'Shared' secondary tab); with just translatable fields in the translation forms. When there are so many fields, it's worth slimming down forms as much as possible! This also has the advantage that untranslatable data can be edited without needing to touch any specific translation.
     
  5. Override the edit form for your node type in a custom module, to use the Field Attach Form Selective module, so that fields are only shown on the form as they are filled in. This vastly reduces the amount of stuff on the form. I've written a gist that demonstrates this, and includes wiring it up to work nicely with ETSSEF. You must copy the entire contents of node_form() from node.pages.inc in Drupal core into the farmer_node_form() function, but replace the call to field_attach_form() at the bottom, with a call to field_attach_form_selective(). Use the same arguments.
     
  6. I then added some classes and CSS to the secondary tabs on the page to show the flag icons next to each language, as well as repeating the current tab name in the page title. I then added CSS to fix the page header in place so that editors easily retain that contextual information as they scroll down the giant forms. Otherwise it's too easy for them to forget which language they are editing!

 

Season to taste

Now when you edit your content type, your forms will be much slimmer and your site will run far smoother with hundreds of fields. As with any recipe, take the bits of this that are to your taste, ignore others, or blend it into your own creations! This was only for D7, so bringing the ideas over to Drupal 8/9 in some form would be an obvious thing to do. I’d love to hear of other ingredients you use to help when editing content forms with enormous amounts of fields, translatable or not.

 

Photo by Maarten van den Heuvel on Unsplash

Hi, thanks for reading

ComputerMinds are the UK’s Drupal specialists with offices in Bristol and Coventry. We offer a range of Drupal services including Consultancy, Development, Training and Support. Whatever your Drupal problem, we can help.