RuntimeException: Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() func Failed to start the session because headers have already been sent by "" at line 0. (/xxx/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php 152)

#0 /xxx/web/core/lib/Drupal/Core/Session/SessionManager.php(162): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start()
#1 /xxx/web/core/lib/Drupal/Core/Session/SessionManager.php(193): Drupal\Core\Session\SessionManager->startNow()
#2 /xxx/vendor/symfony/http-foundation/Session/Session.php(189): Drupal\Core\Session\SessionManager->save()
#3 /xxx/web/core/lib/Drupal/Core/StackMiddleware/Session.php(60): Symfony\Component\HttpFoundation\Session\Session->save()
#4 /xxx/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle()
#5 /xxx/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#6 /xxx/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#7 /xxx/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle()
#8 /xxx/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#9 /xxx/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#10 /xxx/web/core/lib/Drupal/Core/DrupalKernel.php(716): Stack\StackedHttpKernel->handle()
#11 /xxx/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#12 {main}

apache2, php 7.4, debian 10; I have installed drupal 9 on it but I am getting this error. what could be missing?

Problem/Motivation

Using core 8.7.6, if you make a JSON:API resource request which has an include and an entity does not have that included entity reference field populated, the following results:

Warning:

Warning: array_flip(): Can only flip STRING and INTEGER values! in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 265 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array) (Line: 147)
Drupal\jsonapi\IncludeResolver->resolveIncludeTree(Array, Object) (Line: 74)

The code stems from IncludeResolver.php:
$references[$target_type][] = $field_item->get($field_item::mainPropertyName())->getValue();

Proposed resolution

Check that the field returned a value before using it.

Remaining tasks

Write a patch.

Problem/Motivation

Our documentation specifies that #ajax items in render arrays must be arrays. RenderElement::preRenderAjaxForm() confirms this behavior. Yet in three places we set '#ajax' => TRUE in render arrays.

Proposed resolution

- Update \Drupal\Core\Render\Element\Ajax documenation.
- Make sure '#ajax' => TRUE are accepted - transform into array in core/lib/Drupal/Core/Render/Element/RenderElement.php

Remaining tasks

- Update drupal.org and api.drupal.org documentations after commit.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

In reviewing #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`, the UX team had this feedback about the "remove" button that appears for each embedded media item:

...it [is] entirely too easy to accidentally stray-click the "X" icon and remove an embed. They asked for a confirmation dialog to be displayed first. Since the existing image embed button does not display an "X" (you just have to click the embedded image and press Delete on your keyboard), we agreed to remove the "X" button from this patch and add it back, with a confirmation alert box, in a follow-up.

That's this follow-up.

Proposed resolution

Restore and update the relevant code from #2994702-43: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption` into a new patch in this issue, and add a confirmation dialog when the "remove" button is clicked. (Also, figure out if the presence of the confirmation should be configurable.)

Remaining tasks

Restore the old code, then determine what the text of the confirmation box should be, whether it should be configurable, etc. Then add tests, get UX and accessibility sign-off, and commit.

User interface changes

Media items embedded in a CKEditor instance will receive a new button which allows them to be removed from the content.

API changes

None expected.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

When implementing the Streamable OEmbed, the thumbnail URL is provided, but Drupal throws a Failed to open stream: No such file or directory error for the file_get_contents() function. This leads to a situation where the thumbnail URL is set, but its height & width cannot be determined, which breaks the flow.

Steps to reproduce

