November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Hi, Mark,
This might not be the same approach you have taken, but take a look at this, it might be of use:
http://world.episerver.com/blogs/Magnus-Stalberg/Dates/2014/8/Projects-Beta/
Marija,
Thanks for that - we looked at Projects, but they don't quite do what we want. For workflow / audit reasons, our customer wants to see blocks exactly as they were when a page version was published, and when a particular page version is re-published, the blocks should be re-set to exactly as they were at that version of the page.
Projects looks like it will be great for multiple pages, but EPiServer doesn't handle blocks properly (for us, anyway), as when a block is added to a content area, it is published, and is then visible in the content area for all versions of the page.
Hi,
Our customer has a requirement that editors must be able to see blocks that are 'relevant' to a particular page version when previewing, and if they re-publish a page version, then the current blocks for the new page version should be those that were current for the page when it was originally published. Blocks are always 'for this page', rather than shared blocks, and always belong to ContentAreas on the pages.
We can achieve this requirement by comparing the Saved date for block versions with the page version's save date, and by creating new versions of blocks (picking the ones that match the original page's Saved date) when a page is re-published. However, our customer has upped the ante by requiring multiple drafts of a page to be in progress at any one time, which means that save dates for individual blocks will no longer be directly related to a particular page version.
What I'd like to be able to do is something like the following:
When a page is initially created, I set a property on the page (VersionGuid, say) to a particular value. If a block is created on this page version, then I set a corresponding property on the block to the value of the VersionGuid property on the page version. This way, I can explicitly relate the block to the page version. If a new version of the page is created, I update the VersionGuid value on the page, and clone the existing blocks in all the page's ContentAreas that match the original VersionGuid value, setting their VersionGuid values to the new value.
However, there is a big flaw: ContentAreas aren't versioned, so if I (say) edit a block in a Content Area, and capture the change in the SavingContent event, I can get the ContentAssetFolder for the block, but that ContentAssetFolder only 'points' to the page, so I can't determine which page version the block should derive it's VersionGuid value from.
Is there any way I can either get at the currently edited page version when an event is fired for a Block change, or some way of making ContentAreas versioned, so that a change in the page version results in a new Contentarea version containing blocks relevant to this partiicular page version?