I have a project where the client has some requirements around version control of pages and files. Specifically, they want previous versions of any given page to be available to end-users via the date. A bit like a wayback machine type of thing.
I know Umbraco keeps a version history of changes made to pages, but I don't think that's going to be sufficient as it isn't accessible for front-end users. It also doesn't keep track changes to uploaded files (I don't think?), which also need to be kept in sync.
The idea is that the page contains information that is relevant for a given period of time, and will be overwritten, but that people may still need to refer back to previous versions. So a user might enter a date, and the site would switch to how it looked on that date (but with a big disclaimer so they know it's not current info).
I'm a bit worried that this could turn out to be quite a big bit of work, but also it seems like the kind of thing that others might have needed, so does anyone know if there's any existing plugins that might help me with this?
Hi Simon
It seems like when you save and publish a page, you want to intercept the save event to save a version of it with a url that has the date in it, then continue with the save and publish of the changes.
I did a blog post about intercepting content changes in Umbraco.
Hmm, your requirement could become very complex very quickly...
You are right Umbraco doesn't version media, just content. But this isn't part of published content. I think Paul's idea of using save events to create a new version is the way to go.
But you are going to have potential issues with things like embedded media and links. This is because Umbraco stores the ID of these - so if they change in the new version, they'll change in the older versions, too. And if a page or media is deleted, then any references to it will disappear. Imagine the scenario where page X has links to page Y - but in future page Y is deleted. You need page X to link to the version of page Y that existed at the time X was created. That sounds very tricky.
You may also need to parse out all the media on the page and take versions of this and then replace the originals with the new ones - and take into account media pickers as well as images / files embedded within the RTE. (Which means parsing them out, creating new versions, then replacing the Ids).
I've been thinking about something similar the last week or two - I have a requirement to take biannual archive copies of a set of pages, but want these to be separated from the 'live' versions so that changes made to the doctype don't impact old versions (ie, I might want to add/remove a property, but that shouldn't impact the archive).
I'd thought about creating a versioned doctype as part of the archiving process, but realised that would then mean archived versions of all dependencies - all views, css, scripts, controllers, media, else I wouldn't have the flexibility of modifying the doctype.
At the moment, I'm leaning towards storing a flat html file for the archived docs, which means I'm only dependent on CSS/JS/media assets, which I can version and store pretty easily.
IMO, this type of requirement should be separated entirely from Umbraco, so that changes made to the site don't inadvertently mess with the archive. Would still have issues with links, but I'm planning on removing all links that point outside the archive, so it would be a pile of static pages referencing each other...
The static HTML version is something I thought about when this was mentioned, and I think it's probably the best way of achieving this. But, as you mentioned, you'd need to strip out links and possibly images/media for it to work.
You can easily make an HTTP request to a page, get the HTML response and then use HtmlAgilityPack to return just the main content, then parse out unwanted tags.
Another, perhaps even crazier idea, would be to "screenshot" the page as a JPEG - that would preserve images but obviously wouldn't be ideal :)
Newcomer with questions
Hi.
I have a project where the client has some requirements around version control of pages and files. Specifically, they want previous versions of any given page to be available to end-users via the date. A bit like a wayback machine type of thing.
I know Umbraco keeps a version history of changes made to pages, but I don't think that's going to be sufficient as it isn't accessible for front-end users. It also doesn't keep track changes to uploaded files (I don't think?), which also need to be kept in sync.
The idea is that the page contains information that is relevant for a given period of time, and will be overwritten, but that people may still need to refer back to previous versions. So a user might enter a date, and the site would switch to how it looked on that date (but with a big disclaimer so they know it's not current info).
I'm a bit worried that this could turn out to be quite a big bit of work, but also it seems like the kind of thing that others might have needed, so does anyone know if there's any existing plugins that might help me with this?
Thanks for any tips :)
Hi Simon It seems like when you save and publish a page, you want to intercept the save event to save a version of it with a url that has the date in it, then continue with the save and publish of the changes.
I did a blog post about intercepting content changes in Umbraco.
http://www.codeshare.co.uk/blog/intercepting-content-and-member-save-events-in-umbraco/
Cheers
Paul
Hmm, your requirement could become very complex very quickly...
You are right Umbraco doesn't version media, just content. But this isn't part of published content. I think Paul's idea of using save events to create a new version is the way to go.
But you are going to have potential issues with things like embedded media and links. This is because Umbraco stores the ID of these - so if they change in the new version, they'll change in the older versions, too. And if a page or media is deleted, then any references to it will disappear. Imagine the scenario where page X has links to page Y - but in future page Y is deleted. You need page X to link to the version of page Y that existed at the time X was created. That sounds very tricky.
You may also need to parse out all the media on the page and take versions of this and then replace the originals with the new ones - and take into account media pickers as well as images / files embedded within the RTE. (Which means parsing them out, creating new versions, then replacing the Ids).
Hi guys.
Thank you both for the feedback -- there's lots to think about there.
The project isn't starting right away, so I've got time to consider it, try a few things, and work out my options.
If anything interesting comes out of it, I'll let you know. Thanks again. :)
I've been thinking about something similar the last week or two - I have a requirement to take biannual archive copies of a set of pages, but want these to be separated from the 'live' versions so that changes made to the doctype don't impact old versions (ie, I might want to add/remove a property, but that shouldn't impact the archive).
I'd thought about creating a versioned doctype as part of the archiving process, but realised that would then mean archived versions of all dependencies - all views, css, scripts, controllers, media, else I wouldn't have the flexibility of modifying the doctype.
At the moment, I'm leaning towards storing a flat html file for the archived docs, which means I'm only dependent on CSS/JS/media assets, which I can version and store pretty easily.
IMO, this type of requirement should be separated entirely from Umbraco, so that changes made to the site don't inadvertently mess with the archive. Would still have issues with links, but I'm planning on removing all links that point outside the archive, so it would be a pile of static pages referencing each other...
The static HTML version is something I thought about when this was mentioned, and I think it's probably the best way of achieving this. But, as you mentioned, you'd need to strip out links and possibly images/media for it to work.
You can easily make an HTTP request to a page, get the HTML response and then use HtmlAgilityPack to return just the main content, then parse out unwanted tags.
Another, perhaps even crazier idea, would be to "screenshot" the page as a JPEG - that would preserve images but obviously wouldn't be ideal :)
is working on a reply...