Problem/Motivation

PHP 8.1 introduces many deprecation notices that would not appear previously. In my experience, it seems that hitting one of these notices (when thrown by a contrib module) generally causes a critical error coming from Core -- Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).. In such cases, the deprecation message is included in the stack trace:

The website encountered an unexpected error. Please try again later.
Error: Class "Drupal\Core\Utility\Error" not found in _drupal_error_handler_real() (line 63 of core/includes/errors.inc).

_drupal_error_handler_real(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 346)
_drupal_error_handler(8192, 'Return type of Drupal\profile\Plugin\Field\ProfileEntityFieldItemList::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice', '/var/www/html/drupal/web/core/lib/Drupal/Core/TypedData/ComputedItemListTrait.php', 121) (Line: 571)
include('/var/www/html/drupal/web/core/includes/bootstrap.inc') (Line: 571)
Composer\Autoload\includeFile('/var/www/html/drupal/vendor/composer/../../web/core/lib/Drupal/Core/Utility/Error.php') (Line: 428)
Composer\Autoload\ClassLoader->loadClass('Drupal\Core\Utility\Error') (Line: 44)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->on403(Object) (Line: 97)
Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber->onException(Object, 'kernel.exception', Object)
call_user_func(Array, Object, 'kernel.exception', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.exception') (Line: 219)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable(Object, Object, 1) (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 67)
Drupal\simple_oauth\HttpMiddleware\BasicAuthSwap->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: 49)
Asm89\Stack\Cors->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)

Fixing/patching the deprecation seems to get rid of the notice, as well as this error handler error itself. The error handler error is problematic because it turns what should be a simple notice into a critical failure. I think that what must be happening is that the deprecation is somehow short-circuiting the autoloader or something.

Steps to reproduce

Trying to figure out simple steps to reproduce on a clean install. Not sure of a good way yet.

Proposed resolution

Unsure.

We should use href=":link" instead of href="@link" as a best practice in core.

href="@link" is insecure in some cases because it's not filtering insecure protocols.

We should use href=":link" to prevent creating insecure code when developers copy&paste code from core.

I know that code like this is safe:

<a href="@drupal"> Drupal.org </a>. ', [' @drupal '=>' https://drupal.org ']

but I think we should also use :drupal as a best practice in core, using always the secure variant to prevent copy&paste mistakes.

Problem/Motivation

Follow-up from #3261486: Remove core updates added prior to 9.3.0 and adjust test coverage.

Does it make sense to add drupal-9.3.0.bare.standard.php.gz and drupal-9.3.0.filled.standard.php.gz to Drupal 9.3 and 9.4?

contrib modules with update tests that try to add Drupal 10 support can reference those files, instead of adding a check if the current Drupal version is Drupal 10, use drupal-9.3.0.bare.standard.php.gz. Else, use drupal-9.0.0.bare.standard.php.gz

Proposed resolution

Copy drupal-9.3.0.bare.standard.php.gz and drupal-9.3.0.filled.standard.php.gz from the Drupal 10 branch to Drupal 9.4 so contrib modules can use those dumps for their update tests in both Drupal versions.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Media embed attributes are rendered in the container div when preview is rendered in editing view. This includes the alt attribute, which is not a valid attribute on div element.

Proposed resolution

Do not render attributes on the preview container div in editing view.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

This is an issue that we haven't had to deal with since the Drupal 6 to Drupal 7 upgrade path, but now we do again.

The following scenarios are broken:

hook_update_N()

system_update_8900() is added to 8.9.x and 9.0.x

[time elapses]

system_update_9100() is added to 9.1.x to support a new feature, it is not backported to 8.9.x

[time elapses]

A critical bug fix which is eligible for backport to 8.9.x, but requires a small update, is committed to 9.1.x.

[dragons emerge from the darkness, volcanos erupt]

If this update is added as system_update_9101() and backported to 8.9.x, then when 8.9.x sites are updated to 9.1.x, they won't run system_update_9000() because their schema version will be higher already.

If this update is added as system_update_8901() in 9.1.x, and 8.9.x, it won't run on 9.1.x sites because their schema version will be higher already.

hook_post_update_NAME()

This is less of an issue, but still a problem:

system_post_update_fix_config() is added to 9.2.x, it is backported to a 9.1.x patch release, and 8.9.x because it's the LTS, but not 9.0.x because it's security-only.

If a site updates from 8.9.x to 9.0.x, then the post update goes 'missing' from the code base. It will then re-emerge when the site updates again to 9.1.x or 9.2.x

Sequential backports to minor branches without skipping a release are OK though for post updates regardless of how far they go back, since they don't interfere with other post updates.

Proposed resolution

tl;dr

Don't add any 9.x-only hook_update_N() to Drupal 9.0.x, Drupal 9.1.x, or Drupal 9.2.x

If we do, and we have to subsequently backport an update to 8.9.x, this is what we need to do instead:

1. Add the update as system_update_8901() in Drupal 8.9.x. This updates sets a semaphore in state or key/value like system_update_8901_run.

2. Add the update, with nearly identical code, as system_update_9101() to 9.1.x. This update instead of setting the semaphore, checks if we have one, and if so deletes the semaphore and returns early because it's a no-op.

This does not affect modules until they add 9.x-only updates, until then we can continue adding 89** updates and backporting them.

It also doesn't affect post-updates because ordering/dependencies do not matter for those.

To avoid this:

Remaining tasks

There is no actual code to write here, this issue is mainly for documentation and to explore if there are any alternative approaches.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The system_site migration migrates empty (or missing) site_403 and site_404 variables as front page path (/).
In addition to this, when drupal_weight_select_max is unavailable in the source DB, it will be set to 0, but in these cases, we should migrate its default value, which is 100.

h2. Steps to Reproduce
Execute system_site migration with empty (or missing) site_403 and site_404 variables.

h2. Expected Result

• Empty or missing site_403 variable is migrated as an empty 403 page config.
• Empty or missing site_404 variable is migrated as an empty 404 page config.
• Missing drupal_weight_select_max is migrated as weight_select_max set to 100.

Steps to reproduce

Execute system_site migration with empty (or missing) site_403 and site_404 variables.

Proposed resolution

Skip processing of 'page/403' and 'page/404' destination properties if the corresponding Drupal 6 / Drupal 7 variables are empty.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There is a test failure in Aggregator update path test on PostgreSQL:

testAggregatorUpdate

fail: [Other] Line 44 of modules/simpletest/tests/upgrade/update.aggregator.test:
Feed data was preserved during the update.

The issue seems to be that the db_select() does not use ORDER BY, so that the order of the returned items could be different in each of the two runs of the query->execute():

    $pre_update_data = $query->execute()->fetchAll();
    $this->assertTrue($this->performUpgrade(), 'The update was completed successfully.');
    $post_update_data = $query->execute()->fetchAll();

Steps to reproduce

Run Aggregator update path test on PostgreSQL.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

PathMatcher::isFrontPage does not work with aliased paths, causing the front page path to not redirect to the root path if an aliased path is used. Internal paths like /node/1 work fine.

• With /homepage (path alias) as front page, visiting / redirects to /homepage
• With /node/1 as front page, visiting / does not redirect (this is the correct behavior)

The site configuration form makes it look like the front path is the path alias, but in reality the /node/1 path is stored in system.site config. This creates a hard dependency between site content and site configuration, something that's not desirable in modern workflows.

Steps to reproduce

1. Create a page node with alias /homepage
2. Configure the front page path to be /homepage
3. Visiting the front page will result in the /homepage path, instead of the root path

Proposed resolution

Change PathMatcher::isFrontPage to check both internal and aliased paths.

Remaining tasks

Problem/Motivation

Calling ImageFormatter::__construct() without the $file_url_generator argument is deprecated in drupal:9.3.0 and the $file_url_generator argument will be required in drupal:10.0.0. See https://www.drupal.org/node/2940031

Steps to reproduce

This field formatter extends its parent and needs to pass the right parameters in the constructor.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Discovered while working on #3224652: [drupalImage] Add ckeditor5-image's imageresize plugin to allow image resizing.

