>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3387144. --> Reported by: [slucero](https://www.drupal.org/user/1612534) Related to !85 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The implementation of the bulk update process for pattern block content as of the Beta 7 release loads all layouts and related entities to iterate through them individually searching for blocks with available updates. To date this has worked ok, but on sites with large databases and many entities and layouts to load and iterate through, we're seeing out of memory errors. A revamped solution to run these updates through batch processing may be needed for these situations.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Reimplement bulk pattern content updates through a batched operation.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Implement discovery and processing for more than just Nodes</li> <li><del>Write follow-up issue for configuration form and batch processing via admin UI</del> (<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/patternkit/issues/3388321" title="Status: Postponed">#3388321: Add Administrative UI for Batch Updating</a></span>)</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <ul> <li>New Drush command and options for batch processing updates</li> </ul> <h3 id="summary-api-changes">API changes</h3> <h4>New Batch Manager and Worker Services and Implementation Model</h4> <p>Two new batch manager services have been implemented to manage and execute batched operations. For each of these services, much of the implementation work has also been separated out into "batch worker" classes that get instantiated for the execution of each batching pass. This offers several benefits:</p> <ul> <li>The primary work for each batch operation is much more easily tested as opposed to all static methods</li> <li>Service dependencies may be injected into these workers</li> <li>Implementing a base class for these types of workers allows for consolidation of a lot of redundant functionality</li> <li>Additional batch operations could be implemented later by writing new workers</li> </ul> <h4>New Layout Discovery Batch Manager/Worker</h4> <p>This batch manager (<code>LayoutDiscoveryBatchManager</code>) and worker (<code>LayoutDiscoveryBatchWorker</code>) pair handle the loading of entities to identify layouts for processing. These discovered layouts are then loaded into a queue for subsequent processing via either batch process or typical execution of the Queue API. Unless explicitly disabled, a secondary batch operation using the <code>LayoutUpdateBatchManager</code> is queued for immediate execution to process all queued layouts.</p> <h4>New Layout Update Batch Manager/Worker</h4> <p>This batch manager (<code>LayoutUpdateBatchManager</code>) and worker (<code>LayoutUpdateBatchWorker</code>) pair handles processing of the items in the <code>patternkit_layout_updates</code> queue via a batch operation.</p> <h4>New Queue and QueueWorker: <code>LayoutUpdateQueueWorker</code> (<code>patternkit_layout_updates</code>)</h4> <ul> <li>This queue worker processes items expected to be queued by the new layout discovery batch service (<code>LayoutDiscoveryBatchManager</code>) and runs the update process for all patterns discovered within a layout designated in the queue item.</li> <li>This queue may be run as part of a batch operation via <code>LayoutUpdateBatchManager</code> where the related batch worker (<code>LayoutUpdateBatchWorker</code>) will load and execute this queue worker plugin on each queue item.</li> </ul> <h4>New Drush Command: <code>drush patternkit:batch-update</code></h4> <p>This new Drush command executes the bulk update process using the new batching services. It offers the same filter options as the existing <code>drush patternkit:libUpdate</code> command with the addition of the following:</p> <ul> <li><strong>--revisions</strong>: Set which revisions should be loaded for discovery.</li> <li><strong>--no-run-queue</strong>: If all discovered layouts should not be processed yet, this option allows for loading them into the queue and leaving them there for later processing.</li> </ul> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None.</p>