By rjacobs on

Hello,

I'm working on some updates for the Juicebox HTML5 Responsive Image Galleries module (which I maintain) and have a targeted question about the proper use of hook_update_n when re-structuring existing user configuration data that's been populated through the fields and views APIs.

This integration module implements a field formatter and view display plugin that allows imagefield data to be presented with a popular 3rd party javascript library (Juicebox). It implements custom field formatter and views display settings through the fields and views APIs, and therefore does not directly manage the way this settings data is dealt with in the database. From what I can see, both fields and views just store custom formatter and display data in a "schemaless" structure as serialized data arrays (inside the field_config_instance and views_display tables). Furthermore, the structure/hierarchy of this serialized data directly mirrors that of any fieldsets used on the configuration form itself (unfortunately it seems '#tree' = TRUE must be enforced on the form fieldsets).

One of my updates changes the way some configuration options are nested in fieldsets on the configuration forms, which therefore impacts the way this data is structured in the serialized data arrays noted above. So in order to support existing user data during the update it's looking like I need to leverage hook_update_n in such a way that directly changes these serialized data arrays but without using any fields or views APIs (as that seems to be very bad practice within hook_update_n). I'm slightly nervous about this though as those data structures are core fields and views concepts (not concepts of my module) and if I do something wrong I could inadvertently damage entire field instances or view displays for hundreds of my users.

So as a sanity check, I'm hoping someone could help me confirm if I'm approaching this the right way. I can share some example code that I'm testing, but my strategy is:

  1. Fetch a bunch of rows that contain the individual field formatter or view display data directly with db_query (inside the field_config_instance or views_display tables).
  2. Loop though these rows and unserialize the info in the "data" column (that may contain my module's config settings).
  3. Loop though the unseralized data and search for indicators that this is a field formatter or views display that my module handles. If I find cases where my module is involved, then:
    1. Restructure the data array to align with the the new nested fieldset structure that will be used on the configuration form itself.
    2. Serialize the new data array.
    3. Write the updated seralized data back to the database with db_update.

Does this all seem correct, or is there necessary logic that I might be missing?

Any info and guidance is hugely appreciated!

⋅ Categories: Drupal 7.x

Comments

rjacobs’s picture

rjacobs commented

Here's an example chunk of hook_update_n code that I've been testing to specifically update the Juicebox view displays (the code that deals with the field formatters is fairly similar). Note that _juicebox_update_7100_process_settings() is the function that actually changes the settings structure (just re-nests some parts of the settings array).

// Next check all juicebox view displays and processes the settings for each.
if ($sandbox['view_displays_processed'] < $sandbox['view_displays_total']) {
  $result = db_query_range('SELECT display_options, vid, id FROM {views_display}', $sandbox['view_displays_processed'], $view_display_rows_per_pass);
  $view_displays = $result->fetchAll();
  if (!empty($view_displays)) {
    // Loop through the returned views displays looking for Juicebox displays.
    foreach ($view_displays as $view_display) {
      $data = unserialize($view_display->display_options);
      if (!empty($data['style_plugin']) && !empty($data['style_options'])) {
        if ($data['style_plugin'] == 'juicebox') {
          $current_settings = $data['style_options'];
          $updated_settings = _juicebox_update_7100_process_settings($current_settings);
          // If any updates were found go ahead and update the relevant
          // display in the database.
          if ($current_settings != $updated_settings) {
            $data['style_options'] = $updated_settings;
            $data = serialize($data);
            db_update('views_display')
              ->fields(array('display_options' => $data))
              ->condition('vid', $view_display->vid, '=')
              ->condition('id', $view_display->id, '=')
              ->execute();
            $sandbox['view_display_updates']++;
          }
        }
      }
      $sandbox['view_displays_processed']++;
    }
  }
}
rjacobs’s picture

rjacobs commented

I just wanted to note that I also posted a similar question to this one in the "views" issue queues and got some great responses from merlinofchaos there. See:

#1965786: Methods to alter display data structures when views integration modules are updates (hook_update_n vs runtime checks, etc.)

Just in case anyone comes across this and is interested in the outcome.