Back when rollback was announced as being deprecated I queried if there was more information on what Rollback is being replaced with?
Just wondering if there’s any update?
We’re using Rollback to some degree to help keep track of content changes and it would nice to hear an update before we commit to an upgrade to 5.5.
We’re using Rollback to some degree to help keep track of content changes and it would nice to hear an update before we commit to an upgrade to 5.5.
Though deprecated, Rollback is still available in 5.5, and won’t be completely removed up until next major release. Next major release will contain some alternative for existing rollback functionality.
The release notes indicate:
Losing all the existing rollback data isn’t something that is a trivial matter. Running a clone of the previous 5.4 install also isn’t something we’d necessarily want to do for long.
If there’s no Squiz planned replacement solution we may need to look at third party alternatives.
Hi,
Out of interest would the logged messages (logs) still work in future version of Matrix once Rolleback is fully deprecated?
We never really needed rollback because our systems are backed up every night but I do find the logged messages useful to see any changes mage to an asset.
Thanks
I think those are from the log that records actions? I have a recollection of digging through the logs to recover lost content on our server that doesn’t have Rollback enabled.
For us, it’s the convenience of going to _admin, then rollback, picking a date and voila - there’s the old page, and we can see when it was changed and by who and recover content / markup / code if recovered.
Having full backups is great - but having to spin up a clone of our CMS server, and then loading the backups onto that isn’t a five to ten minute task like Rollback allows for.
Yes it would be the log records.
I should have explained that most of our important product pages are in Contentful and it is also stored in a seperate database for backup.
Most of the revision control and new content publishing happens in Contentful and pushed to Matrix. So in the event we screw up Matrix royally we can spin up the saved image and if we destory a product page then it is matter of running individual product sync.
We’re now in the process of moving over all the Wordpress blogs onto Matrix/Contentful.
Matrix logging / internal messages logging wouldn’t be affected by Rollback deprecation.
Just to be clear - this has always been a requirement with the way Matrix Rollback functions when upgrading between all major and most minor versions. There were a handful of minors within Matrix 5 that didn’t end up requiring this, so that’s why it got the extra emphasis for the 5.4->5.5 upgrade.
Does Squiz have a solution where Rollback is being used in some capacity for records management, and there’s a need to carry over data through an upgrade?
I must say that I don’t think I’ve heard the need for data to be purged between major versions before - and we’ve been interested in using Rollback since we initially got on board back in 2009. The manuals also seem to be bereft of that information.
It always used to be a matter of taking a backup and if it needed to be accessed restoring it in a VM.
I don’t think it’s highlighted as well as it should be but https://matrix.squiz.net/manuals/server-administrator/chapters/rollback-management-script#resetting-rollback has:
This process should be completed after major upgrades of Squiz Matrix.
IIRC all 3.x minors (which would have been current in 2009) required a reset and a few 4.x minors required a reset, I think this is the first 5.x minor that required a reset.
If your hosting was managed by Squiz I know for sure they were forcing the resets during basically all 3.x upgrades and the critical 4.x ones, if you’re self managed and it was missed it might have just not been obvious that bits of rollback were actually not functional (some bits of it still work, but some historic data can’t be viewed correctly if an attribute definition or worse yet table definition has changed between the version it was stored in and the version it’s viewed on).
I got corrected by someone internally, during at least 3.x.y the the x was “major”, in 5.x.y.z the x is “minor” and the upgrade docs at the time did say that every major required a reset - https://web.archive.org/web/20090116130840/http://matrix.squiz.net/resources/upgrading/upgrade-3.18-to-3.20
I’m not clear if that terminology changed during 4.x or at the start of 5.x - but the terminology in the manuals is probably from when the second number was still “major”. I’ll try to follow up on Monday with some people who may know but aren’t available today.
Thanks for the engagement David -
We’ve always managed our own hosting, and ongoing Rollback discussions finally saw us have it enabled with 5.x (for many years we were discouraged from using it). That would explain somewhat the absence of any experience with upgrades with 3.x and 4.x
If you can find out anything further that would be appreciated.