Problem/Motivation

This will remove the services deprecated in #2979588: Deprecate Laminas\Feed reader and writer services

Proposed resolution

Do it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This issue is to create a new “Views Responsive Grid” format in Drupal 10 core.

Background

We've fixed this in Olivero, and the 10.x solution is fantastic. It injects the number of columns into the markup via inline CSS variables, and also sets a minimum width for the grid cells.

The browser will automatically readjust the column count taking into account the inputted number of columns (which it treats as a maximum value) and the minimum width of the grid cell.

• Codepen demo: https://codepen.io/mherchel/pen/xxXXbog
• Drupal 10.0.x demo: https://3151553-views-grid-responsive-smap87qfp2e6gy4lp8twqyulyaobwpib.t...
• CSS in Olivero: https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/oliv...

Views UI Settings

Responsive horizontal style in action (in Stark theme)

Responsive vertical style in action (in Stark theme)

Testing instructions

1. Apply patch (or pull branch) and clear cache
2. Create or modify a View that uses the new “Responsive Grid” format (available in the “Format” section of the Views UI
3. Go into the settings for this format, and adjust the various options. There are four:
   1. Maximum number of columns: This is where the grid “wants” to be, if the grid container has space enough so that the grid cells are not under the “Minimum grid cell width” setting.
   2. Minimum grid cell width: As the grid container is resized, the grid cells with grow shrink to maintain the maximum number of columns. However, once the grid cells reach the “Minimum grid cell width” value, the number of columns will be reduced to maintain this minimum width.
   3. Grid gutter spacing: This is the space that will be between the grid cells (in pixels). This maps to the CSS gap property.
   4. Alignment: these two options are exactly the same as the old “Grid” format. If set to “Horizontal” the Views rows will be ordered left to right (or RTL if needed) and appear in horizontal rows. If set to “Vertical” the grid items will be formatted using CSS columns and be ordered from top to bottom and then left to right (or RTL).
4. View the grid page and resize the browser and play around and verify all the settings. Verify it works as expected.
5. Test in multiple browsers such as Chromium, Safari, Firefox.

Problem/Motivation

FrameworkTest sets $headers[] = 'X-Requested-With: XMLHttpRequest'; but it should be $headers['X-Requested-With'] = 'XMLHttpRequest';

Steps to reproduce

Proposed resolution

Fix the code.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When installing from existing config, interface translations are always downloaded and imported, regardless of locale's translation.use_source config.

The download of drupal PO files happens in install_check_translations():

if ($translations_directory_exists && $readable && $writable && $translation_available) {
  $translation_downloaded = install_retrieve_file($translation_url, $translations_directory);

  if (!$translation_downloaded) {
    $requirements['translation downloaded'] = [
      'title'       => t('Translation'),
      'value'       => t('The %language translation could not be downloaded.', ['%language' => $language]),
      'severity'    => REQUIREMENT_ERROR,
      'description' => t('The %language translation file could not be downloaded. <a href=":url">Choose a different language</a> or select English and translate your website later.', ['%language' => $language, ':url' => $_SERVER['SCRIPT_NAME']]),
    ];
  }
}

Shouldn't there be an extra check for locale_translation_use_remote_source()?
My understanding is that if we set locale's config: translation.use_source: local, then Drupal should not try to fetch PO files from the server.
Is this a bug or intended behavior?

Proposed resolution

Possibly by adding an extra check for locale_translation_use_remote_source() in install_check_translations()

Problem/Motivation

Under circumstances system updates will not be executed as the first ones even if there are no dependencies preventing this. However there are cases where the system and the DB should be prepared before other updates are allowed to run.

Actually there are a lot of places in the core, which are suggesting that it is desired that system updates are the ones being executed first, but under some circumstances this is not completely guaranteed - e.g. having one system update and multiple updates of another module leads to assigning lower weights to the updates of the other module.

Proposed resolution

In update_build_dependency_graph() find update functions without edges to system updates and add such updates as edges to system updates so that system updates are executed first / get assigned lower weights by \Drupal\Component\Graph\Graph::searchAndSort().

Provide a general check in \Drupal\FunctionalTests\Update\UpdatePathTestBase assuring system updates will be executed first.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.

If the BookNavigationBlock does not have the configuration option "all pages" (UI option "Show block on all pages"), it only displays the subpages of the current book in the navigation block.

On line 143 there is this code:

          $data = $this->bookManager->bookTreeAllData($node->book['bid'], $node->book);
          $book_menus[$book_id] = $this->bookManager->bookTreeOutput($data);

which outputs the items in the book using ->bookTreeOutput()

but for some reason, on line 177, it only outputs the subpages:

 $tree = $this->bookManager->bookTreeAllData($node->book['bid'], $node->book);
  
        // There should only be one element at the top level.
        $data = array_shift($tree);
        $below = $this->bookManager->bookTreeOutput($data['below']);
        if (!empty($below)) {
          return $below;
        }

I guess some developers would only want the some pages, so I'm not sure if this is a bug, or should be an option.

Problem/Motivation

The current approach on #3050384: Provide a starterkit theme in core only support single starterkit theme to be used as the starting point for generated themes. However, it could be useful to have other themes be available as the starting point.

Proposed resolution

Allow themes to indicate if they can be used as a starting point on the starterkit theme generator. We probably should also provide command that allows finding themes that can be used a starterkit theme.

Scope of this issue

This issue only consists of

1) Allowing themes to specify starterkit: true in the info.yml file
2) Theme generator will only be able to duplicate themes that have this specified
3) Appropriate test coverage.

