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!