Problem/Motivation

Some argument handlers provide their own default argument handling, like the Date argument. The Date argument handler does so by extending the list of of options in the defaultArgumentForm. An exception is however thrown on saving the form.

Steps to reproduce

• Create a new view /admin/structure/views/add using (node) content
• Under advanced tab, add new Contextual filter, select Created date (node.created)
• On "When the filter value is not available", select "Provide default value", on the drop-down select "Current date".
• Try to submit this form.

Result: A fatal error occurred on dblog: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "date" plugin does not exist.

Proposed resolution

Get the date handlers in line with the other default argument handlers.
Add a 'Current date', a "Current node's creation time" and "Current node's update time" default argument handler.

Remaining tasks

• Add a follow-up for improving caching - see #114
• Add a follow-up to make this work for all entity-types using a deriver - see #176
• Confirm if this works with date time range fields - see #157

User interface changes

API changes

Data model changes

Release notes snippet

Problem

Steps to reproduce:

Proposed resolution

Problem/Motivation

Summary

When creating an RSS feed display and submitting it for validation to the w3c validator, the latter makes a recommendation that should be implemented - https://validator.w3.org/feed/docs/warning/MissingAtomSelfLink.html

Steps to reproduce

1. Enable views & views_ui
2. Go to admin/structure/views/add, create a view with a Feed display with Format: RSS Feed, assign it a title and a path and make it accessible to anonymous users (see this screenshot)
3. Save the view
4. Go to http://validator.w3.org/feed/
5. Under 'Validate by URI' tab, enter the URL of the feed

Expected result

• The RSS feed validates without complaining

Actual result

• A message shows up saying it is a best practice to use an atom:link tag (see this screenshot)
• The RSS 2.0 spec seems to recommend the same

Proposed resolution

Patch suggested in #5 (this can be tested on https://simplytest.me/ for instance).
When validating the view with the patch, the W3C validator does not complain (see this screenshot).

Related Issues

• This problem occurs when using Drupal's core RSS feed #365498: Add missing atom:link with rel="self" to RSS feeds
• This problem does not occur when using views_rss

Original report by jvieille

I am trying to subscribe a LinkedIngroup to the rss feeds from a Drupal web site.
This feed is generated by my frontpage view.

No items are collected from linkedIn, and I am suspecting some strict validation control by LinkedIn
Feed validator says that the RSS feed is valid, but reports errors
http://validator.w3.org/feed/
the feed address is http://web2.see.asso.fr/rss.xml

- "description should not contain relative URL references"
- "Use of unknown namespace: http://drupal.org/group/og"
- "style attribute contains potentially dangerous content: white-space: pre;"
- "Invalid HTML: EOF in middle of construct"
- Missing atom:link with rel="self"

Thanks for help

Make Drupal 7 compatible with PHP 8.3, which is released on 23 November 2023.

https://www.php.net/releases/8.3/index.php

Problem/Motivation

Claro datetime range min-width is causing "empty" fields (containing dd/mm/yyyy placeholder) to be wider than filled fields. See image.
This will only occur when viewing the form for saved content and one date field has a date set and the other does not. If the value is one you just added and haven't yet saved, the widths will still be the same.

Steps to reproduce

1. Set up a fresh install of (the latest) Drupal 10.x
2. Enable the Datetime Range core module in /admin/modules
3. Add a new field of type 'Date range' to a new or existing content type
4. Create a new node of the content type you just added your field on via /node/add
5. Before you fill out the Date range field on the /node/add/xxx form, it seems to look fine
6. Fill out all fields of the node, except the end date/time and try to save
7. Drupal will throw a form validation error, asking you to choose an end date
8. As you can see in the following screenshots, the empty date field is wider than the other:

Chrome 113 on MacOS:

Firefox 112 on MacOS:Not an issue, this is the expected behavior of characters in non-monospaced fonts not all having the same width.

Proposed resolution

