With SharePoint 2007 it was common to use the EditModePanel to display some content when the page is in Display mode, and perhaps output a different layout using another EditModePanel configured for Edit mode. This would often be used to change the HTML for editing purposes, for example if the edit mode required additional fields that required a variation on the layout, which could result in the same field being output in 2 places depending on the page mode.
Well for some reason that I cannot work out, and cannot seem to find out on the Internet, SharePoint 2010 has an updated EditModePanel that now checks the user’s permissions and will only show the content if the user has higher permissions than ReadOnly. That means, particularly for sites supporting anonymous access, ReadOnly users cannot see any content placed inside an EditModePanel, whether it is set for Display mode or Edit mode.
Having searched around for solutions, I came across this suggestion that seems to work fine, although it is not ideal, but is the only solution so far. The trick is to combine the EditModePanel with the AuthoringContainer.
The AuthoringContainer is somewhat similar to EditModePanel, but is configurable to display content for ReadersOnly or AuthorsOnly instead, so enabling the page to be designed to perhaps include more content for authors than for readers.
To get the original EditModePanel behaviour that we are used to from SharePoint 2007, it seems we now have to take a few extra steps. First we output content to ReadOnly users inside an AuthoringContainer which is configured with DisplayAudience=”ReadersOnly”. Note, as this is for ReadOnly users, there is no concept of an Edit mode from the perspective of ReadOnly users. Then we need to add another AuthoringContainer configured with DisplayAudience=”AuthorsOnly”. This “AuthorsOnly” container should contain two EditModePanels, one configured with PageDisplayMode=”Display” to contain a copy of the content already put in the ReadersOnly AuthoringContainer, and the other EditModePanel with PageDisplayMode=”Edit” to contain an edit version of the content. See example below.
<PublishingWebControls:AuthoringContainer runat="server" DisplayAudience="ReadersOnly"> <h1>Show content to Readers</h1> </PublishingWebControls:AuthoringContainer> <PublishingWebControls:AuthoringContainer runat="server" DisplayAudience="AuthorsOnly"> <PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Display"> <h1>Show content to Authors in Display mode</h1> </PublishingWebControls:EditModePanel> <PublishingWebControls:EditModePanel runat="server" PageDisplayMode="Edit"> <h1>Show content to Authors in Edit mode</h1> </PublishingWebControls:EditModePanel> </PublishingWebControls:AuthoringContainer>
As you can see the Display Mode content needs to be repeated for Readers and Authors, while the Edit Mode content needs only be displayed to Authors as it is not applicable to Readers. It is just a shame that Microsoft felt the need to change the EditModePanel on the quiet, forcing us to take this more convoluted approach with duplicated content.
Having worked with this approach for a while, I came across a problem with duplicating content for Readers, when it came to using the TaxonomyFieldControl that was required to be displayed to Readers as well as Authors. Using this approach meant that the TaxonomyFieldControl appeared 3 times, for Readers and Authors, as well as in Display and Edit modes. However the TaxonomyFieldControl would throw an exception when trying to view a page with it duplicated like this. It doesn’t mind being used twice in the EditModePanels, so long as it appears once for Display mode, and once for Edit mode. However it doesn’t like being used twice in the AuthoringContainer controls, once for ReadersOnly and once for AuthorsOnly. The simple solution here is that for ReadersOnly and in Display mode, we can instead just use the TextField control to output the field value, as we don’t really need to us the TaxonomyFieldControl unless in Edit mode, for AuthorsOnly.
Hope this helps!
Update Sept 15, 2011:
Service Pack 1 has updated the EditModePanel. Looking at the code it appears to now resolve this problem so read-only users can now view content in display mode, now implementing a security check to ensure it will not render if the form mode has been changed (hacked?) to edit mode. This security check would appear to be the reason for the original change without realising the consequences of not showing display mode content to read-only users. It looks like we can now use the EditModePanel in the same way we have always used it in the past so long as we are using SP1.
Update Sept 20, 2011:
I have now been able to test the EditModePanel with SP1 and can confirm that it now works properly, showing content in display mode to read-only users.
- Click to email (Opens in new window)
- Click to print (Opens in new window)
- Click to share on Twitter (Opens in new window)
- Share on Facebook (Opens in new window)
- Click to share on Reddit (Opens in new window)
- Click to share on Google+ (Opens in new window)
- Click to share on Tumblr (Opens in new window)
- Click to share on Pinterest (Opens in new window)
- SharePoint Online: Sign up for a free Office 365 Developer Site from your MSDN subscription
- SharePoint: How to check which Site Template was used to create a site just using a web browser
- SharePoint 2010: How to get the My Site Host URL or the Current User's Personal Site URL Programmatically
- SharePoint 2010: How to set Taxonomy Field Values programmatically
- SharePoint 2010: PowerShell to Clear the Timer Job Cache
- June 2015 (1)
- June 2013 (1)
- May 2013 (2)
- April 2013 (3)
- March 2013 (1)
- February 2013 (1)
- December 2012 (1)
- November 2012 (3)
- October 2012 (3)
- August 2012 (1)
- July 2012 (1)
- June 2012 (1)
- May 2012 (1)
- April 2012 (2)
- March 2012 (5)
- February 2012 (8)
- September 2011 (1)
- July 2011 (2)
- June 2011 (6)
- August 2010 (1)