views blocks that were set to hide via "Hide block if the view output is empty: Yes" still renders the general structure of the view output. The view in question has a contextual filter "content: id" that is set to "Provide default value" -> content id from url. Fields are set to be hidden if empty. The rendered block doesn't show any output but creates the structure down to the views-row class.

How can blocks be completely hidden if there is no output? Seems like the "Hide block if the view output is empty: Yes" is without function at the moment, or?

Problem/Motivation

We've had to deal with quite a lot of deprecations in Symfony validator, which has been the main barrier to updating Symfony minor releases.

The most recent of these is #3029540: [Symfony 4] Sub class \Symfony\Component\Validator\ConstraintViolation and use that in \Drupal\Core\TypedData\Validation\ExecutionContext::addViolation(). There was also #2721179: Replace deprecated Symfony ExecutionContextInterface between Symfony 2 and 3.

This is a much higher maintenance burden than if we'd written a validator component ourselves.

The main issue we have is that we're exposing Symfony interfaces directly to contrib and custom code (I have custom validators written on client projects), which means any change Symfony makes directly impacts implementations.

This is very different to most other Symfony components (YAML, the container etc.) where interaction is either non-existent/extremely superficial and unlikely to be affected, or extremely rare and low level.

Proposed resolution

Couple of ideas:
1. Can we write some kind of layer so that validators implement Drupal rather than Symfony interfaces, then make them work for the Symfony internals?
2. How much code is there in the component itself that's not the validators? What if we froze the API and forked the internals (just changing the Symfony interfaces to a Drupal one). Are there other components that depend on Validator we'd then be incompatible with and would we actually be affected by this?

Other ideas welcome of course.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The json-schema shipped with jsonapi module is incomplete/incorrect; this doesn't necessarily affect any of Drupal's current implementation, but it is "wrong." This is being addressed upstream, but we do not necessarily need to wait on jsonapi.org to ship the "correct" json-schema if we feel an alternative is more correct. This could be an issue if extending code chooses to validate against the json-schema file in core (or even link to it from a client?) so this is minor at the moment, but should be fixed or at least tracked to include the updated file when a fix is adopted officially upstream.

I actually ran into this using the same file downloaded from jsonapi.org when doing client-side validation, and discovered we ship a copy of the schema in Drupal core.

See https://github.com/json-api/json-api/issues/1554#issuecomment-1010338466

Problem/Motivation

We need to decide on what to set as the minimum PHP version for Drupal 10.0. It needs to be at least 8.0, since that's required by Symfony 6. The question is whether to set it to 8.0 or 8.1.

These are the key factors to consider, in priority order:

1. Although Drupal 9 will have had only 3.5 years of total life from release (June 2020) to EOL (Nov. 2023), in #3238652: [policy] Adopt a 2 year major release cadence and a 6 month LTS-to-LTS overlap period for Drupal 10 and beyond we are proposing for Drupal 10 to have 4.25 years of total life (from June 2022 to Sep. 2026). Given the desire for >4 years of total life, it is especially important to begin Drupal 10.0 on the latest major versions of all of our vendor libraries. Otherwise, it's a long time for Drupal's security team to have to triage, and where needed issue our own fixes for, public disclosures of unfixed security vulnerabilities in those libraries. Therefore, if one of our vendor libraries begins requiring PHP 8.1 prior to Drupal 10's release, that'll be a strong argument for Drupal 10 requiring PHP 8.1 as well.
2. Drupal 9 will go EOL in Nov. 2023, which is exactly when PHP 8.0 goes EOL. If Drupal 10 requires PHP 8.1, then PHP 8.0 users will have 0 grace period during which to remain on a just-EOL'd PHP version but still be able to run a supported version of Drupal. https://blog.packagist.com/php-versions-stats-2021-1-edition/ shows that there's a non-trivial percentage of PHP users who continue to use EOL PHP versions for a while.
3. It's good for Drupal to get a decent amount of early adoption of a new major Drupal version (i.e., the X.0 version), since that provides the ecosystem support for contrib modules to get upgraded. At the same time, there's not much incentive for someone to adopt 10.0 when the 9.4 version has exactly the same features and a larger pool of contrib projects that work. So either way there's a small pool of initial adopters, but setting a PHP 8.1 requirement shrinks that pool even more. For example, RHEL users won't get PHP 8.1 in their app stream until Nov. 2022.
4. It would be nice to be able to use PHP 8.1 language features in Drupal 10 minors, but this is a lower priority consideration than all of the above.

Proposed resolution

In order to accommodate as many of the above priorities as possible, while giving more weight to the higher priorities, the current proposal is:

• Leave open the possibility that Drupal 10.0 will require PHP 8.1. This means that for anyone who wants to adopt Drupal 10 right when it's released and needs to plan their server requirements ahead of time, they should plan for PHP 8.1.
• However, don't actually raise Drupal 10.0's PHP minimum to 8.1 until a vendor library does. If none do prior to Drupal 10.0's release, then keep Drupal 10's PHP requirement at 8.0. Based on #27, it's quite likely this will be the case and we'll end up with an 8.0 requirement.

Remaining tasks

Agree.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

Follow up to #3129043: Move core database drivers to modules of their own and to #3230714-11: ConnectionUnitTest should be skipped for any database not psql or mysql:

Once #3129043: Move core database drivers to modules of their own is complete, it would be good to split the Database tests in 'core' ones and 'driver specific' ones, with the 'driver specifc' ones running dependent on the db driver in use by the SUT.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you don't want to translate your URL alias, the original URL alias won't work with your translations.

Steps to reproduce:

1. Install with standard
2. Enable language and content translation.
3. Add a language (e.g. Spanish)
4. Go to content translation settings and enable article translations. Uncheck the URL alias field.
5. Create a node, assign an URL alias in the form (e.g. /my-alias)
6. Translate the node. The URL alias is prepopulated with your source alias (e.g. /my-alias).
7. Submit the form.

Current outcome:
In the alias list, you have (/my-alias, EN).
Going to /es/my-alias gives a 404.

Expected outcome:
In the alias list, you should have (/my-alias, UND).
Going to /es/my-alias gives a 200 and displays the Spanish translation.

Proposed resolution

• If the entity OR the path field are not translatable, save the path alias with the langcode 'und'.
• If the entity AND the path field are translatable, save the path alias with the langcode of the entity (or translation).

Remaining tasks

• Agree on proposed resolution
• Review

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

When adding some native ckeditor plugins, in this case mathjax, when adding blocks the first load will look fine, as soon as you go to configure the block, the ckeditor does not appear and a JS error is thrown.
Image may be NSFW.
Clik here to view.
Image may be NSFW.
Clik here to view.

Steps to reproduce

Add a new ckeditor plugin to a text format. On a block use that new text format. The first load inside layout builder will work fine, as soon as you go back to configure the block, the ckeditor will not be displayed.

Proposed resolution

Add a check inside drupalmedia plugin.js to check for undefined editor.widgets.

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://tugboat10-3x5xy8bgnoeowboihwsqmci3ot9vk5uw.tugboat.qa/grid-view
• CSS in Olivero: https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/oliv...

Views UI Settings

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

Responsive horizontal style in action (in Stark theme)

Image may be NSFW.
Clik here to view.

Responsive vertical style in action (in Stark theme)

Image may be NSFW.
Clik here to view.

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.

Node revision table issue: langcode for all the revisions is default language.

In order to get the latest revision id for a specific langauge Node_revision inserting the specific lang code in 'langcode' field.

How to get revision id (vid) for a specific language in drupal backend. It seems not possible from node_revision table right now.

Thanks & Please suggest

Problem/Motivation

The article (1) https://www.drupal.org/docs/develop/coding-standards/configuration-file-... says in the section "Simple configuration" the following: "Usually, the choice of name is (extension).settings for the unique configuration name, but this is not required."

The problem is, there are modules, like "Distribution Update", which need the configuration file name to be exactly like described.

My colleagues and me recognized this behaviour when we renamed a module and forgot to rename the corresponding configuration, too. Even after a fresh reinstall and a just-for-test configuration change in a different module, the distribution update was unable to perform the updates.

Example:
module_a contains configuration module_a.settings
module_b contains configuration module_b.settings

Now you rename module_a to module_a2 but do NOT rename module_a.settings to module_a2.settings
After that you change anything in configurations file for module_b.settings.
In the following Distribution Update will say: "The configuration cannot be imported becauce it failed validation for the following reason: Configuration module_a.settings depends on the module_a extension that will not be installed after import"

If you change the configuration name to module_a2.settings afterwards, everything works as expected.

Proposed resolution

• The first part of the configuration name has to be be the extension name
• The documentation article (1) changes from "Usually, the choice of name is (extension).settings for the unique configuration name, but this is not required." to something like "The name is always (extension).settings"

Remaining tasks

• Rewrite the one sentence in documentation article (1)

Problem/Motivation

Since having lots of block derivatives has various implications for performance, it would be great to only create field blocks for entities that are customised with layout builder.

I have a site where 1600 block plugins are being created for webform submission bundles, which will never require field blocks. This number will grow for every webform added to the site.

Proposed resolution

Ensure FieldBlockDeriver only creates blocks it needs.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Since #2852067: Add support for rendering computed fields to the "field" views field handler Views can render computed fields. However, this only works for computed base fields not computed bundle fields.

The problem is that generally a view is not specific to a given bundle, so we cannot know up-front to which bundle a (computed) bundle field may belong.

Steps to reproduce

@todo

Proposed resolution

Allow specifying a bundles key as part of the views data for (computed) bundle fields and - if it is - fetch the respective field definition for those bundles.

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

Drupal 10 is scheduled to ship sometime in 2022. We should plan what to do with each of our JavaScript dependencies.
CKEditor is not part of this list, it will be handled as part of #3231364: Add CKEditor 5 module to Drupal core

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I want to use the :is() pseudo-selector within #3257583: Olivero: Refactor tabs CSS to make use of modern CSS. This is supported by Drupal 10's supported browsers. However it's not supported by the Nightwatch tests running Chromedriver 87. See https://caniuse.com/css-matches-pseudo

Problem/Motivation

The problem I encountered occurred when I was attempting to update from Drupal core 9.2.10 to Drupal core 9.3.2. It fails on the "drush updatedb" command and the site becomes unusable. Rolling back the updates with composer doesn't fix the problem as has been done on other update testing. Once the "drush updatedb" command is executed after the Drupal core and the sqlsrv module are updated, the site becomes un-recoverable without restoring a previous version of the DB.

After I ran into this error, I found one Drupal issue with the same basic problem (search_api issue 3256944). But it appeared for a specific contributed module. So, I'm posting this issue for the core level as it appears the problem affects basic user related stuff.

Steps to reproduce

Our website configurations as of 2021-12-22:

• Operating System: Windows 10 Enterprise and Windows Server 2012 R2 Standard (both are 64-bit)
• Web server: Apache 2.4.51 (64-bit) using mod_fcgid for PHP
• PHP version: PHP 8.0.13 (64-bit, non-threadsafe)
• Database: Microsoft SQL Server Enterprise 14.0.3048.4 (64-bit)
• Drupal version: 9.2.10
• Drupal driver for SQL Server and SQL Azure: 4.2.3
• PHP to SQL Server driver: 5.9.0 from https://pecl.php.net/ for sqlsrv and pdo_sqlsrv

We started using earlier, stable versions of all of the above in 2016 and have kept them all as current as possible.

We updated to Drupal 9.2.10 from an earlier 9.2 version on 2021-12-22 using composer and had no issues then or since.

