Problem/Motivation

JSON:API has a soft dependency on justinrainbow/json-schema; validation is performed automatically if the dependency is enabled via a check in \Drupal\jsonapi\EventSubscriber\ResourceResponseValidator:

use JsonSchema\Validator;
...
    elseif (class_exists(Validator::class)) {
      $this->validator = new Validator();
    }

@larowlan has previously noted that this causes severe performance issues at runtime, and the fix is to uninstall the dependency.

However, Experience Builder uses justinrainbow/json-schema at runtime (although at the time of writing this is not explicitly declared): #3469516: Declare explicit runtime dependency on `justinrainbow/json-schema`

In turn this will cause performance issues on sites that want to use both Experience Builder and JSON:API.

Steps to reproduce

Proposed resolution

Move ResourceResponseValidator behind some kind of feature flag instead of magically enabling it when the dependency is present. This could be a development mode flag similar to the Twig debug mode, or a feature flag module.

It may even be preferable to move this out of core to a contrib module, as this doesn't feel like it is necessarily in the core use case. Tagging for product manager review. see #2. Also I (bbrala) dont think we should remove it right now.

Remaining tasks

1. Discuss the best solution
2. Implement.

User interface changes

n.a.

Introduced terminology

n.a.

API changes

New parameter in services.yml

Data model changes

n.a.

Release notes snippet

n.a.

Problem/Motivation

In #2788777: Allow a site-specific profile to be installed from existing config we excluded profiles from being installed that contain hook_install implementations.

The reasons for this was to exclude complexity, limit the scope of the issue and getting it done.
The complexity can be summarized as:
Install hooks in profiles were so far only called when a site was installed and after all the listed modules were installed and all the configuration was imported. Thus hook_install implementations were able to make a lot of assumptions about the state of the site when the code was executed.
When installing from configuration the configuration is synchronized and the install hooks are called as the extensions are installed and then the configuration is imported. In addition a profile can list modules to install which are not dependencies and, therefore, these modules can be uninstalled. The install hook can therefore also not rely on all the modules being installed.
The canonical example being standard expecting the contact module to be installed.

Right now if a profile wants to be able to be installed from config and still do something extra it has to not implement hook_install and instead define a custom install step.

Proposed resolution

to be defined

Temporary Workaround

See @slucero's comment in #25. There are differences with hook_install, see hook_install_tasks for details. This is an example of how it can be used, replacing "PROFILE" with your profile's machine name:

/**
 * Implements hook_install_tasks().
 */
function PROFILE_install_tasks(&$install_state) {
  $tasks = [
    'PROFILE_install_content' => [
      'display_name' => t('Install default content'),
      'type' => 'normal',
    ]
  ];

  return $tasks;
}


/**
 * Callback function to install default profile content.
 *
 * @see PROFILE_install_tasks()
 */
function PROFILE_install_content() {
  ...
}

Remaining tasks

find solution
implement it
test it
commit it

User interface changes

none probably.

API changes

to be seen.

Data model changes

none.

Problem/Motivation

#3059984: Add new “Content Editor” role to Standard Profile added a new role with permissions for modules that not installed. We've removed them in #3221258: Fix content editor role to only have permissions that exist - however this affects how useful the role is.

Let's decide how to add the permissions to role when modules are installed in a way allowed by #2571235: [regression] Roles should depend on objects that are building the granted permissions.

Proposed resolution

When a core recipe enables a module, include permissions from that module for the content_editor role, if any, that were included in #3059984 and removed in #3221258.

Here are some options that were suggested before recipes were available:

• Add standard_hook_modules_installed() to do the work (I think this is the better solution)
• Add a new key to the role config entity to permissions_to_install
• Make modules part of the standard install

Remaining tasks

1. Add permissions for the content_translation module.
2. Add permissions for the media module.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Part of enabling the sniff Drupal.Commenting.FunctionComment.MissingParamType.

Steps to reproduce

Proposed resolution

Add the param types in core/lib/Component

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3477614: Ignore VariableComment.Missing as needed was added to keep things moving but after actually false positive.

Steps to reproduce

N/A

Proposed resolution

Revert #3477614: Ignore VariableComment.Missing as needed when #3477601: False positives with Drupal.Commenting.VariableComment.Missing is fixed

Remaining tasks

Wait for 3477601 to be complete
Revert 3477614
Review

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

