Problem/Motivation

When adding an oembed remote video with the media module, the resulting video always displays at width 200px height 113px.
This is unlikely to be the desired outcome.

It is likely that most people will expect the video to display at the smaller of 100% width (of the content area) or the original width of the media in px, and maintain the original correct aspect ratio.

#3060968: Some oEmbed videos do not maintain aspect ratio has some examples of alternate .css in comment 27 and 62 to address the issue.

However this suffers from an assumption as to the desired ratio of the source video.

Steps to reproduce

This can be seen on any clean install of Drupal 10.x

1. Install Drupal
2. Enable the media module.
3. Insert a media field into the basic page content type
4. Create a content item with a remote oembed youtube video

It can be observed here:
https://tugboat10-radtonmrxxuykt76b3oveqdu9pp4zqwg.tugboatqa.com/node/59

Proposed resolution

Two potential solutions:

1. Alter the attributes of the iframe & its parent in PHP to add inline styles
2. Add JavaScript that adds inline styles to set the aspect ratio of the iFrame's parent

Problem/Motivation

The disabled checkboxes on the modules page are confusing: why can't I disable a module after I just enabled it? The reasons for this are complex and already discussed. But having re-experienced this issue recently, it's still confusing. We should provide *some* help for users.

Proposed resolution

Adding a simple title attribute provides a browser-based hover behavior that can help save time. It's not the ultimate solution, but it is easy to implement and a step forward with no downsides for desktop users.

Remaining tasks

Review text.

User interface changes

Hover text is shown in desktop browsers when the cursor hovers over the disable checkbox.

API changes

none.

Data model changes

none.

Problem/Motivation

DateTimeItem and DateRangeItem both have class constants. These should be on interfaces.

Proposed resolution

- Move the DateTimeItem constants onto DateTimeItemInterface as-is.

- Create DateRangeItemInterface, and move DateRangeItem constants as-is.

- Update usages to refer to the interface or static:: as appropriate.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

In #3349368-14: [policy, no patch] How much of The Update Framework integration is needed for alpha-level review/commit of Package Manager? @xjm stated that core cannot require https and therefore Package Manager will need to implement The Update Framework(TUF) as an Alpha requirement. The decision not to require https for core Automatic Update and Package Manager I guess was made a while ago(anybody with a source would be good). I know there was decision that contrib module could not require TUF while the drupal.org signing infrastructure was being created and to mitigate that it require HTTPs but It wasn't clear the core version would then drop the HTTPS requirement when it require TUF.

In relation to #3349368 since drupal.org's implementation of TUF would only cover packages.drupal.org and maybe drupal/ packages hosted on packagist that would mean that other packages would NOT have TUF protection. The current plan on #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged does not include signing for any other packages. This would mean fetching our vendor dependency would not be protected by TUF and if the module does not require https requests it will also not be protected by that.

Drupal core's current Update module requests the Update XML by default with HTTPS but does have fault back non-UI setting, update_fetch_with_http_fallback that allows using plain HTTP, see #1538118: Update status does not verify the identity or authenticity of the release history URL. Is the need for a fallback the same now? Interestingly translations require HTTPS and there is no fallback. See #3179318: Always use HTTPS for fetching translations. Is the difference because downloading translations is something that is done locally?

Proposed resolution

Possible solutions

1. Require HTTPS requests by Composer to use Package Manager and have some other modules like Automatic Updates require TUF for Drupal projects as planned in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged , 3rd party vendor packages would not be TUF protected but would always be fetched by HTTPS
2. Require HTTPS requests by Composer and require TUF for Drupal projects as planned in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged to use Package Manager. 3rd party vendor packages would not be TUF protected but would always be fetched by HTTPS
3. Don't require HTTPS requests by Composer but require TUF for Drupal projects as planned in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged to use Package Manager. 3rd party vendor packages would not be TUF protected and would NOT be fetched by HTTPS.
   

   ⚠️⚠️⚠️⚠️⚠️⚠️ IMPORTANT

   This seems to be what is currently proposed in #3349368: [policy, no patch] How much of The Update Framework integration is needed for alpha-level review/commit of Package Manager? unless it is assuming TUF protection which is not detailed in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged and while it protects drupal/ packages 3rd party packages are not protected