$assert_session->waitForElementVisible('css', '.figure.image')

is wrong, it should be figure.image.

Steps to reproduce

N/A

Proposed resolution

1. Assert the result: guarantees the selector works; should fail tests
2. Fix selector; should make tests pass again

Remaining tasks

Review

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Coming from #934050: Change format into string:

Relatively complex problem space; the below list of problems are depending on each other, so it does not make sense to split them into separate issues. The resolution needs to take all of them into account.

Problem

• A field schema is set in stone after initial creation and cannot be updated.

Goal

• Field type modules have to be able to programmatically update their field schema.

Details

• As with any other module, the field schema of field type modules will change over time. Currently, Field API tries to prevent any schema updates on the assumption that the schema update has been triggered via Field UI. While limiting the possibilities of the user interface makes sense to some extent, there must be a way for field type modules to perform intended, safe, and wanted field schema updates, just like any other module has to be able to update its schema. Field type modules are no exception to that rule.

  AFAICS, Field UI already implements the necessary logic to prevent users from updating a field schema through the UI. The current patch does not change the runtime API of field_update_field(), so it still disallows field schema changes. Instead, an update helper function is introduced, which basically is the same as field_update_field(), but works within the update.php environment and does not disallow schema changes.

EDIT: Splitted the other issues with field_update_field() into #937554: Field storage config entities 'indexes' key

Problem/Motivation

I am finding in the reports the following message:

TypeError: Exception::__construct(): Argument #3 ($previous) must be of type ?Throwable, string given in Exception->__construct() (line 103 of /var/www/drupal/core/lib/Drupal/Core/Database/Driver/pgsql/Insert.php)

In the line 103 of Insert.php we see:

throw new DatabaseExceptionWrapper($message, 0, $e->getCode());

"DatabaseExceptionWrapper" extends "\RuntimeException" that expect as third parameter a "Throwable". Here "$e" is a "PDOException", and getCode() return a string.

Steps to reproduce

I can't tell when it happens exactly because it hides the real DB error.

Proposed resolution

Use "$e" as third parameter instead of "$e->getCode()"

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up for #3202664: CKEditor 5's UI language should match Drupal's interface translation to provide API for contrib projects to load CKEditor translations. This requires identifying which translation files exist, an associating them to the related library. Once the translation file is associated to the correct library, CKEditor 5 module is able to load the correct translation files based on the current UI language.

Proposed resolution

CKEditor 5 plugins needs to be compiled with the DLL build to be able to work with Drupal. This build automatically adds translations to the translations/ subdirectory. This is predicable because the original .po files used in the translation process are in a lang/translations/ sub-directory by convention.

The expected directory structure of a DLL build is the following:

ckeditor-plugin-name/
  - translations/
  - ckeditor-plugin-name.js

The only thing needed from contrib author is to declare that a plugin has translations and it can be done by adding a dependency to the core/ckeditor5.translations library in their plugin library declaration. Then Drupal will automatically find and load translations files.

myDrupalCkeditorPlugin:
  js: 
    assets/js/ckeditor5/ckeditor-plugin-name/ckeditor-plugin-name.js: { minified: true, preprocess: false }
  dependencies:
    - core/ckeditor5
    - core/ckeditor5.translations