1. Implement the Streamable OEmbed provider (I used the OEmbed Providers module)
2. Create a new media type with this provider.
3. Attempt to add a streamable URL (such as https://streamable.com/pt3eor) as a new media item.
4. See the Failed to open stream: No such file or directory warning thrown, and the additional The thumbnail dimensions must be numbers greater than zero. error in the logs.

Proposed resolution

Add an additional check that the URL can be retrieved before getting the thumbnail dimensions.

Spin-off from #1499596-96: Introduce a basic entity form controller:

I noticed that due to $controller->form_state the form state gets serialized *into itself* when it is cached. I've discussed that with plach and we agreed to remove $controller->form_state for now and just pass it on to respective methods always. We may want to simplify the getEntity() calls to do not require the passed on form-state again in the follow-up where we fix the controller being still duplicated to $form and $form_state.

To be completed.

A '\n' (newline) character is included at the end of every tag output by theme_html_tag(). This causes extra whitespace that may not always be desired. One specific example is for use with sprite icons that are included within links.

<a href="#"><span class="sprite"></span>Text</a> 

If the span above is rendered using theme_html_tag() then there will be extra whitespace between the icon and the text because of the newline character. Any spacing would be better controlled by css (margin or padding).

Related CRhttps://www.drupal.org/node/2019739

Problem/Motivation

When a render array sets $elements['#access'] to an AccessResultInterface instance, any cache metadata on that object is thrown away when the instance is not AccessResultAllowed.
If the access check was "allowed" the cache metadata bubbles up as it should, so content can be re-rendered in case of invalidation or contexts are different. If denied/neutral, no rendering happens, but also no bubbling, so only cache contexts/tags/max-age for those with access will influence what goes into the cache. The expected result would be that no matter which type of access result is returned, the cache metadata is kept so it can be re-evaluated for the next user.

Steps to reproduce

This was discovered while working on #2473873-111: Views entity operations lack cacheability support, resulting in incorrect dropbuttons as with that patch, some operation links appeared for the wrong user if someone with access visited a cached page before them, or the other way around, because the 'user' cache context added via the AccessResultInterface in the operation link's '#access' key.

The easiest way to reproduce this is with a controller returning a custom render array which sets $element['#access'] = AccessResult::allowed()->cachePerPermissions() for one user and $element['#access'] = AccessResult::forbidden()->cachePerPermissions() for another. Depending on which user views the page first you get different results after both of them have visited the page.

Proposed resolution

The renderer should bubble the cache metadata if it encounters an element which has $element['#access'] instanceof AccessResultInterface and the result is not allowed, near the start of ::doRender(), same as it does a few lines below if the result was allowed.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

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

While working on the parent issue #3362898: Password input width is incoherent and overflows, we found that password-confirm class is used twice.

Steps to reproduce

1. Go to /admin/people/create page.
2. Search for password-confirm class.

Proposed resolution

Update password confirm class on pass2 password input by password-confirm-field and js-password-confirm to js-password-confirm-field

Remaining tasks

Patch
Review
Commit

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

When #2633878: Finalize cacheability for plugins is fixed, add a @CacheableMetadata annotation that is parsed to a CacheableMetadata, so statically defined plugins are able to share their cacheability metadata.

Since #2633878: Finalize cacheability for plugins is a bug fix, and without this issue statically defined plugin definitions cannot be cached, I am marking this a bug as well.

Problem/Motivation

Plugin derivers are essentially a foreach loop for providing plugin definitions.
Typically they iterate over the result of some other service, creating a definition for each item.
If that list of items changes, the plugin definition cache must be cleared so that the deriver can accurately reflect the up-to-date list.

In practice, this has meant that another piece of code, like a hook implementation, will manually clear the plugin definition cache.

For example, \Drupal\system\Plugin\Derivative\SystemMenuBlock loops over all menu entities to provide menu blocks.
\Drupal\system\Entity\Menu::save() and \Drupal\system\Entity\Menu::delete() are then responsible for clearing the block plugin definition cache.

Proposed resolution

Plugin managers already support the use of cache tags for their definitions cache.
Allow the derivers themselves to affect the list of cache tags used.
This will remove the need for external code (like a hook) to clear the cache.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

When taxonomy terms were converted to be revisionable in #2880149: Convert taxonomy terms to be revisionable we disabled Content Moderation integration because the UI was not ready yet.

Proposed resolution

After #2899923: UI for publishing/unpublishing taxonomy terms lands, we should re-enable CM integration.

Remaining tasks

See #39

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

While discussing #2035079: Figure out what to do with the install/uninstall modules page at #3373236: Drupal Usability Meeting 2023-07-14 we identified several issues with disabled checkboxes on the uninstall modules page:

1. Disable form elements are not recommended from an accessibility or usability perspective, we should avoid using them.
2. If the user wants to uninstall a module, along with all of the modules which depend on that module, it is currently not possible to do this in a single action. The user must first identify the modules that depend on that module, uninstall those, then they can finally uninstall the original module. This gets quite tedious when you have multiple levels of dependencies.
3. The uninstall module experience does not provide feature parity with the install module experience. The install modules list allows the user to select any module which is currently not installed (assuming no dependencies are physically missing), and if that module has dependencies, Drupal will automatically install those, and inform the user of this on the confirm form.

Steps to reproduce

Proposed resolution

Allowing users to select even modules which other installed modules depend on would solve the usability and accessibility issues with disabled checkboxes. After the user selects one or more of these modules, the confirm form would then provide a list of modules which will also be uninstalled should the user choose to proceed.

For example, if the user selects the Migrate module, the confirm form would list the Migrate UI module as a module which would also be uninstalled (assuming the user had Migrate UI installed).

We want to draw the user's attention to this, so styling this information as a warning message, and using a bulleted list, would help to ensure that the user is aware that other modules will also be uninstalled.

This also provides parity with the install confirm form, the install module form shows not only the modules the user selected but also any modules that the selected modules depend on.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In #3123832: [META] Fix @todo items referencing closed issues we've discovered there's a @todo in \Drupal\Tests\rest\Unit\EventSubscriber\ResourceResponseSubscriberTest::providerTestSerialization.
This @todo is linked to an d.o. issue that is already closed: #2427811: ResourceHandler can't serialize a stdClass.

This is the @todo:

  public function providerTestSerialization() {
    return [
      // The default data for \Drupal\rest\ResourceResponse.
     [snipped]
      // @todo Not supported. https://www.drupal.org/node/2427811
      // [new \stdClass()],
      // [(object) ['test' => 'foobar']],
    ];
  }

Proposed resolution

#2427811: ResourceHandler can't serialize a stdClass was closed as a ''won't fix", with this remark by @WimLeers:

There's no more need to use \stdClass. You should always use actual classes/interfaces. Otherwise… just use array. And as #15 says: arrays work fine.

I don't see why we would want to support \stdClass.

Let's remove the @todo as is no longer seems relevant.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While reviewing #2035079: Figure out what to do with the install/uninstall modules page at #3373236: Drupal Usability Meeting 2023-07-14, we identified that when installing multiple modules, the install confirm form does not use a bulleted list, instead it displays all modules on a single line.

Meanwhile, the uninstall module confirm form displays each module on a separate line, using a bulleted list.

Using a bulleted list for the install confirm form would be easier to read and more user friendly than a comma-separated list on a single line.

Steps to reproduce

Proposed resolution

Change the module install confirm form to use a bulleted list for the list of modules which will be enabled. Styled similarly to the uninstall module confirm form.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There's some deprecations in upcoming PHP 8.3

- https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures
- https://wiki.php.net/rfc/assert-string-eval-cleanup

Proposed resolution

https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#...
- Replace deprecated get_class() call without argument

$ git grep 'get_class()'
core/lib/Drupal/Component/Plugin/PluginManagerBase.php:128:    throw new \BadMethodCallException(get_class() . '::getFallbackPluginId() not implemented.');

https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#...
- ReflectionMethod::__construct() with 1 argument

core/lib/Drupal/Component/Utility/ArgumentsResolver.php:126:      return new \ReflectionMethod($callable);

https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#...

$ git grep -A 5 ReflectionProperty|grep setValue
core/tests/Drupal/Tests/Component/Utility/HtmlTest.php-31-    $property->setValue(NULL);

Problem/Motivation

While reviewing #2035079: Figure out what to do with the install/uninstall modules page at #3373236: Drupal Usability Meeting 2023-07-14 we agreed that using a drop/split button for the module links could provide a better overall user experience, and make the module list slightly more consistent with other areas of Core.

Currently, the module links are hidden in the expandable description detail element, so moving them to a more prominent position could make them easier to access.

Steps to reproduce

Proposed resolution

This would involve adding a drop/split button to the far-right side of each module in the module list and moving the module links out of the expandable description detail element.

For installed module, the drop/split button would contain the existing links. We may also want to add a Uninstall link, as this could provide a slightly more convenient way of uninstalling a module right from the list.

For uninstalled modules, we could provide a single Install link, this could result in a slightly more convenient experience for installing a single module, where the user could simply click the link, rather than having to select the checkbox next to the module then scroll to the button of the list. On some sites the module list can be quite lengthy, so this could save time for users.

This issue does not currently have an opinion about whether or not the module link icons should be retained. Discussion and prototypes/screenshots may be required to assess how well icons work in a split/drop button layout.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Post-#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, the Modules UI looks like this:

Checkboxes are used in order to enable modules. However, once modules are enabled they can never be disabled, so the checkboxes stay checked and disabled, even for non-required modules and modules without sub-dependencies (unlike what the disabled checkboxes represented in Drupal 7).

The only thing you can do after enabling a module is uninstall it, but that's on a separate tab, which is not immediately obvious. The discussion here is how to address this disconnect, ideally by combining the two pages.

Proposed resolution

Several proposals have been put forth:

Option 1: Move checkboxes to "bulk operations" style checkboxes, add drop-button for action, add column to indicate on/off status of modules

Mock:

Option 2: Keep checkboxes as they are, make the "off" version perform uninstall

This is the simplest thing that could possibly work. It's tricky however, since "uninstall" is destructive, making it very easy for people to accidentally delete data they didn't mean to by making it "too" easy to perform uninstallation, especially if enabling/uninstalling modules are combined into the same form submission.

yoroy mocked a confirm form to warn people about potential destruction, in response:

Updated confirm form from Bojhan:

Option 3: Stop using checkboxes for communicating state; switch to buttons instead

Possible mockup from Bojhan in #54:

The advantage to this approach is that colour cues as well as labels can begin a warning prior to initiating any action. There is also no chance of weird interactions when trying to install and uninstall modules in the same page request. The disadvantage is installing multiple modules in one go is no longer possible (which is convenient esp. for modules like Drupal Commerce, etc. with multiple sub-modules), though presumably toggling would initiate an AJAX request so it wouldn't be quite as tedious (however, bear in mind that each button click is initiating a 30+ second page load by rebuilding all of the various caches).

This one has one other strong advantage which is that it is a very visually stark change from Drupal 7, which is indicative of the stark behavioural change from Drupal 7 as well, which will hopefully cut down on accidental destruction of data from those who do not read warnings carefully enough.

Option 4: Add uninstall button to each enabled module

Similar to browser extension UIs, this would place the uninstall button on the same row as the enabled module, within the "expanded" view. This also has the advantages of being highly visible what you're about to do, and an incremental improvement. We would lose the feature of being able to uninstall many modules at once, but this could be a "feature" from a stability POV.

Option 5: Make modules page similar to admin/content

Same style and pattern as with content and module specific actions as dropbuttons. Also including bulk actions and combining this list/layout with confirmation page from Option2.

Remaining tasks

Discuss, deliberate, make a decision.

User interface changes

Yes; that's rather the point. ;)

API changes

Unknown.

Original report by @fubhy

D.o procid experiment

This issue would be a good case study to evaluate procid #2154143: Evaluating Procid, a tool to help the drupal community improve the consensus building process for d.o issues
You do not have to use procid to work on this issue, but if you want to, your feedback would be very helpful.

----

Follow-up / spin-off for #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

Once #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed is in the install/uninstall modules page are going to need some serious overhaul and re-consideration regarding the UX. Let's discuss that here. We might end up with only one page too if we can figure out how to solve this in a way that does not end up with people accidentally uninstalling modules and thereby deleting all their data.

There are currently two WSCCI conversion issues for these two pages:

#1990544: Convert system_modules() to a Controller
#1993202: Convert system_modules_uninstall() to a Controller

Which did get a fair amount of love already. We might want to do a straight conversion first and then fix this issue afterwards after using those two issues basically as first iteration for a clean-up of the existing code.

This issue is critical as it's a required follow-up for the original issue which is also critical.

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: TODO

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

We discussed the following issue:

NR and RTBC issues marked Needs usability review.