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:
- 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', },
- 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