The sniff Drupal.Commenting.VariableComment.Missing is reporting errors on some variables that do have a comment. For example, this from core/modules/node/src/Plugin/views/row/Rss.php.

   /**
    * The base field for this row plugin.
    */
   // phpcs:ignore Drupal.NamingConventions.ValidVariableName.LowerCamelName
   public string $base_field = 'nid';

Steps to reproduce

Proposed resolution

Add Drupal.Commenting.VariableComment.Missing to the existing phpcs line.

Remaining tasks

Make a follow up to remove the ignore changes when #3477601: False positives with Drupal.Commenting.VariableComment.Missing is fixed.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\serialization\EventSubscriber\UserRouteAlterSubscriber->onRoutingAlterAddFormats() (line 55 of core/modules/serialization/src/EventSubscriber/UserRouteAlterSubscriber.php).

The deprecation notice can occur if some other code has altered and removed the _format requirement on one of the 'user.login_status.http', 'user.login.http', 'user.logout.http', or 'user.pass.http' routes.

Steps to reproduce

Have another module alter one of the routes to remove _format requirement. The other module has to come before the serialization module.

See the proposed test case in the merge request.

Steps to reproduce issue,

1. Create custom module having the logic to alter the Route.
2. Altering RouteSubscriberBase as below.

<?php

namespace Drupal\custom_module\Routing;

use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;

/**
 *
 */
class RouteSubscriber extends RouteSubscriberBase {

  /**
   * Disable access to cohesion entities if assets have not been imported
   * or "Use Site studio" option is set to 'disable'
   * {@inheritdoc}.
   */
  protected function alterRoutes(RouteCollection $collection) {

    if ($route = $collection->get('user.pass.http')) {
      $route->setRequirements([]);
      $route->setRequirement('_access', 'FALSE');
    }
  }

}

3. Clear the cache, Access the route user/password
4. Getting below error

Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\serialization\EventSubscriber\UserRouteAlterSubscriber->onRoutingAlterAddFormats() (line 55 of /var/www/html/docroot/core/modules/serialization/src/EventSubscriber/UserRouteAlterSubscriber.php)
#0 /var/www/html/docroot/core/includes/bootstrap.inc(164): _drupal_error_handler_real(8192, 'explode(): Pass...', '/var/www/html/d...', 55)
#1 [internal function]: _drupal_error_handler(8192, 'explode(): Pass...', '/var/www/html/d...', 55)
#2 /var/www/html/docroot/core/modules/serialization/src/EventSubscriber/UserRouteAlterSubscriber.php(55): explode('|', NULL)

Proposed resolution

Check the _format exists and not empty.
Confirm $route->getRequirement('_format') has value before passing for explode().

Remaining tasks

Needs review.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

The <button> tag is a long standing element in HTML

Per http://www.w3.org/TR/html4/interact/forms.html#h-17.5

Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. For example, a BUTTON element that contains an image functions like and may resemble an INPUT element whose type is set to "image", but the BUTTON element type allows content.

In themes, the <button> allows for much more advanced styling compared to <input />.

It also fixes an inconsistency in the Form API where elements are addressed as 'buttons' but are output as <input type="submit" />

Proposed resolution

Replace all submit <input />s with <button />s.

Remaining tasks

1. Manual testing

User interface changes

Input submit buttons are consistently styled as buttons.

API changes

None

Original report by @sanguis

