Problem/Motivation

After upgrading to Drupal 10.1 JavaScript is no longer aggregated correctly if xdebug is installed.

Steps to reproduce

1. Create a docker Ubuntu container with Apache2, PHP 8.1
2. Install php-xdebug (apt install -y php-xdebug)
3. Drop your favorite Drupal 10.1 site into the container
4. Load pages from the site
5. Examine the apache error logs

At step 4 I noticed that none of the portions of the site's pages which depend on JavaScript looked or behaved correctly. I examined the aggregated JavaScript and saw that it contained almost none of the site's code. Aggregation had apparently failed after collecting a single line of JavaScript. At step 5 (examine the apache error logs) I found:

PHP Warning: Uncaught Error: Xdebug has detected a possible infinite loop, and aborted your script with a stack depth of '256' frames in /var/www/vendor/mck89/peast/lib/Peast/Syntax/Utils.php:93

I went into the site's configuration and turned off JS and CSS aggregation and the problems disappeared.

I turned aggregation back on and the site was broken again.

I then found /etc/php/8.1/mods-available/xdebug.ini which had a single line:

zend_extension=xdebug.so

Note that the failures occurred without having configured xdebug to actually enable remote debugging. It was enough that PHP could find the DLL for the module. I commented out that line, restarted Apache, and aggregation worked again.

Rolling back from 10.1.0 to 10.0.9 also eliminated the failure.

Proposed resolution

Restore the ability to use xdebug with aggregation enabled.

Problem/Motivation

In #3366083: [META] Hooks via attributes on service methods (hux style) we proposed to provide a new way to implement hooks, using object methods with attributes.
A similar system already exists in contrib: https://drupal.org/project/hux

In this issue we will do proof-of-concept implementation and experiments.

Once this is done, we can split out real implementation issues that can then be developed and merged one by one.
E.g. perhaps there will be separate refactoring issues as preparation for the new system.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem

When adding a specific language, zero translations are imported for that language even if imports are enabled. Not all languages are affected.

Steps to reproduce

I seem to be able to enable a language, delete the language, and then enable the same language again. This results in zero translations imported.

Cause of issue

Even if a language has been deleted, locale does not clear it's cache entry in it's locale.translation_status key_value collection. It seems that the presence of this cache entry lingering causes a future import during a language add operation to result in zero imports.

Steps to address

When adding a new language, clear that language's translation cache entry in the locale.translation_status key/value collection in locale's add language submission handler.

#2756331: Custom blocks cannot be properly exported and imported is pretty nasty in terms of UX but apparently hard to fix.

Basically, if you export a custom block configuration and import this configuration in a new website you will have a "This block is broken or missing" error has the content is effectively missing.

But we perhaps give the user a chance to save is website by replacing:

"This block is broken or missing. You may be missing content or you might need to enable the original module."
by
"'The content of the block (%bundle %uuid) is missing. Add missing content.'.

Proposed resolution

• Listen to missing content event in block content module.
• Take note of missing block content UUIDs
• Store them in state.
• In the derivative discovery, make definitions available for those UUIDs
• In the build method for these, output a link with a prebuilt uuid and type (taken from the missing content event stuff that is saved in state)
• This link will create a stub entity of that type and with that uuid and then present the edit form
• User submits, hey presto its fixed
• State entry is cleaned up when block is saved
• Tests cover that scenario

Remaining tasks

Approach as per comment 37

Problem/Motivation

This is a follow-up discussion from #1972300-78: Write a more scalable dispatcher, where we purposed Drupal EventDispatcher for symfony in https://github.com/symfony/symfony/pull/12521

Here is the small update on the upstream PR [EventDispatcher] Add Drupal EventDispatcher is closed in favor of [DI][EventDispatcher] Add & wire closure-proxy argument type which is reverted in [Di] Remove closure-proxy arguments and symfony added [EventDispatcher] Handle laziness internally instead of relying on ClosureProxyArgument in symfony 3.3. Over in #2874909-52: Update Symfony components to 3.3.* I'm trying to fix the EventDispatcher fails. Can we drop Drupal EventDispatcher in favour of Symfony EventDispatcher now?

Proposed resolution

This is potentially blocked by #2874909: Update Symfony components to 3.3.* but let's start the discussion.

Remaining tasks

Find out how SymfonyEventDispatcher improvements can help EventDispatcher.

User interface changes

None

API changes

Don't know yet.

Data model changes

None.

