No Code Attached Yet bug ?
avatar kofaysi
kofaysi
26 Nov 2020

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.

avatar kofaysi kofaysi - open - 26 Nov 2020
avatar joomla-cms-bot joomla-cms-bot - labeled - 26 Nov 2020
avatar chmst
chmst - comment - 26 Nov 2020

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.
avatar bembelimen
bembelimen - comment - 26 Nov 2020

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?

avatar brianteeman
brianteeman - comment - 27 Nov 2020

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

avatar Fedik
Fedik - comment - 27 Nov 2020

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

avatar Quy Quy - change - 25 Feb 2021
Labels Added: Information Required
avatar Quy Quy - labeled - 25 Feb 2021
avatar brianteeman
brianteeman - comment - 21 Jan 2022

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?

avatar Fedik Fedik - change - 22 Jan 2022
Status New Closed
Closed_Date 0000-00-00 00:00:00 2022-01-22 18:32:02
Closed_By Fedik
Labels Added: No Code Attached Yet
Removed: ?
avatar Fedik Fedik - close - 22 Jan 2022
avatar Fedik
Fedik - comment - 22 Jan 2022

I closing it as expected behavior.

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

avatar brianteeman
brianteeman - comment - 22 Jan 2022

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

avatar Fedik Fedik - change - 22 Jan 2022
Status Closed New
Closed_Date 2022-01-22 18:32:02
Closed_By Fedik
avatar Fedik Fedik - reopen - 22 Jan 2022
avatar Fedik
Fedik - comment - 22 Jan 2022

Okay, then

avatar Fedik
Fedik - comment - 22 Jan 2022

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

avatar brianteeman
brianteeman - comment - 22 Jan 2022

perhaps

avatar roland-d
roland-d - comment - 23 Jan 2022

Why not use AJAX to save the options?

avatar Fedik
Fedik - comment - 23 Jan 2022

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.

avatar roland-d
roland-d - comment - 23 Jan 2022

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?

image

avatar Fedik
Fedik - comment - 23 Jan 2022

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.

avatar brianteeman
brianteeman - comment - 23 Jan 2022

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

avatar Fedik
Fedik - comment - 23 Jan 2022

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

avatar Fedik
Fedik - comment - 24 Jan 2022

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.
Screenshot_2022-01-24_16-46-45

avatar chmst
chmst - comment - 24 Jan 2022

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
avatar Fedik
Fedik - comment - 24 Jan 2022

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)

avatar roland-d
roland-d - comment - 24 Jan 2022

@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.

avatar brianteeman
brianteeman - comment - 24 Jan 2022

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

avatar roland-d
roland-d - comment - 24 Jan 2022

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

avatar brianteeman
brianteeman - comment - 24 Jan 2022

I think you posted the wrong screenshot.

avatar roland-d
roland-d - comment - 24 Jan 2022

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.

avatar brianteeman
brianteeman - comment - 24 Jan 2022

so similar to my rfc #36807 but completely full width

avatar chmst
chmst - comment - 24 Jan 2022

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"

avatar roland-d
roland-d - comment - 24 Jan 2022

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?

avatar roland-d
roland-d - comment - 24 Jan 2022

@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)

avatar brianteeman
brianteeman - comment - 24 Jan 2022

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

avatar brianteeman
brianteeman - comment - 16 Feb 2022

@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

avatar brianteeman
brianteeman - comment - 27 Jun 2022

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/

avatar Hackwar Hackwar - change - 20 Feb 2023
Labels Added: bug
avatar Hackwar Hackwar - labeled - 20 Feb 2023
avatar brianteeman brianteeman - change - 24 Aug 2023
Labels Removed: Information Required
avatar brianteeman brianteeman - unlabeled - 24 Aug 2023
avatar brianteeman brianteeman - change - 24 Aug 2023
Labels Added: ?
avatar brianteeman brianteeman - labeled - 24 Aug 2023

Add a Comment

Login with GitHub to post a comment