>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2875752. --> Reported by: [oheller](https://www.drupal.org/user/2750577) Related to !25 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>When using drag and drop to reorder blocks, all blocks in a region (not only a specific block that was moved) may be assigned a new weight. This works okay when only core is in play and a single form is used to reorder all blocks, since reassigned weights retain their relative ordering.</p> <p>When editing only a specific block visibility group, however, the fact that all of that group's blocks may be assigned a new weight means that, while their internal ordering is okay, their ordering relative to blocks placed globally or via other block visibility groups may have changed.</p> <h4>Steps to reproduce</h4> <p>The problem arises from variations on the following steps:</p> <ul> <li>Assign some sitewide blocks.</li> <li>Create one or more block visibility groups and assign them blocks. </li> <li>Bring up the main block layout page with "All blocks" selected for "Block Visibility Group". Note the relative ordering of blocks.</li> <li>For "Block Visibility Group", select one of the groups you created previously. Add a new block and drag and drop it for ordering. Save.</li> <li>Return to the main block layout page with "All blocks" selected for "Block Visibility Group". Result: not only the new block, but others as well may have shifted in relative position. Source of problem: weights for all blocks in the block visibility group were changed, so their position relative to other blocks on the site has changed.</li> </ul> <h4>Source of bug</h4> <p>The tabledrag behaviour leads to reassigned weights for all items in a group, not only the one that was dragged. Since they are not present on the form, blocks in different visibility groups retain their old weights, and so are out of order with the reordered ones.</p> <h4>Workaround</h4> <p>A workaround is: whenever using any block layout screen, ensure "Show row weights" has been selected before making any changes, so that all block ordering is done manually through explicitly selecting block weights.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>Alter the block filtering such that all blocks are always on the form, though only ones for the current visibility group (and, if desired, global blocks) are visible. Thus, all blocks in a given region are re-weighted and so retain their relative order.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h4>Fix up tests</h4> <p>For test coverage, we're drawing on the core test <a href="https://api.drupal.org/api/drupal/core!modules!book!tests!src!FunctionalJavascript!BookJavascriptTest.php/function/BookJavascriptTest%3A%3AtestBookOrdering/8.3.x"><code>BookJavascriptTest::testBookOrdering()</code></a>for its use of JS drag and drop.</p> <p>See the handbook page <a href="https://www.drupal.org/docs/8/phpunit/phpunit-javascript-testing-tutorial">PHPUnit Javascript testing tutorial</a> for details on how to run JS tests.</p> <h4>Empty regions</h4> <p>Handling for the case that a given region has blocks but they're now all invisible. Need to change relevant class from 'region-populated' to 'region-empty'.</p> <h4>Optimizing?</h4> <p><code>::getEntityIds()</code> may now be invoked multiple times and might need some caching.</p> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3> >>> [!note] Pre-migration files - [after-weights-shown.png](https://www.drupal.org/files/issues/after-weights-shown.png) - [after-weights-hidden.png](https://www.drupal.org/files/issues/after-weights-hidden.png) - [change-noblock-global-hidden.png](https://www.drupal.org/files/issues/change-noblock-global-hidden.png) - [before-weights-hidden.png](https://www.drupal.org/files/issues/before-weights-hidden.png) - [before-weights-shown.png](https://www.drupal.org/files/issues/before-weights-shown.png) >>>