Problem/Motivation

Hooks are invoked and events dispatched using an arbitrary string. Hook implementations and event listeners then get picked up based on that arbitrary string.

However, with events, we've adopted the pattern of putting the string in a constant on an Events class. See for example https://api.drupal.org/api/drupal/core!modules!migrate!src!Event!Migrate...

This has caused problems on module enable, see #2712647: Update Symfony components to ~3.2 and #2776235: Cached autoloader misses cause failures when missed class becomes available.

Event listeners reference the event class in getSubscribedEvents() - but they either have to rely on the event class always being loaded, or use class_exists() to check if it's available. This introduces a very fragile dependency on the classloader being updated when the module list is.

Proposed resolution

Stop using event classes with constants for event names, just use strings everywhere.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Postponed on #3346765: Add PerformanceTestBase for allowing browser performance assertions within FunctionalJavaScriptTests and #3352389: Add open-telemetry/sdk and open-telemetry/exporter-otlp as dev dependencies.

See #638078: Automated performance testing for core for rationale.

Steps to reproduce

Proposed resolution

#3346765: Add PerformanceTestBase for allowing browser performance assertions within FunctionalJavaScriptTests gives us the ability to pass or fail tests based on certain performance characteristics, but this only works for things you can count.

For things that can't be counted but only timed (like how long a request takes from first byte to first paint), we could instead look at graphing these over time and flagging changes.

Open Telemetry is a suite of tools that will allow us to do this via adding some development dependencies, and setting up a 'collector' on Drupal.org infrastructure.

We can add the capability to PerformanceTestBase to send traces to OpenTelemetry, these can then be made available for browsing in signoz. signoz will show both trends over time and allow you to drill down into individual traces. See the screenshot for a proof of concept.

Traces are currently using data from the performance navigation API: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTi... via executeScript() - this lets us log this information without running any extra JavaScript on the tested site.

One thing I've not been able to figure out yet is how to get LargestContentfulPaint reliably (https://developer.mozilla.org/en-US/docs/Web/API/PerformancePaintTiming).

Note that the MR doesn't include the OpenTelemetry collector or the configuration to enable this, that will have to be handled on the infrastructure side. However there is a test repo using this patch that gives you a full end-to-end installation via ddev. https://github.com/tag1consulting/google-drupal

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When modules are installed, plugin definitions are cleared.
Breakpoints and Layouts also allow themes to provide plugins, they need to be cleared as well.

Any manager using YamlDiscovery has to pass in the list of directories to search, and these are not updated.
Additionally, the %container.namespaces% parameter is updated by the DrupalKernel, but is also cached by the discovery

Proposed resolution

Reset the discovery in \Drupal\Core\Plugin\DefaultPluginManager::clearCachedDefinitions()
Adjust \Drupal\Core\Extension\ThemeInstaller::resetSystem() to match \Drupal\Core\Extension\ModuleInstaller

Remaining tasks

Reroll
Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

NOTE: For us this problem occurs with Drupal 8.9.13. I have not confirmed yet if it happens in 9.x.

Problem/Motivation

After renaming a layout, or after switching to a branch where a given layout does not exist, any attempt to fix the layout configuration will fail.

Steps to reproduce

Create a custom layout.
Create a layout builder configuration using that custom layout.
Remove or rename the custom layout.
Attempt to edit the layout builder configuration form, OR try to use "drush cim" to revert to a configuration where this layout was not used.

Expected: Layout builder config can be repaired.
Actual: Error.

The "layout_xyz" plugin does not exist. Valid plugin IDs for Drupal\Core\Layout\LayoutPluginManager are: ...

Proposed resolution

Use try/catch in strategic places to recover from this.

Remaining tasks

See tags

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Error when adding a custom block entity to the block layout when no block description have been added (i.e., the field base was hidden from the form).

Error stack:

Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\Component\Transliteration\PhpTransliteration->transliterate() (line 135 of core/lib/Drupal/Component/Transliteration/PhpTransliteration.php).
Drupal\Component\Transliteration\PhpTransliteration->transliterate(NULL, 'x-default', '_') (Line: 254)
Drupal\Core\Block\BlockBase->getMachineNameSuggestion() (Line: 390)
Drupal\block\BlockForm->getUniqueMachineName(Object) (Line: 137)
Drupal\block\BlockForm->form(Array, Object) (Line: 106)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('block_form', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object) (Line: 27)
Drupal\block\Controller\BlockAddController->blockAddConfigureForm('block_content:9252e0db-83d7-421b-b410-60cfa0629557', 'olivero')
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 686)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