With this declaration will automatically look for translations in the assets/js/ckeditor5/ckeditor-plugin-name/translations/* folder.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

There is a test failure in Basic minimal profile update path tests in testBasicMinimalUpdate() on PostgreSQL.

The failure looks like this:

fail: [Other] Line 582 of modules/simpletest/tests/upgrade/upgrade.test:
Unique key on {date_formats} exists

The issue with this is that db_index_exists() on PostgreSQL will check the index name with the pattern [table]_[name]_idx, but the real unique key name is [table]_[name]_key (as it is not an index, but a unique key). So the check in PostgreSQL will never succeed. MySQL and SQLite are not suffixing indexes/keys so they are not affected by this.

Steps to reproduce

Run Basic minimal profile update path tests in PostgreSQL.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Comment form needs to override destination when comment form submitted on comment field attached to block content entity
After submission visitor should stay on the same page

Steps to reproduce

If a comment-form is attached to a block, the redirect after submission is wrong - it points to the page "block/[block-id]/2#comment-x - instead of the current page.

Proposed resolution

add protected method to return commented entity (to which comment is attached to)

Remaining tasks

fix patch, add test, commit

User interface changes

submission a comment form attached to block content entities keeps you on the same page (current URL)

API changes

TBD

Data model changes

no

Release notes snippet

no

Problem/Motivation

Discovered while working on #3206522: Add FunctionalJavascript test coverage for media library.

In the CKEditor 4 media integration, the EditorMediaDialog shows a placeholder containing the default alt for the image media.

In CKEditor 5, it does not show this. (Note that alt text overrides were added in #3206461: Support alt text for image Media.)

We should consider making it happen there too.

It's not without challenge though:

Today

Ideal

But … CKEditor 5's fancy UX for showing the label in a tiny way gets in the way

If you specify a input[placeholder] value, then the result looks like this today

Steps to reproduce

Click embedded image media's "override alt" button in the balloon.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

None.

Data model changes

None.

After some modifications in my block settings and my custom menu which are all migrated from a drupal 6 site i got the following error on blocks layout page:

InvalidArgumentException: $string ("Array") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct() (line 140 of core\lib\Drupal\Core\StringTranslation\TranslatableMarkup.php).

Perhaps the issue is not related to the block modification but after uninstall blocks module the error disappeared.

This is a translated one lingual Hungarian site running on Drupal 8.1.0.

Please help! I am really stuck :(

Problem/Motivation

testExpressionUpdate

fail: [Other] Line 878 of modules/simpletest/tests/database_test.test:
Number of affected rows are returned.

  /**
   * Test updating with expressions.
   */
  function testExpressionUpdate() {
    // Set age = 1 for a single row for this test to work.
    db_update('test')
      ->condition('id', 1)
      ->fields(array('age' => 1))
      ->execute();

    // Ensure that expressions are handled properly.  This should set every
    // record's age to a square of itself, which will change only three of the
    // four records in the table since 1*1 = 1. That means only three records
    // are modified, so we should get back 3, not 4, from execute().
    $num_rows = db_update('test')
      ->expression('age', 'age * age')
      ->execute();
    $this->assertIdentical($num_rows, 3, 'Number of affected rows are returned.' . " num_rows: $num_rows");

Steps to reproduce

With PostgreSQL $num_rows is 4 so the test fails.

Proposed resolution

Probably backport changes made in #805858: Affected rows inconsistent across database engines

Problem/Motivation

Internet Explorer is currently the only browser supported by Drupal which doesn't ship with scripting engine that conforms (at least for the most part) with ECMAScript 6. Drupal 10 will drop support for Internet Explorer 11: #3155358: [policy, no patch] Drop IE11 support from Drupal 10.0.x.

The current build tooling requires us to depend on handful of 3rd party dependencies, increasing the cost of maintenance. Requiring a build step, duplicates all JavaScript code, and also makes the contributor experience more complicated, requiring contributors to use additional tooling when working on issues modifying JavaScript.

There could be some reasons to keep the tooling because the way the build tool is set up at the moment, would allow us to utilize features from newer versions of the ECMAScript standard. The tooling reduces the likelihood of accidentally using syntax that isn't supported by all of the supported browsers.

Goals

1. Remove a large number of JS dependencies by not needing most of babel toolchain
2. Remove code duplication in the code source
3. Keep naming relevant, in D10 we have a .es6.js file that contains ES6 and a .js file that also contains ES6 code.

Proposed resolution

The es6 trick allowed us to use new features for old browsers, now the supported browsers caught up and we don't need this workaround anymore. We can rename all the .es6 files to .js and update all the toolchain we have to remove all the compile/checks steps for JS code.

Use tool like es-check to see if we are using any features not included in ES6 standard, and check browser support for the features not part of ES6 standard manually.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet