Edits in options for components in Global settings are ignored, if not saved with each component

[kofaysi]

Steps to reproduce the issue

Go to Global settings > Articles > Integration > Show Feed Link > make an edit/change in the switch
Go to Contacts
Go back to Articles > Integration > Show Feed Link > the edit is not prepared for saving

Expected result

...
Go back to Articles > Integration > Show Feed Link > the edit is prepared for saving

OR

A pop-up message is issued, when edits are not saved and the user attempts to enter another component's options.

Actual result

...
In Articles > Integration > Show Feed Link > the edit is not prepared for saving

System information (as much as possible)

J 3.9.23

Workaround

Save options before going to another component's options.

Although, I do not consider myself as a newbie, this behavior is somehow not consistent within Joomla. The edits are remembered within a components options when switching tabs until save. The list of components is also easily accessible -- almost so easily as the tabs.

[chmst]

If I understand this right, it is expected behaviour. In Joomla you always must save input - for every compontent.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/31495.}

[bembelimen]

A pop-up message is issued, when edits are not saved and the user attempts to enter another component's options.

Additional to @chmst who is right, you could try to work something out with onbeforeunload and create a PR?

[brianteeman]

Just looking at the page in j4 and it really does appear as if it is one page with one save

[Fedik]

no issue here,
it is how every website works, when you load new page 😉

[brianteeman]

A pop-up message is issued, when edits are not saved and the user attempts to enter another component's options.

I have no idea wht the "information required" tag is for on this issue.

Additional to @chmst who is right, you could try to work something out with onbeforeunload and create a PR?

I started to look at using onbeforeunload BUT the problem with that is you do not have any control on the message. It is defined by the browser for security reasons.

That in itself might not be a problem except that chromium says

Do you want to leave this site? Changes you made may not be saved.

Only Firefox gets it right with

This page is asking you to confirm that you want to leave - data you have entered may not be saved

Maybe there is some other means instead of using onbeforeunload?

[Fedik]

I closing it as expected behavior.

It need to save the form to store your changes before open another one.

[brianteeman]

Please do not close this. It is a real user problem and we can/should solve it.

From a user perspective there is no difference between changing tabs when editing an article and changing the option set here

[Fedik]

Okay, then

[Fedik]

Then I think it need to be re-designed, so it does not looks like the same page.

[brianteeman]

perhaps

[roland-d]

Why not use AJAX to save the options?

[Fedik]

Why not use AJAX to save the options?

It does not make difference, User still should push the "save" button.

And we cannot auto-save while navigation between different forms, because User expect that it not saved untill he/she push the "save" button.

So only re-design should help here.

[roland-d]

That is a fair point. So how does the redesign looks like? A dropdown with the extensions like we have in other places, such as custom fields?

[Fedik]

So how does the redesign looks like?

No idea, but it should be obvious that it no a "single page with tabs" .
And do not complicate navigation in the same time.

A dropdown with the extensions like we have in other places

Some kind of dropdown sounds as not a bad idea to me.
With this we can even save some space for the form itself.

[brianteeman]

Why are the other components even present when I click on Template Options

[Fedik]

That is good for usability, when "everything at hand".
I usually go to Global Configuration first and select needed component from there.

[Fedik]

What about move the nav, and display it as configuration menu,
Basically create a Configuration menu that displayed only when index.php?option=com_config (or one of Component config) is active.

[chmst]

What about

1. styling the Configuration menu like the main menu (dark background)
2. When a user opens a component then disable all other buttons until the active component is saved or cancelled

[Fedik]

styling the Configuration menu like the main menu (dark background)

I suspect that in current position it still will looks like tabs ;)

When a user opens a component then disable all other buttons

We definitely should not block anything, I may want to switch the component without saving active one (as it currently)

[roland-d]

@Fedik I like the idea of having the navigation in the sidebar. What I was also thinking is that as soon as you click one of these components, you get the same view as when you edit an item. Your "only" way out is the toolbar buttons (ignoring the browser back option). That would prevent users from accidentally clicking outside of the designated area and losing their changes.

[brianteeman]

The problem with that approach (and the one I suggested) is that it is very useful to click on one component to see the permissions and then click on the next component etc

[roland-d]

However in my suggestion you will not see the other components. Your page will look like this:

[brianteeman]

I think you posted the wrong screenshot.

[roland-d]

I did not. It is just an example of how the config screen would look like of course the fields are different etc. I have not build a new UI, just trying to say that this same principle of editing an article for example can be applied to editing a component configuration.

[brianteeman]

so similar to my rfc #36807 but completely full width

[chmst]

This is an interesting UX problem - it depends completely on the workflow.

I agree: someone wants to click through and compare settings, this should be possible without restriction, so blocking is a bad idea.
Can we make an alert, if someone has changed the input "you have made changes, they will be lost if you don't save them"

[roland-d]

Oh yes, I did see that RFC before but somehow did not register the screenshots. Indeed, exactly like that but without the side menu because you are basically in edit mode.

Where does a user go when they click on Close in your RFC?

[roland-d]

@chmst

Can we make an alert, if someone has changed the input "you have made changes, they will be lost if you don't save them"

Brian already looked at that but not really feasible, see his remark: #31495 (comment)

[brianteeman]

Where does a user go when they click on Close in your RFC?

The options button is on the component page so when you close the options page you return to the component page as it uses &return= in the url

[brianteeman]

@chmst

Can we make an alert, if someone has changed the input "you have made changes, they will be lost if you don't save them"

Brian already looked at that but not really feasible, see his remark: #31495 (comment)

Perhaps it would be possible to keep the display of the sidebar but disable it and do so ONLY when the current page has unsaved edits

[brianteeman]

I think I may have found a process to resolve this or at least improve it

We can't use onbeforeunload as mentioned earlier but I believe this should work. I just dont have the js skills to implement it.

Step 1 - watch for changes

js to monitor the current options form and set a flag if there are unsaved changes

Step 2 - reset

js to reset the flag whnen the current options form is saved

Step 3 - disable other options

while the flag is set to saved change the default action of the other component options in the sidebar. Instead of changing the form we can display an alert/warning about unsaved changes.

simply disabling the links would not be obvious in the ui why they are disabled. this way you get a prompt warning you before proceeding and even offering to save

note

This would not prevent someone leaving the options component completely but with the above change it is more unlikely that this would happen unless a user deliberately did not want to save

sweetalert provides a nice way to do this
https://sweetalert2.github.io/