Testing instructions

1. Run help php core/scripts/drupal generate-theme --help , and verify starterkit info is ouput
2. Verify that bartik cannot be used by this script by running php core/scripts/drupal generate-theme --starterkit bartik mike
3. Add starterkit: true to bartik.info.yml
4. verify that bartik gets copied over as a starter theme by once again running php core/scripts/drupal generate-theme --starterkit bartik mike

Release notes snippet

There is a strange behavoir with the _form_alter hook if the form is located inside an block. The form attributes are set on the block instead of the form element.

We had this issue with the search api pages block and now again with an views exposed filter block.

Steps to reproduce (fresh Drupal 8 installation):

1. Create a view
2. Add some fields and filters which are exposed to the user
3. Under "Advanced" choose Exposed form in block > Yes
4. Save the view and add the block
5. See the markup, for example the "views-exposed-form" class is set on the block instead of the form. If you switch the view setting Exposed form in block to NO, its correctly printed out as form class

Problem/Motivation

I'm finding more and more incomplete or wrong type hints with PHPStan. We are running PHPStan on our private code base, but it complains about type mismatches due to Drupal core not being documented correctly.

Example:
Parameter #1 $label of method Drupal\Core\TypedData\DataDefinition::setLabel() expects string, Drupal\Core\StringTranslation\TranslatableMarkup given.

Steps to reproduce

Run PHPStan with at least level 5 on a code base that makes use of a lot of core APIs.

Proposed resolution

Start a PHPStan initiative to run a phpstan.neon config on Drupal core itself to figure out problems. We can enable PHPStan runs on the testbot by modifying drupalci.yml and adding a step. That way we prevent regressions for any Drupal core changes in the future.

• commit a patch (this issue) with ignores and a baseline that can enable running PHPStan level 0 and prevent further level-0 issues to enter the codebase
• in this issue, keep to a minimum other code changes - i.e. only those without which PHPStan execution would crash
• once committed, open followups to clean baseline and ignores to level up the existing codebase to level 0
• once above done, repeat the same for level 1 and so forth

Dependency evaluations

Dependency evaluation for PHPStan

Maintainership: Very frequent releases. 55 million downloads from packagist. One of the main static analysis tools for PHP.
Security policies: See https://github.com/phpstan/phpstan/blob/260513fc8d06403dfe82e7665262ca1c.... This is a dev tool and will not be present on production. There has not been a security issue raised against the project.
Expected release and support cycles: Frequent. Version 1.0 was released in Nov 2021. We are already on 1.3.3

Dependency evaluation for phpstan/extension-installer

