[UX] - Better "Available updates" option for recipes

[stpaultim]

Description of the need

As I experiment more and more with recipes, I'm running into little problems with how modules and projects work on BackdropCMS.org and in the project browser.

The most recent problem is a complaint from someone that their website shows that an update is available for a recipe. In fact, recipes are not updatable, which is very confusing for people using recipes.

• Updating Recipes backdrop-contrib/zeever#28

Proposed solution

We should either have a way to indicate that a project is not updatable, so that the project browser DOES NOT check for updates on that project.

OR

We should put some kind of message or notification on the updates page that indicates that while there might be a more recently updated version of a recipe available, updating the recipe will have no effect on your site.

Alternatives that have been considered

It's entirely possible, that we currently have tools in place to handle this kind of situation and I'm just not aware of them. Are there other options.

Another option, would be to implement a "recipe" project type that accomodates these kinds of concerns.

Additional information

Here is an example of a site showing two recipes with updats available. But, updating to the most recent version of these recipes is NOT recommended or even possible.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop now includes better support for recipes, specifically recognition that it is not possible to update a recipe after it has been installed. Backdrop no longer recommends updates for recipes.

[klonos]

Another option, would be to implement a "recipe" project type that accomodates these kinds of concerns.

Yes please! We should finally bite the bullet and make recipes a "first-class citizen", by making them a separate project type 😉 (#3763)

I realize that there may be a possible use case in the future where we might have the need to indicate other types of projects as non-upgradable, but at the moment this is an edge case when it comes to other project types. Recipes on the other hand are by their nature non-upgradable.

Consider this: say we implement a simplistic way to do this; something like a new upgradable = false property in the .info file. That would work, but it would mean that every single recipe out there would need to add that line. Well, that is not ideal then. Besides, if we are to add a new line in the .info file to achieve this, then why not a type = recipe line?

[argiepiano]

I don't understand why recipes are not/should not be updatable.

[klonos]

@argiepiano recipes are meant to be "run once". They act (or should act) like scripts, in the sense that they perform certain actions, and then they serve no other purpose after that. Recipes aren't meant to be upgraded in the same way that they cannot be "uninstalled" (not in the sense that modules can be uninstalled at least).

[laryn]

Some of what we're calling recipes include tpl.php files and .css files (I think) which would potentially have an effect when updated. I understand that the config changes don't automatically get applied if they've already been imported from earlier defaults.

[argiepiano]

recipes are meant to be "run once".

Yes, I get that, but that initial run happens in two ways currently:

• Through the hook_install(), which only runs once regardless of updates
• By moving config files from the module's config folder to files/config_XXX/active, which ALSO happens once, when you enable the module

So, updates should offer no potential harm to the site, since those scripts and config files will not be run or installed again. And updates offer the possibility of doing things to the installation through hook_update_N().

Am I missing something?

[klonos]

Am I missing something?

Recipes should not be behaving like modules/themes. So they should not be listed as "enabled" nor shown in the "Available updates" page. There should be no "enable" or "install" actions (it should be "run" or "execute" or something like that instead), no update hooks, no "disable" or "uninstall" actions either. If the project is doing any of these actions, then it's a module.

[argiepiano]

Recipes should not be behaving like modules/themes.

OK, perhaps you are talking about a Recipe API that doesn't yet exist. In fact, current recipes like Digital Agency are modules, and they do behave like modules. This original post proposed to create a way to make these recipe modules "un-updatable". My point is that this is not needed, since the current approach to recipes is to use hook_install and config files. Unless I'm missing something, updating a recipe module will not harm any existing installations of the recipe, plus it has the advantage to make hook_update_N() available to these recipes. If you somehow make these modules un-updatable, then you lose the ability to use hook_update_N in your recipe module updates to do helpful and/or needed things to the installation.

[stpaultim]

Unless I'm missing something, updating a recipe module will not harm any existing installations of the recipe, plus it has the advantage to make hook_update_N() available to these recipes.

The reason I opened this issue was that someone opened an issue in the Zeever issue queue reporting that their site indicated that an update was avaialble. They were nervous, for reasonable reasons, because given the nature of recipes - it's not clear what would happen when a recipe is updated.

They choose to run the update, but then didn't notice anything different and wondered if something went wrong or if that was expected?

This is the problem I would like to solve. MOST of the time, when I issue a new release for a recipe, it is because I've changed the config files. I don't know of any safe way for someone to update their site with this kind of config, yet I also don't know of any way, other than in the release notes, to let people know that they should not try to update their site.

I suppose, that I could make every update a MAJOR release, indicated breaking changes. That might be the way I need to go.

I was hoping that there might be a existing option to issue a release that does not trigger the "upgrade available" notification on sites. If not, then I am likely to advocate for a new type of project (recipe or something else) that is not updatable.

If the maintainer wishes to include features that can be updated, they would release their project as a module. If they are only including features that can't be upgraded, they can use this new project type.

The goal here is to reduce confusion for people using these recipes projects.

---

I've started to break my recipes into two sub-categories.

1. Recipes that can and should only be run once and have no css or code that is updateable.
2. Recipe Packages that have more than config and that should not be disabled and in theory could be updatable.

I'm not happy with the term Recipe Packages, but have yet to come up with anything better.

[olafgrabienski]

Another approach could be to make important update information more visible, e.g. provide an option for Backdrop to show selected update info directly in the Backdrop interface (not only in linked release notes). Good for recipes that don't need to be updated, but also helpful for modules and themes (think of CSS changes).

[argiepiano]

it is because I've changed the config files. I don't know of any safe way for someone to update their site with this kind of config, yet I also don't know of any way, other than in the release notes, to let people know that they should not try to update their site.

@stpaultim I still think there is a misunderstanding here. Updating any config files in your recipe module config folder will not make any changes to existing site's config files. Once a config file was installed when the module was first enabled (i.e. moved from the module's config folder to the site files/config_XXX/active folder), the config file will will not be moved there again, unless you manually do that in a hook_update_N hook.

