@danielcavanagh

i've had this issue twice now during big drupal updates

in my case it was caused by the mass pkg update somehow downgrading simple_oauth from 6 to 5

just double check the same hasn't happen to you before you resort to manually updating the db

patches for 10.4.x and 11.x to set collection permission id on media entity

the permission already exists and is used in other situations, but now will work for allowing access to the media overview page

rerolled patch for latest version

We've just run into a similar issue: menu items and their children being attached to the entirely wrong parent seemingly for no reason, even when all items were active

It ultimately stems from the list of links returned from DB query in MenuTreeStorage::loadLinks() not being ordered properly, despite the function correctly setting the SQL orders (p1 ASC, p2 ASC, etc.) before querying and the data in the DB being correct. It seems to make no sense. It's mostly ordering it correctly, but a few odd items are being moved out of order somehow

    for ($i = 1; $i <= $this->maxDepth(); $i++) {
      $query->orderBy('p' . $i, 'ASC');
    }
    ...
    $links = $this->safeExecuteSelect($query)->fetchAllAssoc('id', \PDO::FETCH_ASSOC);
    // links are already out of order

Perhaps there's a bug in the SQL fetch code that leads to the row order being wrecked when converted to an associative array, or perhaps there's some custom hook that runs after queries

This code triggers the issue:

$parameters = new MenuTreeParameters();
$parameters->onlyEnabledLinks();

This doesn't:

$parameters = new MenuTreeParameters();

It seems this also doesn't tho 🙃:

$parameters = new MenuTreeParameters();
$parameters->onlyEnabledLinks();
$parameters->addCondition('expanded', 1);
$parameters->setActiveTrail([...]);
$parameters->setMaxDepth(3);

We're working around the issue by not using onlyEnabledLinks() and instead manually filtering out disabled links after loading the full tree