The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
The business_rules_action (defined in \Drupal\business_rules\Entity\Action), business_rules_condition (defined in \Drupal\business_rules\Entity\Condition), and business_rules_variable (defined in \Drupal\business_rules\Entity\Variable) entity types are config entity, with corresponding @ConfigEntityType annotations.
As of 8.6.0, ConfigEntityType annotations need to define a config_export key so that they can be exported properly. See the annotation for core's \Drupal\block\Entity\Block for an illustrative example.
This will need to be fixed to be compatible with D9, and to avoid notices like the following:
Entity type "business_rules_variable" is using config schema as a fallback for a missing `config_export` definition is deprecated in Drupal 8.7.0 and will be removed before Drupal 9.0.0. See https://www.drupal.org/node/2949023.
Proposed resolution
Add config_export keys for Actions, Conditions, and Variables.
Remaining tasks
- Determine what needs to be added to the
config_exportkey in the @ConfigEntityType annotation for Actions, update issue summary - Determine what needs to be added to the
config_exportkey in the @ConfigEntityType annotation for Conditions, update issue summary - Determine what needs to be added to the
config_exportkey in the @ConfigEntityType annotation for Variables, update issue summary Write a patch- Review and feedback
- RTBC and feedback
- Commit
User interface changes
None.
API changes
Compatibility with Drupal 9.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3172492-3--business_rules_config_export.patch | 4.06 KB | mparker17 |
Comments
Comment #2
billdaff commentedHello, I had to create a patch to address this for my own Drupal site. This is my first post/contribution so I am not sure if I generated the patch correctly. Sorry if it is not, but it works for me using patch files in composer and maybe it will help someone else.
Comment #3
mparker17Hi @billdaff! Welcome to the Drupal community, and thank you for contributing!
(as an aside, I noticed that your drupal.org user account had not yet been confirmed as "not a spammer" so I've done that for you... you can read more about what that means here)
Your patch is excellent, although it was missing some metadata that makes it easy for Git to figure out how to apply it (Git prefers patches in unified format). So I've re-uploaded your patch some more of that metadata and I've uploaded it to this message (Git extends the unified format even further with info about which commit you started from, making merge conflicts less likely). If you're interested in the method I used, I've thoroughly-documented it in a blog post. I've made sure to credit you in the patch.
I also renamed the patch slightly to include Drupal.org's issue ID (3172492) and comment number that I intend to upload to (#3), in order to make it a bit easier for the maintainers (who are likely to end up with a whole bunch of patches in their Downloads folder).
Also, a pro tip, once you've uploaded a patch, change the issue status to "Needs Review" to indicate to maintainers and other people using the module that you'd like them to review your patch! That also tells Testbot to run automated tests on your patch to ensure there aren't any regressions.
I'm currently in the middle of other client work right now but I'll try to manually test your patch soon, and if everything works, move it to RTBC ("Reviewed and Tested By the Community").
Thank you and welcome! :D
Comment #4
mparker17(EDIT - in this comment, I tried to change the issue's credits but was unsuccessful)
Note testbot's report of a "composer require-dev failure" is an issue with the business_rules-8.x-1.x branch, not your patch!: https://www.drupal.org/node/2863145/qa
Comment #5
nwom commented#3 works perfectly. Thank you!
Comment #6
colanComment #8
colan