Changing preferences — draft until published?

Author Posts



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.


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
Button label: Save Preferences (draft)
Button Tooltip: Update (draft) preferences for logged-in admins only

# Secondary button
Button label: Save & Publish Preferences
Button Tooltip: Update preferences for everyone, including site visitors

When the user clicks the “Publish” button in the main UI, draft preferences would be published alongside the CSS settings.

What do you think?


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?


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.


You must login or register to reply to this topic.