#Needs issue summary update

Hi @andy-blum, I've added the gap between the site logo and site title & slogan. Attaching the screenshot of the after fixes for your reference. Please review the changes.

Thanks!

Yes I think we can close this now!

Is this resolved by the PHPCS and PHPSTAN checks in Gitlab?

Rebased

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Hi nod_, From understanding the issue from the beginning, we need to change the value of --color-absolutezero-active because in the issue (Darker Blue color for hover & active 📌 Darker blue color for :hover & :active Fixed ) , @saschaeggi mentions that the hover color should be #0036B1 and the active color should be #00339A. However, based on comment #11, she updated the color codes for both hover and active states according to the Figma design: Despite this, the recent patches haven't updated the active color value. Therefore, I didn't change the active color code. Should we proceed with updating the active color value as well? "I have created a merge request based on the recent patches, which means I only made changes to the hover color. The latest version of Drupal uses #002e9a as the active color value.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I think #5 + #6 are the needed update now that this is actually actionable :D

Applied #5 to the questions in the issue summary — please review 🙏

This seems very important for usability? Bumping priority and tagging.

This also seems not blocked anymore?

This feels almost like a sensible next step after 📌 [Needs design] Library confusingly lists SDC-sourced and Block-sourced Components together Active , but AFAICT it's not limited to code components — it applies to all \Drupal\experience_builder\Entity\PrimaryComponents? 🤔

So per the logic in \Drupal\experience_builder\Entity\Component::computeUiLibrary(), it will apply to both theme-provided SDCs (module-provided ones end up under either dynamic components or extension components) and XB's code components.

rinku jacob 13 → made their first commit to this issue’s fork.

I tried to reproduce this issue but:

• The issue should be raised against 2.0.x because the route given in issue summary does not exist in 8.x-1.x
• I could not find any issue on /admin/config/development/performance/purge. So if you could provide steps to reproduce this issue and this patch does not make any changes.

Working on it.

MR 11394 is against 11.x and includes a Nightwatch test.

Based on discussion in 🐛 [meta] Some interface components don’t meet the minimum target size Active , I reduced the height of the elements to 1.5rem, which comes to 24px.

I am attaching new screenshots with the changes, as they are different than the previous version.

Tagging for https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html

kentr → changed the visibility of the branch 3223147-mobile-friendly-breadcrumb-fix to hidden.

kentr → changed the visibility of the branch 3223147-mobile-friendly-breadcrumb to hidden.

Believe feedback on this one has been addressed
Hiding patches since the fix is in the MR

That is the issue that I am dealing with in 10.3, codebymikey.

Now that the hook_views_data() argument definition doesn't include entity_type some of my Views are breaking and causing WSOD - especially using Leaflet in Views.

The warnings I get are:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 142 of /data/drupal/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).

Warning: Undefined array key "entity_type" in Drupal\views\Plugin\views\argument\EntityArgument->titleQuery() (line 75 of /data/drupal/web/core/modules/views/src/Plugin/views/argument/EntityArgument.php)

Note the empty value of entity type. And since the entity doesn't have a value, the titleQuery() function cannot retrieve a value.

The Drupal site using a View that displays a Leaflet map and uses the Contextual Filter "Provide default value" with the option "Content ID from URL" to grab the latitude and longitude values to feed to this View.

So this code was introduced in #1886448: Rewrite the theme registry into a proper service → , swapped from _theme_registry_callback and _theme_test_load_registry which just did a print.

I grepped for the string "registry initialized" which is checked in \Drupal\Tests\system\Functional\Theme\FastTest

Debugging that test, ThemeTestSubscriber::onView is never hit. This is because MainContentViewSubscriber::onViewRenderArray runs before it and calls setResponse which stops propagation.

Increasing the priority of ::onView to 10 will cause it to run BUT exposes even more issues with the test.

1. the test hits user/autocomplete which is not an autocomplete path, it's a user path. The test hits a 404 page
2. The test checks the response contains the account name, which it does, but not in any markup.
3. The test checks for the absence of the "registry initialized" text, which I don't think would even happen if everything was working as expected because the event subscriber throws an exception, it doesn't print anything.

catch → closed merge request !11336

Committed/pushed to 11.x, thanks!

Did my best with issue credit but there are a lot of comments from a lot of different people on this issue so apologies if I overlooked someone.

Thanks for clarifying this, @catch 😊

catch → closed merge request !10908

Edit: I wonder if test classes are considered @internal, meaning a CR and deprecation wouldn’t be strictly necessary. However, doing so is certainly the more considerate approach.

fwiw this is exactly how we approach it most of the time, if we really need to skip deprecating and introduce a hard break then we can and will, but if it's straightforward to provide bc then that's preferred to avoid disrupting contrib modules too much/often in minor releases.

Committed/pushed to 11.x, thanks!

