Drupal 11 compatibility for Features module

Hii @mark_fullmer

I have created patch for "Drupal 11 compatibility for Features module" . Thanks

Came across this patch because I wanted to work features into a demo. I can't even get the demo going because I can't get features included via composer.

We need this in.

I think this patch needs more testing. I did the following:

1. I rolled a brand new D11 site with just features (and the require dependency, config_update and features_ui, installed).
2. I navigated to the features_ui admin page (/admin/config/development/features) and received the following error:

The website encountered an unexpected error. Try again later.

Error: Call to a member function getName() on null in Drupal\features_ui\Form\FeaturesExportForm->buildPackageDetail() (line 382 of modules/contrib/features/modules/features_ui/src/Form/FeaturesExportForm.php).
Drupal\features_ui\Form\FeaturesExportForm->buildListing() (Line: 181)
Drupal\features_ui\Form\FeaturesExportForm->buildForm()
call_user_func_array() (Line: 528)
Drupal\Core\Form\FormBuilder->retrieveForm() (Line: 279)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

Apply this MR for D11 now with:

...
    "repositories": {
        "https://packages.drupal.org/8": {
            "canonical": false,
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        },
        "https://drupal.org/node/3447460": {
            "canonical": false,
            "type": "vcs",
            "url": "https://git.drupalcode.org/issue/features-3447460.git"
        },
    },
...
    "require": {
        "drupal/features": "dev-3447460-drupal-11-compatibility",
    }
...

Merge with https://www.drupal.org/node/3229045 →

so should we just manually install this for D11?

The latest two commits address compatibility with PHPUnit 10 and PHP 8.2:

• Unit test dataProviders must be static methods, per https://www.drupal.org/project/drupal/issues/3353210 📌 [PHPUnit 10] @dataProvider methods must be declared static and public Fixed
• Creation of dynamic properties are deprecated, per https://www.php.net/manual/en/migration82.deprecated.php

PHPUnit tests are green for both Drupal 10 and Drupal 11. This is ready for a narrowly-scoped release, 8.x-3.16, which would include only this change and https://git.drupalcode.org/project/features/-/commit/d8bb8c1baa795b93b27... compared to 8.x-3.15.

Can the maintainers provide a timeline for when this compatibility will be provided in a new release? Thanks for all the work you do!

looking forward to D11 release.

Can we at least have a dev release with this change? Thanks for all the work you do!

Sending to Needs work on a small nit.

That nitpick should be resolved in 📌 Use dependency injection instead \Drupal calls. Needs review

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

Thank you so much @davereid! I tested this merge request against an active project and it worked great. In my testing, I was upgrading from Drupal 10.4.1 to 11.1.5.

I tested by the following:

Added a custom repository to the root composer.json in the "repositories" section:

        {
            "type": "vcs",
            "url":  "https://git.drupalcode.org/issue/features-3447460.git"
        }

Changed my "require" line for Features to the branch:

        ...
        "drupal/core": "^11.1.5",
        "drupal/core-composer-scaffold": "^11.1.5",
        "drupal/core-project-message": "^11.1.5",
        "drupal/core-recommended": "^11.1.5",
        ...
        "drupal/features": "dev-3447460-drupal-11-compatibility",
        ...

Then deleted composer.lock and ran composer install.

As all my other dependencies were already upgraded on Drupal 11-compatible versions, I was then able to install Drupal 11 normally. Note that my site had several Feature modules that needed to be manually changed in their .info.yml files to core_version_requirement: '^9.3 || ^10 || ^11'.

Drupal 11 installed successfully, using the new Features version.

Once up and running I tested:

• Viewing the list of all features.
• Selecting a custom feature bundle for my installation profile.
• Comparing features against active config.
• Importing feature config into active.
• Exporting/writing current config into feature modules via the bulk feature export.
• Exporting/writing current config into a single feature via the feature configuration form
• When exporting/writing a feature module, the .info.yml file was correctly changed to core_version_requirement: '^10 || ^11', including 11 and dropping 9.3.

I still see some existing issues that pre-existed like #2912545: Permissions stripped from roles, but dependencies added anyway → , but I found no regressions and most importantly, this unblocks our project's upgrade to Drupal 11.

Code changes all look great to me too. This looks ready to go!

+1 RTBC https://www.drupal.org/project/features/issues/3447460#comment-16051589 📌 Drupal 11 compatibility for Features module Active #19
Let's release major alpha|beta version of the module, please

Let's release major alpha|beta version of the module, please

Agreed that a release is well justified, though I'll note that it should probably simply reflect a minor version release from 8.x-3.14 to 8.x-3.15 . Per https://www.drupal.org/project/drupal/issues/3357742 🌱 Guidelines for semantic versioning and Drupal core support Active , this can be provided via a minor release since it does not drop support for currently supported versions of Drupal core.

Hi maintainers, thanks for all you do to make this valuable module available for the community! When can we expect a Drupal 11 release?

This is a static patch of the MR to be applied.

HI Maintainers, when we can expect Drupal 11 Release?

Reviewing the commentary on the merge request, it appears that the only question holding this up is whether and how this module should leverage the new parameter, $previous_config_names, available in ConfigInstaller::findPreExistingConfiguration, per https://git.drupalcode.org/project/features/-/merge_requests/39#note_494953

This new parameter was introduced in Drupal core (11.2.x) as part of 📌 Add the ability to install multiple modules and only do a single container rebuild to ModuleInstaller Active . Per that issue summary, the role of this parameter is a way of identifying when a container rebuild can be bypassed during the installation of a new module:

A $previously_checked_config argument is added to the protected methods \Drupal\Core\Config\ConfigInstaller::findPreExistingConfiguration() and \Drupal\Core\Config\ConfigInstaller::findDefaultConfigWithUnmetDependencies(). This argument is a list of previously checked configuration, keyed by collection name.

As this relates to the role of the Features module, as a tool for executing configuration imports on behalf of bundled configuration, I don't see this module as having a role in determining whether certain configuration changes can skip the container rebuild. That would be relevant only in the context of a finite, curated set of configuration in, say, a module, where the developer knows that a container rebuild is not necessary.

Furthermore, this has been implemented in Drupal core's business logic as an addition to a conditional that checks for $active_storage->exists($config_name), so in the context of Features imports, the core code already checks what it needs to check: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

Therefore, I conclude that the Features implementation of should simply pass along the second parameter as is already staged in the merge request, array $previous_config_names = [].

Thus this issue remains, in my opinion, RTBC. A timely merge and release for Drupal 11 compatibility is important to the community!

Hello Team,
I would need to update my drupal site to D10 to D11, when we will plan this D11 supported version?
Is there any tentative date?
when we can expect Drupal 11 Supported Release?