Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add 'recipe' project type to Backdrop #3763

Open
BWPanda opened this issue May 11, 2019 · 25 comments

Comments

@BWPanda
Copy link
Member

@BWPanda BWPanda commented May 11, 2019

This is a spin-off of backdrop-ops/backdropcms.org#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:

  • Making it possible to port certain (cough, WordPress) themes to Backdrop - ones that include styling, a custom layout, and features like sliders, etc. (e.g. a theme, a layout and one or more modules).
  • Providing a full demo site to go along with a tutorial (users install the recipe and get all the modules, content types, themes, etc. setup automatically).
  • Setting up a new site with things installed and configured the way you (as a developer) normally like them (e.g. simplifying the initial setup of multiple, similar sites).

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.).

@laryn

This comment has been minimized.

Copy link
Contributor

@laryn laryn commented May 11, 2019

Love it!

@herbdool

This comment has been minimized.

Copy link

@herbdool herbdool commented May 11, 2019

Would be good to have a proof of concept. I think it could be mocked up with a custom module, which includes the dependencies and runs some hooks to set up a baseline config. Would need to figure out how to include the theme and layout as dependencies.

@herbdool

This comment has been minimized.

Copy link

@herbdool herbdool commented May 11, 2019

Would need to test out what happens if the recipe is disabled or uninstalled, or the are updates to the recipe from upstream, how to deal with divergent changes...

@Graham-72

This comment has been minimized.

Copy link

@Graham-72 Graham-72 commented May 12, 2019

👍

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented May 13, 2019

Another thing to decide is where these recipes will live in the file system ...if they are actual files that is.

The reason why I say this, is because the idea behind these "recipes" was that one could include these as plain-text on say a blog post. Then the "consumer" would copy this text, and paste it into our Project Installer (via the "manual installation" dialog - or some similar UI):

Screen Shot 2019-05-13 at 2 05 08 pm

^^ that's a mockup 😄

So basically, when I thought of this initially, I have not factored in any new project type, .info files, or versioning. Not implying that that would not be the way to go; just saying.

@BWPanda

This comment has been minimized.

Copy link
Member Author

@BWPanda BWPanda commented May 13, 2019

Hmm, yes, I think that's a good idea. We want to make it as easy as possible for people to create and use recipes, so not having to write info/json files and 'install' them would be handy. That'll also solve @herbdool's problem of disabling/uninstalling recipes and I think would make for a simpler setup all-round.

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented May 13, 2019

I am adding the "needs feedback" label. If people agree that this should not be another project type after all, then we can rename this issue accordingly.

@laryn

This comment has been minimized.

Copy link
Contributor

@laryn laryn commented May 14, 2019

It sounds like a recipe could simply be an install script for a bunch of things, without those things being tracked via the recipe going forward. (ie. you use the recipe to make a cake, but the cake doesn't change next week if you later adjust the recipe).

That makes sense to me.

Would it also be possible to load example configuration and content via a recipe, or would that have to be done through a module that the recipe installed? (e.g. getting a shell of a site built out quickly with some sample content, blocks in place on certain layouts, etc.)

@BWPanda

This comment has been minimized.

Copy link
Member Author

@BWPanda BWPanda commented May 15, 2019

@laryn I think install profiles are still the best place for that.

@BWPanda

This comment has been minimized.

Copy link
Member Author

@BWPanda BWPanda commented May 15, 2019

I think I'm starting to get confused... I'm now wondering how recipes will be any different than the 'INSTALL PROJECTS BY NAME' field in @klonos's screenshot above...? If you can enter the names of modules, layouts and themes there and have them all installed for you (with dependencies, etc.) then isn't that what a recipe would have been essentially anyway? And if that field's only for modules, then perhaps a simple feature request to expand that to layouts and themes as well would suffice.

Unless I'm missing something and there's more to the idea of recipes than that...?

@jenlampton

This comment has been minimized.

Copy link
Member

@jenlampton jenlampton commented May 17, 2019

If you can enter the names of modules, layouts and themes there and have them all installed for you (with dependencies, etc.) then isn't that what a recipe would have been essentially anyway?

Maybe it becomes an info or json file, and the "instructions" just become to copy/paste it into that box?

@docwilmot

This comment has been minimized.

Copy link
Contributor

@docwilmot docwilmot commented May 30, 2019

I wasnt thinking that recipes would be entirely different from profiles, but the distinguisher would be that you could install them at any time, using the Installer UI. For example, you want a new church site, with menu and pages and so on; you select a church Recipe in Installer, and it walks you through the "recipe" for building one: you choose a theme, you choose some options, you decide on dummy content, etc, then click install and voila! a new church site. It eventually could probably have an advanced option to backup your dbase first so you can revert.

But something like that.

@findlabnet

This comment has been minimized.

Copy link

@findlabnet findlabnet commented May 30, 2019

@docwilmot great scenario. Not church only, but restaurant, gallery or real estate agency - here we go to real users.

@jlfranklin

This comment has been minimized.

Copy link
Member

@jlfranklin jlfranklin commented May 30, 2019

How is this different from the Features module? What you're describing is close to its original purpose.

In the case of Features, someone would put together a Features module that included all the required modules as dependencies, the content types, and all the config to deploy a particular kind of site. Features went beyond that to allow a site to enable certain features -- enable the calendar or not, enable the blog or not, enable reservations (like for a restaurant), enable catering?

Features + the Installer module would allow someone to upload just the feature module and then download any additional modules they may need, enable all of it, and have a "pre-built" site.

@docwilmot

This comment has been minimized.

Copy link
Contributor

@docwilmot docwilmot commented May 30, 2019

How is this different from the Features module? What you're describing is close to its original purpose.

this is a reasonable point. Port Features instead?

@herbdool

This comment has been minimized.

Copy link

@herbdool herbdool commented May 30, 2019

Sure, port Features... if you want to enter a world of pain. 😋 I imagine D7 version can't easily be converted to use config instead of the db as a source. Though maybe I'm wrong.

@jlfranklin

This comment has been minimized.

Copy link
Member

@jlfranklin jlfranklin commented May 30, 2019

Sure, port Features... if you want to enter a world of pain. 😋

Same question still applies: How is this different from Features? Specifically, how does it avoid the pain points that Features suffers?

Part of the problem with Features is people tried to use it for configuration management, not feature definitions. Re-applying a feature was never really part of its design, nor was removing something, like a field in a content type. Reapplying sometimes worked, and sometimes it didn't (often with hilarious results.) You could remove something from the feature module, but all Features would do is orphan it on the site.

Features itself had no concept of a migration path. A fantastic dev team could write migrations via hook_update_N(), but the amount of testing it required for an automation that would run exactly once... it was nearly always faster to just write down the migration steps in the ticket.

@jenlampton

This comment has been minimized.

Copy link
Member

@jenlampton jenlampton commented May 30, 2019

How is this different from Features?

The only real difference is that we'd be saving config, which Backdrop knows how to handle, not some crazy one-of thing that Drupal didn't really understand.

how does it avoid the pain points that Features suffers?

Features was painful because Drupal didn't really understand how to store things that are configuration anywhere other than in the database. This would avoid that because It's Backdrop, and not storing anything that's config in the database.

Part of the problem with Features is people tried to use it for configuration management,

This won't be a use-case for Backdrop. We'd only be using features for it's intended purpose: Packaging config together.

Sure, port Features... if you want to enter a world of pain

I was envisioning we'd build something completely new, and name it "Features". But a port miiiiight be possible?

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Oct 10, 2019

I'm interested in this issue. I've started playing with a simple repo of config recipes: https://github.com/TeamTriplo/backdropcms-features
https://github.com/backdrop-contrib/config_recipes

So far, I have two recipes/features. This is not an ideal system, because it requires that I load each config file separately and in the right order. It's not bad, but there must be another way.

Should I make my config recipes a contrib project? I am not sure if that his the right place for them?

EDIT: After a discussion during a dev meeting, I went ahead and created a github project for this experiment.

@klonos

This comment has been minimized.

Copy link
Member

@klonos klonos commented Oct 10, 2019

That's an interesting subject for the dev meeting @stpaultim. On the one hand, I don't like the idea of "polluting" contrib with recipes, but on the other, d.org did allow for distributions, which is the equivalent of (or similar to) what we are talking about here.

I am interested in this as well.

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Oct 18, 2019

We talked about this on todays DEV call. As things currently stand, a user can ONLY input all config at once or one file at a time. It would be helpful if a user could enter a batch of config files that make up a recipe.

It is possible to export the current config directory, add a batch/recipe to the entire directory, and then import the entire batch.

Would it be possible (relatively easily possible) to add an option that automates this. An UI that allows the user to add a directory of config files and then have Backdrop combine the current files with the new batch?

(OK, now that I write it out, this is probably no easier than simply coming up with a way to add a batch of config on their own. I guess, the combining with active config files is only necessary because of the lack of the alternative UI).

@jenlampton

This comment has been minimized.

Copy link
Member

@jenlampton jenlampton commented Oct 18, 2019

Would it be possible (relatively easily possible) to add an option that automates this. A UI that allows the user to add a directory of config files and then have Backdrop combine the current files with the new batch?

Yes. This is exactly what I want in core :)

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Oct 18, 2019

I documented my current process in the forum, which is cumbersome.
https://forum.backdropcms.org/forum/how-add-bundle-or-group-config-files-site

I hope we can make progress on this issue.

Here is a related issue:
#3933 (CLOSED) in favor of #661

AND - I created a github contrib project for a very simple library of config recipes:
https://github.com/backdrop-contrib/config-recipes

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Nov 1, 2019

@stpaultim

This comment has been minimized.

Copy link
Member

@stpaultim stpaultim commented Nov 3, 2019

I created a video: https://youtu.be/VgFibVrEZEw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.