Maintainership: Part of the PHPStan package.
Security policies: None. This is a dev tool and will not be present on production. This is a composer plugin to make it easy to use libraries which add PHPStan rules.
Expected release and support cycles: Likely to change only when to composer changes.

Dependency evaluation for mglaman/phpstan-drupal

Maintainership: Maintained by Matt Glaman who has worked on Drupal for many years.
Security policies: See https://github.com/mglaman/phpstan-drupal/blob/main/.github/SECURITY.md. This is a dev tool and will not be present on production.
Expected release and support cycles: Will change when an upstream change in PHPStan forces it to. Likely to change as more rules are added because of usage by core :)

Dependency evaluation for webflo/drupal-finder

Maintainership: Maintained by webflo who has worked on Drupal for many years.
Security policies: None. This is a dev tool and will not be present on production. It is used by Drush so it present on thousands of Drupal installs already.
Expected release and support cycles: Only likely to change if core changes it's directory structure.

Remaining tasks

1) One ignored error in phpstan.neon

+++ b/core/phpstan.neon.dist
@@ -0,0 +1,36 @@
+		# @todo files below need to be excluded as they prevent baseline generation.
+		# Fixing them is a priority.
+    - modules/link/tests/src/Kernel/LinkItemTest.php
+

would be nice to be fixed before commit, but it's not a blocker.
It's currently being looked at #3254966: PHPStan error LinkItemTest and upstream at https://github.com/mglaman/phpstan-drupal/pull/279, https://github.com/mglaman/phpstan-drupal/issues/228, https://github.com/phpstan/phpstan/issues/6231. Once solved we will need updating to a new version of both phpstan/phpstan and mglaman/phpstan-drupal.

2) PHPStan recommends to always run analysis full scope - a result cache is implemented for that purpose, see https://phpstan.org/user-guide/result-cache

PHPStan caches the result of the analysis so the subsequent runs are much faster. You should always analyse the whole project - the list of paths passed to the analyse command should be the same to take advantage of the result cache.

However, it may be hard to do in DrupalCI.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

@todo

Problem/Motivation

Currently it is not possible to group REST results in views.

Proposed resolution

Implement grouping functionality.

User interface changes

Add grouping select to views formatter settings.

After upgrading to Drupal 9.3 I'm getting errors with mail system. I can't say for sure this started in 9.3 because I disabled mail functions for a time while testing other parts of my system.

Error: Call to undefined method Symfony\Component\Mime\Header\Headers::addHeader() in Drupal\Core\Mail\Plugin\Mail\PhpMail->mail() (line 92 of [root]/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php)

Any ideas on this?

Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-val, which targets the jQuery val function.

Steps to reproduce

Proposed resolution

Remaining tasks

