@leksat

leksat → created an issue.

Maybe someone has idea...

After updating to latest version I get the this behavior:
- No exception in RenderedItem: the view render array is cached with "max-age: 0"
- If there's an exception in RenderedItem: the view render array is cached with "max-age: -1" which makes the view cached with this exact results for any query 🤯😅

FYI: The patch does not work for the recent stable release of Gin (v3).

Also, the jQuery code does not use the context for the element selection. So every time it is applied to the whole page, no matter of the passed context.

$('.toolbar .toolbar-bar .toolbar-tab > .toolbar-item').css('background-color', settings.environmentIndicator.bgColor);

This new code now changes the background color of our custom toolbar elements. Now sure what to do with that 🤔

@sgostanyan thanks! Works like a charm ✨

leksat → created an issue.

Temporary patch for 6.0.1

leksat → created an issue.

Temporary patch for 2.0.0-alpha3

Snapshot of MR 42 for using with Composer patches.

Fixed a little bug.

alexpott → credited leksat → .

Added a check for the domain access field on the entity. Otherwise, content that is not domain restricted cannot be translated.

A reroll of #24 on 2.0.0-beta2

@eiriksm Great :)

So which behavior is the desired one? Allow all images styles? Or none?

@eiriksm The warning is not the main issue here.

An existing website gets a Gutenberg update => allowed styles are empty
Admin resaves a content type (without doing any changes) => allowed styles are filled with all styles

Which behavior is correct?

If allowed styles are meant to be empty, the the content type form save should behave differently.

If allowed styles should be prefilled, then we need a post-update hook.

There's a new issue caused by this change: 🐛 Warning: Trying to access array offset on value of type null in gutenberg_form_node_form_alter() (line 578 of gutenberg.module). Active

I explained my findings here: https://www.drupal.org/project/gutenberg/issues/3471570#comment-15786262 🐛 Warning: Trying to access array offset on value of type null in gutenberg_form_node_form_alter() (line 578 of gutenberg.module). Active

Allowed image styles were added in ✨ Limit available image styles for image related blocks Fixed . No upgrade path was provided.

If I follow #4 solution, Gutenberg adds all styles to {content_type}_allowed_image_styles. Which I guess is the desired behavior.

If I use the current MR, the warning will be suppressed, but there will be no allowed image styles at all. Which I guess is wrong.

My assumption is that we need an upgrade path for ✨ Limit available image styles for image related blocks Fixed . A post-update hook that will add all available image styles to all content types. I hope maintainers can clarify this.

For those who have issues in Github CI
- PHP 8.3 installed using shivammathur/setup-php
- runs-on: ubuntu-latest
- Error: The database server version /3.37.2/ is less than the minimum required version /3.45/.

The solution is to update to Ubuntu 24.04. So runs-on: ubuntu-24.04

I think I have found something.

https://git.drupalcode.org/project/drupal/-/blob/4692fca5bcd33728bff24a5...

⚠️ Everything below this point is copy/pasted directly from https://github.com/ckeditor/ckeditor5/pull/15222, to continue to use the `width` and `height` attributes to indicate resized width and height. This is necessary since CKEditor 5 v40.0.0.

CKEditor5 uses image_resized attribute to track whether the image was resized or not. Drupal does it differently - it uses only width and height attributes of the img tag.

The problem here is that both width and height attributes are set immediately after an image is uploaded. Once the editor is reloaded, Drupal makes CKEditor think that the image was manually resized.

Looks like a bug in drupalimageediting.js

Same here. After some changes in Docker setup, Composer stopped to run plugins:

Composer plugins have been disabled for safety in this non-interactive session.
Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user.
Do not run Composer as root/super user! See https://getcomposer.org/root for details

More info: https://github.com/composer/composer/issues/11073

Rebased. Tests are green now ✅

The test failures seems to be caused by PDOException: SQLSTATE[HY000] [2002] Connection refused. So I guess they are random and not related.

It looks like I have no permissions to re-run them 🤷

Created follow-ups
- 📌 Adjust caching logic of FieldReuseAccessCheck::access() Active
- 📌 Adjust caching logic of LayoutBuilderAccessCheck::access() Active
and linked them in TODOs ✅

Please note: The deprecation notice points to 10.3.0, but the MR still targets 11.x

Leksat → created an issue.

Leksat → created an issue.

@smustgrave Changes are ready.

What about the two other questions pointed in TODOs? Should the maintainers of the corresponding modules answer them? There's one in field_ui and one in layout_builder.

Tests are green, but there are open questions. I've put them into the MR.

Tried to fix LocalActionManagerTest::testGetActionsForRoute.

It fails because in the test we mock LocalActionInterface which does not extend CacheableDependencyInterface. And then it is passed to RefinableCacheableDependencyTrait::addCacheableDependency().