4. Don't require HTTPS requests by Composer but require TUF protection for Drupal projects as planned in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Ruggedand require TUF for all Composer packages to use Package Manager. 3rd party vendor packages would be TUF protected ,, , nothing would be fetched by HTTPS. This would require either Packagist to implement TUF or drupal.org to provide signing for all the Packagist resource
5. Don't require HTTPS requests by Composer but require TUF protection for Drupal projects as planned in #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Ruggedand require TUF for all Composer packages in core's dependency tree to use Package Manager. Some 3rd party vendor packages would be TUF protected but dependencies of Contrib or custom code would not. nothing would be fetched by HTTPS. This would require drupal.org to provide signing for all packages in the Drupal core dependency tree
6. Require both HTTPS and TUF for Drupal.org and packagist, only HTTPS for anything else
7. Require TUF for Drupal.org and packagist, encourage HTTPS via a hook_requirements() warning without a hard requirement

Remaining tasks

Determine the best solution that can be implemented. There may be more than I could think of in the list above

Problem/Motivation

Amongst the current suppressions found in the PHPStan level 1 baseline is: #pre_render/#lazy_builder callback '\Foo\Bar' at key 'n' is not trusted..

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.
- Run PHPStan on level 1 and don't see the above issue any more.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

It would be keen if Drupal core were nice enough to alert you if you tried to register a module and theme of the same name... but it doesn't.

If you name your theme and a module the same name you get name space collisions. E.G samename_block(..) will conflict if you have it declared in both module and theme.

It would save a lot of new Drupal developers frustration if Drupal didn't let you register a theme and active module by the same name.

Also noted here http://drupal.org/node/143020

Problem/Motivation

Currently, tabledrag displays a warning message when a row is dragged, stating that changes are not saved until the form is submitted.

However, There are other tabledrag changes that warrant this warning message (e.g 'Manage display' screen, when the settings of a formatter are changed), changing a widget, etc.

Additionally, layout builder added some code that results in formatter changes incorrectly being saved as soon as the change is made, instead of requiring a save on the manage display/manage form display form . That should be addressed here so the need to save these settings in the tabledrag is consistient.

Steps to reproduce

Make any change that requires saving manage display/manage form OTHER than moving a row, and notice that there is no warning that the manage display/manage form display form must be submitted to save the changes, despite that being necessary to save the changes.

Proposed resolution

With JS, trigger the "must be saved" warning to appear based on any change that will not be stored until the manage display/manage form display form is submitted.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Performance issue with Views query plugin.

The Views getCountOptimized is never set to TRUE. Every view creates two queries, the 'query' and the 'count_query'. The 'query' is created first, then the 'count_query'. In the first pass while creating the 'query', 'get_count' is FALSE, and thus it sets 'getCountOptimized' to FALSE. On the second pass while creating the 'count_query', 'getCountOptimized' is already set, so it's not recalculated. Had it been recalculated, it would have been set to TRUE on the second pass.

This code goes all the way back to where the 7.x-3.x branch was added in https://git.drupalcode.org/project/drupal/-/commit/a626abb24faa51ac140f7.... This may have been broken for a long time.

Proposed resolution

Views getCountOptimized is never set to TRUE, use local variables instead of global

Remaining tasks

Need Automated Testing

User interface changes

API changes

Yes

Data model changes

Nil

Problem/Motivation

Duplicate maintenance mode message displayed.

Steps to reproduce

1. On any content type that has a simple file field, create a node with an attachment file.
2. Put the site in maintenance mode.
3. Edit the node and remove the file attachment by clicking on the "Remove" button beside the file.
4. Now when the file is removed, the form has the "Operating in maintenance mode. Go Online" message at 2 more places on the form, apart from the usual top message.

Proposed resolution

Display on one message, at the top of the screen.

Remaining tasks

Write a test
Add new before screenshot to the User interface changes section of the Issue Summary
Add an after screenshot to the User interface changes section of the Issue Summary
Review

User interface changes

Before

After

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

In kernel tests we lack page requests ($this->drupalGet()). We could make use of a custom language negotiator that

1. helps to render things in a given language
2. helps to test language url prefixes.

