This project is read-only.

Upload recipe on setup screen - good or bad?

Topics: Core
Dec 5, 2013 at 2:56 PM
Here's the feature request about having a way to upload arbitrary recipes on the setup screen I've created an initial implementation in this fork: as demoed on the last Community Meeting:

We agreed to discuss the matter separately, so here it is.

I think this would be a useful feature: currently the only way to use custom setup recipes is to add them to the core Setup module, what is modding. The ability to upload recipes would enable the usage of any custom setup recipe.

The UI in the fork is not something I'm proud about but Piotr had an idea about improving it that I liked: adding an option "Upload recipe" to the recipe dropdown. When selecting that you'd be able to upload a custom recipe.

Critiques were mentioned about the security implications: notably that there are possibilities to do more from recipes than from the admin UI, even things that in a multi-tenant scenario wouldn't be possible for tenants like disabling core modules (yes, you can indeed disable core modules, or at least modules with the category Core like jQuery with commands from recipes). This is indeed an issue however I think that if users can do something that they shouldn't be allowed to it's a problem to solve regardless of the interface - in this case, commands. Specifically you shouldn't be able to disable core modules from commands either (I'm not speaking about low-level services but about a kind of user interface).

BTW commands are constrained to tenants in recipes, so anything you can do from recipes is still constrained to the tenant.
Dec 5, 2013 at 4:51 PM
Another way is to use the core recipe in the setup and run a module recipe from the admin dashboard. I think it has the same issues as uploading a recipe regarding security, if recipes from modules are not restricted somehow.

A shortcut to run the recipes in a pipeline, like listing module recipes if core recipe is selected in the setup and running the selected after the core would be nice.

I used this when developing on SQL CE and running the setup over and over, and during development module recipe was nice enough. I can't think of any other use actually, when one wants to upload any recipe during setup, or recipes in circulation. It would be a different story if automatic module/theme download from the gallery works when activated by a dependency. Even then, I think instead of an upload, dowloading a recipe from the gallery during setup would suit better.

Dec 5, 2013 at 9:35 PM
I agree with this proposal, running recipes directly from set up would be really cool. I think they shouldn't be run in a pipeline because I don't think you would always want to run the default recipes beforehand. For instance, we use the old Media and Taxonomies modules, and these are both enabled by the Default recipe. I guess you could always run Core, cant remember exactly what that enables but I dunno, just running recipes directly seems the way to go.

I think we would then need a tool for exporting enabled features so sites could easily be replicated. I have one on my codeplex I believe... not that that needs to be in core or anything :)
Dec 5, 2013 at 11:19 PM
Yes, executing the Core recipe, then running a recipe from the admin can be in effect the same, however it's a two-step process; selecting an arbitrary recipe at setup is more straightforward.

This would very much aid team work (and thus be mostly, but not exclusively a developer feature as Sebastien pointed out): there can be recipes for the team as a base but then everybody can create their own recipes, depending on their needs or local environment.
Dec 6, 2013 at 1:41 AM
Regarding team work, from development perspective, I would prefer having the recipe in the source control, and being able to select it on a list in the setup screen instead of uploading, which is a boring thing with file dialog if you repeat often. Everybody can still create their own recipes, and commit them in a module, maybe only there for hosting recipes, and share with the teammates. I wouldn't mind at that point to have a file upload button there, in case someone wants to upload one not available in the list. In this case a browser addon that would fill the form and post the file as well would be great time saver, does anyone know one?

This is why I suggest allowing the recipe from modules to be selected and executed *only if* the core recipe is selected first. Core recipe would ensure mandatory core features are enabled, and module recipe does what it does.

If it's not too much control, the gallery would serve recipe modules, only if they don't disable core features. This eliminates some risk. I think development team should live with the risk anyway. Living on the edge, one can always change the built-in recipes, or the setup screen anyway. This is what I do actually to change the setup screen to select the core recipe by default, in order not to forget it and run the default recipe instead.

Dec 6, 2013 at 1:50 PM
I'm thinking about recipes that do not necessarily need to be in source control: one-time-use or personal recipes are such.

Now that I think about it we could also enable adding setup recipes without modifying the module: by adding a new element to the <Recipe> tag like <IsSetupRecipe /> or even more simply adding the tag "setup" to the recipe's tag would allow the recipe to be selectable on the setup screen. Recipes (defined in standard recipe files) can be collected from extensions regardless of them being enabled: by slightly modifying SetupService and either adding this new element (and property on the Recipe class) or just introducing the tag convention we can have an extensibility point for setup.

Does this sound like an idea that's more easily loveable?
Dec 6, 2013 at 1:53 PM
Defo sounds good
Dec 8, 2013 at 12:06 PM
I like that much better: the Setup screen harvesting recipes from modules' Recipes folder. That way we don't have to add our recipes to Orchard.Setup or upload the recipe each time manually. Great for development purposes. I don't know if anyone sees a security risk with this, but if there is one, it might make sense to only harvest those recipes when the request comes from the local machine?