When setting up a new application on a development machine you normally need to add a hosts file entry such as dev.clientname.local to point back to your local machine e.g. http://dev.clientname.local. It’s not normally a pain though it is another thing to remember/document when getting set up a new development machine. If you have several applications as part of a solution that require host file entries then it can become cumbersome.
I recently encountered an issue where EPiServer Composer appeared to be serving up old versions of pages, even after they have been published. This was identified on EPiServer CMS 6 R2 and Composer 4.
The issue was traced to a particular behaviour where editors copy/pasted a Composer page that contained global Composer blocks. After this operation the newly created page would revert back to an "old" version that contained no Composer blocks. This happened after a period of time and to compound the issue it is only noticable in view mode and not edit mode.
I was initially captivated by your flexibility, marvelled at your ability to be customised and wowed by some of your cool features like tethering and uploading my photos straight to Dropbox. I believed in you, I left iOS for you and ultimately I bought into you in the belief this could be something long lasting and solid.
I wanted to be just another consumer, like everyone else. I didn't want to bring my work home with me, debugging at 2am. I thought we would have uncomplicated fun together and it would just work. When things started going wrong I thought it was my fault, but realised the problem is not me, its you.
This post is written as a result of attempting to run an existing EPiServer CMS 6 R2 solution on new build Windows 8 machine. If you are trying to use the EPiServer 6 installer to install a new site on Windows 8 take a look at Arild Henrichsen's blog on the EPiServer 6 Powershell bug on Windows 8. However if you are having trouble running an existing EPiServer CMS 6 R2 solution on Windows 8 read on...
EPiServer 7 adds many great new features but the new edit mode is really different from "old" edit mode. Personally I think EPiServer 7 edit mode is easier for editors new to EPiServer but some seasoned editors may still be very comfortable with "old" edit mode (at least for a short while).
I was discussing this with a client and they thought that we could upgrade an EPiServer 6 R2 site to EPiServer 7 quicker than they could arrange training for all of their editors for EPiServer 7 (the client has editors in several offices across the world).
So I set out working out how to hide the new edit mode for selected editors (at least for a short period anyway).
When using EPiServer Composer in EPiServer CMS 6 R2 one of my favourite features was the personalisation container:
For those who haven't used it, it allowed editors to quickly add personalisation to a page by dragging a personalisation container onto a page, selecting some visitor groups then drag/dropping some content functions which will be displayed based on the visitor groups selected.
We now have EPiServer 7 with blocks where blocks can be used in place of Composer. If shared blocks are to be personalised then they must be personalised at a block level using access rights (Edit block > Forms editing > Visible to: "Manage"). This leaves a major headache: Blocks will be personalised for every page they are used on. This isn't the case when using the Personalisation Container and may not be appropriate for all blocks in EPiServer 7.
So I decided to try and try and bring Composer Personalisation container like functionality to EPiServer 7. This would allow editors to use a container block to show/hide blocks based on visitor group.