@liam morland yes that's exactly the idea.

I read the MR and did a brief manual test and can't see any changes that are required.

Committed ea29660 and pushed to 11.x. Thanks!

Also published the change record.

Automatically closed - issue fixed for 2 weeks with no activity.

I merge in the upstream changes from 11.x and fix the merge conflicts. Setting back to RTBC.

Does this change make it so that I can declare before/after relative to a library that is not on the page? In other words, if that library is on the page, load this library before/after it, but do not add that library to the page if it would not already be there.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

We're adding some gap between the site title & slogan, but there's currently none between the text of this block and the site logo. Can we add the same --sp0-5 between the image and the text as we have between the title & slogan?

Updated the issue summary.

Can the issue summary be flushed out some please

Always recommend to never remove summary heading, even if they don't apply just leave blank or put NA.

Put proposed solution can it be more specific, don't need code but looking at the changes seems to be doing more then just altering the message.

If you are another contributor eager to jump in, please allow the previous poster at least 48 hours to respond to feedback first, so they have the opportunity to finish what they started!

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

With the issue above I was also having this when moving a paragraph field to translate. Someone created a patch that when a asymmetric paragraph get turned on to translation content will be migrated to it's own translation.

https://www.drupal.org/files/issues/2023-06-07/2992777-paragraphs_asymme... →

Does anyone know if there is a way to fix the issues describe below?

1. Entity reference field referencing ECK is set to not allow translations (created through IEF - when creating node)
2. Content is created
3. Entity Reference Field allow translations is turned on
4. Translations are now missing the Entity Reference field that was created in step 2.

Is there an automated way to create those translation that are now missing?

This must happen in the current sprint.

Raised this in slack with @catch, posting response below:

I still think #20 is what we should do tbh. Use the assertion to find the errors, fix the errors in their own issue, then add the assertion to core itself later.

Back to NW to get this into an MR.

new RFC happening https://wiki.php.net/rfc/true_async

Changes look good and comments have been addressed.

I am able to reproduce on 11.x with different STR. I updated the IS and am attaching the HTML Lighthouse report.

I think I can fashion a failing Nightwatch Axe test.

The Axe rule currently referenced by Lighthouse now specifies 24x24 px instead of 48x48 px, but I didn't change that in the IS because I don't know the history.

On a meta-level, in case it is a policy problem:

This issue is WCAG 2.2 AA. A Nightwatch Axe-core test just for this issue will need to explicitly invoke WCAG 2.2 AA, because the existing automated Axe tests don't appear to run WCAG 2.2 AA. So, the standard for this test will differ from the rest unless all tests are updated.

The Accessibility Coding Standards are unclear IMO on whether core / Drupal CMS are required to meet WCAG 2.2 AA.

Though the existing Axe tests still wouldn't have caught this for other reasons, in general they would catch some target-size problems if we started including WCAG 2.2 AA.

catch → closed merge request !9525

Committed/pushed to 11.x, thanks! Also cherry-picked to 10.5.x for API parity.

Reviewed and confirmed the links are correct.

Updated IS, made an MR with the suggestion.

Ok after doing a bit more research it appears at least in my example. Content and translations were created before the field was set to be translatable. Once I went into the field settings and made the field translatable that is when the translation will not display the fields any more.

I think it is because I have an inline entity form reference to an eck inside a paragraph. I will see if I can generate steps to reproduce

Automatically closed - issue fixed for 2 weeks with no activity.

Amazing work, got nothing left to say.

Workaround:

/**
 * Implements hook_ckeditor5_plugin_info_alter().
 */
function my_module_forms_ckeditor5_plugin_info_alter(array &$plugin_definitions): void {
  // Adding span to remove format plugin to avoid error reported on issue
  // https://www.drupal.org/project/drupal/issues/3449576.
  if ($plugin_definitions['ckeditor5_removeFormat'] instanceof CKEditor5PluginDefinition) {
    $removeFormat_plugin_definition = $plugin_definitions['ckeditor5_removeFormat']->toArray();
    $removeFormat_plugin_definition['drupal']['elements'] = [
      '<span>',
    ];
    $plugin_definitions['ckeditor5_removeFormat'] = new CKEditor5PluginDefinition($removeFormat_plugin_definition);
  }
}

If I understand correctly, we are discussing implementing functionality similar to the Filter Permissions module, which allows filtering permissions by role or provider (module).

Having this feature in Core would be highly beneficial, as it can be challenging to locate permissions related to a specific module. While the route "/admin/people/permissions/module/[module_name]" already exists for filtering by module, adding a select list at the top of the permissions page would improve usability.

@jksloan2974 do you mean the patch from #131. Do you have any steps to reproduce? I think if you were to apply that patch to a site that was using the previous method from an earlier patch (where the language of the entities was changed rather than translated) I could see that happening but not sure how it would occur on a fresh site.