Option 1:
Add a max width in CSS to prevent the empty date input field to exceed a filled out date field.
@bnjmnm: "This is not ideal as different languages or accessibility needs can result in fonts/characters that occupy a different amount of space."
@bnjmnm: "The problem is extra unwanted margin added in some instances. That extra margin should be fixed instead of bloating the size of other datepickers to match it for the sake of symmetry."

Option 2:
@bnjmnm: "The difference is the spacing around the calendar picker icon - so that icon is what should be targeted in your solution."

Option 3:
???

Remaining tasks

• Decide on the optimal solution
• Create a patch
• Test and review patch
• Commit!

User interface changes

None.

Problem/Motivation

On a multilingual website:

1. Create an article with a tag, for example in english
2. Translate the article in french and do not associate the french version with the tag.
3. Go to the tag page in english
4. See your article in english: OK, normal
5. Go to the tag page in french
6. See your article in french: KO, the french version of the article is not associated with the tag

The problem is due to the taxonomy_index table, the langcode of the node is not stored. So when the contextual filter "Content: Has taxonomy term ID" make a relationship on the table, it includes the node in all the languages.

Proposed resolution

I don't know how the clean way to solve this and as I need something working quickly I made a workaround. I will upload a patch (with a hook_update_n starting at 8300 to not be incompatible with further merged hook_update_n).

The idea is to add a "langcode" column to store the langcode of the node in which the taxonomy term is referenced.

Then adding a new view filter on this column to be able to filter the results to avoid duplication.

Remaining tasks

1. Code / idea review
2. Needs tests
3. Needs proper update path

User interface changes

A new view filter is created: "Taxonomy term: Node language"

Data model changes

Column "langcode" added to taxonomy_index and "langcode" added to the primary key and the ndexes of the table.

Problem/Motivation

Field UI allows you to select multiple target bundles for a field. However, the views term filter only allows you to filter on terms from a single vocabulary.

Proposed resolution

Allow to set multiple vocabularies

Before:

After:

Remaining tasks

Pleaes review MR !3681 see #242 and #247 for details.

User interface changes

Site builders are able to filter on terms across multiple taxonomy vocabularies (see the screenshots).

API changes

None.

Data model changes

The 'vid' key in 'views.filter.taxonomy_index_tid' config schema is deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. The new key 'vids' (sequence of strings) is added to 'views.filter.taxonomy_index_tid' config schema as the replacement.

Release notes snippet

When using the Has taxonomy term views filters, site builders are able to filter on terms across multiple vocabularies.

Problem/Motivation

symfony/http-foundation released a security update so we updated our Drupal 10.3 site to version 6.4.14 from 6.4.12. Here is the diff.

We noticed that after doing that the site worked but the Views UI page /admin/structure/views was not loading and this error appeared in watchdog:

Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Invalid URI: A URI must not start nor end with ASCII control characters or spaces. in Symfony\Component\HttpKernel\HttpKernel->handle() (line 83 of /var/www/vendor/symfony/http-kernel/HttpKernel.php).

Turns out a trailing space in one of our view's paths caused the above error. That error was a new exception that was added to symfony/http-foundation. So I think Views UI potentially should be looking for bad characters and fail more gracefully.

I am not sure if this affects Drupal 11 yet but will try that next. Affects Drupal 11 as well.

Steps to reproduce

1. Create a view and add a trailing space to the path.
2. Update to latest version of symfony/http-foundation if you have not.
3. Try to load /admin/structure/views or that view.

Proposed resolution

TBD

Remaining tasks

• Test against Drupal 11. - Drupal 11 with version 7.1.7 of symfony/http-foundation.
• Figure out how to handle such an exception in Views UI.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

RouteProcessorCsrf::processOutbound() does not take into account optional parameters when calculating a CSRF token, leading on-request validation to fail on a generated route in which one or more parameters were not provided at the time of generation.

Problem/Motivation

I expect the Available Updates report to show all modules. But a particular patched module is missing from the report.

Steps to reproduce

