Convert rules to store as JSON config files

[kelizoliva]

This relates to issue #25 where @Graham-72 worked out getting the rules to export/import via a file. The next step that would be great to see using that work to inform rule writing to JSON config files, rather than too the database. This would make the rules portable and deployable like much of Backdrop configuration.

[laryn]

Sounds like a good plan.

[herbdool]

Most of the meat of the configuration functionality is here: https://github.com/backdrop-contrib/rules/blob/1.x-2.x/includes/rules.core.inc.

[nattywebdev]

Is there any progress on this enhancement? I am now finding it a problem to be unable to transfer Rules updates from dev to live sites compared to most other config changes, so would love to see it added.

[argiepiano]

I am now finding it a problem to be unable to transfer Rules updates from dev to live sites

Can you elaborate? You should be able to still transfer rules easily with the current features. While Rules are not saved as json (they are in the database), they can be transferred with current functionality, either as part of the database (when you transfer the db), or through the available import/export functionality.

[nattywebdev]

I can copy the rules* tables from dev to staging database but it makes me feel nervous.
How can I do it through the import/export functionality? Am I missing something useful there?!

[bugfolder]

or through the available import/export functionality.

Yes, I've been doing exactly that with a current site. Write/test/debug the rule on my local dev, export it as JSON, then import on live site.

@argiepiano, shall we do a new release with the two approved PRs that address file import? (And might you have a chance to look at the other "maintainer review requested" PRs?)

[bugfolder]

How can I do it through the import/export functionality? Am I missing something useful there?!

@nattywebdev, on the Rules config page at admin/config/workflow/rules, use the EXPORT option in the dropbutton to create the JSON for export. Copy the entire block.

Then back on admin/config/workflow/rules on your production site, click the "+ Import - paste" link near the top, paste in your copied code, and click "Import".

The only drawback is you have to do that rule-by-rule, which can take a little while if you have a lot of rules.

In my system, I have a lot of similar rules, so it's actually a bit faster to copy the first one to a text file, make copies of that text file, then edit them to make the unique, but similar, rules, then copy and paste from those.

[nattywebdev]

Thanks @bugfolder - yes, of course, I did know that (but forgot about it). That will help but is a bit of a faff when I am changing half a dozen Rules.

[argiepiano]

@argiepiano, shall we do a new release with the two approved PRs that address file import? (And might you have a chance to look at the other "maintainer review requested" PRs?)

I'll try to get this later today. A new release sounds like a good idea.

I can copy the rules* tables from dev to staging database but it makes me feel nervous.

While unusual, that should work too (you'd need to be sure to clear caches after you import), unless your site has a lot of traffic and you may miss some of the triggers while you truncate the rules table.

Converting to fullfledged json config files may take a while. It's no trivial task, and I don't have that kind of time this summer.

[herbdool]

And converting to Config objects should be enabled for all entities stored this way, such as for Search API. Then they can all benefit. Maybe a new storage type for entities that's basically the Config class.

[argiepiano]

And converting to Config objects should be enabled for all entities stored this way, such as for Search API. Then they can all benefit. Maybe a new storage type for entities that's basically the Config class.

Both Search API and Rules use "configuration entities" (aka exportable entities) provided by Entity Plus. I did some work (a contrib module) that provided a new configuration entity controller that adapted the original controller so that it saved to config files. I'm currently using that module quite a bit (https://github.com/backdrop-contrib/entity_plus_cmi). I think this is the way to go - the change would need to happen at the Entity Plus level.

[argiepiano]

Perhaps a good first step might be to create a submodule of rules that alters the entity info for rules configurations (changing the controller class and entity class). It would extend the classes provided by entity plus CMI. This would probably be a smooth transition. I'll give this a try.

[herbdool]

That's a great idea @argiepiano. I forgot about your entity CMI module.

[argiepiano]

I have started working on this (as a contrib module). Made some progress, but I had to leave it aside for a couple days. I'll come back to this.

[argiepiano]

I have published a contrib module that stores rules as config files. Please do test. It'd be helpful to get feedback and contributions!
https://github.com/backdrop-contrib/rules_cmi

[argiepiano]

Please notice that it requires release 2.0.1 of Entity Plus CMI
https://github.com/backdrop-contrib/entity_plus_cmi/releases/tag/1.x-2.0.1-beta

[nattywebdev]

I've done some testing between a local dev and remote staging server and all seems to work just fine.

Only issue I can see is repeats of php notices of this type in my log file:

Notice: Undefined property: EntityPlusCmiEntity::$feed_node in RulesEntityCmiController->attachLoad() (line 43 of /<myroot>/public_html/modules/rules_cmi/includes/RulesEntityCmiController.inc).
Notice: Undefined property: EntityPlusCmiEntity::$feeds_item_guid in RulesEntityCmiController->attachLoad() (line 43 of /<myroot>/modules/rules_cmi/includes/RulesEntityCmiController.inc).
Notice: Undefined property: EntityPlusCmiEntity::$feeds_item_url in RulesEntityCmiController->attachLoad() (line 43 of /<myroot>/public_html/modules/rules_cmi/includes/RulesEntityCmiController.inc).

Is this peculiar to me or do they mean something to you @argiepiano ?

[argiepiano]

Thanks @nattywebdev. That's produced by properties added by Feeds. I will need to be sure to account for those. The notice is annoying but harmlesss.