Problem/Motivation

See #1037.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Recommendations:

Change to an up/down icon when four-way movement isn't possible.

Add a border to indicate draggable items are activated on mouseover.

Problem/Motivation

Basically, if you're using CKEditor with styles dropdown and "limit allowed HTML tags", automatic "allowed tags" updating can really trip you up.

Steps to reproduce:

1. Add a new text format
2. Configure it to use CKEditor
3. Add "Styles" button to your "Active Toolbar"
4. Add a "Styles dropdown" entry, like p.test|Test
5. Enable "Limit allowed HTML tags and correct faulty HTML"
6. Under "Allowed HTML tags" enter in <p class>
   • The significance of "class" with no set value is it allows all values
7. Save the configuration
8. Edit the configuration again
9. You see this message:
   

   Based on the text editor configuration, these tags have automatically been added: <p class=" test">.

10. The "Allowed HTML tags" now has <p class=" test">

This is unnecessary because <p class> allowed for class='test', but is worse because now only the test class is allowed. Of course, you can change this before you save, but you'll have to do it every time you edit the configuration.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

If FieldPluginBase::trimText() has the values of max length 4 and with the ellipsis setting set to True... and it trims a value like 'admin' it returns admi… which is length 5 and not trimmed at all :)

Problem/Motivation

As detected by #2484693: Telephone Link field formatter InvalidArgumentException with 5 digits or fewer in the number, PHP does not guarantee the parse_url function results for URIs.
The problem is that PHP's parse_url is 'designed' for url's not for URIs.
Because by documentation parse_url:

This function is intended specifically for the purpose of parsing URLs and not URIs.

That can lead to many issues as this function is widely used in the Core as shown in the following table:

The ones which work:

Not OK:

Proposed resolution

We have Drupal\Component\Utility\UrlHelper (URL). We should create a similar UrIHelper (URI) class which is a true RFC 3986 parser.

Note: An external parser can't be used with our current Drupal requirements (PHP 5.6+ or php-intl requirements, both which Drupal doesn't have now)

Wrap parse_url in a drupal_parse_uri function so we can manage all specific cases and unit test it.

Remaining tasks

Discuss, Fix PHP, Fix Drupal, Enjoy

User interface changes

None.

API changes

An added URIHelper class.

Data model changes

None.

Problem/Motivation

In the DrupalWebTestCase->prepareEnvironment() there are more dynamic properties, which in PHP 8.2 results in these deprecation messages:

Deprecated function: Creation of dynamic property $originalLanguage is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1417 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $originalLanguageUrl is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1418 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $originalLanguageDefault is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1419 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $originalProfile is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1422 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $originalCleanUrl is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1423 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $public_files_directory is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1442 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $private_files_directory is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1443 of /modules/simpletest/drupal_web_test_case.php)
Deprecated function: Creation of dynamic property $temp_files_directory is deprecated in DrupalWebTestCase->prepareEnvironment() (line 1444 of /modules/simpletest/drupal_web_test_case.php)

Steps to reproduce

Run simpletest on PHP 8.2.

Proposed resolution

Add these missing properties to the DrupalWebTestCase class.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are creating dynamic properties on PDOException class here:

Deprecated function: Creation of dynamic property PDOException::$query_string is deprecated in DatabaseConnection->query() (line 770 of /includes/database/database.inc).
Deprecated function: Creation of dynamic property PDOException::$args is deprecated in DatabaseConnection->query() (line 772 of /includes/database/database.inc).

Steps to reproduce

Run simpletest on PHP 8.2.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The $condition property is created dynamically in MergeQuery class:

Deprecated function: Creation of dynamic property MergeQuery::$condition is deprecated in MergeQuery->__construct() (line 1357 of /includes/database/query.inc).

Steps to reproduce

Run simpletest on PHP 8.2

Proposed resolution

Add the property.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Using Drupal\Core\Archiver\Zip to initialize a zip object from a file path, I'm receiving a ArchiverException Cannot open %file_path, returned error by ZipArchive ZIP_ER_OPEN - 11

I was able to reproduce the issue with:
Ubuntu 14.04
PHP 5.6.23
ZIP lib 1.12.5

