Does anyone else ever experience issues with switching groups in different browser tabs? We experience a couple of things that I feel are due to this.
Sometimes, when switching to a browser tab that is logged into LiveWhale, it takes some seconds for things like links to become “active”. The amount of time varies, but is usually enough to be noticeable, and often bothersome. Lately, I have come to the realization that this seems to happen when switching from another browser tab that was also logged into LiveWhale but active in a different group. It’s like LiveWhale takes some time to adjust to the different group or something.
Occasionally we will be creating or editing an event, story, page, etc. and when we click “Save” it will fail. Sometimes there is a message that says something like, “You have been switched to X group” which is not the group the content was being edited in, but rather a group that was active on a different browser tab. At that point, all edits were lost and have to be re-done.
Long story short: yes, particularly the latter point.
I brought it to LW support some time ago. We tested things out, but I’m not sure anything conclusive was found. I’m still experiencing it now.
I think we were also uncertain if it was just me (browser, settings, etc) or a broader CMS issue. Someone else experiencing the issue could potentially provide better clues to the cause.
@mischlern It’s definitely not just you. Several of us on our web team have experienced it numerous times. Most of our users don’t switch groups, so it has been limited to mostly us admins. My colleague in Communications and Marketing said she spent 45 minutes building a new event, and lost it all when she tried to save because of the issue.
My colleague in Communications and Marketing said she spent 45 minutes building a new event, and lost it all when she tried to save because of the issue.
I know this very well. Maybe only 1-2 times at that scale– magazine stories– but many instances of edits lost when working across multiple groups.
Jon I remember some communications with you about this quite a while back — many, many versions ago. I know we’ve made a variety of adjustments in this area over the years; I can also see how an admin or busy content person can wind up with 10 tabs open and each is logged into a different group.
I can’t necessarily promise a fix here, but what I can say is that if either of you can identify a specific path to reproducing the error — create a story, new tab, switch groups, etc. — then it will be much easier for us to resolve.
If you don’t mind, I would love to sort of hijack this thread to bounce a couple of things we’re considering for LW3 off of you both. Either of these I think might have some effect on the issues you’re describing.
As you know, when you edit a story in group X, we switch you to that group for editing. Then when you go back to the site, you remain in that group. We are looking at passively switching you to the group that owns a page whenever you visit that page. (By “passive” I mean that we’d try to make it a quick, seamless change that you wouldn’t have to think about much.) So you would never be on a Group X page but switched into Group Y. Do you guys have any thoughts on that?
Autosave. We have had autosave features working in the lab for a while, but in practice we’ve found it annoying to use — and we haven’t had enough interest in the feature to press on with it. It seems clear to us that “always autosave everything” isn’t a good idea. But we could perhaps make that something you opt into — like an “Automatically save work on this story” kind of checkbox. Are there any more specific applications of an autosave function that you think would be especially useful for your editors?
I’ll see what I can do. The problem is so sporadic that it might be difficult to nail anything down.
Now, regarding your other questions:
I like this idea. I can’t tell you how many times I have been editing a page and want to insert an image, widget, etc. and find I am not switched to the group that owns the page, so the group content is not available. At that point, I will typically save a draft, switch groups, and re-edit the draft to continue.
I am curious how this would work for non-group-switchers, though. How would they get switched to the group that owns the page if they don’t have access to that group?
And would this potentially make the issue described above even worse as it could lead to even more group switching in different tabs?
I would absolutely not want autosave in LiveWhale. I would not feel comfortable editing anything, which often involves experimenting with different content and layouts until I’m satisfied, if I knew that LiveWhale was auto-saving as I did so.
The only thing I can imagine being useful in this regard is if LiveWhale auto-saved your work as a temporary file, but absolutely never saved or published it without confirmation. It could be used if you accidentally navigated away from a page, or your browser crashed, or the issue above presented itself, etc.
Regarding #1, I had another thought. What is even the point of group-switching on pages, other than having access to resources of the group you are in? What if the group switcher in that context went away entirely? When adding things like images and widgets, those dialogs would automatically show content in the group owned by the page, regardless of what group you may be “in”.
Maybe I’m missing something, but group-switching has always seemed like a backend function, and something that could be irrelevant on the frontend if done right.
I can’t necessarily promise a fix here, but what I can say is that if either of you can identify a specific path to reproducing the error — create a story, new tab, switch groups, etc. — then it will be much easier for us to resolve.
I did some fairly specific testing with support some time ago, and I don’t think there is a clear, obvious sequence to trigger this issue; it seems persistent but inconsistent. If I understand my notes from 10/05/2023, my best guess is:
A tab can become “corrupted”, losing its ability to maintain/remember its group ID.
In this state, it can take on the group ID of another tab an editor focuses on.
Once mismatched, if the editor tries to work in the original tab, any reload of a page or page element (i.e. list of items being filtered) will use the group ID of the other tab.
This will persist until the group switcher is used in the original tab, giving it a fixed identity again.
I know support added some code to our site help track group ids and mismatches. If that code could be shared with us, or identified on our servers if its still there, I could try to do more systematic testing.
For your questions:
Question 1. The ability to mismatch page group and backend group has its narrow uses, but I don’t see it worth maintaining. In addition to having mismatched content available, I find it annoying when I navigate the frontend to another group, then click “Dashboard” to find I’m still in the original group. I could have skipped the frontend move, and just done the backend shift.
The concern of what would happen for an editor for only Group A looking at pages for Group B is a good one. The idea to just disregard the group switcher in the front end may be good, but I think it should still tell you what group you’re in, even if you can’t change it. If you can change the group, it could change you to that group’s pages. (What if a group doesn’t have pages? Then to Dashboard?)
In short, yes, sync the page group and the active group. (Not sure if this would help with the thread’s issue. May trigger it more if an editor is looking at multiple pages.)
Question 2. I don’t have a strong initial opinion here. I agree that the idea of working with potentially Live content is concerning. Reading what you both have to say, some questions/ideas:
For autosave: could it be handled similar to revision history? Edits are saved every X minutes or manually. If there are edits but no publish made, then a prompt alerts the editor to the fact there are autosave edits available to load. These are only kept for 1-2 days at most, with the user interface making it clear to the user to either publish their work or save it elsewhere.
Alternatively: could we get drafting for the backend content, similar to pages? If drafting was an option, then “autosaves” could be saved as a system “working draft” of the document. It would also allow editors to save their work in general, especially for Live items like Profiles or Blurbs.
For the thread’s issue: could a copy of the content be saved in another resource before the save to database attempt is made? Then, if the save fails, the content is still readily available to copy/paste or load back in?
For the thread’s issue: for existing content being edited, could backend saving avoid needing to be in the correct group? If I am saving an item in Group A, and I have a mismatch to Group B, the save step appears to load B, determines the item is owned A, then the group switch back to A interrupts the save step. Given the item exists and has its own unique ID, I assume it may be possible to save to that ID without needing to be in the item’s group.
Thank you for the concise version of what I intended. I couldn’t quite get there at 6pm.
There’s still the issue of new items. I’ve had a few instances where:
I start making an item (event, story, profile, etc) in Group A.
I trigger a group mismatch, so the tab is quietly working as Group B.
I save the item successfully, but it is saved to Group B, rather than Group A.
(Particularly annoying when it is a profile, and its type is limited to Group A…)
Perhaps for this:
Could the target group be assigned to a hidden field on the new item editor page load, and that group value used on save, regardless of the group value the tab thinks it should be working with?
Could the above also be used as potential solution for the above idea for existing items. If an item knows its owner group, then so long as a valid editor is making the save, the group value the item has could be used instead. (Risk of value mismatch, if the owner group is changed but the item’s value isn’t. Could compare on page load again?)
I don’t know, neither what’s possible or feasible for the whole thing. Hopefully the ideas inspire more ideas, if nothing else. >_>
I hadn’t thought about new items, but I think your ideas are good. I like the idea of establishing the group connection immediately on new items and using that regardless of what happens during editing.
I totally forgot about this scenario, but yeah that has happened on occasion and is tough. I’ve had to resort to finding the new profile in the database and changing the group ID there.
Adding my two cents, since I have similar group switch issues as Jon and Nick sometimes.
The passive switching sounds interesting for page content uploads/embeds since I’m often working on/helping out people in different departments, but would this just add on to the issue of getting switched on tabs that are already open and I then go there to make a change? I’ve tried to record it as any specific actions making it happen, but there isn’t anything specific. An existing tab will simply reload with the newest group I switched to on a different tab whether I’m saving a dynamic item or loading a new dashboard tab sometimes, but it doesn’t happen all the time or enough to be a specific pattern. It just happens every once in a while when I have two or more groups switched to in different tabs.
Like you said, autosave on everything is a bad idea, but autosave with an opt-in checkbox sounds interesting. However, one of the things I’ve run into sometimes is that I’m creating a new item (page/story/event etc), but when I go to save it, it reloads a group I opened in a different tab after this one, so the story/event does not exist anymore since I had not managed to save it as an item at all in the first place and the save action was superseded by the group switch reload action. Would this optional autosave also work on previously unsaved items in some sort of temporary location, kind of like how MS word shows you an option to recover changes on an unsaved doc when you restart it, if the program quit accidentally while you were working on a new document?
i’ll admit this is not so big an issue that it consistently bothers me, and it’s mostly me, since most of our users are either single group, or only work in one group at a time so all I need to do is…not multitask lol, but it would be good to have it not happen even for those few times. Thanks!