Tour tips are provided as configuration, so never get updated

Reading through the mentioned issue comment from @sun #1809352-62: Write tour.module and add it to core I cannot found any mention of this issues title.

A further note would be: how does core work out this config update and what is different for tour?

This probably has a big impact as tips are now user specific making caching a pitb. We could store this information @ the browser but that would be weird when switching browser.

I see we have a backbone model for tour but is that server bound? I'm new to backbone so prob ask stupid questions. We could use that for state-management I guess without harming cache.

Regarding the visual marker we have
- forum-icons.png
- message-warning.png
- message-info.png
- star.png & star-empty.png
in one of our core/misc/ dirs

Hope that helps.

What is this issue actually about? Here are my best guesses:

a) If you update a module and the new version has a different version of a tour, a completely new tour, or has removed a tour, you will already have imported the config/install for the tours for that module, and you will not get any of these changes. The Config Help (help topic entity) module has this same problem on #2371439: Figure out what to do when module updates configurable topic, and I am not sure yet what to do about it. But both Tour and Help Topics are config entities that need this ability to notify admins and/or get the updates. I am very interested in thinking about What Should Be Done and working on solutions together, if this is the point of this issue.

b) If you install a new module and it introduces new tours, users might conceivably want to know about these new tours that were not on the system prior to installing this module.

I'm not sure if this issue is about (a), (b), or maybe something completely different. Maybe an updated issue summary would clarify what it is about?

I just made a sandbox/contrib module that will do this for any config entity:
https://www.drupal.org/sandbox/jhodgdon/2391835

I haven't specifically tested it on Tours and it is a bit rough still but you may want to try it out?

Just a note here that the sandbox referenced in the previous comment is considerably matured since a month ago:
https://www.drupal.org/sandbox/jhodgdon/2391835

On #1398040: Detect if default configuration of a module has been changed, and allow to restore to the original there is a discussion of whether this sandbox functionality should go into Core. I think it would resolve this issue if it did; if not, the resolution could be "use contrib".

In thinking about whether the Config Revert sandbox (reference in previous two comments) could be added to Core, I was looking at this issue and others to see if any are classified as bugs. This one was a task, but really it's a feature I think, so at this point has to be 8.1.x material.

And by the way, the module referenced above is now a full contrib project:
https://www.drupal.org/project/config_update

Even just typos fixed in tips, or improved language won't show up. This is therefore a quite big problem.

This is a generic problem in Core configuration, not just Tour. It can be solved with something like the contributed Configuration Update Manager module, which at least gives you a report that tells you things have changed:
https://www.drupal.org/project/config_update

We should definitely get that into Core, IMO, but I have no energy for this effort.

This seems like an architectural issue with the tour module. Seems like it could do something similar to migrations where there is a template YAML, which can potentially be replaced by configuration, as opposed to always configuration.

Trying to update configuration doesn't seem like the right approach - configuration updates are tricky since you don't want to overwrite customisations either.

This was a bugsmash random issue. It is still valid. We agree to unassign the issue since @nick_schuch has not been active for 9 years.

This extension is being deprecated, see #3336033: [Meta] Tasks to deprecate Tour module. It will be removed from core and moved to a contrib project, #3376099: [11.x] [Meta] Tasks to remove Tour.

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.