We look to lock out editors for upgrades so that in the event we need to rollback to snapshots of servers or backups we don’t lose any edits that editors might try to make during the upgrade.
Is this something other Matrix users around the globe look to do? Anyone care to share tips or techniques?
It’s certainly something Squiz do for their Squiz Cloud customers. I’m not sure what else they do behind the scenes, but one thing I’ve noticed is they simply go to System Configuration and change both the Admin Mode Suffix and Edit Mode Suffix - a nice quick and easy solution to stopping editors from being able to make any edits!
…not sure which version it was added but there is a system maintenance mode:
https://matrix.squiz.net/manuals/concepts/chapters/maintenance-mode
…choose which assets are locked down.
Other that that we used to redirect the admin / edit users to a static ‘editing disabled’ message
K
Maintenance mode suggests itself for locking out our forms, so that we don’t lose submissions. We’d be interested to confirm it works as the manuals suggest.
Has anyone had experience with using Maintenance mode to halt form submissions?
After reading the manuals, I wasn’t sure maintenance mode could perform a comprehensive editing lockout so I created a quick squizmap idea - Maintenance Mode - Disable editing :
Maintenance Mode suggests itself as a very useful option for performing Matrix system upgrades.
It would also be useful however to have functionality in Maintenance Mode to lockout editors and administrators from making changes while an upgrade is underway. We currently have to perform this by modifying the security setup around our editing and admin addresses which is always a bit messy and more clumsy than a built in solution would provide.
That editing lockout could support the option of enabling certain groups with access. This option could then be used to enable certain groups for testing the upgrade was succesful.
When we first built maintenance mode, we did consider letting users login but not actually submit any changes. Basically put everything in read only mode.
At the time, it would have added significant amount of extra development and testing to the feature, and the main priority was to be able to easily disable form data getting posted from the front end (custom forms, asset builders, etc).
The reason we also didn’t lock down editing is that we normally change the edit and admin url suffixes as a standard for all of our clients upgrades, as Jason mentioned, which takes care of the editing prevention.
I can see some benefits of easily allowing all non-sys admin users to login to /_admin or /_edit but not being able to do any changes, but all they would really be doing is looking at the content that is already there, which may not really be useful to them if they can’t edit it anyway and can see it on the frontend already.
We have two concerns about lost data, and form submissions are what I’m primarily concerned about in the event that either:
In the past we’ve modified our security stanzas (apache level) but that didn’t work 100% nor address people who had existing sessions.
What we’ve found is that no matter how well you communicate a planned outage, someone either doesn’t see the message, read the message, remember the message, or magically thinks it doesn’t apply to them (we have a lot of distributed editors and content authors, and our staff profiles are setup to be maintained by the individual staff members (and we have 1500+ staff)).
With changing the url suffixes, does that close any open admin/edit sessions?
Changing the URL suffixes doesn’t close any open sessions as such, but anyone actually using _admin or _edit at the time will get 404s once the suffixes change.