When cloning an entity either via code or via a module such as Entity Clone the inline block usage is not carried over, meaning if you delete the original entity, the inline blocks will be removed and break the clone.

Problem/Motivation

Drupal's components (in the namespace Drupal\Component) all have composer.json files for #1826054: [Meta] Expose Drupal Components outside of Drupal.

For example, here's the Annotation component's composer.json:

{
  "name": "drupal/core-annotation",
  "description": "Annotation discovery and implementation of plugins.",
  "keywords": ["drupal"],
  "homepage": "https://www.drupal.org/project/drupal",
  "license": "GPL-2.0-or-later",
  "require": {
    "php": ">=7.3.0",
    "doctrine/annotations": "^1.4",
    "drupal/core-file-cache": "^8.8",
    "drupal/core-plugin": "^8.8",
    "drupal/core-utility": "^8.8"
  },
  "autoload": {
    "psr-4": {
      "Drupal\\Component\\Annotation\\": ""
    }
  }
}

There are several problems with this:

1. The PHP version requirement is wrong. Drupal core requires PHP 8.1, so PHP 8.1 syntax may appear in the core components at any time.
2. The constraint for Doctrine is out of date for D10; 10.0.x requires ^1.12.
3. The specified versions of other components are also wrong and/or broken. Very bad things would certainly happen if you tried to install the 8.8.x version of the Plugin component with parts of Drupal 10. I think the most we could guarantee is that they work with each other within the same major version. (Actually, this means they're all incorrect in Drupal 9 too, because they say ^8.8 rather than ^8.8 || 9.)

There is also no set of expectations anywhere that I could find about the support, BC, and ugprade path policies of the theoretical standalone packages that would come from these composer.json files. Nor has anyone reported the D9 components' packages being broken with unresolvable dependencies.

Proposed resolution

Either get rid of these files, or come up with a way to make them maintainable.

• One possibility is to write a script or something that at least updates them automatically for when a new major version is branched.
   

• That's still not a complete solution because they also would potentially need to be updated every time core increases a requirement for an external dependency they have a constraint on, which could happen in any minor or patch release.
   

• Additionally, the external dependencies would need to be updated between releases. For example, doctrine/annotation is going bye-bye in Drupal 10. (TBD whether this component will go along with it, or just be rewritten for the PHP attributes implementation, but other for other components it'd be easy to miss that removing a use statement might also mean needing to update the composer.json file.)

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

Drupal's Component packages are now semi-automated from drupal/drupal's update script.

The drupal/drupal dev repo now reconciles components' dependencies with those of drupal/core and drupal/drupal during a Composer update command.

This means that dependency constraints declared in the components will always follow the needs of Drupal core.

This step is taken to ease maintainership of these components.

Claro's node form's layout is handled by floats that were originally written for the Seven theme back in the dark ages of CSS.

This task is to refactor this to use either Grid of Flexbox. There should be no visual or functional differences. Care must be taken not to break focus order.

Problem/Motivation

PHPstan baseline generation seems to be taken a lot more time.

Steps to reproduce

Let's investigate

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Extend->System->Help - change sub-headings into bold

URL
sitename/admin/help/system

Problem/Motivation

PHPUnit 10 was originally planned for February 2021, but has been delayed. We are hoping to ship Drupal 10 with support for PHPUnit 10 and so we can start preparing for this now, even though it is not fully released yet, thanks to Symfony's PHPUnit bridge and #3174200: Use PHPUnit-bridge polyfills for forward compatibility layer which adds forward compatibility for PHPUnit 10 to existing tests.

Proposed resolution

• Start converting the deprecated methods as possible
• Upstream, https://github.com/symfony/symfony/issues/45223 and https://github.com/symfony/symfony/pull/45226 allows skipping Drupal's implementation of DeprecationListener to silence deprecations.
• Obviously, wait for PHPUnit 10 to be a thing
• The biggest effort will then come, i.e. converting the deprecated listeners (that will be removed in PHPUnit 10 AFAWCS) to the new event system included in PHPUnit 10. This will have upstream impacts on Symfony's PHPUnit-bridge, too, because the deprecation reporting process that it (and from there, Drupal) implements is based on listeners. So we likely will have to see what Symfony startegy will be before outlining ours.

Remaining tasks

• #3125809: Remove usages of \PHPUnit\Framework\TestListener once PHPUnit 9 support is dropped
• Allowing DrupalCI to execute PHPUnit against different phpunit.xml.dist, depending on the PHPUnit version being run, would allow minimizing the warning messages sent out when, for instance, PHPUnit 10 finds a listener section that is a must have in PHPUnit 9. For the moment it's just noise-avoidance, but who knows in the future.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

PHPStan is currently ignoring #^Cannot unset offset# errors.

Proposed resolution

Fix the issues and remove the ignore.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

(I'm not sure where to put this, component wise.)

Here is my go to configuration when theme building in Drupal:

Turn on Twig debug in sites/default/services.yml:

  twig.config:
    debug: true
    auto_reload: null
    cache: true

Disable page, dynamic_page, render cache so I get fresh data as I edit Twig templates:

$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['page'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

Rebuild Drupal cache. Launch Laravel Mix with Browsersync, and go!

The problem is that this is fairly clunky and very backend orientated.

Proposed resolution

Find some way to easily enable faster theme debugging/building mode. Something that could read settings.php setting and tell the container to recompile and set the Twig parameter to debug and auto write the null cache backend.

I think it belongs in settings.php since it's easier to have local overrides there. Drupal doesn't have out-of-the-box local site service definitions.

Remaining tasks

Get DX feedback

User interface changes

API changes

Data model changes

Follow-up issues

#3278887: Update development.services.yml to include twig debug by default

Release notes snippet

Problem/Motivation

The return docs for \Drupal\layout_builder\Section::getComponents() say:

   * @return \Drupal\layout_builder\SectionComponent[]
   *   The components.

This should say the array is keyed by the component UUID.

I was trying to write some migration code using UNION and an ORDER BY and found it putting the ORDER BY before the second query. Queries added via SelectQueryInterface::union() should either have their order stripped or be turned into subqueries. I think the fix is to move the UNION output in __toString() so it is called before the parts processing ORDER BY and RANGEs.

See also https://www.drupal.org/node/1145076 for history.

I've been running sqlite3 on my local dev environment (Ubuntu 10.04 Lucid Lynx, sqlite3 3.6.22) and have seen more than one of these fatal "database is locked" #fails. In each case, a page reload fixes it fine. I'll see if I can do an upgrade of sqlite and see what happens.

Error message
PDOException: SQLSTATE[HY000]: General error: 5 database is locked: INSERT INTO {variable} (name, value) VALUES (?, ?); Array ( [0] => rules_empty_sets [1] => a:55:{s:29:"commerce_cart_product_prepare";i:0;s:33:"commerce_customer_profile_presave";i:1;s:32:"commerce_customer_profile_insert";i:2;s:32:"commerce_customer_profile_update";i:3;s:32:"commerce_customer_profile_delete";i:4;s:26:"commerce_line_item_presave";i:5;s:25:"commerce_line_item_insert";i:6;s:25:"commerce_line_item_update";i:7;s:25:"commerce_line_item_delete";i:8;s:22:"commerce_order_presave";i:9;s:21:"commerce_order_insert";i:10;s:21:"commerce_order_update";i:11;s:21:"commerce_order_delete";i:12;s:36:"commerce_payment_transaction_presave";i:13;s:35:"commerce_payment_transaction_insert";i:14;s:35:"commerce_payment_transaction_update";i:15;s:35:"commerce_payment_transaction_delete";i:16;s:24:"commerce_product_presave";i:17;s:23:"commerce_product_insert";i:18;s:23:"commerce_product_update";i:19;s:23:"commerce_product_delete";i:20;s:19:"rules_config_insert";i:21;s:19:"rules_config_update";i:22;s:20:"rules_config_presave";i:23;s:19:"rules_config_delete";i:24;s:11:"node_insert";i:25;s:11:"node_update";i:26;s:12:"node_presave";i:27;s:9:"node_view";i:28;s:11:"node_delete";i:29;s:4:"init";i:30;s:4:"cron";i:31;s:8:"watchdog";i:32;s:11:"user_insert";i:33;s:11:"user_update";i:34;s:12:"user_presave";i:35;s:9:"user_view";i:36;s:11:"user_delete";i:37;s:10:"user_login";i:38;s:11:"user_logout";i:39;s:14:"comment_insert";i:40;s:14:"comment_update";i:41;s:15:"comment_presave";i:42;s:12:"comment_view";i:43;s:14:"comment_delete";i:44;s:15:"comment_publish";i:45;s:17:"comment_unpublish";i:46;s:20:"taxonomy_term_insert";i:47;s:20:"taxonomy_term_update";i:48;s:21:"taxonomy_term_presave";i:49;s:20:"taxonomy_term_delete";i:50;s:26:"taxonomy_vocabulary_insert";i:51;s:26:"taxonomy_vocabulary_update";i:52;s:27:"taxonomy_vocabulary_presave";i:53;s:26:"taxonomy_vocabulary_delete";i:54;} ) in variable_set() (line 804 of /home/rfay/workspace/d7git/includes/bootstrap.inc).

Problem

The SQLite database does not support row level locks. As a result we have to acquire a reserved lock on the database immediately.
For more information, see: https://bugs.php.net/42766.

Problem/Motivation

Under certain circumstances when creating a new service with new service decorators you can end up with the error

The service "moduleb.service" has a dependency on a non-existent service "modulea.service".

Presently the only way to solve this problem is to create a Service Provider with the following code:

public function alter(ContainerBuilder $container) {
    if (!$container->hasDefinition('modulea.service')) {
      $container->removeDefinition('moduleb.service');
    }
  }

There are better ways to address this issue. One potential solution is https://www.drupal.org/project/drupal/issues/3111008 because that will allow service.yml files to set decoration_on_invalid to something other than exception (the default value).

This issue is to provide a smaller solution that will hopefully be easier to get passed.

Steps to reproduce

1. Create a Drupal site. Create and install moduleb.
2. Create modulea and create a service
3. Add a service in moduleb that decorates the service from modulea

After those three steps nothing will function.

Proposed resolution

In the drupal copy of YamlFileLoader when setDecoratorService is called, it should be passed a parameter saying ignore any service with invalid behavior. This will cause any invalid service decorator to be silently ignored instead of putting the site into an unrecoverable error state.

Problem/Motivation

The image module does not test the PHP platform for library support of image types the module supports. This has affected a few site owners after upgrading to PHP builds that were not compiled with support for some image types.

Proposed resolution

Add requirements tests for JPEG support, etc.

Original report

Hi,
I installed media and media library.
I am on an Ubuntu PC with docker environement for my Drupla 8.8.2 install.
(PHP 7.3.14, Apache 2.4.38, MySql 5.7.29)

When I try to upload an image I get this error:

Warning: imagesx() expects parameter 1 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagesy() expects parameter 1 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagecopyresampled() expects parameter 2 to be resource, null given in Drupal\system\Plugin\ImageToolkit\Operation\gd\Resize->execute() (line 67 of core/modules/system/src/Plugin/ImageToolkit/Operation/gd/Resize.php).
Warning: imagesx(): supplied resource is not a valid Image resource in Drupal\system\Plugin\ImageToolkit\GDToolkit->getWidth() (line 328 of core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php).
Warning: imagesy(): supplied resource is not a valid Image resource in Drupal\system\Plugin\ImageToolkit\GDToolkit->getHeight() (line 343 of core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php).

All other functions of the site are OK.
I can also uplad PDFs with media manager but not images.

thx.

noticed in #1945226: Add language selector on menus

Updated: Comment #0

Problem/Motivation

The custom menu add form had a element to show the machine name while the title is being typed, after save, that machine name is not editable, but is shown on the edit menu form.

During creation (add), if the menu title is "hello" it shows the machine name will be hello. That's not what happens though, the machine name is actually "menu-hello", and "menu-hello" is what is shown after saving on edit of the menu

Proposed resolution

make the preview of the machine name match the actual machine name.

Remaining tasks

discuss a way to fix this.

User interface changes

No.

API changes

None anticipated.

Related Issues

• #1945226: Add language selector on menus
• ? what issue decided to prefix with menu- ? It was like that in D7.

This issue is currently postponed on:

1. a bot with a PHP 8.1. instance compiled with libavif support
2. #3116611: Add a requirements check for GD support of allowed image types
3. a PHP 8.2 bot to test getimagesize() on AVIF

Problem/Motivation

AVIF image file format is getting traction in browsers' support.

This issue is proposing to implement support to this image format in Drupal core's GD Toolkit.

Prerequisites:

• libgd should support the AVIF format - DONE, first release supporting is 2.3.2, released on: March 6, 2021
• a PHP version supporting an IMAGETYPE_AVIF constant - upstream PR https://github.com/php/php-src/pull/5127 - supported with PHP 8.1
• a DrupalCI testbot container should be available for testing.
• upstream - PHP cannot save files via imageavif(), a codec is missing - https://bugs.php.net/bug.php?id=81217
• #3239935: Refactor ToolkitGdTest

Proposed resolution

Need to decide, once the prerequisites are met, whether to provide conditional support (i.e. the toolkit supports AVIF only when libraries are availble and compiled), or strict support (i.e. libraries are required).

In the #2340699: Let GDToolkit support WEBP image format issue, the second path was taken.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Deprecated function: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\Component\Utility\Html::escape() (line 424 of core/lib/Drupal/Component/Utility/Html.php).

Error message

    Deprecated function: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\Component\Utility\Html::escape() (line 424 of core/lib/Drupal/Component/Utility/Html.php).

    Drupal\Component\Utility\Html::escape(NULL) (Line: 262)
    Drupal\Component\Render\FormattableMarkup::placeholderEscape(NULL) (Line: 208)
    Drupal\Component\Render\FormattableMarkup::placeholderFormat('@module_name (incompatible with version @version)', Array) (Line: 195)
    Drupal\Core\StringTranslation\TranslatableMarkup->render() (Line: 15)
    Drupal\Core\StringTranslation\TranslatableMarkup->__toString() (Line: 73)
    __TwigTemplate_1361787e6bd422814df2231172d66144->doDisplay(Array, Array) (Line: 405)
    Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
    Twig\Template->display(Array) (Line: 390)
    Twig\Template->render(Array) (Line: 55)
    twig_render_template('core/themes/claro/templates/classy/dataset/item-list.html.twig', Array) (Line: 384)
    Drupal\Core\Theme\ThemeManager->render('item_list', Array) (Line: 422)
    Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
    Drupal\Core\Render\Renderer->render(Array) (Line: 181)
    template_preprocess_system_modules_details(Array, 'system_modules_details', Array) (Line: 287)
    Drupal\Core\Theme\ThemeManager->render('system_modules_details', Array) (Line: 422)
    Drupal\Core\Render\Renderer->doRender(Array) (Line: 435)
    Drupal\Core\Render\Renderer->doRender(Array) (Line: 435)
    Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
    Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
    Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
    Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
    Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
    Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
    Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
    call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
    Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
    Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
    Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
    Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
    Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
    Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
    Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
    Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
    Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
    Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
    Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Steps to reproduce

After upgrade to php 8.1: Error on /admin/modules

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

PHP 8.2 is due 24 November 2022 as per https://github.com/php/php-src/milestone/4. Alpha versions are expected soon. Drupal core must be compatible with it in 9.5 and 10.0 as much as possible.
The release schedule is https://wiki.php.net/todo/php82 - at July 21 is beta1 with frozen API version should be available.
Starting with September 1 final polishing went to Release Candidate phase

Steps to reproduce

Compile PHP 8.2 locally and run a site to reproduce any errors. Once alpha releases become available, this will become easier.

Proposed resolution

See child issues.

When PHP 8.2 is available as a reasonable pre-release to begin testing with, 'un-postpone' this DrupalCI issue to create the environment:
#3283449: Create a DrupalCI Environment for PHP 8.2

Remaining tasks

See if we need more child issues. Fix the child issues.

User interface changes

N/A

API changes

See child issues.

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

PHP 8.2 has what is likely to be a hugely disruptive deprecation of dynamic properties. This is used through out core and likely to cause numerous problems. Obviously deprecation don't _break_ sites but they will introduce warnings into dev environments that capture deprecation errors and block support for PHP 9 where they will be errors.

https://wiki.php.net/rfc/deprecate_dynamic_properties

Steps to reproduce

You can compile php 8.2 and run a site and see a number of deprecation notices. Late 2022 php 8.2 should be released and we will be seeing these in phpstan and during testbot runs.

Proposed resolution

Fixes will vary. For data objects we can either add #[AllowDynamicProperties] or there is a simple-ish hack we can apply to support.

  /**
   * Raw row data.
   *
   * @var array
   */
  private array $data = [];

  /**
   * Implements the magic method for getting object properties.
   *
   * @param $name
   *   Property name.
   *
   * @return mixed
   *   The property value.
   */
  public function &__get($name) {
    return $this->data[$name];
  }

  /**
   * Implements the magic method to determines whether a property is set.
   *
   * @param $name
   *   Property name.
   *
   * @return bool
   *   True if property is set.
   */
  public function __isset($name) {
    return isset($this->data[$name]);
  }

  /**
   * Implements the magic method to set a property.
   *
   * @param $name
   *   Property name.
   * @param mixed $value
   *   The property value.
   */
  public function __set($name, $value) {
    $this->data[$name] = $value;
  }

  /**
   * Implements the magic method to unset a property.
   *
   * @param $name
   *   Property name.
   */
  public function __unset($name) {
    unset($this->data[$name]);
  }

Some things just don't work anymore #2531564: Fix leaky and brittle container serialization solution

Remaining tasks

• Create tasks for issues.
• Fix issues

User interface changes

n/a . This should only affect code interfaces.

API changes

Most changes should be to data objects or just missing properties so hopefully limited. I expect this will turn up some code smell that may result in deprecation though. Also we may find other hard changes like to our service container that require complicated fixes.

Data model changes

n/a

Release notes snippet

tbd

Problem/Motivation

The #[AllowDynamicProperties] been merged into 1.8.0 release via https://github.com/phpstan/phpstan-src/pull/1478

Steps to reproduce

See #3275858-4: View's ResultRow uses deprecated dynamic properties testing results

Proposed resolution

Upgrade to https://github.com/phpstan/phpstan/releases/tag/1.8.0 to allow testing PHP 8.2 attribute which required to fix compatibility

Remaining tasks

- define upgrade path
- create patch and fix mglaman/phpstan-drupal
- commit

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

no

Problem/Motivation

Coming from #3190585-14: [META] Run PHPStan on Drupal core but as 10.0 core should be compatible with PHP 8.2 this now required

Replace usages of static::class . '::methodName' to [static::class, 'methodName'] array callable versus concatenation on static::class

That is why we have this error:

-
			message: "#^\\#pre_render value 'non\\-empty\\-string' at key '0' is invalid\\.$#"
			count: 1
			path: lib/Drupal/Core/Render/Element/Pager.php

From:

 public function getInfo() {
    return [
      '#pre_render' => [
        static::class . '::preRenderPager',
      ],

It's just a PHPStan thing where static:class is handled a specify way for generics. So concatenating is weird. So let's use the proper array callable format for these scenarios and it will pass. See https://github.com/mglaman/phpstan-drupal/issues/301 for more background.

Other example: modules/big_pipe/tests/modules/big_pipe_regression_test/src/BigPipeRegressionTestController.php

Steps to reproduce

- https://wiki.php.net/rfc/deprecate_partially_supported_callables
- https://php.watch/versions/8.2/partially-supported-callable-deprecation

Proposed resolution

Adjust places where this is used.
Adjust baseline.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet