Revisions in and of themselves are a wonderful thing. They offer content editors the possibility to circle back to a previous version of an entry and correct some mistakes that might have been introduced along the way. From a developer perspective, however, there are more of a nuisance. In one of our projects, they even deteriorated the whole content editor experience. This is the tale of how we had to rethink our approach of working with revisions, and contributed to the Craft CMS Core along the way.
Normally, saving an entry only takes fractions of a second in Craft CMS. However, in one particularly big project, we started to experience long saving times (sometimes up to 10 seconds) for larger entries. Initially, we couldn't figure out why exactly this was happening. Surely, having multiple different versions of a whole entry stored away in the database, the size of the latter will grow exponentially (something which is not to be taken lightly), but this shouldn't have an impact on how long it takes to save an entry.
In order to first keep the database size somewhat in check, we decided to limit the number of revisions that will be kept by the CMS. While Craft allows some 50 revisions to be saved by default, we lowered this threshold to 10 revisions on our Production system and 5 revisions on our Staging system. This can be achieved by setting the parameter maxRevisions in the Craft CMS general config to the respective value. While this notion worked great, it still didn't fix our initial problem at hand. After a thorough analysis of what actually happens when an entry is saved, we finally found the catch: when saving a new version that would increase the number of an entry's revisions over the threshold, the oldest revision gets deleted before the new version is saved.
While this makes total sense (otherwise the limit would be exceeded), it creates quite some problems when an entry is large or has lots of different Content Builder elements in it. Our immediate idea upon discovery of this issue was to let the old revision be deleted by means of a queue job (https://github.com/craftcms/cms/issues/5902), and it's not without pride that we can announce that this idea has made it into the upcoming release (version 3.5, probably out in summer) of Craft CMS!
However, since we couldn't wait for Craft CMS 3.5 to be released, we had to implement a small workaround ourselves: by setting maxRevisions to zero, unlimited revisions are saved and no revisions are deleted – ever. While this in itself would be catastrophic, lucky for us a new Craft CLI command was introduced recently, which goes by the name of utils/prune-revisions. Needless to say, it does exactly that: prune all the revisions that are above a certain threshold. So the only thing left to do was to schedule a Cron Job to prune down all revisions exceeding 10 on our Production system (and 5 on our Stage system), and off we went.
# Cron Job – Revision Pruning php /path/to/project/craft utils/prune-revisions --max-revisions=10