1. Create or edit a custom block type
2. Go to Manage Form Display
3. Hide the 'Block Description' field
4. Go to `/block/add` and choose the custom block type you just edited/created
5. Fill the required fields and then press `Save`
6. The error should have been triggered when on the block form

You can also trigger it when adding an existing custom block entity through the Block Layout UI.

Proposed resolution

Handle cases when the `Block Description` is hidden and no value has been set.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The same exception is thrown for 3 different cases:

    if (!isset($this->languages[$langcode]) || $this->hasTranslation($langcode) || $this->languages[$langcode]->isLocked()) {
      throw new \InvalidArgumentException("Invalid translation language ($langcode) specified.");
    }

The exception message is fairly generic and vague, and because there are 3 different ways to get this, it's impossible to understand the problem.

This should be split into three separate checks, with different exception messages.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

You can access single value field in node template easily:

{{ content.field_test }}
or
{{ node.field_test.value }}

But iteration over multiple value fields is not pretty:

{% for key, item in content.field_tags if key|first != '#' %}
  <div class="item-{{ key + 1 }}">{{ item }}</div>
{% endfor %}

You can, of course, use a field template, but sometimes it doesn't make sense to have a ton of field template when you can simply have one node template.

Example:

I need to add "," between a field's values (a multiple value entity references field rendered in label). So I have a field template with:

{% for item in items %}
  {{ item.content }}{% if not loop.last %},{% endif %}
{% endfor %}

And in my node template I have:

{% if content.field_facilities is not empty %}
   <p>{{ content.field_facilities }}</p>
{% endif %}

But I would prefer to have a similar code directly in my node template like:

{% if content.field_facilities is not empty %}
   <p>
     {# This do not works! #}
     {% for item in content.field_facilities %}
       {{ item.content }}{% if not loop.last %},{% endif %}
     {% endfor %}
   </p>
{% endif %}

What would be the best way to solve that?

See also:

• http://drupal.stackexchange.com/questions/208723/iterate-through-multipl...
• https://www.drupal.org/node/2682011
• http://drupal.stackexchange.com/questions/186488/multivalue-field-with-t...
• http://drupal.stackexchange.com/questions/174742/loop-through-child-elem...

Problem/Motivation

The documentation on the Drupal\Core\Render\Element\Select element doesn't warns that using #empty_value could lead to overwriting a value in #options.

See #1936636: Fix the documentation for #empty_value for more details.

Steps to reproduce

N/A

Proposed resolution

Add a warning in the comments about this situation.

Remaining tasks

User interface changes

API changes

None.

Data model changes

None.

Release notes snippet

None.

Transferred from https://security.drupal.org/node/134653 since this was determined to be a feature request for FAPI, as opposed to a security vulnerability.

Problem/Motivation

Example 1 reported by hejazee
==================
some form validators should take precedence. for example the validator should be executed first.
and if it fails, other validators should not be executed.

because form validators set messages on the form.
and if the initial validation fails, the user (attacker bot) should not see if other fields are valid since this could expose unwanted information.

Example 2 reported by jpcondon (private issue)
==================
This module has a denial of service vulnerability.

You can see this vulnerability by:
1. Install Drupal.
2. Create content type with file field with two different restrictions on it, such as file size and file type.
3. Upload file with wrong file type and wrong file size and observe that both error messages appear.

While this isn't a big deal when simply validating file type or size, this presents a larger issue when using a module like the ClamAV module where it will attempt to scan the file even if other file validation errors have occurred. If a file is excessively large it will still be scanned which could cause a denial of service on the website.

Proposed resolution

a validation callback, should be able to bypass other validation callbacks.

This is basically implemented now for the form token check, but there is no such general feature in the API.

Remaining tasks

Decide how to add this feature in a backward-compatible way.

Commentary from @David_Rothstein:

There probably isn't a way to actually prevent other validation functions from running currently, but there should be some ways to prevent their error messages from displaying... Here's what I wrote elsewhere:

I don't think we necessarily need a change to Drupal core for this. I haven't looked too deeply into it, but couldn't you at least use something like form_get_errors(), form_set_error(), and form_clear_error() to clear out all validation errors on the form (at the end of the validation process) and then re-set the ones from the desired field only? I think something like this technique might work for both Drupal 6 and Drupal 7.

Also for Drupal 7 there's $form_state['triggering_element']['#limit_validation_errors'] which is a cleaner way to tell Drupal to ignore (and not display) certain form validation errors, but perhaps there's no place in the code where you can set that during form validation and have it work on the rest of the validation... not sure.

User interface changes

n/a

API changes

TBD

Data model changes

n/a

This meeting takes place every Friday at 14:00 UTC (currently 7:00am PT, 10:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@Gábor Hojtsy (he/him), @worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Antoniya, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @penyaskito, @Mike Gifford (CivicActions), @April, @Quynh, @yoroy, @EricRubino

Go to the issue for the next meeting to add/remove yourself to/from the list.

Recording of this week's meeting: https://youtu.be/ugO_ZGhs2bo

Rough transcript of this week's meeting: Drupal Usability Meeting - 2023-07-07.txt

We discussed the following issue:

• #2709507: [META] Remove outdated references to "upgrade" from core

NR and RTBC issues marked Needs usability review.

Problem/Motivation

User gets an error when trying to reference an unpublished entity that they have just created and that he has full access to. This basically makes it impossible for a user to submit a set of unpublished interreferencing entities (e.g. artefact/architect/city).

Steps to reproduce:

1. Create content type A, make sure Published is unchecked in the Publishing options.
2. Create content type B, add an ER field referencing A, choose Autocomplete widget in Form display.
3. Create a test user, give permissions to View own unpublished content, to Create A and B, to Edit own A and B.
4. Log in as that user.
5. Create a test node of type A, verify that it is Unpublished and the user can see it.
6. Create a test node of type B, start typing the label of the A node just created, verify that it's not recognised and suggested by the system.
7. Type the complete label and hit Save, get the "No such entity" error.
8. Type the entity label followed by its nid in parentheses, still get the "This entity (node: N) cannot be referenced”

This issue also prevents the user w/ appropriate permissions from referencing unpublished entities authored by other users.

Proposed resolution

Allow referencing unpublished entities if the current user has access to them.

Remaining tasks

Resolve what to do for entities that are created via an entity-reference field. (See comments #43–46)

The gist of the problem: The existing kludge that Core had before this patch misleads site builders and content creators into inadvertently exposing private content. Is it more important to fix that, or is it more important to avoid changing existing behaviour (because some people may be relying on that).

Options include:

• Do not make any changes to entity creation.
• Roll a separate issue for this, possibly bump to Drupal 10.
• Decide that fixing the problem is more important than maintaining existing behaviour.

Secondly, some changes to tests were recommended in comment #43 that still need to be addressed.

User interface changes

none

API changes

none

Data model changes

none

Release notes snippet

Problem/Motivation

In #3123832: [META] Fix @todo items referencing closed issues we've discovered there are a couple of identical @todos in \Drupal\Tests\rest\Unit\EventSubscriber\ResourceResponseSubscriberTest::providerTestResponseFormat.
This @todo is linked to an d.o. issue that is already closed: #2752325: Automatically provide HEAD support when a REST resource supports GET.

This is the @todo:

// @todo add 'HEAD' in https://www.drupal.org/node/2752325

Steps to reproduce

Proposed resolution

Re-enable the testGet() in this class since it now runs without errors.

Remaining tasks

Add 'HEAD'-method to \Drupal\Tests\rest\Unit\EventSubscriber\ResourceResponseSubscriberTest::providerTestResponseFormat, since support for that was added in #2752325: Automatically provide HEAD support when a REST resource supports GET.

User interface changes

API changes

Data model changes

Release notes snippet

Hi Team,

We use hook_entity_view_mode_alter() to change the view mode of an entity based on some conditions, but we also require the ability to override it with Layout Builder on the entity level. It seems that Layout Builder doesn't know about the hook; thus, it gets the layout from the default full view mode,

Expected Behavior

If the view mode has been changed by hook_entity_view_mode_alter(), the Layout Builder override should get the layout from the new view mode.

Please examine the attached image where I wrote in Black large font size what I mean by "empty space" here.

Why do Olivero webpages have empty space and how to remove this empty space?

Problem/Motivation

Amongst the current suppressions found in the PHPStan level 1 baseline is: Offset 'foo' on array{} in isset() does not exist..

This issue exists to fix all of those.

Steps to reproduce

- Run PHPStan on level 1 and see the above issue amongst all others.

Proposed resolution

- Solve all of the reported issues for the above mentioned.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet