VersionX is an awesome extra - should be part of the core IMHO.
With that said, I have found - especially with the dawn of Fred - that the modx_versionx_resource table gets quite large very fast.
Is there any good easy way to have versions houscleaned/purged yet? I found this post, however it seems to have left the answer in limbo? Also - the solution here is not really practical to do with sites with dozens or more pages.
Thanks!
I don’t see why the number of pages is a concern here. The snippet removes old versions for all the pages. Just takes more time to execute if there are a lot of pages/versions.
Also, you may want to look at this thread with the same topic which is quite recent.
Thanks @halftrainedharry - I misunderstood the nature of the snippet. I interpreted it that it purged old content for JUST the resource it was executed from - not all resources.
Definitely more practical your way 
FWIW, the canonical issue about this feature is here: https://github.com/modmore/VersionX/issues/30 That will be updated when there’s an actual fix.
So far the bar I’ve set for including something like that into VersionX has not been met: no opportunity for deliberate data deletions through regular use. That means any sort of solution that operates based on a max X number of versions or keeping versions only for the last X days is too easily exploited and will not be incorporated.
I do have some ideas on what would satisfy that: storing deltas instead of version copies. Right now VersionX creates a full copy of the entire resource on save (which is why it has the potential to grow fast, especially with ContentBlocks or Fred). With deltas, it would store only the changed “before” and “after”, or the difference between versions.
On its own that already reduces the size immensely, but that could be taken further to automatically combine deltas over time. While you may want each individual delta for the last week or two so you can revert any individual change, those deltas could be merged into a daily delta for anything up to a month or two, and then even a weekly delta or monthly delta for even older changes.
Would love to work on that when budget for it becomes available, but so far my attempts to get compensated for open source work haven’t been very promising… so that may be a while.
Totally understand. As always, whatever you do for this community is appreciated.
From my point of view, I think the approach to purge the “middle X” is ideal. Something as simple as two sliders (1 to 50 for example) in the UI. First slider is keep first “X” number of records. Second slider is keep last “X” number of records. Click the process button and everything in between gets purged.
Simplistic in it’s explanation I know - less so in it’s implementation I expect, but the ability to do the above strictly on-demand would solve most needs I think.
@markh Storing deltas instead of copies… Just like Git…? I’m mostly relying on Gitify for rare cases where something needs to be restored to an earlier version. In PhpStorm and SmartGit, it’s easy to compare older versions of the Gitify extract side by side. Easy for a developer, that is.
Just thinking out loud… For editors, would it be possible to have an interface in MODX that leverages Git and Gitify in the background? Something that checks out older versions of a page, allows you to preview them, and then accept (commit) them? I’m sure there are a lot of caveats to consider, like: how and where to initialize the repository, how to deal with an existing repository, etc.
Storing the deltas was the intention and approach I used when I created Revise. Though that was never completed, you are free to take a look at that and rip any ideas from it.
Is it possible to delete older rows in the modx_versionx_delta and modx_versionx_delta_field table, or will this damage the data integrity?
E.G. the first 6000 entries:
DELETE FROM modx_versionx_delta
WHERE id < 6000;
DELETE FROM modx_versionx_delta_field
WHERE delta < 6000;
DELETE FROM modx_versionx_delta_editor
WHERE delta < 6000;
With VersionX V3, better use the “Optimise Storage” button in the CMP (or run the “cron.php” file)
This leaves ~7000 Deltas with ~300.000 delta_fields and ~40 MB database storage. In this special case it is to much for me.
VersionX V3 only saves the differences (deltas) between the versions. The way the extra reduces the database storage is that with time these deltas get merged.
The time periods for which deltas are merged are hard-coded.
You’d have to write a custom class (similar to DeltaMerger.php) with different time periods to reduce the amount of stored data.
If you just delete the older data from the database tables, you lose the initial state and most likely break some of the functionality.