VersionX Housekeeping

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 :wink:

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.

1 Like

@markh Storing deltas instead of copies… Just like Git…? :wink: 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.

1 Like

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.

2 Likes