We are very close to merging (this PR has now been merged) a pull request into the 1.20 branch of Backdrop CMS that will make it possible to create simple recipes in the form of modules with nothing but a .info file and a batch of config files. While not trivial to create, these "recipe" modules could in theory be downloaded from BackdropCMS.org, installed through the UI, and enabled just like any other module.
The simplest of these recipe modules could include a combination of fields, content types, and views, combined to deliver functionality such as a FAQ, Testimonials, or a Staff Directory. A slightly more advanced recipe might include dependencies on other modules and/or use a .install file and some PHP to customize the configuration of those modules. An even more advanced recipe might generate sample content and provide some custom css files. An advanced recipe might actually look very much like a traditional module.
Here are two simple TEST recipes for experimentation and discussion:
- While it is possible to declare modules or themes as dependencies for these recipes, it is not currently possible to alter the configuration of a specific module through a config-only recipe. This could be done through an install file and some PHP, but once you start adding PHP to a recipe, the recipe begins to look a lot like any other module.
- Is it not currently possible to "uninstall" a configuration recipe as you would a module. Fields, content types, and views will need to be deleted manually if you decide you no longer need the module/recipe.
We could create a special project type called recipe and list such recipes on BackdropCMS.org, but since the basic structure of a recipe is very similar to a module, we may need to think a bit about what exactly a recipe is and what qualifies as one.
One possible path forward:
We might simply decide that for the time being, we will do our best to make sure that Backdrop CMS supports the concept of recipes, but that it will be up to contrib and the marketplace to figure out what they are and where they fit in the Backdrop landscape.
Without any additional official action or decisions, we could encourage the development of a contrib module (based largely on existing code in core) that creates a new interface for filtering recipes found on BackdropCMS.org, managing them, and allowing them to be enabled.
The creator of the new module could decide what tag or project type needs to be defined in order to indicate that a module is a recipe. Any modules without the tag or type would simply not be recognized by Backdrop CMS as a recipe. Anyone creating a project and uploading it to BackdropCMS.org would decide for themselves if their project is a recipe, and if so, then provide the necessary tag or type in order for it to be recognized as such.
With or without a contrib module, we could officially accept config-only modules on BackdropCMS.org (I do not believe that anything prevents that right now). The concept of a recipe already exists and works in core, what remains to be done is to to decide how much (if any) control we wish to exercise over what is officially designated as a recipe, and how we wish to organize and support the concept of recipes within the Backdrop CMS ecosystem.
These are the personal thoughts of the author.