Co-Authored-By: Claude Opus 5.5
Problem/Motivation
Drupal core #3549134: Move text_with_summary to its own module moved the Text (formatted, long, with summary) field type, its widget and its formatters out of the Text module into a new core module, text_with_summary. See change record: #3568381: Text with summary plugin is deprecated
Core's text.schema.yml on 11.5.x and 11.x no longer defines field.field_settings.text_with_summary (it is still there on 11.4.x). The schema now ships with the new module. Commerce still assumes the field type lives in the Text module:
modules/product/config/install/field.storage.commerce_product.body.yml:type: text_with_summary,module: text, and a dependency on thetextmodule.modules/product/config/install/field.field.commerce_product.default.body.yml:field_type: text_with_summary, a dependency on thetextmodule, and thedisplay_summary/required_summarysettings.modules/product/commerce_product.info.yml: depends ondrupal:textonly.commerce_product_add_body_field()incommerce_product.module:BundleFieldDefinition::create('text_with_summary').- The kernel test base classes do not enable
text_with_summary.
Core's issue says existing sites get their field config updated to depend on the new module when updating to 11.5. The install config shipped with Commerce, and therefore fresh installs and kernel tests, is not covered by that update path.
Steps to reproduce
Run a kernel test that extends OrderKernelTestBase against Drupal core 11.5.x-dev with Commerce 3.x (seen with 3.3.14). In my case this is the GitLab CI "next minor" job of another contrib module, commerce_taxjar. setUp() fails on installConfig(['commerce_product', 'commerce_order', 'system']):
Exception when installing config for module commerce_product, message was: Schema errors for field.field.commerce_product.default.body with the following errors: field.field.commerce_product.default.body:settings.display_summary missing schema, field.field.commerce_product.default.body:settings.required_summary missing schema, field.field.commerce_product.default.body:settings.allowed_formats missing schema OrderKernelTestBase.php:42
All kernel tests built on OrderKernelTestBase are affected, so every Commerce add-on module that tests against 11.5.x-dev will see the same failure. I have not confirmed whether Commerce's own test pipeline shows it.
Proposed resolution
Commerce 3.x still supports core versions that do not have the text_with_summary module, so a plain drupal:text_with_summary dependency in commerce_product.info.yml cannot work.
A few options to discuss:
- Conditional field type for body field: use text_with_summary module is enabled, otherwise text_long/text_textarea
- Drop text_with_summary from installation config and base fields. Add BC where applicable.
- Convert Commerce's text_with_summary fields to text_long/text_textarea by renaming and replacing, similar to what Umami has done. (Maybe this is more appropriate as an opt-in, or wait until D12 is further along?)
Remaining tasks
Confirm the failure in Commerce's own pipeline on 11.5.x-dev.- Agree an approach for fresh installs and for the update path on existing sites.
- Review and revise the winning MR, including adding a deprecation signal to the status page.
- Change record including upgrade path
Issue fork commerce-3637360
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #6
aaronbaumanMR 786 3637360-conditional-field-type-on-install: Implements a conditional field type for body field - text_with_summary if the module is installed, otherwise text_long/text_textarea.
This is included as an option for completeness, as I don't think it's a great idea to keep installing a deprecated field type.
My opinion, we should use this approach:
MR 787 3637360-drop-text_with_summary: Drops text_with_summary from installation config, while maintaining backwards compatibility for old installs that still have it.
The failing tests on both MRs are unrelated to these changes.
I did not implement any solution for approach 3, rename and replace, but let me know if that's the preferred solution.