VersionX
VersionX copied to clipboard
Allow versions to be deletable
This is a feature request. It would be great if it was possible for the user to be able to delete versions that are no longer required, not only would this help keep the database small but would also assist in the management of the versions.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Just to play the devil's advocate here, do you think there should be some limits imposed in terms of removing versions? Like, only if they are older than one month or always keeping at least the last two? Just wondering if we should prevent a malicious user from changing all sorts of pages, to continue deleting the older versions and destroying the ability to revert.
That's probably a good idea to have some restrictions, although personally I'd prefer to keeping at least 2 rather than any date based thing as I often make a number of changes within a week and wouldn't want to be restricted to having to wait 2 months before deleting those versions not needed.
If a malicious user is logged in to your site they could cause a lot more damage by simply deleting the resources anyway couldn't they?
If a malicious user is logged in to your site they could cause a lot more damage by simply deleting the resources anyway couldn't they?
Yea, but when running VersionX in its current shape, they wouldn't be able to actually delete the stored versions, so the admin can easily restore :)
Maybe putting the older versions in a bin that:
- empties itself every week/month/... or
- deletes versions after they expire
That brings it close to issue #4, too..
I get what you guys are saying but from my experience a previous version of a page isn't always less valuable just due to it being 6 months old, if that was the last change before the current one however some limit or delete option would be great.
If I wanted to go in an delete them manually for now, does it store the versions in it's own table?
I think any limits based on dates is a bad idea, the best method from my experience and also my clients from a business rules perspective is only allowing it save the last N versions. This way you can change the number of previous version you need based on the frequency of content updates. Example those companies that update content frequently might want to keep more versions where as those that are slower to update would keep fewer.
my half cent of thoughts - good luck with that choice
It's stored separately in the modx_versionx_* tables, where the content_id (or contentid, not sure from the top of my mind) references the ID of the resource or element.
Thanks Charles! Much appreciated. I also think that makes sense, giving people the ability to customize how it works depending on the client.
I've also bounced the thought of allowing users to "highlight" or "mark" specific versions, which could then be excluded from automatic deletion.
exclusion from delete would be great, I have had cases where clients have seasonal content so that would allow them to ensure that the last seasons content could be excluded for easily restoring and altering in the next season.
Great work on this project overall, it's been a great extra for me and my clients.
Hi @Mark-H
How about something that retains all versions that are either x days old OR the last y versions – whichever has the most versions in? Say if x days = 7 and y versions = 10, then even if all versions were over a week old then the 10 previous versions would still be retained.
Anyway, I just had to 'restart' versions again: uninstall, delete tables in Db and reinstall because there were getting on 4000 rows in the resource table.
Thanks, Shaun
I second Shauns comment, I have had to uninstall the plugin as it was getting too much to have to go in and manually delete rows in the db. When i uninstalled the version x tables were tacking up 22mb - thousands of entries.
I think my site is at abt 3000 or so entries... while I definitely want to incorporate automatic date or count based cleanups (in next release actually; 1.2), any particular reasons you felt the need to empty the db? Any performance issues or other side affects you guys are seeing that haven't shown itself in my installs?
22mb isn't all that much - that's about the size of 10 client-uploaded images uploaded by your clients :-) MySQL can handle millions of records just fine, too.
(Also, if you want to get rid of the stored copies, you don't have to uninstall.. just open up the DB in like phpmyadmin and truncate it, or craft a query that removes all records older than XYZ) Op 1 mei 2013 23:31 schreef "antsplace" [email protected] het volgende:
I second Shauns comment, I have had to uninstall the plugin as it was getting too much to have to go in and manually delete rows in the db. When i uninstalled the version x tables were tacking up 22mb - thousands of entries.
— Reply to this email directly or view it on GitHubhttps://github.com/Mark-H/VersionX2/issues/30#issuecomment-17307857 .
Until a native solution is implemented I created a simple snippet to clean up the VersionX records. More details on the MODX forums here:
http://forums.modx.com/thread/86917/snippet-for-deleting-versionx-content-no-longer-required#dis-post-478916
Add a permission VersionX_DeleteResourceVersion, VersionX_DeleteSnippetVersion etc. in addition of checking for MODx->hasPermission('delete_resource') etc
Hi Marks, sorry I never saw your reply and question!
While I understand mysql can handle that many entries, I prefer to keep my site as agile as possible. Not only for performance but backup, storage and ease of transfer too. I think it's also better from a housekeeping perspective to have control over which versions to keep.
I often save a page I'm working on after only a small change but then after an hour or so had tons of versions when in reality I really didn't need that many. In addition having so many makes it more troublesome to find the one you want.
Hi minigerges, can you explain in more detail how this will accomplish deleting of versions
First we need to add 1 more feature request (Add option in VersionX tab or a property for Resource/element to be excluded from Versioning)
What I meant about permissions: Check if user has permission to edit/delete resource/element then accordingly act on context action (revert version/delete version) in addition custom versionX permissions can be added to specify which user groups has the right to delete or revert a version.
VersionX 3.x offers automatic cleanup based on certain epochs (see the readme). Milestones preventing deletion are also now a feature. Closing!