The actual class (LocalActionDefault) however does extend CacheableDependencyInterface.

I see two options:
1. Make LocalActionInterface extend CacheableDependencyInterface (would it be an API change?)
2. Mock LocalActionDefault instead (but AFAICS we always mock interfaces, not classes)

Does any of them look good? Are there other options? I have no clue 😅

Another +1. I spent quite some time with a debugger trying to find why a GraphQL query wasn't cached.

@apaderno Even better 🎉 Thanks!

The MR looks good and solves the issue ✅

Leksat → created an issue.

For the record. I got this error today in CI. I upgraded PHP from 8.1 to 8.2 in CI and the error is gone now ✅

I don't understand why 😂 but #19 works 🎉

Confirming the issue with Better Exposed Filters described in #33. Somehow, when BEF is used, the value already comes as an array. Attaching a patch with a fix.

Try 2.0.10. I removed composer.json completely.

There is always a chance 😁

2.0.8 is out!

Agree with @andypost. If we install from an existing config, we want the exact config to be imported and we want no changes. Voting for #8.

Thanks for the fix!

How about a release for this one? Isn't it critical if the editor does not load at all?

Patch that applies to 2.0.0-beta1

Patch that applies to v1.2

Added

-  public function normalize($field_item, $format = NULL, array $context = []) {
+  public function normalize($field_item, $format = NULL, array $context = []): array|string|int|float|bool|\ArrayObject|NULL {

Snapshot of the current MR. Applicable to 8.x-1.0-beta6

Oh wow, thank you for the patch!

I met this bug when updated link_target to the latest version and then ran drush site:install --existing-config. PHP ate 72GB 😱 of ram and then died without a word 😅

Hm.. Maybe we should place the link at the same place where the "Unmasquerade" link appears?

I additionally added a menu link for better UX

And attached the current patch for better DX :)

Leksat → made their first commit to this issue’s fork.

RTBC++

Reroll for 10.0.x

Just got this error on a new content type I created. The solution was to make the Body field optional.

I found this issue for a bit different reason. On my website there are users with administer users permission. Yet I don't want them to manage the auth keys.

Basically I need the following:

-      $access = AccessResult::allowedIfHasPermission($current_user, 'administer users');
+      $access = AccessResult::allowedIfHasPermissions($current_user, 'manage any auth keys']);

If this sounds like a good idea, we could add an update hook that adds the new manage any auth keys permission to all users having administer users.

One additional suggestion: Display entity type and bundle labels in the "type" label.

Currently it is: node, media. etc.

It can be: Content: Page, Media: PDF, etc.

It would be especially handy because Linkit can group suggestions by bundles.

I tried to add attributes requested in #6. But it turned out that this is simply not possible:

1. Gutenberg's link supports only 4 attributes
   https://github.com/WordPress/gutenberg/blob/fd98542335ce1a2eb0517b9e4f28...

   attributes: {
   	url: 'href',
   	type: 'data-type',
   	id: 'data-id',
   	target: 'target',
   },
   

2. There is no way to extend them
   https://github.com/WordPress/gutenberg/issues/11599

Rewriting LinkControl and core/link is not an option. So I guess @bgilhome already did the maximum of what we can do. Shall we go with his solution?

@bogdog400 Did you try it with Drupal 10? Does it work?

@mxr576 thanks for the patch.

I tried it after I met some issues on a project where Drupal is a package in a pnpm monorepo. Kernel tests were failing because of hardlinks:

RuntimeException: SplFileInfo::openFile(/Users/alex/work/silverback-mono/apps/silverback-drupal/web/modules/contrib/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/tests/Cypress/node_modules/@-drupal/test_session/test_session.info.yml): Failed to open stream: Invalid argument

Looks beautiful, right? :D

So I tried the patch and found the following:

1. There is a typo: setting.testing.php instead of settings.testing.php

2. file_scan_ignore_directories should be set before Database::addConnectionInfo('default', 'test-runner', $this->getDatabaseConnectionInfo()['default']);. Otherwise, the error persists.

3. I solved the two above issues, but found that tests run crazy slow. Even if they pass. So it looks like something else still scans the blackhole :)

In the end I found another Drupal-unrelated solution. But maybe my findings will help someone.

Please, we need a release :)

beta2 would make life easier 🙏

Looks good, works good!

Also, this patch is a must-have for the Drupal 10 compatibility. Without the patch, the KeyAuth::getUserByKey call fails with the following error:

Drupal\Core\Entity\Query\QueryException: Entity queries must explicitly set whether the query should be access checked or not. See Drupal\Core\Entity\Query\QueryInterface::accessCheck().

Re-rolled #74 on 10.0.x