Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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 thepanelizer_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 thepanels_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.
Comment | File | Size | Author |
---|---|---|---|
#2 | 2881315-layout-2.patch | 4.22 KB | dabbor |
Comments
Comment #2
dabbor CreditAttribution: dabbor at Morpht commentedProviding the patch I promised.
Creating a patch was a necessity for us to be able to run updatedb with 8.x-4.0 panelizer.
Comment #3
dabbor CreditAttribution: dabbor at Morpht commentedI 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.Comment #4
DamienMcKennaYeah, 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.