Problem/Motivation

Package                                Current Wanted  Latest
stylelint                 14.16.0 14.16.1 15.4.0   
stylelint-config-standard 29.0.0  29.0.0  32.0.0   
stylelint-order           5.0.0   5.0.0   6.0.3  

Steps to reproduce

Proposed resolution

yarn add -D stylelint stylelint-config-standard stylelint-order
yarn build:css
yarn lint:css

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

\Drupal\Core\Menu\LocalTaskManager::getLocalTasksForRoute is not optimal at the moment

Proposed resolution

Improve it by extracting things into dedicated methods which have each proper documentation. This itself is worth it

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The States API won't pick up the value of a select field with #multiple = TRUE option.

Steps to reproduce:
- Create two fields in a form with the following code:

  $form['dependee'] = array(
    '#type' => 'select',
    '#options' => array(
      'a' => 'Option A',
      'b' => 'Option B',
      'c' => 'Option C',
    ),
    '#multiple' => TRUE,
  );

  $form['dependent'] = array(
    '#type' => 'textfield',
    '#states' => array(
      'visible' => array(
        'select[name="dependee[]"]' => array('value' => array('a')),
      ),
    ),
  );

The dependent field will stay hidden regardless of the value of the dependee. This happens because the value of a multiple select field is an array, and States tries to compare it with the reference with a === operator, which returns always false.

Proposed resolution

Add a handler for arrays in states.Dependent.comparisons. This works with ANDed values:

'select[name="dependee[]"]' => array('value' => array('a', 'b')),