We have been using the "Drupal driver for SQL Server and SQL Azure" project to interface between MS SQL Server and Drupal. Drupal 9.3 required version 4.3.1 and I attempted to update with that as well. All the composer update operations finished without errors.

This is the sequence of commands processed before the failure happened:

composer global update
drush -y config-set system.performance css.preprocess 0
drush -y config-set system.performance js.preprocess 0
drush cache:rebuild
composer require drupal/core-recommended:^9.3.2 drupal/core-dev:^9.3.2 drupal/core-composer-scaffold:^9.3.2 drupal/core-project-message:^9.3.2 drupal/core-vendor-hardening:^9.3.2 drush/drush drupal/devel composer/installers --update-with-dependencies
composer require drupal/sqlsrv:^4.3.1
drush updatedb

The output from the updatedb command:

Do you wish to run the specified pending updates? (yes/no) [yes]:
 > yes

>  [notice] Update started: user_update_9301
>  [notice] Update completed: user_update_9301
>  [notice] Update started: block_post_update_replace_node_type_condition
>  [notice] Update completed: block_post_update_replace_node_type_condition
>  [notice] Update started: node_post_update_rebuild_node_revision_routes
>  [notice] Update completed: node_post_update_rebuild_node_revision_routes
>  [notice] Update started: system_post_update_delete_authorize_settings
>  [notice] Update completed: system_post_update_delete_authorize_settings
>  [notice] Update started: system_post_update_sort_all_config
>  [notice] Update completed: system_post_update_sort_all_config
>  [notice] Update started: user_post_update_update_roles
>  [notice] The role anonymous user has had the following non-existent permission(s) removed: access site map, see menu_editor placeholder pages, use exclude node title.
>  [notice] The role authenticated user has had the following non-existent permission(s) removed: access site map, use exclude node title.
>  [notice] The roles anonymous user, authenticated user have had non-existent permissions removed. Check the logs for details.
>  [notice] Update completed: user_post_update_update_roles
>  [notice] Update started: views_post_update_sort_identifier
>  [notice] Update completed: views_post_update_sort_identifier

In ProcessBase.php line 171:

 Unable to decode output into JSON: Syntax error

 {
     "0": {
         "user": {
             "9301": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "update"
             },
             "update_roles": {
                 "results": {
                     "query": "The roles <em class="placeholder">anonymous user, authenticated user</em> have had non-existent permissions removed. Check the logs for deta
 ils.",
                     "success": true
                 },
                 "type": "post_update"
             }
         },
         "block": {
             "replace_node_type_condition": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "post_update"
             }
         },
         "node": {
             "rebuild_node_revision_routes": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "post_update"
             }
         },
         "system": {
             "delete_authorize_settings": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "post_update"
             },
             "sort_all_config": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "post_update"
             }
         },
         "views": {
             "sort_identifier": {
                 "results": {
                     "query": null,
                     "success": true
                 },
                 "type": "post_update"
             }
         }
     },
     "drush_batch_process_finished": true
 }

The double quotes within the "update_roles":"results":"query" string appear to be what are causing the upset. (The carriage returns in that string were part of the actual output.)

Subsequent "drush updatedb" commands simply state that there are no updates with no errors reported. But attempts to open any page (public or admin) failed.

Since the admin interface was no longer available to check if Drupal caught any errors, I used a Perl/Tk tool of my own design that directly reads the database to report on what is in the watchdog table and other events. That tool showed that Drupal does report an error when I try to open anything page on the site (I replaced the actual site path with {thesitebase}):