The tag is a long standing element in HTML (http://dev.w3.org/html5/markup/button.html), and it has not support in Drupal.
it is counter intuitive to label as a button a something that will output as a .
To add to this confusion the variable 'button_type' does noting but set a class in the output to a class of form-#BUTTON_TYPE with in the tag generated.
This means that to genreate a "reset button" I have to add it as a "markup" type form elemnt.

Beta phase evaluation

Problem/Motivation

In preparing another issue, I ran into the non OO function image_filter_keyword() in image.module.

Besides, image_filter_keyword() can return float despite its doc says

 * @return int|string
 *   The offset from the anchor, in pixels, or the anchor itself, if its value
 *   isn't one of the accepted values.

This causes deprecations in PHP 8.1 if the returned value is used in GD functions that expect ints instead.

Proposed resolution

This patch:

• Moves the function image_filter_keyword() to a static method in \Drupal\Component\Utility\Image.
• Adds test coverage for it.

Remaining tasks

User interface changes

None.

API changes

image_filter_keyword() deprecated
new \Drupal\Component\Utility\Image::getKeywordOffset() method

When view has ajax on and page url has some parameters what are exposed filters (view page with some applied filter values) if uncheck selected filters and submit exposed form looks view is still filtered by the value from url.

Problem/Motivation

A media title is overridden with filename after saving of media translation with different image for target language

To reproduce:

• Install Drupal 8.6.0 in English
• Enable these modules: Core: Media, Multilingual: Content Translation
• Add a language ( /admin/config/regional/language )
• Check the 'Media' custom language settings in /admin/config/regional/content-language and make image media type translatable (translation for Image field should be enabled too).
• Add an image (/media/add/image) and translate it: upload different image and change title

Actual result: media title is overridden with file name in translation.

I guess there is mistake in Media::prepareSave() method:

        foreach ($translation->bundle->entity->getFieldMap() as $metadata_attribute_name => $entity_field_name) {
          // Only save value in entity field if empty. Do not overwrite existing
          // data.
          if ($translation->hasField($entity_field_name) && ($translation->get($entity_field_name)->isEmpty() || $translation->hasSourceFieldChanged())) {
            $translation->set($entity_field_name, $media_source->getMetadata($translation, $metadata_attribute_name));
          }
        }

Looks like current condtition is not OK, and OR condition should be replaced with AND condition:

if ($translation->hasField($entity_field_name) && ($translation->get($entity_field_name)->isEmpty() && $translation->hasSourceFieldChanged())) {

In this way title will be overridden only in case when it is empty.

Proposed resolution

Remaining tasks

Update summary
Review

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The contact form allows users to change the name and mail fields. This can be considered a security issue in that recipients of the message may be tricked into communicating with an impostor.

Proposed resolution

Remove the ability for logged in users to change name and email address on the contact form.

Remaining tasks

• Minor cleanups.
• Manually test the email sent for both the sitewide and personal contact forms for both anonymous and authenticated users.

User interface changes

Only anonymous users will be allowed to enter a name and email address on the contact form. Users with an account will be forced to use the settings from their user data. Text will alert recipients of the sent emails that the anonymous users are not verified.

Before patch

After patch

String addition

The string t('Unverified') is added to contact form emails sent by anonymous users.

API changes

The structures of contact_site_form() and contact_personal_formm() change for authenticated users (replacing text fields with read-only values).

Original report by Dave Reid

Currently, both the site-wide and personal contact forms allow registered users to change the values of the 'name' and 'mail' fields. So I could submit a user's personal contact form with the name 'Dries' and 'dries-not-valid-mail@drupal.org' and it would look to the user like this e-mail actually came from Dries, which is a bad thing.

These forms should both remove the fields when a non-anonymous user is using them, and instead use theme_username() to display that the e-mail will be 'sent' from the current user.

Problem/Motivation

We already have a \Drupal\Core\DependencyInjection\AutowireTrait class, suitable for wiring dependencies into classes extending \Drupal\Core\DependencyInjection\ContainerInjectionInterface, implemented in #3394870: Allow controller service wiring via constructor parameter attributes

I think we should have a similar thing for \Drupal\Core\Plugin\ContainerFactoryPluginInterface, so we can easily skip adding a create() method for plugins.

I acknowledge we also have something similar #3294266: Allow plugin service wiring via constructor parameter attributes, but this is useful in the short term for improving DX, before removing the requirement for ContainerFactoryPluginInterface. I guess the proposed new autowire trait would be removed from drupal alongside ContainerFactoryPluginInterface, if ever that happens. So I dont see this as redundant code.

Proposed resolution

Add a AutowireTrait for plugins, so they dont need to implement create().

Remaining tasks

• Tests.
• Should we switch any non-tests core usages now? My suggestion is not, because I imagine there will be a huge LOC change here (many LOC removals, for the better!). But create methods could also be doing other things, or not all dependencies autowirable yet.

User interface changes

Nil.

API changes

New trait

Data model changes

Nil

Release notes snippet

Problem/Motivation

I am using Drupal 10.2.5 and PHP 8.3.6 on Ubuntu 22.04.

My website suddenly no longer displays properly since last night and only displays the following message:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist. Valid plugin IDs for Drupal\Core\Display\VariantManager are: in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

Those "varying words" were initially "text_default" and became "language", "block_page", etc. when I tried to resolve the issue according to past posts here.

Steps to reproduce

Many past posts here on similar issues have been read. They were basically related to Drupal 8 or 9. I am now using Drupal 10. Those issues have been closed for quite some time. The solutions posted have been tried by me but without success. Such solutions are: using drush updatedb, drush eval "drupal_flush_all_caches();", drush cr, etc. or editing the codes.

I had restored once the website and mysql database based on 7 April 2024 backups. It worked.

But after I have done composer update -W, drush updatedb, and drush cr, the above message appears again.

Proposed resolution

I guess that the updates since 7 April 2024 might be the cause of the problem.

I would restore the old backup again for temporary use.

I am looking for help to resolve the issue.

Thanks!

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When we scroll on the vertical toolbar it also scrolls the main page behind it, and on scrolling, the header doesn't stick with the toolbar which doesn't look right. So if want to switch to shortcut options or admin options we have to scroll to the top of the page to see the header.

I've seen this issue in Chrome, Edge, and Firefox, I didn't check safari.

Expected Behaviour: The header should stick to the top when the side toolbar is expanded and when scrolling on the toolbar, it shouldn't scroll the main page behind it.

You can see the issue in the attached gif.

Steps to reproduce

TBA

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

The scrollTop() AJAX command calls the native scrollTo() method with a hard-coded offset of 10px.

If we would call scrollIntoView() (spec) instead, sites that are using a fixed header could define a scroll offset through CSS, which avoids the element to be scrolled below the header, e.g. like this for views:

[data-once="ajax-pager"] {
  scroll-margin-top: 5rem;
}

Moreover, the command tends to scroll to the top of the page even when the target element is located further down (see also #3273068: Make Views AJAX scroll to top optional). That's caused by this piece of code:

      // We can't guarantee that the scrollable object should be
      // the body, as the element could be embedded in something
      // more complex such as a modal popup. Recurse up the DOM
      // and scroll the first element that has a non-zero top.
      let scrollTarget = response.selector;
      while ($(scrollTarget).scrollTop() === 0 && $(scrollTarget).parent()) {
        scrollTarget = $(scrollTarget).parent();
      }

Not sure what this is good for, but it might not be necessary any more when using scrollIntoView().

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up from #3442259: Reduce time of Migrate Upgrade tests by not outputting the logs by default. When I was reviewing that, I noted:

Took me a moment to understand why we're moving assertLogError() outside the check for if we've written anything to the logs. But then with grep and looking at more context outside of the MR diff, I see that that function relies on $this->expectedLoggedErrors, which is only set in the two functions where assertLogError() is now found.

At the risk of slowing down this important fix, I have to ask: should that method really be something like:

assertLogErrorCount(int $expected): void

Why bother with the expectedLoggedErrors property at all? It's only set exactly twice with hard-coded ints each time:

./core/modules/migrate_drupal_ui/tests/src/Functional/d7/Upgrade7Test.php:    $this->expectedLoggedErrors = 27;
./core/modules/migrate_drupal_ui/tests/src/Functional/d6/Upgrade6Test.php:    $this->expectedLoggedErrors = 39;

We never increment or anything. It's basically just a constant. Why not pass it directly where we need it?

@catch replied "I think #8's a good idea for follow-up." so here we are. 😂

Steps to reproduce

Proposed resolution

• Rename MigrateUpgradeExecuteTestBase::assertLogError() to assertLogErrorCount(int $expected).
• Remove the expectedLoggedErrors property.
• Update the 2 call sites to pass their values directly instead of setting this property.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Event subscribers in Drupal are quite verbose.

symfony provides an easier way to register event listeners: The #[AsEventListener] attribute, which can be placed on service classes and methods.
https://symfony.com/doc/current/event_dispatcher.html#defining-event-lis...

Steps to reproduce

Proposed resolution

Let's support this in Drupal.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

According to the W3C CSSOM View Module document, window.scrollY is explained about the property detail but window.pageYOffset is only explained that must return window.scrollY value. And on the MDN document, it explains that window.pageYOffset is an alias for window.scrollY.
In my opinion, using window.scrollY/window.scrollX is suitable than window.pageYOffset/window.pageXOffset.

Note:

In VSCode, window.pageYOffset is identified as deprecated feature.

Proposed resolution

Replace all window.pageYOffset/window.pageXOffset with window.scrollY/window.scrollX.

Remaining tasks

User interface changes

No.

API changes

No.

Data model changes

No.

Release notes snippet

No.

Problem/Motivation

The method ContentEntityBase::getLoadedRevisionId() should not return string values. In the docblock the return value is defined to be an integer value or NULL when it is not set. All entity revision id's are always of the integer type.

Proposed resolution

Add type casting to the return value of the method.

Remaining tasks

TBD

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

TBD