and with ORs as well (following the syntax proposed in #735528: FAPI #states: Fix conditionals to allow OR and XOR constructions):

'select[name="dependee[]"]' => array(array('value' => array('a')), array('value' => array('c')))

Remaining tasks

1. Land #2702233: [backport] Add JavaScript tests for Form API #states: required, visible, invisible, expanded, checked, unchecked so we have somewhere to put tests for this.
2. Expand that test to cover this case.
3. Upload test-only vs. full patch to verify test and fix.
4. Further reviews/refinements.
5. RTBC.
6. Commit to D9/D8.
7. Open follow-up issue to backport to D7.

User interface changes

This feature finally works as intended:

Before

After

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD.

Problem/Motivation

When pagination navigation happens, even tough exposed filters are default, the reset button will be displayed.

Steps to reproduce

1. Go to /admin/content view with enough nodes to trigger pagination
2. Don't fill in any filters
3. Go to another page
4. Reset button appears

Proposed resolution

Don't display reset button when form is empty and using only pagination.

Remaining tasks

Review patch
Commit

User interface changes

NA

API changes

NA

Data model changes

NA

Release notes snippet

NA

Original Post

When pagination navigation happens, even tough exposed filters are default, the reset button will be displayed.

Steps to reproduce

1. (optional) Edit the content views pager to make sure it has more than one page.
2. Got to content and without changing any filters navigate to the second page

This happens with all views and in all 8.x drupal.

Drupal 10's new theme generator tool is intended to replace the need for creating subthemes from existing core themes. This will enable core themes to change markup without the need to take into account subthemes and backwards compatibility.

This issue is to allow the theme generator tool to clone Olivero.

Things that we'll need to do:

• Bring build step into Olivero - this is the ability to compile PostCSS
• Rename Olivero filenames.
• Rename functions etc

File names that will need to be renamed

• All of the config items within core/themes/olivero/config
• core/themes/olivero/olivero.breakpoints.yml
• core/themes/olivero/olivero.info.yml
• core/themes/olivero/olivero.libraries.yml
• core/themes/olivero/olivero.theme
• core/themes/olivero/src/OliveroPreRender.php

File contents that will need to be renamed

• Various config within /config
• Lots of comments within the JavaScript
• The JavaScript config that gets loaded at Drupal.olivero
• Color settings that get loaded under drupalSettings.olivero
• Various once names (these may be able to have the namespace removed)
• Various CSS selectors (.olivero-details)
• Various CSS Animation names (eg olivero-throbber)
• References to Olivero in /templates (eg {% include '@olivero/includes/preload.twig' with { olivero_path: olivero_path } only %})
• Comments within /templates
• Libraries attachments ({{ attach_library('olivero/layout-views-grid') }})
• Everything olivero related in olivero.theme and theme-settings.php

To figure out

• Tests. This all seems pretty brittle. If we change something, we need to make sure the theme generator works.
• We need to ensure that the user-supplied theme name is valid. This needs to work in the JavaScript, preprocessing, templates, etc.

Testing Instructions

• Checkout the MR branch to local/gitpod
• cd into the webroot
• php core/scripts/drupal generate-theme <theme_machine_name> --name "<Theme Name>" --starterkit olivero
• Check new theme for any files that have "olivero" in their name or file contents

Problem/Motivation

Currently all documentation is within markdown files within the code itself (within the MR at #3340712: Add Single Directory Components as a new experimental module).

Proposed resolution

Let's move documentation to drupal.org pages.

This is not a bug report

The bug report is here: #3125827: Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder".
That issue needs help with reliably reproducing this bug outside of a migration.
This is a support request that includes a workaround patch to help you identify the malformed config on your site.

Original report by adubovskoy

Existing drupal 8 site (upgraded from 8.2.x to 8.3, 8.4, 8.5). Current version 8.5.5 . If I enable layout_builder, then:

Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions() (line 111 of /home/agwophqf/public_html/core/modules/layout_builder/src/Plugin/Derivative/FieldBlockDeriver.php) #0 ...

Problem/Motivation

Views integration works for config fields created in the UI, but not for base fields added to the entity types in code.

As an example, consider Date module. That diligently implements datetime_range_field_views_data() to declare its custom Views filters and arguments. But if I add a date field to my entity's base fields, the Views integration is completely missing.

Proposed resolution

Add the views handler to the field annotation as with the entity annotation. Provide the default base class for standard views data. Allow custom fields to have specific classes for views data.

Remaining tasks

Write a patch for the above proposed resolution.

User interface changes

None

API changes

API completion

Data model changes

None

Release notes snippet

TBC

This is a stable blocker for SDC.

Documentation exists at the Single Directory Components Documentation Guide at https://www.drupal.org/docs/develop/theming-drupal/using-single-director....

We need to do the following

• Review and improve the current documentation
• Create a FAQ (very early work at https://docs.google.com/document/d/1WfBAKeFvgoZiCUyBu2jfS1XxDaejwLEX4JN3...)\
• #3352262: Create SDC "Quick start" documentation / code

Completed

• #3352272: SDC: Move the documentation from markdown to Drupal.org (this is actually a beta blocker)

Problem/Motivation

The toolbar experiences several kinds of visual flickering when initialized.
This issue is specific to the flickering that results from top or side padding being added shortly after the page is rendered, in order to make space for open trays (top padding added for horizontal trays, side padding added for vertical)
This happens on every page-load, both in vertical and horizontal orientation.

There are 4 possible states:

In the gif attachments you can clearly see this.
These gifs are recorded with Standard profile and Drupal 8.7.x.

Note that the flicker of the 'admin' button in the black top-menubar is not part of this issue, see #2951268: Improve rendering account link in the toolbar
The toolbar in general has it's share of flickery things that can't all be addressed within this issue, but see gifs below for the specific problem being targeted and see this video of the proposed fix in action as of April 4 2023.

Visual effect

Horizontal toolbar orientation

Main-content area jumps 1 row lower (exactly the toolbar height) on page-load.
Main-content starts with Drupal-icon + "toolbar_rendering_...".

Vertical toolbar orientation

Main-content area goes from 100% width to 80% width (exactly 100% minus toolbar width).
You see the main content moves from left to right on page-load.

Proposed resolution

The reason is that javascript is used to add/change some css-classes to the page that are used by the toolbar.
And this javascript is executed after the initial page drawing.
Therefor the browser paints the toolbar twice when loading the page.

The css-classes needed for painting the toolbar must be there on initial page-load. So that the first html delivered to the browser contains the toolbar state. Pseudo-code <div class="toolbar toolbar-orientation-vertical toolbar-shortcuts-open"></div>. This can be added by inlining JS that loads before the page is painted, and adding the necessary classes to the <html> tag - the only tag available that early in the rendering process.

Remaining tasks

User interface changes

API changes

Data model changes