Subsites not safe for multiple tabs

[robingram]

I'm not sure that there is an easy fix for this but we do believe that it has caused issues for us.

Since the ID of the current subsite is stored in the session this can cause problems if working on different sites across multiple tabs:

1. Open two tabs on main site
2. Switch to a subsite in tab 2
3. In tab 1 create a new page

Expected:

Page is created in main site.

Actual:

Page is created in subsite.

It is easy to not notice this because initially it looks like the page has been created in the main site as expected.

[robbieaverill]

Hey @robingram, yeah you're right. The SubsiteID is stored in the session during CMS use. I think one way that we could get around this is by perpetually storing the SubsiteID in the query string instead. Do you have any other ideas?

[robingram]

Nothing elegant I'm afraid @robbieaverill. My initial thought was to make sure that the subsite ID was included in any form submissions but of course that would mean getting it from somewhere other than the session so maybe the query string is the best place.

[robbieaverill]

The problem is that the logic of "when changing subsites in the CMS, take the query string value and store it in the session, then redirect back again so the URL is nice and clean" is pretty well baked in to the core. I think if somebody wanted to work on adding support for permalinked style CMS URLs with subsite support then we'd support that idea.

[robingram]

I can only think of hacky things like grabbing the value of the subsite DDL and doing something with that on form submission.

[robbieaverill]

Yeah, that could be a compromise. Add the subsite ID as a HiddenField when the CMS form is loaded. It's probably worth noting though that this would need to be done for most data objects in the system, so would need to be applied in a way that would intercept any form load/write I guess

[robbieaverill]

How do you think we should treat this issue @tractorcow?

[tractorcow]

Front end state has always been an extremely prickly issue... we have had this issue with page ID being absent from the edit urls for the longest time also, although we had recently addressed this with some smart URL rewriting.

Unfortunately, the only advice I can give is to ensure all URLs are populated with the necessary SubsiteID; This should be done both via querystring, as well as page edit form to ensure posted values contain these values.

If you have a look at translatable (and perhaps to a lesser extent, https://github.com/tractorcow/silverstripe-fluent/) you can see we attempt the same fix here.

What I would like in core is (perhaps one day) a standard "state bag" that gets emitted with every request, but is bound to the front-end rather than a session.

[robbieaverill]

Copied from #19:

Moved from http://open.silverstripe.org/ticket/4224

Issue description:

Open the CMS in one browser tab and go to a subsite Open another browser tab and load the main site (public view - not the CMS) Now when you try to insert a link on the subsite, the site tree shows the main site instead of the >subsite. Desired behaviour:

The site tree should always be populated based on the currently open site in the CMS. This may be related to ticket http://open.silverstripe.org/ticket/4012

[chillu]

I've discussed this with Charlie a bit, recommended that we should just refresh every "background tab" when you switch subsites in the active tab. This can likely be done through shared state (local storage) and web worker events or something. It's a stop gap measure, but a whole lot quicker to fix than making every single view and edit request in the CMS subsite aware through stateless payloads (incl. GraphQL etc). That should be our goal eventually, but will be a lot of work

[sminnee]

Thanks @chillu I've split that into a separate ticket for easier tracking.