Passing a \ZipArchive::CREATE flag to ZipArchive open() method, fixed the problem, but Drupal\Core\Archiver\Zip doesn't allow to pass any additional arguments to constructor.

Proposed resolution

To add a second optional $flags argument in Drupal\Core\Archiver\Zip __constructor() and pass by default \ZipArchive::CREATE (create the archive if not exists) flag.

Problem/Motivation

We are creating dynamic property $stringVersion in the DatabaseCondition class:

Deprecated function: Creation of dynamic property DatabaseCondition::$stringVersion is deprecated in DatabaseCondition->compile() (line 1887 of /includes/database/query.inc).

Steps to reproduce

Run simpletest on PHP 8.2

Proposed resolution

Add the property.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are creating dynamic properties in the SelectQuery class:

Deprecated function: Creation of dynamic property SelectQuery::$alterTags is deprecated in SelectQuery->addTag() (line 978 of /includes/database/select.inc).
Deprecated function: Creation of dynamic property SelectQuery::$alterMetaData is deprecated in SelectQuery->addMetaData() (line 997 of /includes/database/select.inc).

Steps to reproduce

Run simpletest on PHP 8.2.

Proposed resolution

Add the properties.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The property should be defined for class on PHP 8.2, see #3275851: [META] Fix PHP 8.2 dynamic property deprecations

there's // @todo: Pass $violation->arrayPropertyPath as property path. found later in code from #1969728: Implement Field API "field types" as TypedData Plugins

Usage is small enough to replace it with proper method of current API

There's 26 usages in contrib http://codcontrib.hank.vps-private.net/search?text=arrayPropertyPath

$ git grep arrayPropertyPath
core/lib/Drupal/Core/Field/WidgetBase.php:452:          $violation->arrayPropertyPath = $property_path;
core/lib/Drupal/Core/Field/WidgetBase.php:468:            // @todo: Pass $violation->arrayPropertyPath as property path.
core/modules/text/src/Plugin/Field/FieldWidget/TextareaWidget.php:49:    if ($violation->arrayPropertyPath == ['format'] && isset($element['format']['#access']) && !$element['format']['#access']) {
core/modules/text/src/Plugin/Field/FieldWidget/TextareaWithSummaryWidget.php:103:    return ($element === FALSE) ? FALSE : $element[$violation->arrayPropertyPath[0]];
core/modules/text/src/Plugin/Field/FieldWidget/TextfieldWidget.php:40:    if ($violation->arrayPropertyPath == ['format'] && isset($element['format']['#access']) && !$element['format']['#access']) {

Steps to reproduce

Drupal\Tests\field_ui\Functional\ManageFieldsFunctionalTest::testDefaultValue

Exception: Deprecated function: Creation of dynamic property Symfony\Component\Validator\ConstraintViolation::$arrayPropertyPath is deprecated
Drupal\Core\Field\WidgetBase->flagErrors()() (Line: 452)

Proposed resolution

Could be extended with other options

1) Add a method to \Drupal\Core\Entity\EntityConstraintViolationList
2) finish todo at form-api level

Remaining tasks

- decide solution
- add test
- patch/commit

User interface changes

no

API changes

TBD

Data model changes

no

Release notes snippet

no

Problem/Motivation