1. Go to simplytest.me
2. For project, type redirect
3. Choose redirect from the pop-up
4. Choose 8.x-1.x-dev as the version
5. Click Advanced options
6. Choose Drupal 11.1.0 as the core version
7. Enter https://git.drupalcode.org/project/redirect/-/merge_requests/127.patch as the patch
8. Click Launch Sandbox
9. Wait for the sandbox creation process to complete and leave you on the welcome page
10. Click log in
11. Log in to site
12. Click Manage, then Extend
13. Type redirect in the filter field

Expected and actual results: Redirect module is checked.

14. Click Reports it the admin menu
15. Click Available updates

Expected result: Available update status is shown for Drupal Core and the Redirect module. If the module does not provide version information in info.yaml, then show "Version number not provided" as the version number. If because of the version number not being provided, the report is unable to determine whether the module is up to date, replace the "Up to date/Update available" message with "Unable to determine".

Actual result: Available update status is shown for Drupal Core. The Redirect module is not listed.

Screenshot of simplytest.me request:

Screenshot of filtered Extend screen:

Screenshot of Available Updates report:

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3483599: Convert all procedural hook implementations to Hook classes moved all the procedural hook implementations into a single Hook class, but the Workspaces module already had them grouped into separate classes.

Steps to reproduce

N/A.

Proposed resolution

Split up the single Hook class to follow the existing grouping.

Remaining tasks

Review.

User interface changes

Nope.

Introduced terminology

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

When adding an exposed and grouped user_name filter, the value doesn't validate correctly. It issue stems from the entity reference autocomplete field handling values using the target_id key, and loaded entities.

This is exactly the same issue as reported in #2576927: Grouped exposed taxonomy filter fails validation for autocomplete widget. Please check it out for more details.

Other changes applied in the merge request are just allowed new tests to pass. There were 2 issues:
1) Default value of the filter was trying to be processed twice but failed with the exception. More information is in duplicated issue: #3250352: Username views filter should not process default value twice . Fixed in this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/1445/diffs?co...
2) There was a PHP notice in \Drupal\user\Plugin\views\filter\Name::validateExposed method, that was fixed in this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/1445/diffs?co...

Steps to reproduce

1. Install Drupal with "Standard" profile
2. Open content view (/admin/structure/views/view/content)
3. Add an exposed grouped filter by "Authored by" (User). Make sure the group item is using autocomplete widget
4. Add at least one item to the group configuration (e.g. "admin")
5. Submit

Proposed resolution

Apply the same fix and test coverage as in #2576927: Grouped exposed taxonomy filter fails validation for autocomplete widget. Also, make additional fixes to let tests pass.

Remaining tasks

Review, commit.

There are no User interface, API or Data model changes.

Problem/Motivation

(Content) Entity API is hard to understand, one aspect of that is there there are multiple ways of doing things and a lot of magic.

This is an attempt to deprecate __get()/__set() on ContentEntityBase *only* (magic methods on field item and field item list classes is a different topic).

There are two different aspects to this:
a) Accessing fields, this can simply be deprecated 1:1 by using get()/set() instead, which only supports fields.
b) Non-field properties like ->original and other cruft, mostly leftovers. This is tougher, for official things like ->original we should add a method, for random stuff we could consider some kind of temporary storage, there is an issue for that that I would need to dig out.

(#1977266: Fix ContentEntityBase::__get() to not return by reference, was only about the by-reference return, this is about deprecating it entirely.)

Steps to reproduce

Proposed resolution

Remaining tasks

Prerequisites/Blockers

* #2839195: Add a method to access the original property / #1480696: Move $entity->original to a separate hook argument
* #2896474: Provide an API to temporarily associate data with an entity

User interface changes

API changes

This will have a huge impact on mostly custom code, accessing fields through magic methods is very common.

Data model changes

Release notes snippet

Problem/Motivation

Navigation uses layout builder to define regions for content and footer. Currently you can place limited blocks into content, but footer is restricted. Modules like Environment Indicator, Workspaces(core) and Masquerade are examples of modules that may be useful to claim space in Navigation with more rigid placement. Most noteably for the scope of this issue, above the content region.

Proposed resolution

Add the ability for module developers to add integrations to a new content_top region that sits above the content region.

Provide hooks to easily extend the content_top region.

A potential follow-up issue could look at adding the same kind of extensibility to the footer region. The footer region is more sensitive from a design perspective to a big number of blocks that content region. Hence it needs further discusssion and is out of scope for this issue.

Remaining tasks

Write Change Record

User interface changes

Output content_top variable/slot in the template.

API changes

• New hook navigation_content_top to define content_top blocks
• New hook navigation_content_top_alter to alter content_top blocks

Release notes snippet

Added a content_top section to the navigation for programmatic additions

Problem/Motivation

Passing a url with a whitespace at the end used to work with PathValidator, however this commit broke it.

As a consequence, sites are blowing up left and right. Browsers have no problems with such URLs, only Symfony does. Maybe there's an RFC somewhere which prescribes this ? but who cares about that.

Steps to reproduce

\Drupal::pathValidator()->getUrlIfValidWithoutAccessCheck('http://example.com/ ') note the extra space.

Proposed resolution

Patch PathValidator to catch the trash Symfony throws.

Update symfony/http-foundation so that tests pass (the expected exception is thrown).

Remaining tasks

Backport to 11.0.x and 10.3.x - note that MR !10307 now updates symfony/http-foundation so that tests pass (the expected exception is thrown).

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently when adding services as properties in tests you need to declare the properties and initialize them in ::setUp. This is unnecessary boilerplate.

Steps to reproduce

Proposed resolution

Add a trait similar to AutowireTrait to initialize the services in setUp.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The majority of the Administration menu (/admin/structure/menu/manage/admin) is displayed via the admin NavigationBlock plugin. There are two parts of the Administration menu that we put elsewhere, the Help menu item and the Content (and all of it's children) menu item.

The problem is the method by which we hide the Help link and Content menu items when displaying the Adminstration menu. We currently use hook_menu_links_discovered_alter to remove Help and Content menu links from the Administration menu. Using hook_menu_links_discovered_alter means that the Administration menu is altered everywhere the Administration menu is used instead of just the place we need it altered within the Navigation bar. For instance, when you go into the Admin UI for the Adminstration menu (/admin/structure/menu/manage/admin), those Help and Content links are gone. This could be very unexpected for other modules using the Administration menu.

Steps to reproduce

1. Browse to the Adminstration menu UI (/admin/structure/menu/manage/admin)
2. Take note of the Help and Content (and child) menu items
3. Enable the Navigation module
4. Browse to the Adminstration menu UI (/admin/structure/menu/manage/admin)

Expected result

• Help and Content (and child) menu items display in admin UI
• Help and Content (and child) menu items do not show in the adminNavigationBlock plugin instance in the Navigation bar

Actual result

• Help and Content (and child) menu items DO NOT display in admin UI
• Help and Content (and child) menu items do not show in the adminNavigationBlock plugin instance in the Navigation bar

Proposed resolution

Take cues from toolbar module for how it achieves the alterations to the Admin menu in order to shuffle parts of it around its UX. Namely avoid using hook_menu_links_discovered_alter and instead alter it on output as part of the adminNavigationBlock plugin.

Remaining tasks

Backend implementation.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

According to the documentation for the Symfony\Component\Routing\Matcher\UrlMatcherInterface::match() method, it's expected to throw a routing exception (namely NoConfigurationException|ResourceNotFoundException|MethodNotAllowedException).

Drupal's Router::match() method, however, calls Request::create(), which can now throw a BadRequestException.

Steps to reproduce

1. Enable language module.
2. Add a second language.
3. At admin/config/regional/language/detection, enable the Account administration pages language setting.
4. At user/1/edit, set the Administration pages language to a language.
5. Visit a URL that triggers the exception, such as foo%20 or :123/foo
6. The page will display "Invalid URI" rather than the normal 404 page.

Proposed resolution

We could catch the BadRequestException and re-throw as ResourceNotFoundException.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Original support request

I saw that a couple of issues(12) were fixed related to the update of http-foundation.

The approach of catching the error is missing on isAdminPath method for LanguageNegotiation/LanguageNegotiationUserAdmin.php

So I was wondering do we need to make some similar implementation to catch the possible throws of this call
$attributes = $this->router->match($path);

One way admins will aways be aware that symphony is throwing error and it is not corrects to have ASCII chars in the url.
Other way we will hide the error for admins as well.

Problem/Motivation

Right now, a Transaction object in Drupal leads to a COMMIT or a RELEASE SAVEPOINT only when it goes out of scope. In practice, it's an autocommit.

We have code like

    try {
      $transaction = $this->connection->startTransaction();
      foreach ($this->insertValues as $insert_values) {
        $stmt->execute($insert_values, $this->queryOptions);
        ...
      }
    }
    catch (\Exception $e) {
      if (isset($transaction)) {
        // One of the INSERTs failed, rollback the whole batch.
        $transaction->rollBack();
      }
      // Rethrow the exception for the calling code.
      throw $e;
    }

or in other cases something like

    try {
      $transaction = $this->connection->startTransaction();
      foreach ($this->insertValues as $insert_values) {
        $stmt->execute($insert_values, $this->queryOptions);
        ...
      }
      unset($transaction);
    }
    catch (\Exception $e) {
      ....
    }

It works, but I personally find unset($transaction) counterintuitive as to be implying a COMMIT on the db.

See also #1025314: Transactions should be allowed to be committed explicitly for a lot of rationale on why this is not optimal.

Proposed resolution

I propose here to add the possibility to explicitly commit (or release savepoint) a Transaction object, as an opt-in vs. current behavior.

For this purpose, I propose to add a ::yield() method to the Transaction object. IMHO we should not name the method ::commit() because we cannot know if the Transaction object is representing the root transaction or a savepoint: so it could well be that a ::commit() method is actually not committing anything on the database. Yield, OTH, indicates that the transaction control is returned to the parent level in a nested transaction scenario like Drupal's - e.g. a savepoint transaction object 'yields' control to its parent 'root' transaction (that can still be rolled back entirely if necessary); a 'root' transaction 'yields' control to the database by committing the db transaction, etc.

We would get into something like

    $transaction = $this->connection->startTransaction();
    try {
      foreach ($this->insertValues as $insert_values) {
        $stmt->execute($insert_values, $this->queryOptions);
        ...
      }
      $transaction->yield();
    }
    catch (\Exception $e) {
      // One of the INSERTs failed, rollback the whole batch and rethrow the exception for the calling code.
      $transaction->rollBack();
      throw $e;
    }

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

NULL results are being passed to array_filter function.
Issue 3348686 allows for modules to provide translations for specific links using an implementation of moduleHandler->alterhere. The problem is that this occurs after checking for empty results. Certain implementations of the moduleHandler->alter may empty this results array (see issue 3358576 for language_switcher_extended module). This can result in an empty result array being passed to the array_filter function causing error.

          if (!empty($result)) {
            // Allow modules to provide translations for specific links.
            $this->moduleHandler->alter('language_switch_links', $result, $type, $url);

            $result = array_filter($result, function (array $link): bool {}

Although this issue is caused by the calling of moduleHandler->alter and works assuming all defaults, it should safely handle cases where a NULL value is passed as result by other core or contrib alterations.

Steps to reproduce

1. Steps to reproduce
2. Install all of the core Multilingual modules
3. Add another language
4. Enable a content type for content translation (including its published field)
5. Use URL -> Path for the language detection
6. Place the Language switcher content block
7. configure a 3rd party module (for example, language switcher extended) to hide block when no translation is expected.
8. Select Alter the language switcher for untranslated content entities
9. Select Hide the language switcher link for the untranslated handler
10. Navigate to a page with no translations

Proposed resolution

Add an additional !empty() check after all modules have made alterations to the link list.

Problem/Motivation

The "Status" field on the user profile form allows users to be blocked. This field is displayed even in my own profile which doesn't really make sense. This allows users to block themselves from the site, which could lead into frustrating situations, like we can see on this forum post: https://www.drupal.org/forum/support/post-installation/2014-04-29/blocke....

Proposed resolution

Hide "Status" field from the user form when rendered for the current user.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet