When you enable user page personalization and you have custom web parts that you are allowing your users to add to the pages, when they perform this action they might receive the following error:
Safe=”True” SafeAgainstScript=”True”
Updating page layouts is a tricky business. And because changes to how a page looks or to the content type are inevitable, at some point you will face this problem.
First of all, to be able to update page layouts, you must make sure they are ghosted. So, after creating them in SharePoint designer, you should remove the following attributes from the Page directive:
meta:webpartpageexpansion=”full” meta:progid=”SharePoint.WebPartPage.Document”
These attributes tell SharePoint that the layout has been modified in the interface and, as a result, the layout will appear as unghosted after it is deployed, even if it has never been opened with SharePoint Designer.
Second, you must make sure that everybody understands that modifying a page layout in SharePoint designer will cause it to become unghosted.
If all the conditions above are fulfilled, then a consecutive deployment of an updated page layout (through a wsp package) will be visible across site collections without any additional actions (feature reactivation, SPD manual work).
True? False.
There is one case when an untouched layout will not get updated through deployment: when the page layout inherits a content type that is instantiated in the site – more precisely when the columns of the content type are visible, editable and have been filled with data on the page instance(s).
In this case, the page layout will appear as unghosted after a page instance has been created and it will not get updated at deployment.
The solution is to reset the page layout to its site definition.
There are more than one ways of doing this, all of them detailed very nicely here. The easiest one is in the interface: Site Settings – Reset To Site Definition on the root web of a site collection.
A drawback to this approach may appear: if your page layout contains web parts that are added to the page when it is created, then resetting to site definition will cause the pages that inherit that layout to have 2 instances of that web part. That happens because SharePoint does what you would have to do manually when it resets to site definition, if resetting to site definition option would not exist:
- it detaches the page from its layout
- it copies the new layout content over the old layout, making it unghosted (identical to the SharePoint root version)
- and then it attaches the page back to its layout and, as a result, reapplies the layout to the page
Among the new features coming with SharePoint 2010, the support for a new event called WebProvisioned can prove useful to a Master Page functionality.
While in SharePoint 2007 we had to resort to feature stapling to get a master page applied to newly created subsites, in SharePoint 2010 we can use this new event handler as an alternative.
In your Master Page project, add an Event Receiver for the Web Provisioned event. Indide the WebProvisioned method write the code that will activate the master page feature.
To save yourself the trouble, activate the Master Page Feature from code, instead of modifying the properties of the SPWeb object. Personally, I always thought that it is better to give the user the possibility to see that the Master Page feature is active and to deactivate it if needed, instead of changing the MasterPageUrl and CustomMasterPageUrl from code and presenting the user with the skinned site but with no option of disabling this feature.
This can, of course, be used for other other types of functionality not just applying a master page.
Problem: You are editing a SharePoint (2010) page that you created based on a custom page layout. You save it and then the page is not displayed in Read mode, but still in Edit mode. Even more weird, you can only see the fields that are supposed to show in the Read mode, but they are still in Edit mode.
Solution: search on your layout for a control that has ControlMode=”Edit” and is not wrapped by an Edit Mode panel.
One of the great secrets of being a good developer is reading the books. Books written by developer or architects and targeted for developers, not power users/admins/or others.
Technology is moving very fast today, from all points of view. New phone operating systems every year, new Windows updates every week, new SharePoint version every 2 years 
Long gone are the days when you could get by just with reading an article and then creating an ASP .NET project in Visual Studio that, with a little bit of luck, would compile and be up and running in 10 minutes.
Reading books written by the Gurus you see at conferences and featured on the MSDN site is what makes you a professional. And don’t forget – books addressed to you and to the position you are aming to.
This being said, I was very happy to see the Microsoft SharePoint 2010: Customizing My Site book launched at Microsoft Press. My Sites’ importance has been growing fast in the last couple of years. With the current requirements for functionality of the sort, with the SharePoint 2010 My Site capabilities, with a good book/guide and, why not, previous experience in My Site customization, I see nothing but blue skies ahead.
Theoretically there are 2 ways of editing a SharePoint publishing page: edit it in the browser or edit its page layout. Last week I was faced with the issue of retrieving a page content and the markup of its . So how could I do that if, when I tried editing the page in SPD it told me to either edit in the browser or edit the page layout?
In SharePoint Server (2010 in my case) you have the option of detaching a page from its layout. What this does is copy the content of the page into the page and breaking its connection to the layout. In my case, I only needed to look at the page’s content, not modify it.
So what I did was:
1. In SPD, I created a copy on the page into the same folder (Pages)
2. I detached the copy from the layout (right click on the page name – Detach from layout)
3. I then opened the page in Edit mode and Voila! – I no longer got the message that it could not be edited in SPD.
There is always the option of reattaching the page to the layout, so you can go with that option instead of copying the page.