'%file' => '{thesitebase}\web\core\lib\Drupal\Core\Plugin\Context\Context.php',
'%function' => 'Drupal\Core\Plugin\Context\Context->getContextValue()',
'%line' => 73,
'%type' => 'Drupal\Component\Plugin\Exception\ContextException',
'@message' => 'The 'entity:user' context is required and not present.',
'@backtrace_string' => '#0 {thesitebase}\web\core\lib\Drupal\Core\ParamConverter\EntityConverter.php(140): Drupal\Core\Plugin\Context\Context->getContextValue()
#1 {thesitebase}\web\core\lib\Drupal\Core\ParamConverter\ParamConverterManager.php(100): Drupal\Core\ParamConverter\EntityConverter->convert('770', Array, 'node', Array)
#2 {thesitebase}\web\core\lib\Drupal\Core\Access\AccessManager.php(90): Drupal\Core\ParamConverter\ParamConverterManager->convert(Array)
#3 {thesitebase}\web\core\lib\Drupal\Core\Menu\DefaultMenuLinkTreeManipulators.php(210): Drupal\Core\Access\AccessManager->checkNamedRoute('entity.node.can...', Array, Object(Drupal\Core\Session\AccountProxy), true)
#4 {thesitebase}\web\core\lib\Drupal\Core\Menu\DefaultMenuLinkTreeManipulators.php(92): Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->menuLinkCheckAccess(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#5 [internal function]: Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->checkAccess(Array)
#6 {thesitebase}\web\core\lib\Drupal\Core\Menu\MenuLinkTree.php(149): call_user_func(Array, Array)
#7 {thesitebase}\web\core\modules\system\src\Plugin\Block\SystemMenuBlock.php(193): Drupal\Core\Menu\MenuLinkTree->transform(Array, Array)
#8 {thesitebase}\web\core\modules\block\src\BlockViewBuilder.php(171): Drupal\system\Plugin\Block\SystemMenuBlock->build()
#9 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array)
#10 {thesitebase}\web\core\lib\Drupal\Core\Security\DoTrustedCallbackTrait.php(101): call_user_func_array(Array, Array)
#11 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(772): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#12 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(363): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#13 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(435): Drupal\Core\Render\Renderer->doRender(Array)
#14 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#15 {thesitebase}\web\core\lib\Drupal\Core\Template\TwigExtension.php(463): Drupal\Core\Render\Renderer->render(Array)
#16 {thesitebase}\web\sites\default\files\php\twig\61d746f61cd7b_page.html.twig_-mba0TK8lmguGuiDYYaNh9lp7\oCZvPHaeT84n6YaBbJqRvhCqZ7uVWA_83aBD0zyo_ss.php(72): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#17 {thesitebase}\vendor\twig\twig\src\Template.php(405): __TwigTemplate_ddbd5026d0d4341c27e21b762350bfe96e8a92622d09598b9a624eb9d8b36cc4->doDisplay(Array, Array)
#18 {thesitebase}\vendor\twig\twig\src\Template.php(378): Twig\Template->displayWithErrorHandling(Array, Array)
#19 {thesitebase}\vendor\twig\twig\src\Template.php(390): Twig\Template->display(Array)
#20 {thesitebase}\web\core\themes\engines\twig\twig.engine(55): Twig\Template->render(Array)
#21 {thesitebase}\web\core\lib\Drupal\Core\Theme\ThemeManager.php(384): twig_render_template('themes/custom/d...', Array)
#22 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(422): Drupal\Core\Theme\ThemeManager->render('page', Array)
#23 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#24 {thesitebase}\web\core\lib\Drupal\Core\Template\TwigExtension.php(463): Drupal\Core\Render\Renderer->render(Array)
#25 {thesitebase}\web\sites\default\files\php\twig\61d746f61cd7b_html.html.twig_J17zj6MPfb7Nq7zxjmcGsAbdD\T4hxiOGif2VSQDw6UtWjNm07SKXQyWzwXz7-GzafMN8.php(84): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#26 {thesitebase}\vendor\twig\twig\src\Template.php(405): __TwigTemplate_cb7e698015803eec233db9f6c379f81a2821ad92cfc4696b76a442ae5b538b1f->doDisplay(Array, Array)
#27 {thesitebase}\vendor\twig\twig\src\Template.php(378): Twig\Template->displayWithErrorHandling(Array, Array)
#28 {thesitebase}\vendor\twig\twig\src\Template.php(390): Twig\Template->display(Array)
#29 {thesitebase}\web\core\themes\engines\twig\twig.engine(55): Twig\Template->render(Array)
#30 {thesitebase}\web\core\lib\Drupal\Core\Theme\ThemeManager.php(384): twig_render_template('themes/custom/d...', Array)
#31 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(422): Drupal\Core\Theme\ThemeManager->render('html', Array)
#32 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#33 {thesitebase}\web\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php(162): Drupal\Core\Render\Renderer->render(Array)
#34 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(564): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#35 {thesitebase}\web\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php(163): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#36 {thesitebase}\web\core\lib\Drupal\Core\EventSubscriber\MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#37 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#38 {thesitebase}\web\core\lib\Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher.php(142): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#39 {thesitebase}\vendor\symfony\http-kernel\HttpKernel.php(163): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#40 {thesitebase}\vendor\symfony\http-kernel\HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#41 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#42 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#43 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#44 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#45 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#46 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#47 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#48 {thesitebase}\vendor\stack\builder\src\Stack\StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#49 {thesitebase}\web\core\lib\Drupal\Core\DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#50 {thesitebase}\web\index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#51 {main}',

So, as it stands, we cannot take Drupal 9.3 until this gets fixed.

Problem/Motivation

In #2821554: [FEATURE] Deprecate jsonapi_docson in favor of Schemata. we lost the schemas for our resources. We should go back and have that information added back with the new schemas generated via the Schemata module.

Proposed resolution

Have a contrib module that has support for the JSON API specification using the Schemata module (or a similar technique). The use the reverse patch that removed the schema support in #2821554: [FEATURE] Deprecate jsonapi_docson in favor of Schemata. to add the information back to the resource info.

Additionally we should add a link to the schema in the output as a sibiling of self.

Problem/Motivation

Today, schema for JSON API can only be generated by installing the https://www.drupal.org/project/schemata module, and even then, only imperfectly. Because the Symfony serialization component is not at all concerned with tracking data transformations which of course affect the schema: we don't expose 1:1 data as it is represented by Typed Data. And Typed Data is effectively Drupal's "data schema". JSON API uses it as a starting point, but then refines it.

Proposed resolution

Design and implement an improved normalization system with schema tracking built-in. To guarantee comprehensive schema support, and hence schemas you can actually rely on.

Remaining tasks

TBD

User interface changes

N/A

API changes

#2822768: [PP-1] Add information about the schema in the json:api resource will handle exposing this schema via JSON API.

Data model changes

TBD

After upgrade from 8.6.16 to 8.8.1 this issue pops in for every path except frontpage.
There are other related issues (google_tag, splash_redirect) but here is not the case, something else is injecting it.

After an investigation it seems that $path from getAliasByPath() from AliasManager has the entire url and not only the path.
A small check can lean up the path.

Problem/Motivation

Logically, when a boolean (checkbox) field is unchecked, then logically the inherited isEmpty() method should return true. Because the "On" and "Off" labels are both required in the field's configuration, the isEmpty method returns FALSE even when the checkbox is unchecked when the entity is saved.

Steps to reproduce

Add a boolean field to a content type, and then save a node of that type with the field's checkbox unchecked. Use a debugging tool to test the value of the field's isEmpty() method and observe that the value returned is FALSE.

Proposed resolution

Override the isEmpty() method to evaluate the field value against the "On" label, and return TRUE if the field's value is anything else.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

This came up in #3081123: Add checkrequirements to VariableTranslation source plugin Comment #5. MigrateSqlSourceTestBase tests the rows returned by a source plugin it does not currently test the requirement. It would be simple to add $source_plugin->checkRequirements() but then each source plugin test would need to changed to at least add the system table with the source module enabled.

Is there any reason not to do this?