Follow-up for #3051766: Create API for tour items to replace use of drupalSettings

This extension is being deprecated, see 🌱 [Meta] Tasks to deprecate Tour module Fixed . It will be removed from core and moved to a contrib project, 📌 [11.x] [Meta] Tasks to remove Tour Postponed .

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.

@ksenzee curious if you would like to integrate that functionality into contrib of tour?

I have worked quite a bit with this module now, and really think a client-side API is needed to start, stop, and mess with existing tours, so opened 📌 Provide a JS interface by exposing Shepherd Tour object Active .

Also i think a server-side API is needed, to create dynamic tour objects. After some fiddling i found i can create config on the fly and pass it to TourViewBuilder, and call it a day. Not an elegant way in any sense, but it works for me. (I'll publish amodule soon-ish which may serve as documentaton.)

I thought a bit about, and do not see other obvious use cases.

So unless there are such use cases, let's remove the code-todo and close as WONTFIX.

@ksenzee thoughts?

I’m fairly sure a server-side API is still needed, if anyone cares about tour data on the server side. The tourauto functionality (which at some point I might actually manage a MR for) needs to keep track of which users have seen which tours, and it can’t do that on the front end because it’s user-specific data, not visitor-specific. So it needs to know on the server side which tours exist for the current route, so it can record that the current user has visited those tours. I still don’t see a way for other modules to do that right now other than copying a bunch of code from tour.module.

The original reason for this issue, as far as I can tell, was more about good internal architecture than about specifically letting other modules access the data. I think that reason still stands as well.

@ksenzee #12:
Thanks for clarifying. Looks like we are totally on the same boat:

> The original reason for this issue, as far as I can tell, was more about good internal architecture than about specifically letting other modules access the data. I think that reason still stands as well.

I boldly updated the title to what i understand. By any means challenge that if it's not correct.

> I’m fairly sure a server-side API is still needed.
> [tourauto ... needs to record taken tours]

Yes, that use case sounds reasonable. I see some room for bikeshedding though. When is a tour taken? Seen one tip? Finished it? But that's a different story for a different issue.

I am still envisioning the same thing I proposed in #5: a backend service for tour data, including "what tours are on this route," and a tiny amount of glue code that queries the service and sticks the data into drupalSettings for use on the front end. I've reworded the title to hopefully capture that. Feel free to change it again.

Actually question does tour_tour_tips_alter() not allow for this to happen?

If tour_tour_tips_alter() doesn't cover that please please reopen.