• In core/.eslintrc.jquery.json Change "jquery/no-val": 0, to "jquery/no-val": 2, to enable eslint checks for uses of jQuery .val(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory
• Add the following lines to core/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed
  

  # @todo Remove the next chunk of lines before committing. This script only lints
  #  JavaScript files that have changed, so we add this to check all files for
  #  jQuery-specific lint errors.
  cd "$TOP_LEVEL/core"
  node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
  
  CORRECTJQS=$?
  if [ "$CORRECTJQS" -ne "0" ]; then
    # No need to write any output the node command will do this for us.
    printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
    STATUS=1
    FINAL_STATUS=1
  fi
  cd $TOP_LEVEL
  # @todo end lines to remove

  Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.

• If it's determined to be feasible, refactor those uses of jQuery .val() to use Vanilla (native) JavaScript instead.

User interface changes

API changes

Data model changes

Release notes snippet

Currently, a blank parameters array is passed into $form_state->setRedirect(), which doesn't allow dynamic routes.

Getting raw parameters from RouteMatch will allow dynamic routes and at the same time does not affect routes without required parameters.

Problem/Motivation

watchdog_exception('system', $e, 'An error occurred while notifying the creation of the @name field storage definition: "!message" in %function (line %line of %file).', ['@name' => $storage_definition->getName()]);

should be (!message) => (@message)

watchdog_exception('system', $e, 'An error occurred while notifying the creation of the @name field storage definition: "@message" in %function (line %line of %file).', ['@name' => $storage_definition->getName()]);

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

• Introductions
• Status and what's next
• Where can contributors help this week? There will be threads for the individual components.
• Claro discussion
• Roadmap is located here: https://www.drupal.org/project/ideas/issues/3167121
• Layout builder discussion
• Roadmap is located here: https://www.drupal.org/project/ideas/issues/3194761
• Media discussion
• Roadmap is located here: https://www.drupal.org/project/ideas/issues/2825215
• Marketing discussion
• Roadmap is located here: https://www.drupal.org/project/promote_drupal/issues/3208461
• Marketing slides issue needs review: https://www.drupal.org/project/promote_drupal/issues/3213086
• Upcoming events with contribution days.
• Global Contribution Weekend (Jan 28-30)
• DrupalCamp Florida (Feb 18-20) is happening IRL in Orlando FL, USA, contrib day is that Sunday.
• DrupalCon Portland (April 25-28) Plan a contribution sprint and BoF.
• Roadmap is located here: https://www.drupal.org/project/ideas/issues/3191533
• Any additional topics to discuss?

Continue the conversation in Slack. Thank you for showing up and contributing!
If you have additional questions or comments, please post them here or on the meeting agenda issue.

Slack link: https://drupal.slack.com/archives/C01PNQZ8Q6A/p1629734433034300

Problem/Motivation

Reproduce:
1. Apply this patch #2350309: Forum index links head to taxonomy/term/{term} instead of forum/{term} or goto forum/1
2. Add a forum topic
3. Edit a forum topic, select moving to another Forums, and Ticked "Leave shadow copy"

Result:
Forum topic moved. No shadow copy in original forum.

Expected:
Forum topic moved. and Leaving a shadow copy with link in original forum.

Proposed resolution

Remaining tasks

User interface changes

Beta phase evaluation

API changes

Problem/Motivation

The \Drupal\views\Plugin\views\field\LinkBase::render() method is presuming too much by not rendering a link whose destination page is not accessible by the current user. The actual behaviour could cover most of the cases but there are still business scenarios when a role should be able to list content, including the URL, but still without the ability to access the content page. This is somehow similar to view label entity access introduced in https://www.drupal.org/node/2661092.

Not having access to a content item, doesn't mean automatically that the content's address cannot be read.

Proposed resolution

Add a new option "bypass_access" in \Drupal\views\Plugin\views\field\LinkBase that allows the site builder to bypass the access check when a link is rendered. The new option should default to FALSE, so the behavior of the actual will not be changed.

Remaining tasks

None.

User interface changes

New option as a checkbox the the Views link fields.

API changes

None.

Data model changes

Views config new option in fields.

Problem/Motivation

With #3124762: Add 'lifecycle' key to .info.yml files committed, we now have a lifecycle key to indicate the status of a module/theme.
Currently, experimental themes use the key/value pair: experimental: true in their .info.yml-files and obsolete extensions are not indicated on the admin status report page.

Proposed resolution

Use lifecycle: experimental for experimental themes.

Update the code to recognize experimental themes marked both ways and recognize obsolete extensions.

Followup: #3250342: [PP-1] Deprecate "experimental: true" in .info.yml

Remaining tasks

Review
Commit

User interface changes

New info shows on admin/reports for obsolete projects.

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Allow Drupal date tokens to be used in the "Upload Directory" path, much like they are used for the upload path in Image fields of Content Types.

That way instead of inline-images one could have inline-images/[date:custom:Y]/[date:custom:m]

Some SEO experts expect trailing slash on all the urls, including home page. Currently this is possible for all the urls but home page.

Offending code is in Drupal\Core\Routing\UrlGenerator::generateFromRoute():

if (!empty($options['prefix'])) {
      $path = ltrim($path, '/');
      $prefix = empty($path) ? rtrim($options['prefix'], '/') : $options['prefix'];
      $path = '/' . str_replace('%2F', '/', rawurlencode($prefix)) . $path;
    }

Suggested solution

By default $path contains empty string for home page but we can change it to forward slash using OutboundPathProcessor. Respect this and do not remove slash if it is the only thing in $path