Update README to mention we won't be updating tour config retroactively

big +1 for this issue. that was one of the major nags. to potential scenarios in this context. about a year or year and a half ago i've started to work on adding tours to ECA. the problem here was that for one if ECA was already installed and when ECA gets those tours for an existing install those were not available for them. the module had to be uninstalled and reinstalled. that case would be covered with this issue. but the other scenario i imagine tricky how would the following case be dealt with now with tours ui merged. you have for example the core tours available, you now alter the description of some of them, now tours gets an update include an update to all tours including their descriptions. would it be necessary to have a check in place to notify the user so the description and the users changes not silently get overwritten?

Yea we would have to either compare the body text with what we expect, showing it's unchanged and probably safe to update.

Or add a new form element to the tip that allows user to say this is custom so we can't update?

hm the downside of noting sorry unable to update since for example the description is custom, that leaves the user potentially out in wild on his or her own. my question as the user would be, what is the new change, do i need it, what happens or what do i miss when i keep my custom setting, where could i find potential update, how could i update to it manually. i would be on my own here. and that could feel challenging with the fear to break anything in the long run.

and yeah i think having a form element that displays the before and after might be the ideal approach, strictly speaking a basic diff functionality? you see your current custom setting, you see the change that is being introduced with the update and you get the option to confirm the override, keep your version or edit? and on edit you get a field were you are able to manually chop together the text pieces you like of your custom text and add additional details from the proposed update?

Adding a diff comparison maybe beyond the scope of the project and my skillset haha. but also if someone where to add a tip to an existing tour then that diff would always show.

Bumping in replace of 🐛 Tour config validation errors Active

hmmm to be honest for me the second sentence is not clear:

**Disclaimer: Due to Tours being config and possible to be edited on a site basis we will not be doing any Tour or Tip updates retroactively. All updates can be made but no update hook will be added.**

what does "all updates can be made" imply? updates within the ui or programmatic updates? i not really understand the actual implications. therefore i am also uncertain about suggesting an alternative wording.

and since you reworded the title and removed the helper function. i would still have the question i really struggled with a few months ago while the tour module was still in core which might be relevant to this issue. back then we started creating tours for eca. but the problem was with the tour module already installed and eca already installed and with tours being added to eca manually (during the creation) or when the tours are ready in a new version of eca - those tours were unavailable in the tour module (only the yaml files were in place). i would have to uninstall eca and reinstall it (or alternatively tours?) to get the tours available in the tour module which is sort of inconvenient. but havent tested nor worked on these tours in a while, sort of stalled back then. but a case like that i consider still relevant?

Good catch. I was trying to mention that fixes to existing tours can still be made just that we won't be doing any update hooks.

What we could do though is start a documentation page or call in the release notes

Something like

2.0.4

Tour content changes
> Admin content tour text was updated from xyz to abc

For the scenario you are describing though you would have to write an update hook in ECA to install those tours. Since Tour is pure config it doesn't get picked up from the module once installed.

Ended up just removing that sentence. So should be simple.

Thoughts?

Automatically closed - issue fixed for 2 weeks with no activity.