Follow-up to #2871157: panelizer_post_update_rename_layout_machine_names() does not work as I wasnt able to reopen it.

The panelizer_post_update_rename_layout_machine_names(&$sandbox) is not working on our site properly yet.

We encounter the never ending "Post updating panelizer [ok]" loop and our observation is:

  • Before any updates are run the number of $results returned by the code
      module_load_install('panels');
     
      /** @var \Drupal\panelizer\Plugin\PanelizerEntityManager $panelizer_manager */
      $panelizer_manager = \Drupal::service('plugin.manager.panelizer_entity');
     
      $results = [];
      // Update overridden panelizer entities.
      foreach ($panelizer_manager->getDefinitions() as $entity_type => $definition) {
        if (db_table_exists($entity_type . '__panelizer')) {
          $storage = \Drupal::entityTypeManager()->getStorage($entity_type);
          $ids = $storage->getQuery()
            ->condition('panelizer', serialize([]), '<>')
            ->execute();
     
          foreach ($storage->loadMultiple($ids) as $entity_id => $entity) {
            $results[] = $entity;
          }
        }
      }
    

    is 20.

  • During the 1. batch run of the update the $results count is 11. I believe the number is lowered from 20 to 11 because of the panelizer_update_8401(&$sandbox) run (It cleans out / rename layout machine names in config entities to match layout discovery's default layouts).
  • During the 2. batch run of the update the $results count is 10. The missing item was updated in the 1. batch run even though it wasn’t modified, as it uses a custom layout so the panels_convert_plugin_ids_to_layout_discovery($layout_id) returns FALSE for it. But somehow the $entity->save(); changes it in a way that it is not picked up later on.

I will attach a patch that

  • saves the entity only if it was modified.
  • keeps a track of already processed entities to find out if all entities were already processed. This is a different approach comparing to usage of a max count and a processed count of items. Relaing only on counts causes problems if the query in the next batch run returns a different number of items and that can happen from multiple reasons.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dabbor created an issue. See original summary.

dabbor’s picture

Status: Active » Needs review
FileSize
4.22 KB

Providing the patch I promised.

Creating a patch was a necessity for us to be able to run updatedb with 8.x-4.0 panelizer.

dabbor’s picture

I tested and debugged the patch on my local via drush and via update.php as well.

I'm using $sandbox['#finished'] = 0.5; in the patch to say that the batch is not yet finished. It would be possible to change it to somehow show how many entities were already processed. I just didn't have a time to play with it. The only problem is that the number of entities to be processed can be possibly changed between batches' runs.

DamienMcKenna’s picture

Status: Needs review » Needs work

Yeah, the $sandbox['#finished'] number update based upon how many entities there might be, it can then post a message at the end saying how many were actually updated.