Emails using MailManager::mail which don't include message id are failing (message ID is optional, even after adding message ID it still fails).
I have custom module that sends emails using MailManager::mail (Drupal::service('plugin.manager.mail').
After upgrading to Drupal core to 9.4.5, i noticed it included https://github.com/egulias/EmailValidator (3.2.x). That latest update in egulias included the below validation which is new addition for the 3.2.xx.

MessageIDValidation: Follows RFC2822 for message-id to validate that field, that has some differences in the domain part. https://github.com/egulias/EmailValidator

.

Error:
PHP Fatal error: Declaration of Egulias\EmailValidator\Validation\MessageIDValidation::isValid(string $email, Egulias\EmailValidator\EmailLexer $emailLexer): bool must be compatible with Egulias\EmailValidator\Validation\EmailValidation::isValid($email, Egulias\EmailValidator\EmailLexer $emailLexer) in <drupal root>/vendor/egulias/email-validator/src/Validation/MessageIDValidation.php on line 23

If i delete the below file , email gets sent ok and works. But there are warnings in the logs for deleted file. Also, documented below
https://www.webtrees.net/index.php/en/forum/help-for-2-0/36616-email-err...

Deleting below file works.
/vendor/egulias/email-validator/src/Validation/MessageIDValidation.php
https://github.com/egulias/EmailValidator/blob/3.x/src/Validation/Messag...

Steps to reproduce

install or update to Drupal core 9.4.5.
Try to use MailManager::mail to send an email (I'm using custom module).
Message won't be received.
Check your php error logs

Proposed resolution

Downgrade egulias/EmailValidator to a version that doesn't include the MessageIDValidation validation such as:
https://github.com/egulias/EmailValidator/tree/3.0.1

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Currently the system uses either: PECL uploadprogress http://pecl.php.net/package/uploadprogress or APC rfc1867 to show file upload progress (neither of which work with PHP 7 and nginx).

There was a discussion here https://www.drupal.org/node/1561866 about using the built in php session upload progress (PHP 5.4+) however Drupal's implementation of PHP session seems to interfere with this in a lot of cases.

https://www.drupal.org/u/droplet suggested that as D8 uses the jQuery.form plugin, it's proposed that we remove the reliance on 3rd party PHP libraries in the built in session upload progress and go with a the jQuery.form client side solution.

I have attached a patch that implements this and removes the old solutions.

It definitely needs review and some additional work (I would like this to work with remote file systems and CORS upload eventually).

Tested with Apache2 and nginx in Chrome (latest version).
I suspect there may be issues with Internet Explorer 9 compatibility. Does anyone know if there is a fallback built into jQuery.form to handle this?

Problem/Motivation

#3222947: Decide whether to move Quick Edit to contrib Is leaning towards "yes, let's remove it."

This is the issue to remove the Quick Edit Module in 10.0.x.
The issue for deprecating the Quick Edit Module in 9.5.x can be found here: #3270434: Mark Quick Edit deprecated in 9.5.x core

Steps to reproduce

n/a

Proposed resolution

Try to remove Quick Edit and see what happens.
Fix any problems that may rear ugly heads.

Remaining tasks

Currently postponed on

Nothing (but that can change very quickly...)
#3291700: new subtree split of core Quick Edit into contrib (v2)
Manual testing: An excellent example of the manual testing that happened on the Color module can be found here #3302799: Manually test color module removal and might/can/should be inspirational.

Note
This MR (against 10.0.x) needs:
- the fixture changes updated
- a separate patch against 10.1.x.

Since fixture changes are tedious work and there are a lot of those floating around in several other issues that are close to being committed, I (=Spokje) have given up on updating the MR until the dust settles a bit and I can do the update in one go.

By the time this issue is actually not being postponed any more it should be quick and easy enough (#FamousLastWords) to create the 10.1.x-patch by me or basically anybody.
The fixture update is a bit more elaborate, but I strongly believe that I since I've figured it out, so can anybody.

If anybody feels inclined to keep the MR up-to-date whilst this issue is still postponed: Please be my guest :)

The current state of the MR should be fine for both issues that this one is postponed on, since the changes that need to be made are only for automated tests outside the quickedit module itself (so OK for a new subsplit) and since its about automated tests, it doesn't interfere with the actual functionality of the module itself, so manual testing should be fine.

If not: Ping me or, preferably, do a reroll yourself :)

Related work.

• #3266476: Ensure that quickedit does not get special core treatment
• #3264949: Move quickedit help topics to Contrib quickedit module

Refer to the tracking issue for removing Quick Edit #3274155: [Meta] Tasks to remove Quick Edit from core and move to contrib

Release notes snippet

QuickEdit has been removed from core. You should add a dependency on the contributed QuickEdit module if you want to keep using this functionality. For more information, see the recommendations for handling deprecated core modules and themes.

Problem/Motivation

Steps to reproduce

Proposed resolution

1. Create a section on Deprecated and obsolete modules and themes to provide recommendations for sites using module MODULE_NAME. The recommendation are to include instructions for sites using MODULE_NAME and for contributed modules that depend on MODULE_NAME.
2. Set lifecycle to deprecated.
3. Set lifecylcle_link to the section added above, https://www.drupal.org/node//3223395#s-MODULE_NAME.
4. Add @group legacy to the tests in the module.
5. The change record for this issue includes a link to the doc page. Create a section on https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol...

Remaining tasks

1. Section on wiki page, https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsol...
2. Change record, use https://www.drupal.org/node/3263629 as an example
3. Maintainer for contrib RDF

User interface changes

API changes

Data model changes

Release notes snippet

Hi there,

I ran into an 'issue' today that gave me a "that can't be right" feeling. I know starting a module name with numeric characters is bad practice since a valid function name starts with a letter or underscore. I don't see why this should also be the case for a package name as this is (as far as my knowledge goes) only used for administrative purposes. I also know that this key should be used for grouping related modules together. In real-life i have encountered multiple projects where the package key was used to group all custom modules for a customer and the customer name was used as it's value.

As we are using Yaml files in D8 there is a difference in the usage of 007 or '007' and the second notation should not lead to any issues.

Steps to reproduce:

1. Create a custom module and set package key to '007'
2. Visit the "admin/modules" page (enabling the module is not needed)
3. See a WSOD or Error message depending on your error level

InvalidArgumentException: $string ("007") must be a string. in Drupal\Core\StringTranslation\TranslatableMarkup->__construct()

I haven't had the chance to dig deep into the code but as far is i can see now the string value from the Yaml file is presented to TranslatableMarkup->construct() as an integer, thus failing the is_string() check.

Remaining tasks

- Add 007 as the package in a test module (see system/tests/modules for many to chose from)
- Re-roll the patch
- Upload the test only version of the patch (with just the changes to the test module info file)
- Upload a test + patch version
- Needs review

Issue so I can crash test patches before they clog up an issue.

Problem/Motivation

There's a @todo in the docblock of seven_preprocess_fieldset__media_library_widget that says:

@todo Remove this when https://www.drupal.org/project/drupal/issues/2999549 lands.

There's also todo in Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget that says:

@todo Use a link here, and delete seven_preprocess_fieldset__media_library_widget(), when https://www.drupal.org/project/drupal/issues/2999549 lands.

Proposed resolution

Address the todo comments.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When doing a site clean install for some reason there's several of tens files that can't be imported in that time and I receiving the following messages (this is just few of them):
[notice] Missing required data for configuration: purge.logger_channels
[notice] Missing required data for configuration: purge.plugins
[notice] Missing required data for configuration: core.entity_form_mode.paragraph.date
[notice] Missing required data for configuration: facets.facet.content_type
[notice] Missing required data for configuration: field.field.user.user.field_picture
[notice] Missing required data for configuration: flag.flag.follow
[notice] Missing required data for configuration: language.entity.bg
[notice] Missing required data for configuration: pathauto.pattern.group_content
[notice] Missing required data for configuration: views.view.watchdog
[notice] Missing required data for configuration: views.view.who_s_new
[notice] Missing required data for configuration: views.view.who_s_online

While debugging I found that it comes from here the message: core/lib/Drupal/Core/Config/StorageCopyTrait.php from the replaceStorageContents function. Further checking this I've found that in the core/lib/Drupal/Core/Config/CachedStorage.php file the following code segment

  public function read($name) {
    $cache_key = $this->getCacheKey($name);
    if ($cache = $this->cache->get($cache_key)) {
      // The cache contains either the cached configuration data or FALSE
      // if the configuration file does not exist.
      return $cache->data;
    }
    // Read from the storage on a cache miss and cache the data. Also cache
    // information about missing configuration objects.
    $data = $this->storage->read($name);
    $this->cache->set($cache_key, $data);
    return $data;
  }

is being executed, where the cache returns an object, but the data in the object is empty. While if I run in that time the $this->storage->read($name); I get back the file contents actually.

Steps to reproduce

Unsure if it's reproducible on other installations, yet. But it should be something like this:
1. Have an already working site.
2. Try to do a clean install from config.
3. While it does the install from config I receive these messages and the configs are not installed or imported, and sometimes I can't do it even after the install as its shows like everything is imported. While enabling another module suddenly changes something and I can import the rest of the configs without an issue.

drush cr does not solve the issue, drush en and some module does...

Proposed resolution

On clean install, it should read the files instead of some cached values.

Remaining tasks

n/a

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a