🇦🇷Argentina @cesarmiquel

@steven-jones unfortunately not easily because the site is a multi-site Drupal and I don't have the ability to patch the Drupal Core. I might be able to request a patch but it will take a while (probably a week or maye more **if** they approve it) for them to patch it so I need to find a work around.

Thanks @steven-jones for your feedback. I will follow this new issue then. Do you know of a workaround for this to work in the meantime?

Hi! I have the following code that used to work fine but now it breaks after this has been deployed. Basically I have a form with a list of items that look something like this:

<?php
$address_list = [];
foreach($address as $id) {
  $address_list[$id] = [
    '#type' => 'item',
    '#markup' => '...',
    '#states' => [
      'visible' => [
        ':input[id="some_select"]' => ['value' => $id],
      ]
    ]
  ];
}
$form['addresses'] = $address_list;
?>

This used to work fine before this patch. When you selected an option in the select it would display one of these items which have information related to the selection. I've identified the issue and have verified that this fix is breaking the previous code but I have no clue why when the data-drupal-states is set in the #attributes it works but not in the `#wrapper_attribtues`. Any help? Is there something wrong with the way I'm using the #states? Heelp🙏

I also experienced this issue and noticed the problem was the same as in comment #8: by commenting out the theme__preprocess_block__simple_block(&$variables) in the custom theme, rebuilding registry and I was able to run the update without problems. I don't think deleting templates is the correct way to fix this. I would recommend looking into your .theme file.

This worked for me as well on Drupal 9.5.11 (version 2.0.4 of decoupled_router).

cesarmiquel → created an issue.

Is somebody working on this? I hit this issue so I'd like the rule to be added. I volunteer to try to do it if someone can point me to a similar rule I can use as reference.

I looked at the .install for this module and the problem is that the fields are added in rest_api_access_token_update_8021() but they should also be added to the rest_api_access_token_schema() function. The way Drupal works is if you install the module for the first time Drupal saves the ID of the last update (8021) and only applies updates that are larger than 8021 but will not run any of the previous updates. For fresh installs you need to put the current version of the table in hook_schema(). Currently I don't have time to create a patch but that is the correct way to fix this AFAIK.
The rest_api_access_token_schema() should be something like this:

  $schema['rest_api_access_token'] = [
    'description' => 'Stores access tokens.',
    'fields' => [
      'user_id' => [
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
      ],
      'public_token' => [
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
      ],
      'secret' => [
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
      ],
      'created_at' => [
        'description' => 'Created time.',
        'type' => 'int',
        'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ],
      'refreshed_at' => [
        'description' => 'Updated time.',
        'type' => 'int',
       'unsigned' => TRUE,
        'not null' => TRUE,
        'default' => 0,
      ],
    ],
    'indexes' => [
      'public_token' => ['public_token'],
      'user_id' => ['user_id'],
    ],
    'primary key' => ['public_token'],
  ];

  return $schema
 

Also I'm pretty sure that the 'default' => time() doesn't work as the author of the module expected. You can't set a dynamic default value. You should use 0 and make sure to add the timestamp via code.

The core entry is not in the main module but is inside the submodule audio_embed_media. That's why this patch is needed.

I can confirm patch on #5 works fine.

Just FYI we are on version 8.x-3.15 which is the latest stable version of the module and we had all our site (production) crash because a user cloned a layout and this error started appearing on all pages. Of course it's not a good idea to mess around with layouts in production and we were able to fix it by reverting the configuration. I think it might not be a bad idea to add this patch to the next minimal maintenance mode specially because there is still no stable 8.x-5.0 release.

Not sure why this issue derailed. The patch in #45 🐛 Avoid loading all terms on the taxonomy overview form Needs work worked for me in several tests/sites with large taxonomies and had the blessing by Catch → . All that remained was to add a comment. In all honesty I didn't understand exactly what the comment was but I believe once that comment is added this was RTBC.

There is also a version for 10.x. in #54 🐛 Avoid loading all terms on the taxonomy overview form Needs work . I recommend you test that version and leave a comment if it works.

I don't recommend the solutions that try to increase the memory size as suggested as they will eventually break. The proposed solution worked for me on two large sites I tested.