#Drupal 11 compatibility

Automatically closed - issue fixed for 2 weeks with no activity.

Tested the update manually and works like it should.

Perfect, thank you @grevil! Could you maybe contact @geekmerlin to merge this and tag a D11 compatible release? Would be great!

D11 is out and I think a Drupal 11 version is important for all active modules. Let's get this fixed :)

#MR 2 📌 Automated Drupal 11 compatibility fixes for page_specific_class Active works for D11. Tested on vailla D10 site as well. Moving it to RTBC

Merge request 7 is working fine.
upgrade status is showing compatible with Drupal 11 and no problem found.

Automatically closed - issue fixed for 2 weeks with no activity.

+

Please accept the merge request, or the patch 📌 Automated Drupal 11 compatibility fixes for seven Needs review .

This is blocking a lot of Drupal sites from updating to Drupal 11, since even if you apply the patch using composer patches, the update to Drupal 11 is not working.
Tbh I have not found the reason yet why this is happening. For some reason within the composer.lock file is showing the following lines.

        {
            "name": "drupal/seven",
            "version": "1.0.0",
            "source": {
                "type": "git",
                "url": "https://git.drupalcode.org/project/seven.git",
                "reference": "1.0.0"
            },
            "dist": {
                "type": "zip",
                "url": "https://ftp.drupal.org/files/projects/seven-1.0.0.zip",
                "reference": "1.0.0",
                "shasum": "88e86926388c7e6cf66b0502d13a0470ce2399cd"
            },
            "require": {
<strong>"drupal/core": "^9 || ^10"</strong>
            },

Which is causing the update to D11 to fail.
So my assumption was that there is a composer.json within the contrib theme which is revering to D9 and D10 which also needs to be adjusted. But ... there is no composer.json and so I am wondering why I got that reference to drupal/core 9 and 10 within my composer.lock file.

Automatically closed - issue fixed for 2 weeks with no activity.

I reviewed and tested MR#8 no issue with D11 installation and upgrade rector no issue reported,
MR https://git.drupalcode.org/project/blocktabs/-/merge_requests/8 ready to merge for D11 compatibility release.
artefacts attached

@Nigel Cunningham any chance for a tagged release?

thanks auto bot team yeah!

Automatically closed - issue fixed for 2 weeks with no activity.

ajitdalal → made their first commit to this issue’s fork.

MR #29 was merged yesterday

@poker10, you need to create your own issue to become a maintainer of this module. My request was closed :(

Can 8..x-2 be set as the default branch in gitlab?

Minor feedback posted on the MR. I'll try to circle back to this tomorrow to resolve that, unless someone gets to it before me. Not removing RTBC for that minor nit.

1. I've updated the identified Drupal deprecations per https://www.drupal.org/node/3436275 → . Since the maintainer (vladimuraus) set the core_version_compatibility to 10.3 and above, it is acceptable to replace these, as this release will not need to accommodate versions of Drupal core prior to 10.3
2. Irefactored the jQuery to avoid .click and .change, which are removed from jQuery 4. I functionally tested in an environment using jQuery 4.

The automated tests throw a bunch of failures for either code syntax or Drupal 12 compatibility, but that seems out of the scope of this issue. Setting to "Needs Review."

It looks like this was already resolved in an unrelated Gitlab migration issue 📌 Gitlab CI yml & Drupal 11 support Fixed : https://git.drupalcode.org/project/block_list_override/-/commit/c4725035...

Automatically closed - issue fixed for 2 weeks with no activity.

The proposed changes have been addressed in 📌 [PP-1] Code styling and PHPStan level 8 Active !

Automatically closed - issue fixed for 2 weeks with no activity.

Setting to "Active" to continue to receive deprecation code changes. The actual D11 compatibility effort is in 💬 Drupal 11 release Active .

Yes exactly, -dev. It is not stable yet as there still are issues, at least one test that does not pass.

Fixed. Released with 8.x-1.0-alpha4.

Can we assume new 2.x and 3.x release will be forthcoming in the next couple weeks?

Automatically closed - issue fixed for 2 weeks with no activity.

I added a gitlab ci file to run D11 tests. There are none, so it is unclear if this is actually compatible w/ Drupal 11. However, phpstan and phpcs both come back as pretty clean so I'd give my reserved suggestion this can be RTBC. But ideally we'd add even the most simple of tests to the project to give greater assurance.

One of my recommendations would be to add an issue with a test coverage MR. That would surely demonstrate commitment to this project and desire to see it more better.

The module is now Drupal 11 compatible.

Tested on a D11 project and works without any changes necessary!

Retested in Drupal 11 from start to finish. All working good.

Merged already.

I added some changes to MR1 that adds D11 compatibility and fixes all validations tasks in the Gitlab pipeline.

ajitdalal → made their first commit to this issue’s fork.

Automatically closed - issue fixed for 2 weeks with no activity.

I tested it in my project. Works as expected

Automatically closed - issue fixed for 2 weeks with no activity.

Okay I fumbled around a bit (issue forks are a little tricky) on MR 19 but I think this encompasses your changes tolstoydotcom and a few small small type-safety changes. I think we can roll this in unless someone catches an issue that needs attention.

as it is going to drop support for anything below 10.3, which can be disruptive for existing sites

Yes, of course. Just an idea :)

Let's working on 2.x branch

@ivnish I would probably not do that in 8.x-1.x, as it is going to drop support for anything below 10.3, which can be disruptive for existing sites?

Thanks for creating the other issue.

#MR13 works fine for both D10 & D11 versions. Requesting for the issue RTBC.

jayapriya-18 → changed the visibility of the branch 3483812-d11_ready to hidden.

The change to onlyMethods happened in D9 (example: #3250629: MockBuilder::setMethods is deprecated in PHPUnit8 and removed from PHPUnit10 → ) so we can change to:

+core_version_requirement: ^10 || ^11

once the fixes are done.

Needs work per review.

@poker10 I created https://www.drupal.org/project/projectownership/issues/3488525 📌 Add "administer maintainers" permission to an active maintainer Active

@mark_fullmer good job!

I think we can just add D11 support to 8.x-1.x and allow people to upgrade their sites to D11

Looking at this and 📌 Automated Drupal 11 compatibility fixes for quantcdn Needs review

Looking at this and 📌 Drupal 11 compatibility changes Postponed

I can help with contribute, but we need a plan for 4.0 release

Thank you for the update :+1

henokmikre → closed merge request !1

All I can promise is that I am running 4.0.x-dev on a D11 site and I haven't had problems with it. The best way to find problems is to actually use it - there are probably no more than a handful of sites that have tried it so far. I am making progress, but like you said it's probably going to take a while especially with no community contribution.

laura.j.johnson@gmail.com → made their first commit to this issue’s fork.

Tested in clean drupal 11 install. This works fine, though suffers from 🐛 OTP Email not send Active as well. Anyways that can be addressed there, so this is ready to merge (ie, branch 'project-update-bot-only')

The changes in the patch have all been made already in branch 3.x; see commit 73bb6cd. Leaving open for more patches.

Has also been merged into the new 3.0.x semantic versioning dev branch based on 8.x-2.x for the upcoming semantic versioning release with long holding RTBCs committed to both branches.

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

https://www.drupal.org/project/webform/releases/6.3.x-dev →

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.

@rahul17 you should create other issue for gitlab-ci, it's irrelevant in this issue.

Do you have any confirmation that this module will drop D8 support?

Duplicate issue https://www.drupal.org/project/opigno_class/issues/3483696

Duplicate of 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review
@prudloff thanks for your work here, I credited you in the other issue.

duaelfr → credited prudloff → .

Adding credits from 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review

josedsilva → reopened merge request !2

josedsilva → closed merge request !2

I've scan the module using upgrade status & made required changes to make it compatible with D11.

Just tagged D11 compatible 2.1.0 release, thank you all! 🎉

anybody → closed merge request !7

Thanks you all for fixing that and testing!

ajit dalal → closed merge request !3

Automatically closed - issue fixed for 2 weeks with no activity.

jayapriya-18 → changed the visibility of the branch drupal-11-compatibility to active.

Phpstan issue is already covered here: 🌱 The method \Drupal::moduleHandler()->getName($module) has been deprecated Active

The patch primarily updates the .yml file and appears solid upon review.

I successfully applied the patch and ran the module without encountering any alerts or issues.

However, I couldn't test more advanced features, so this review is partial. Further testing would be beneficial to confirm the module's full functionality.

The patch primarily updates the .yml file and appears solid upon review.

I successfully applied the patch and ran the module without encountering any alerts or issues.

However, I couldn't test more advanced features, so this review is partial. Further testing would be beneficial to confirm the module's full functionality.

The patch primarily updates the .yml file and appears solid upon review.

I successfully applied the patch and ran the module without encountering any alerts or issues.

However, I couldn't test more advanced features, so this review is partial. Further testing would be beneficial to confirm the module's full functionality.

The patch primarily updates the .yml file and appears solid upon review.

I successfully applied the patch and ran the module without encountering any alerts or issues.

However, I couldn't test more advanced features, so this review is partial. Further testing would be beneficial to confirm the module's full functionality.

The patch primarily updates the .yml file and appears solid upon review.

I successfully applied the patch and ran the module without encountering any alerts or issues.

However, I couldn't test more advanced features, so this review is partial. Further testing would be beneficial to confirm the module's full functionality.

@nicrodgers Given that Drupal 10.1 has reached end-of-life and is no longer maintained, dropping support for it seems reasonable. Removing compatibility with deprecated versions can streamline the codebase and reduce technical debt, allowing for a more efficient implementation of current best practices, including using utilities like DeprecationHelper. Moreover, aligning with supported versions ensures we stay updated with security patches and new features.

composer require 'drupal/webform:6.3.x-dev@dev' is drupal-11 compatible

Good call, @poker10. Here's my audit & analysis:

1. The cumulative code changes between the 2.x and 8.x-1.x branch can be seen at https://git.drupalcode.org/project/xmlsitemap/-/compare/2.x..8.x-1.x

• The change committed to 8.x-1.x not present in 2.x is https://git.drupalcode.org/project/xmlsitemap/-/commit/40727c92415802bb1... , which is innocuous enough and could simply be merged into 2.x without issue
• The changes committed to 2.x not present in 8.x-1.x consist of https://git.drupalcode.org/project/xmlsitemap/-/commit/1d59a51562d50b7d3... (see #3257944: PHP 8.1: XmlSitemapWriter::openUri($uri) should either be compatible with XMLWriter::openUri(string $uri): bool → ). This commit removes functions that were deprecated in 8.x-1.x and provides additional PHP 8.1 compatibility with return type hinting.

2. Of note, this MR removes the explicit PHP version constraints from the composer.json file and xmlsitemap.info.yml file that were added in https://git.drupalcode.org/project/xmlsitemap/-/commit/1d59a51562d50b7d3... . I believe this makes sense, since there is no longer a need to specify minimum PHP 8.1 compatibility in the module itself, since its constraint to Drupal 10/11 does the same thing. Conclusion: this change in the MR is fine.

3. I functionally tested this MR locally and can confirm that it works the same in our codebase as 8.x-1.5. While my testing certainly didn't comprehensively evaluate all of the options for XML sitemap, the code review above suggests that there should not be any functional or backwards-compatibility breaking change, and since the Drupal core compatibility is set at ^10.3 || ^11, which have a minimum PHP version requirement of 8.1, there is no risk of incompatibility with sites running on PHP 7.

4. Based on the above, the actions to take, I believe, are:

• (Optional, but probably a good idea) Merge 8.x-1.x into 2.x once more, which will simply add the logo.png file to 2.x and get the branch history up to date.
• Merge the Drupal 11 compatibility changes in this issue into 2.x and release 2.0.0-beta1. The release notes should call out the following:
  • The 2.x major version release of XML Sitemap removes functions deprecated in 8.x-1.x four years ago. The functions were likely unused, but developers who have extended XML Sitemap should review #3156088: user_access() does not exist in Drupal 8 anymore → for confirmation.
  • 2.x also drops support of Drupal 9 up to Drupal 10.2 (i.e., compatible with Drupal 10.3 and 11). Sites still using lower versions of Drupal core should continue to use 8.x-1.5.

Thanks for the merge @dqd!

Thanks for all the hard work in here and the patience for the final commit to latest dev. And to the Drupal 11 compatible upcoming release soon. Any thing you wish to have in the next release, please try to bring according issues to RTBC as soon as possible to be ready to get in.

You all rock! +1

ajit dalal → made their first commit to this issue’s fork.

@tjtj

No they don't, just the -dev version. On stable they are still on 6.2.7.

#17 has been addressed.
Tests are green.

So looks RTBC to me.

Yes, I can commit this and create a release. I looked at the MR and all changes looks good to me (tests are passing with these changes). I can't tell without a deeper check, if the MR is not missing something else, but if tests are green, probably not.

One thing I am not sure about is the status of the 2.x branch. There seems to be some additional commits in comparision with the 8.x-1.x branch. Yes, I can roll a 2.x-beta, but have anyone tested the 2.x-dev if it is really working with all changes currently committed? Sorry, I do not have time to check it commit by commit now.

Thanks!

I've tested the changes from MR11 against drupal/core 11.0.7 and it works as expected.

The steps I took;

1. Fresh Drupal installation with drupal/recommended-project:^11
2. Used mglaman/composer-drupal-lenient and cweagans/composer-patches to install the patch
3. Add the file plugin to the editor
4. Verified that I can upload a file

https://www.drupal.org/project/xmlsitemap/maintainers.json →

Looks like poker10 has all permissions except "administer maintainers"

I think he can commit this and create a new release. It won't take long

@tolstoydotcom, thank you, I was testing against the dev branch. Patch applied fine for me against 8.x-3.x and everything is working well on Drupal 10.3.6.

AFAIK, the link in my last comment is where the latest code is. If anyone wants to test it, just:

git clone git@git.drupal.org:project/wordpress_migrate.git
cd wordpress_migrate
patch -p1 < d11update-3435726-13.patch

Maybe use a Gitlab fork, to streamline the process?

Thank you! Merged !8 without sqashing commits!

If you clone https://git.drupalcode.org/project/wordpress_migrate the patch should apply cleanly.

How do I get a patch to apply or a new D11 release? This is stop[ping my D11 upgrade. Webform has 6.3 out.

Tested with Drupal 11.0.7. Uploading files in the CKEditor resulted in an error due the deprecation of file_validation methods.
file_validate and related functions are deprecated and replaced with file.validator service and Constraint plugins →

I've updated MR11 to replace the deprecated file_validation methods.

@tolstoydotcom I tried applying the patch against wordpress_migrate 3.x-dev@dev but it failed to apply. Do you have other patches applied?

Composer gives me the error:

Gathering patches for dependencies. This might take a minute.
  - Installing drupal/wordpress_migrate (dev-3.x b0ebd6d): Cloning b0ebd6d586 from cache
  - Applying patches for drupal/wordpress_migrate
    patches/d11update-3435726-13.patch (D11)
   Could not apply patch! Skipping. The error was: Cannot apply patch patches/d11update-3435726-13.patch

A src/WordPressMigrationGenerator.php.rej file was generated with the conflicts:

--- src/WordPressMigrationGenerator.php
+++ src/WordPressMigrationGenerator.php
@@ -196,12 +203,12 @@ class WordPressMigrationGenerator {
   protected function createContentMigration($wordpress_type) {
     $dependencies = [];
     $content_id   = $this->configuration['prefix'] . 'wordpress_content_' . $wordpress_type;
-    $migration    = static::createEntityFromPlugin('wordpress_content', $content_id);
+    $migration    = $this->createEntityFromPlugin('wordpress_content', $content_id);
     $migration->set('migration_group', $this->configuration['group_id']);
-    $source                   = $migration->get('source');
+    $source = $migration->get('source');
     $source['item_selector'] .= '[wp:post_type="' . $wordpress_type . '"]';
     $migration->set('source', $source);
-    $process                = $migration->get('process');
+    $process = $migration->get('process');
     // Path alias generator.
     $process['path/alias'][] = [
       'plugin' => 'str_replace',
@@ -224,12 +231,12 @@ class WordPressMigrationGenerator {
       'replace' => '',
       'regex' => TRUE,
     ];
-    $process['uid']         = $this->uidMapping;
+    $process['uid'] = $this->uidMapping;
     $process['body/format'] = [
       'plugin' => 'default_value',
       'default_value' => $this->configuration[$wordpress_type]['text_format'],
     ];
-    $process['type']        = [
+    $process['type'] = [
       'plugin' => 'default_value',
       'default_value' => $this->configuration[$wordpress_type]['type'],
     ];

Good news: I am added. So things will move on now! :+1: I will make you patiently waiting users happy soon ;-)

I just wanted to prevetn too much noise here, that's why I haven't reported yet in here that I have contacted @woprrr already some days ago inviting to add me as co-maintainer to help out for a final Drupal 11 release and beyond So let us be patient and wait a little bit. A I know very well maintainers have a lot to manage. We will move on here as soon as possible.

Decrease issue prio. Descriptions of the Priority → and Status → values can be found in the Drupal project issues → documentation.

Perhaps the testing-related stuff should be moved to 📌 Write basic tests Active .

I wasn't sure if fixing phpcs wold be in scope, but it's great to see fully green. Thank you, @liam morland.

I made some simple coding standards fixes and now tests are fully passing.

liam morland → made their first commit to this issue’s fork.

With 10.3 as the minimum, you can remove the call to version_compare().

There should be a newline at the end of .gitlab-ci.yml.

In addition to changing FormElement to FormElementBase. I changed the minimum Drupal version to 10.3

so how do I install the working D11 version?

I've send the maintainers a message in Slack. Would be nice if this issue lands soon.

Here's an updated patch. It should work with D9/D10 but I only tested D11 this time.

That is fair enough ressa regarding D9 EOL. Maybe the best move is, tag another release as "the last D9 supported release", and after that, include this patch.

@poker10 Do you have permission to cut a release for the 2.x branch? Seems the community has tested this and feels comfortable with this.

Verified patch is working with Drupal and no error found with Drupal rector. Please release Drupal 11 compatibility version.

ajit dalal → made their first commit to this issue’s fork.

I was able to clone in local. Verified functionality in Drupal 10 and Drupal 11 which looks good to me.
Upgrade status and PHPCS is also showing no error found.

Changing status to RTBC.

theme_switcher-3434980 % git status
On branch 3434980-gitlabci
Your branch is up to date with 'origin/3434980-gitlabci'.

nothing to commit, working tree clean
theme_switcher-3434980 %

Thanks everyone for working on this. "hold onto" means keep doing something, which slightly contradicts the first part of the sentence ... But I assume the decision is "No D9 support"?

I think that will be fine. After all, Drupal 9 reached end of life November 2023 https://www.drupal.org/about/announcements/blog/drupal-9-is-end-of-life → .