Updating Recipes

[Egmund]

Today, July 25, there was an update to the 'module' Digital Agency. I am nervous about running the update on my heavily 'hacked' version, but ran it on a test-install. Nothing seems to have changed on the test-site - even after clearing cache. Is this how it works? For actual updates the site in question need to be reinstalled fro scratch? Not very practical. 1, If updates are listed as available, they 'should do something'.

2. Updates without content should be available, since actual users would alter most of the text/content.

Otherwise I am very happy with this project. It made me dive deeper into BackdropCMS - as intended. I have learned a lot, feel more comfortable with it.

[stpaultim]

@Egmund

Thanks for raising this issue. Currently, the way that we are building recipes makes it impossible to update to update them. This is a question that I get all the time and I always point out in presentations that you will NOT be able to update a recipe once it is installed.

I was recently asked what happens if you try to update a recipe and I didn't have a good answer. Thanks for sharing your experience reporting that it did not seem to have any effect.

ALSO - you raise an excellent point about the fact that if a recipe can not be updated, we should do something in core to make that clear. Either, not show updates to recipes OR include some kind of warning/notice that updating a recipe will not have any effect.

There may be some value in letting users know that an update is available, even if they can't use it directly. I would appreciate additional feedback on this.

[stpaultim]

@Egmund I've opened an issue in the core issue queue: https://github.com/backdrop/backdrop-issues/issues/6685

[Egmund]

There is a reason an update is created. Therefore it is good for 'customers' to know about it. With 'regular' modules or themes I sometimes patch instead of updating if I have 'hacked' the module (and then update the version in the info file). Maybe patching is the way here?

[stpaultim]

@Egmund - The problem with "updating" a recipe is that recipes are about 99% configuration. For us to update anything, would require us to alter configuration and we have no way of knowing if the site owner really wants the change we are making or whether our changes actually conflict with choices the site owner has made.

In traditional modules, updates do things like fix bugs, or add new features in code. Recipes don't really provide this kind of functionality. Mostly recipes do things like add content types and custom fields. Once those content types or fields are being used, there isn't much that we can change without risk of breaking sites.

One possibility for the Digital Agency Recipe Package would be css updates. It's possible that some people would want these. But even then, there is a risk that the site owner has already implemented their own custom fix for any css problems that we've tried to update and our update, might break or conflict with things that the site owner has done to mitigate the problem.

The general consensus is that given how recipes currently work, it would be dangerous to update them.

I welcome additional thoughts and ideas about when and how recipes might be updated. But for now, the assumption is that once you install a recipe, your locked into that version of the recipe unless you manually make changes in the future.

I think that once a recipes is relatively stable, it might make sense to release detailed notes in new releases about what has been updated or changes, in case site owners want to make those changes themselves.

[stpaultim]

@Egmund A few more notes, as I think about this.

Most of the changes (or updates) that I am making to recipes are things like adding a new field or changing the default configuration for a field or view, because I have reason to believe that the changes are a better starting point for folks trying the recipe for the first time.

But, once a person has implemented a recipe adding a field or changing the configuration for them could be dangerous and conflict with changes they have made on their own.

Does this make sense?

[Egmund]

I agree with your thoughts on this. I will look at the changes since I installed and maybe do some patching. But this issue makes me say once more, that recipes should not be modules, but something else - it is confusing.

[stpaultim]

@Egmund - Good points.

Please, take a moment and post a comment here about your experiences with recipes and how leaving them as modules can be very confusing. https://github.com/backdrop/backdrop-issues/issues/3763

Adding a new project type to Backdrop is not trivial and will probably only happen if people ask for it.

[Egmund]

Actually: Updating does something. All 'hacks' to css in the 'module' are 'erased' since the css is replaced. In this case I experimented with flexboxes in the footer - some formatting for nicemenu was overwritten w. update.

[stpaultim]

All 'hacks' to css in the 'module' are 'erased' since the css is replaced. In this case I experimented with flexboxes in the footer - some formatting for nicemenu was overwritten w. update.

This is true of all modules and themes. It's the reason that themes allow for sub-theming, so that you can update the parent theme without destroying any custom css you have put in your subtheme.

Any time you hack a module, you need to track the changes you made and reimplement them every time you upgrade the module or risk loosing your changes.

[Egmund]

Yes, that is true. Bad habit of mine. Another solution I like is having a custom css and then add a line regarding it in the info file after updating - easier than sub-theming.