backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 39 forks source link

Add 'recipe' project type to Backdrop #3763

Open ghost opened 5 years ago

ghost commented 5 years ago

This is a spin-off of https://github.com/backdrop-ops/backdropcms.org/issues/46 specifically for proposing a new project type for Backdrop: recipes.

With Backdrop supporting modules for functionality, themes for styling, layouts for, well, layout and install profiles for the initial configuration and setup of a site, I see the addition of a 'recipe' as combining all these separate things into a bundled package of sorts.

Use cases include:

The reason I like the term 'recipe' (which @klonos originally suggested in the issue linked above) is that 'package' (my original suggestion) implies something that you open to find other things inside, whereas 'recipe' is a bunch of ingredients which, when combined, create something new. I think recipes could be as simple as a single info file, such as:

name = My demo
description = Sets up a Backdrop site for demoing.
backdrop = 1.x # Not sure if this line is necessary...
type = recipe

modules[] = devel
modules[] = webform
modules[] = flexible_layout

themes[] = summer_fun

layouts[] = flexible_template

profiles[] = demo_profile

Or maybe even a JSON file and use it in config somehow... Either way, a simple text file should suffice. And as per info files you should be able to optionally specify versions too.

So modules provide the features/functionality, themes the styling, layouts the layout and profiles the setup (install modules, set theme as default, add blocks to a layout, add custom content types, etc.). Of course all of these would be optional (you could have a recipe of just modules, or a theme and matching layout, etc.).


Wiki Page Summary Related META Issue: https://github.com/backdrop/backdrop-issues/issues/5240

ericfoy commented 9 months ago

I'll throw my opinion in... From a position of empathy with the Backdrop Customer (the site builder),

A Recipe should be a separate type of installable from a module, thus it should be categorized and listed separately from modules.

This is because of the following perceptions (some of which might be incorrect, yet useful, nonetheless, for one's understanding):

  1. In general, a recipe may depend on one or more modules, but modules do not depend on recipes.
  2. A module adds persistent structural functionality to the website,whereas a recipe simply preconfigures said structure with certain features.
  3. A module adds stuff that is impossible to add through the administrative UI, whereas a recipe adds stuff that one could add himself through the UI.

I would even go so far as to say that this (or a similar) set of rules should be put in place in order to clearly delineate and define a recipe, and to guide and constrain the development of recipes.

"Install a module to extend Backdrop, Install a recipe to utilize Backdrop."

klonos commented 2 months ago

Thanks @ericfoy 🙏🏼 (and apologies for the late reply here). In #6595, I outlined the following (among other things):

... What I would like recipes to be is "code-less scripts" or natural-language (sorta) "instructions". ... I would like anyone that can read through a how-to article or watch a tutorial video to be able to convert it to machine-readable, yet plain-language (as much as possible) instructions set with very minimal effort, and no code (almost no code - writing a .json or .info file is still "code"). I want recipes to resemble as much as possible an actual food recipe, and have its simplicity:

  • start with a name for the "dish"
  • add a section of required "ingredients" (dependencies on modules/themes/templates, which the project installer can pull and install)
  • provide the actual recipe instructions (steps outlined in the .info file ideally, which will be followed/executed sequentially)
  • sprinkle some "seasoning" if required (things like CSS - possibly via modules like css_injector, which will have already been added as one of the "ingredients" in step 2)