So, none of the hook_install code will be run again, nor any of the config files will be installed again - you are safe, there is no need for what you are proposing (unless I'm missing something else). Is there any other case you had in mind?

[avpaderno]

I guess that what proposed here is avoiding to show there are updates for a recipe when those updates do not do anything.
IMO, that is only possible if recipes are not handled by Backdrop as normal modules. For example, installation profiles can do everything a module can do, but Backdrop would not report there are updates for installation profiles.

[stpaultim]

I still think there is a misunderstanding here.

@argiepiano - This may be true.

There is no misunderstanding about the actual danger of "updating" a recipe. I understand that this is not really a risk and that is not the problem I'm trying to solve.

The problem I'm trying to solve is this.

1. I change the default config files in a recipe and issue a new release targeted at future users of the recipe.
2. People who have used this recipe and left it enabled (which is not required), are given a notice that Backdrop CMS recommends that they update the recipe. This causes confusion, because:

a) They might have heard enough about recipes to understand that in theory they don't need to be updated, but then why is Backdrop recommending an upgrade.
b) They know that the recipe added content and made config changes, but are not confident that updating the recipe won't effect those changes - again, if they understand that recipes are different from modules.
c) They might assume that because Backdrop is recommending this upgrade that they should run the upgrade and expect that they are actually getting an upgrade, when they are not.

ALL of this confusion, when we know up front that running the upgrade will do nothing.

(I opened this issue after someone reported this kind of confusion to me, in exactly this kind of situation.)

The problem I am trying to solve is "How do we avoid the confusion that might be generated when Backdrop CMS is recommending an upgrade that will have no effect on the site?"

At a very minimum, I would like a way to release a new version of a recipe that DOES NOT recommend to users that they update the recipe.

Barring such a solution, I think I'll just have to use release notes (which are unlikely to be read in most cases) to explain that the update will do nothing and can be ignored, despite the recommendation by Backdrop CMS.

I guess that what proposed here is avoiding to show there are updates for a recipe when those updates do not do anything. IMO, that is only possible if recipes are not handled by Backdrop as normal modules. For example, installation profiles can do everything a module can do, but Backdrop would not report there are updates for installation profiles.

@avpaderno - Yes, If I can't update a recipe with a "No update necessary" option. Then, another logical solution would be to finally bite the bullet and create a new project type called "recipes" or something similar and make it clear, that recipes can not be updated. By definition, anything that can be updated remains a module.

See: #3763 - Add 'recipe' project type to Backdrop

@olafgrabienski - Yes, the ability to show more info about the update could also be helpful. For example, if there were a message in the Backdrop UI saying that there is no benefit from updating the recipe (or module), this might reduce confusion.

[stpaultim]

Discussed during dev meeting yesterday.
Here is a link to the specific timestamp for that conversation: https://www.youtube.com/live/O17yLvRozoM?si=sD9BNdBnMKCcTsma&t=1856

@quicksketch pointed out that if a project does not have anything in the .info file for "project", the site will not look for updates. He suggested that if that line were left out of the .info file, the module would still be available on backdropcms.org, but that backdrop would not look for updates.

I need to confirm that, it's seems odd to me.

He also suggested, that if we have a recipes module - the recipes module MIGHT alter the .info file after it has been installed to prevent backdrop from looking for updates.

He also points out, that there are security concerns should a situation arise and a security issue be found, that could be updated, but that there was no way to notify people using the module/recipe.

I think we should talk about this more at the next Backdrop LIVE in the regularly schedules discussion about recipes.