Pages

Thursday, September 4, 2008

Programmatically Update Page Layouts

I updated my page layouts that I deployed as a feature, but found that I could not overwrite the Layout File. The solution was to add a new page layout and then you would have to associate the new layout with every page on your site that used it.

Obviously with a site of any size you'd have a lot of manual work to get this done, so doing it programmatically makes for a much better (and thorough) approach. After you've got your new page layouts, you could do something like this (in your event receiver class):

public override void FeatureActivated(SPFeatureReceiverProperties properties) { //replace current page layouts with new page layouts on all pages

In my case I'm reprovisioning with a new filename (you might want to do that if you are eliminating columns). If you don't want to do that then don't specify a new name for the existing file in your provisioning file. If you simply want to update/overwrite just do an stsdev -upgradesolution.

So I take it you aren't using a solution package? In the future I would definitely suggest doing that.

What you want to do is basically what I describe in the above post. You'll have to give your new file a new name and add it to the Page Layout Gallery. As long as the new page layout uses the same content type as the old page layout you can do a layout swap (either manually or using the above code). If you choose to use the above code since you didnt deploy your page as a solution/feature, you'll need to create a command line app or some other app that will execute the code.

Hi, We're using a similar approach to update our layouts.The issue we're facing is due to the fact that at the bottom of pages the name and date of last modification si displayed, but since this update process is done by the System account, all other data is overwritten during the checking and approuving of the new layout... Did you figure out something about this ?

No, we haven't had to deal with that issue, however a workaround (off the top of my head) would be to create a custom field that would track last modified date and the name of the person who did the modification and then add an event receiver that, when the item was updated, would check to see if the user was the System Account and ignore it, otherwise it would add the Name and Time to the custom field.