- This topic has 3 replies, 2 voices, and was last updated 2 years, 7 months ago by
Sebastian.
Author | Posts |
---|---|
Norm6257
August 31, 2022 at 10:31 pm
|
Hi, My experience is that when changing preferences they are always published live right away. So when I’m playing around with the loading order (or other UX settings) they are seen on the public site before I’m actually ready to truly publish them. Suggestion: Make preferences changes draft just like you do with CSS changes, until explicity published. |
Sebastian
September 1, 2022 at 11:26 am
|
Another good point Norm. I can foresee possible confusion about preferences not applying straight away to logged out users on the frontend (e.g. when people are testing with another browser). So perhaps two buttons on the preferences page would be best e.g. # Primary button # Secondary button When the user clicks the “Publish” button in the main UI, draft preferences would be published alongside the CSS settings. What do you think? |
Norm6257
September 1, 2022 at 12:55 pm
|
Thanks for the feedback and consideration, Sebastian. For me personally, I don’t see the confusion with testing and logged out users. I would prefer it to be consistent with the behavior of the CSS draft changes. When draft changes are made to the CSS those changes are not visable to logged out users. I would expect the same behavior with preferences. For me, just follow the settings for autopublish and the way it works for CSS changes… if autopublish is enabled, then changes to preferences or CSS become immediately live. If autopublish is disabled, then changes to preferences or CSS are not live until explicitly published (meanwhile, the changes are visible to admin users). For the save button label, could it be dynamic? That is, you look at the status of autopublish. If enabled then the button label would be “Save and Publish”. But if disabled, then the button label would be something like “Save as draft”. Make sense? |
Sebastian
September 3, 2022 at 2:03 pm
|
Hey Norm, Perfect! I think your button suggestion would resolve any ambiguity and be more consistent with how the draft status is relayed in the rest of the UI e.g. on the option to jump to the frontend. Nice one. I’ll add support for this while I’m working on the conditional page logic for folders, as that will involve some changes to the way MT manages draft vs published settings. Cheers, |