Saturday 28 April 2007

Deploying master pages and page layouts as a feature

This is the fourth article in my series of how to create common SharePoint site artifacts as features. Last time we looked at deploying content types as a feature.

Now that we have content types and all the supporting artifacts deployed, we can focus on deploying the things that make a real difference to how our site works - master pages and page layouts. I'll also cover web part deployment in a forthcoming post.

The basic premise is:-

  • develop master pages/layouts using SharePoint Designer (SPD)
  • save each file to the filesystem (as opposed to the Master Page Gallery) ready to be added to a feature. Unfortunately, SPD will actually screw up hyperlinks and some control references when you do this - in particular references to user controls using the '~/_controltemplates/' path. The best solution is to copy the contents of the final file into notepad, and save the file to the filesystem with the same name.
  • create the feature.xml and element manifest file for the feature. An example of an elements manifest file to deploy 2 master pages and 3 page layouts is shown at the end of this post.

Let's talk through the values used in the example below. At the module level (collection of files to deploy to a particular location in SharePoint), we specify the URL and whether the files should only be deployed to the root web or to all webs in the site collection. At the file level, attributes for the master pages are fairly simple:-

  • 'IgnoreIfAlreadyExists' - should be true if we want to overwrite an existing file of this name, false if not.
  • 'Type' - should be 'GhostableInLibrary' for files which exist in a document library such as the Pages, Style Library or Master Page Gallery libraries which exist in a SharePoint publishing site.

For the page layouts, things are slightly more complex. Here, we need to specify the following:-
  • 'ContentType' - specifies whether the file is a page layout or master page. Use the value '$Resources:cmscore,contenttype_pagelayout_name;' to specify SharePoint's internal string which represents the page layout option.
  • 'PublishingPreviewImage' - path to URL accessible image file to be displayed when this layout is selected in the listbox when creating a page.
  • 'PublishingAssociatedContentType' - this is where we specify which content type the layout should be associated with. This means the layout will automatically have this binding and will be ready for use. Note that if this value is omitted, by default your layout will be associated with the basic 'Page' content type from the publishing feature. This means any custom columns you have added will not be available. The value for this property should be in form ';#<Content type name>;#<Content type ID;#>. So a real example would be ';#Welcome Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#'.


Another interesting facet of deploying files to SharePoint in this way, is that it's not possible (AFAIK) to update a file deployed from feature 'A' by a separate feature 'B'. This makes sense but gets in the way if you want to update a common file like itemStyle.xsl (used by the Content Query web part) using a feature. This won't work since the file was originally provisioned by the PublishingResources feature, not your custom feature.

I've also seen problems updating page layouts which were associated with content types created through the UI rather than by a feature.

So now that we have our lists, site columns, content types and master pages/page layouts deployed, we can create pages using the layouts and add content to the site.

Next time I'll talk about options around deploying web parts.

Here's the XML sample mentioned earlier:-

<?xml version="1.0" encoding="utf-8"?>
<elements xmlns="http://schemas.microsoft.com/sharepoint/">
<module name="MasterPagesModule" url="_catalogs/masterpage" rootwebonly="True" path="">
<file url="cScape.master" ignoreifalreadyexists="TRUE" type="GhostableInLibrary"></file>
<file url="accessible.master" ignoreifalreadyexists="TRUE" type="GhostableInLibrary"></file>
</module>
<module name="PageLayoutsModule" url="_catalogs/masterpage" rootwebonly="True" path="">
<file url="AdvancedSearchLayout.aspx" ignoreifalreadyexists="TRUE" type="GhostableInLibrary">
<property name="ContentType" value="$Resources:cmscore,contenttype_pagelayout_name;"></property>
<property name="PublishingPreviewImage" value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png"></property>
<property name="PublishingAssociatedContentType" value=";#Welcome Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4;#"></property>
</file>
<file url="HelplineHomeLayout.aspx" ignoreifalreadyexists="TRUE" type="GhostableInLibrary">
<property name="ContentType" value="$Resources:cmscore,contenttype_pagelayout_name;"></property>
<property name="PublishingPreviewImage" value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png"></property>
<property name="PublishingAssociatedContentType" value=";#RNIB Welcome;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4007AC2318FCE0E474eADE554A22E4B6135;#"></property>
</file>
<file url="HomePage.aspx" ignoreifalreadyexists="TRUE" type="GhostableInLibrary">
<property name="ContentType" value="$Resources:cmscore,contenttype_pagelayout_name;"></property>
<property name="PublishingPreviewImage" value="~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png, ~SiteCollection/_catalogs/masterpage/$Resources:core,Culture;/Preview Images/ArticleLinks.png"></property>
<property name="PublishingAssociatedContentType" value=";#RNIB Welcome;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390064DEA0F50FC8C147B0B6EA0636C4A7D4007AC2318FCE0E474eADE554A22E4B6135;#"></property>
</file>
</elements>

75 comments:

Anonymous said...

I am having problems with the following.

Property Name="PublishingAssociatedContentType"
Value=";#News Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3903;#"

When I use it on my Page Layout in sharepoint in the Master Page Gallery under the Associated Contnet Type instead of me seeing Home Page (like default shows Welcome Page) I see the ugly string of Home Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3903

Any ideas why this would be?

Thanks for you help

Chris O'Brien said...

Are you sure the content type ID is correct (for your content type) in the value string?

What happens when you go to create a page based on your layout? Can you select it from the available layouts or does it show "(Invalid content type)" in the selection box?

Anonymous said...

This problem was fixed.

Sometimes regardless of whether I deactivate, uninstall, and reset IIS installing a feature with changes do not take place.

AS IN, it continues to have attributes based on the last install of that feature.

Have you experienced this? Any solution? Only solution I found was to create a brand new site collection (not ideal at all but the feature always works as new).

On a side note. Master Pages that are ghostableinlibrary if changed on the disk are reflected straight away. CSS in the style library although ghostableinlibrary do not care if the file exists on disk. Why is this? Doesn't ghostableinlibrary apply to style library?

Chris O'Brien said...

Yes, I have occasionally seen issues where files fail to update when a feature is updated. I think my issue was caused by a page layout not being properly associated with a content type (as per the first comment on this post). Assuming this is OK, your files should update fine though.

In terms of the GhostableInLibrary setting, this applies to any file in SharePoint which has an entry in a document library but also exists on the filesystem. Hence this can apply to master pages as well as files in the Style Library.

The reason I think you're seeing a difference is due to the ghosted/unghosted (customized/uncustomized) concept of files in SharePoint. The files you are changing in the Style Library have already been customized, and have therefore been copied into the database. Therefore, amending the copy on the filesystem will not change anything in SharePoint.

In general, you should be careful when modifying core SharePoint files on the filesystem. This can potentially break things and is typically unsupported. Modifying a file in the database is obviously fine though.

Christopher Bermingham said...

In your experience, will re-installing the feature with the force option re-install/overwrite the master page for sites that are already using the feature?

Chris O'Brien said...

Christopher,

Yes it will if the master page is still being referenced from the filesystem (has not been customized).

I've just posted more information on this - see Considerations when using Features to deploy SharePoint files - ghosting/unghosting

HTH,

C.

Thomas M. Turner said...

Chris,

I am a site administrator and my main page has been affected by a parent master page layout (theme). It looks as if there are two themes in one... The master is showing at the top and side, and mine is in the middle were the web parts are. I realize this issue may be simple compared to the detail in your post, but any help removing or disconnecting the master layout would be helpful. We just launched SPS2007 and the main guy has not figured out how to fix it...

Mark

Chris O'Brien said...

Thomas,

It is possible to nest master pages so maybe your developer has done that. If the either of the master pages you are using have a value like @MasterPage="someOther.master" in the @Master directive at the top of the page, this could be the case.

Otherwise, what happens when you change the master page for the site on the 'change master page' settings page (/_layouts/ChangeSiteMasterPage.aspx)?

Thomas M. Turner said...

Chris,

Thanks... He gets back on Monday and I plan on seeing him about the Master Page settings. I do not have access, but he does. Thanks for the quick response...

Mark

Anonymous said...

I'm wondering: I'm deploying a content type, three site columns, a master page and 3 page layouts via a feature. The page layouts are associated with the content type I am deploying. Shouldn't the page layout appear in the drop-downlist with the new content type in parenthesis, like Article Page, instead of just Page, which is what it is doing? The new content type is available in the drop down in Edit Properties for the document, but it would make more sense to me that they start out as the proper content type.

Does order matter in the provisioning process? When using the
PublishingAssociatedContentType attribute, should you specify just the GUID of the content type or the whole parent/child GUID combination? Anything else I'm missing?

Chris O'Brien said...

Hi Colin,

You need to make sure you have the format of the content type value for the PublishingAssociatedContentType element exactly right, otherwise it will fall back to the default behaviour of associating your page layout with 'Page'.

So the format should be as discussed in the bullet point for 'PublishingAssociatedContentType' in this article.

Is this what you have, or just the content type ID on it's own?

Anonymous said...

Chris -

Here is the property element for one of my page layouts:

Property Name="PublishingAssociatedContentType" Value=";#Trading Post;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF390016611AA92AAE4F4BA3A28A1CC4C75A3A;#"

I have been playing around a lot with the feature, including the content type; I'm wondering if I had a bad value at some point and SharePoint is just remembering it, despite my both upgrading and deleting/readding the solution?

Chris O'Brien said...

Colin,

The value you have looks good. However you could be right in that a old configuration is still present - don't forget that if the content type is in use somewhere it won't be removed when upgrade or redeploy the Solution.

Couple of things to try:

- can you manually associate the page layout with the new content type (i.e. through the UI)? You should also create a page based on the layout to test fully. If not, the issue could be with markup for the content type

- what happens when you test deploying Solution/Feature against a fresh site collection. Does this succeed?

Anonymous said...

Chris -

Thanks! There is just too much stuff in SharePoint for one person to keep track of.

I activated the feature on a clean site collection, and that worked fine.

I manually associated the page layouts with the new content type on the original site collection, and that worked.

I then upgraded the solution to make sure the manual changes stuck, and they did. Looks like I'm good to go.

One of the things I noted was that after deploying the feature, I had to go through and manually add the content type to the various page libraries. Is there a way to add content types to existing libraries with the xml features, or is that where you need to write a custom receiver?

Thanks for the help!

Chris O'Brien said...

Colin,

No problem, good to hear you got sorted.

And yes, the association between a content type and an existing list/library can be done using the feature CAML schema - no need to use a feature receiver. Strangely enough, someone else asked the same question today over on another post.

The element you need to use is 'ContentTypeBinding'. The documentation for this element is at

http://msdn2.microsoft.com/en-US/library/aa543152.aspx
.

HTH,

Chris.

Anonymous said...

OK, so can I use this to, say, have the content type always bind to the Pages library whenever a site is created where this feature is deployed? The example Microsoft gives isn't very definitive...

Chris O'Brien said...

Colin,

Typically you don't need to associate custom content types with the 'Pages' library, since by default it already has the 'Page' content type bound to it, and normally items in here will either by of content type 'Page' or a child content type. Hence these will be fine.

However, if you are storing some other content type in 'Pages', then yes you'll need to set the binding, either manually or through the 'ContentTypeBinding' element in a feature.

Most typically, 'ContentTypeBinding' is used to bind a custom content type such as 'MyCompanyExpenseClaim' to a custom document library such as 'Expense claims'.

Hope that makes sense!

Chris.

Anonymous said...

Great article Chris!

I am adding a custom page layout and I want a friendly name to show up in the Page Layout list, so I added the following two properties to the Elements xml:
File Url="MySearchLayout.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary"
Property Name="Title" Value="Custom Search Center"
Property Name="MasterPageDescription" Value="This page layout contains a search box Web Part. It has a single header Web Part zone."

I have uninstalled the feature and re-installed many times but no matter what I do the page always shows up as "MySearchLayout.aspx" in the Page Layout list. And the description never appears.

What do I need to do to get this to work?

Thanks in advance
Kevan

Sundher said...

Hi,

I have created a custom page layout and associated a content type with it. I created pages based on that layout using a console application. Later I updated the layout page in SPD with some web parts and my pages are not updated. How can I update the pages that are created from layout page when layout page is updated.

Chris O'Brien said...

Sundher,

If you are making the updates using SPD there shouldn't be any problems. If you deployed the page layouts as a feature, making later amends with SPD will mean that the layout becomes customized (a blue blob should show next to it in SPD) and will therefore be stored in the database. However, updates via SPD should still be fine.

Are you sure the layout has been checked-in/approved?

Thanks,

Chris.

Anonymous said...

Hi Chris,

I used this method to deploy a custom master page with style sheets and images to multiple site collections. All of the images and style sheets have custom names.

Intermittently it appears as if SharePoint will lose the location or lose access to the style sheets and/or the images. I say this because when browsing to the site the content will be there but the images and or the style applied are not. All of the content will be collapsed to one side and the images are missing. I have been able to temporarily fix the problem by clearing the cache and resetting IIS on the front end but it keeps coming back.


I am not 100% sure if using a feature is the reason this is happening but this was the only thing done differently. Do you have any idea why this might be happening or have you seen it before?

Thank you for any advice and for the article,

J

Chris O'Brien said...

J,

Sorry I've not seen this one! I'm pretty sure it won't be because the files were deployed as a Feature though - that said, bear in mind if you don't update the files through the UI or SPD, they will still be loaded from the filesystem rather than the database. See my article on Considerations when using Features to deploy SharePoint files - ghosting/unghosting for more details.

Is it definitely server-side caching which is causing the problem?

Chris.

Anonymous said...

Hi Chris,

So far they are no longer experiencing this issue. It turns out that some of the permissions on the custom feature folder were not set correctly. This must have happened when I was moving the files around. I set them at one point but forgot to reset them after making changes.

What I don't understand is if it was a permissions issue, why would the problem go away after the cache was cleared. A friend of mine also tried to clear the cache and it did not work for him. But it did work the first three times the issue appeared. I also don't understand how a permissions issue could cause this problem because I would think a problem with permissions would be consistent.

Either way inheriting the permissions from the features folder has solved the problems.

Thanks for your help.

J

Chris O'Brien said...

J,

Actually I have seen this before now I think about it more. I'm guessing you're working directly in the Features directory and creating a subfolder there for each new Feature. In this case, yes the permissions won't be inherited automatically.

One way around this is to initially create the Feature files in another location, and copy the folder into the real 12\Template\Features folder as a later step. This will then carry over the permissions.

Similarly, if you are using Solution packages (.wsp) to deploy your Features as I do, you won't run into the permissions issue. See my post on Building and deploying SharePoint Solution packages for more details on this.

HTH,

Chris.

Anonymous said...

Guys help!

I have created a page layout with an Article content type, published and approved it. But when i try to create a new page, there no my layout in the list to choose.
Can someone help with this?

Chris O'Brien said...

Hi,

Is the page layout definitely associated with the content type?

Otherwise does the site restrict which page layouts can be used (either from the site definition or from site settings)?

Cheers,

Chris.

Anonymous said...

Hi Chris,

I have using this method to deploy a custom master page to my sites, it works great.

However I had a question, when the feature get deployed to a new created site, does the master page file get copied from the /1033/template/feature/myfeature/ folder to the SharePoint masterpage gallery?
if so, when I update the master page in the furture, I need to update the master page file in each Sharepoint MasterPage gallery? (assuming I have multiple portal or top level site in my envrionment)

John

chunzales said...

This article is extremely useful. You should categorize it under "Deployment" as well.

Chris O'Brien said...

John,

Yes, the 'module' instruction in the Feature's elements file will put an entry in the master page gallery which references the file. Note this reference may be to the original file under the Features folder, or to a copy of the file in the database if it has been subsequently customized (e.g. using SharePoint Designer). See my post on Considerations when using Features to deploy SharePoint files - ghosting/unghosting for more details.

I generally work more with publishing sites, but I think if you change the 'RootWebOnly' value to false, an entry for the file would added to each master page gallery within the scope of the Feature (e.g. Site or Web).

HTH,

Chris.

Anonymous said...

Can you help!!
I'm creating a page layout with multiple Page contents "RichHTMFields". The problem I'm having is when testing I entered data into one of the Page Content and at shows in all of them (which is 4).

I have checked to make sure the fields were named differently in the HTML and they are. I have tried recreating the layout and still get the same result.

I don't know what else to do or is it not possible to have more than one Page Content on a page.

Thanks,
Vonnie

Chris O'Brien said...

Hi Vonnie,

You need to make sure the content type you have bound the page layout to has a column for each content field. When designing the page layout in SPD you should have an item in the toolbox (under 'Content Fields' section) for each field. Dragging these on to the design surface should result in the appropriate SharePoint web control being added to the markup with the 'FieldName' attribute set to the column name. This is what binds the control to the data.

You should therefore have 4 controls each with a different FieldName. If not, I'd say you don't have the columns defined properly in the underlying content type.

HTH,

Chris.

Anonymous said...

Thanks Chris!! I'm new at this so I really appreciate your quick response and help. I understand the content types now.

Keep up the good work. It's nice to know I can get answers.

Thanks Again,
Vonnie

Anonymous said...

Chris,
Do you know how to associate a preview image for the master page from the site definition so that a custom preview image shows up when you go to the master selection page?

Thanks
-Pritam

Anonymous said...

Hi Chris,
It's me again. Is it true that you can only have 2 users with Designers permission?

Thanks,
Vonnie

Chris O'Brien said...

Hi Vonnie,

That's a new one on me. What makes you think that might be the case?

Chris.

Anonymous said...

I'm sorry, I didn't make myself clear yesterday. (brain dead)

Is there a setting somewhere for Central Administration to have more than 2 Site Collection Administrators? Right now we can only have a primary and secondary

We we would like to add a third person.

Thanks,
Vonnie

Chris O'Brien said...

Ah gotcha.

No, it's possible to add multiple site collection admins from the 'Site collection administrators' page in the site settings area - '/_layouts/mngsiteadmin.aspx'.

As far as I know there's no limit.

Cheers,

Chris.

Anonymous said...

If you add them this way can they create layouts and Master Pages?

Vonnie

Chris O'Brien said...

No I think you'd also need to grant them specific permissions in the web. I always forget this one, but I'm pretty sure the intention behind the site collection administrator role is not necessarily the same as 'being able to do everything in the sites'.

C.

Chris O'Brien said...

-Pritam,

Yes you should be able to do with the 'PublishingPreviewImage' property element of the file.

HTH,

Chris.

Anonymous said...

Hi Chris,

Thanks for this wonderful log, I'm having problems with page layouts and web parts that disappear, we're using MOSS 2007 and this is the second time its happened, and now the web parts are missing from the main site as well, and ideas you can throw my way?

Thanks In Advance
Patrick Lanning

Chris O'Brien said...

Hi Patrick,

I'm wondering, are your web parts inserted into the page layout directly or in web part zones? If they're in zones, remember that the web part definition (config) does not go into the page markup, but is handled separately by the web part framework. This means that copying/deploying the page layout will not carry over the web parts.

Is that the case maybe?

Chris.

Anonymous said...

Hi Patrick, hi Chris,

I've also got some problems with disappering Webparts. I've got an aspx-File with several webparts declared on it. The webparts are connected with each other. This is all declared in the aspx-File.
When I activate the feature the aspx File is copied on my Site. But when I try to open the page some Webparts disappear, some are still on the page.
The webparts are all installed, I can place all webparts on another page manually.
I'm wondering what does happen while activating the feature? Are there some kinds of validations while the activating the feature? Maybe the webparts are throwing exceptions while activating and Sharepoint deletes them? Or maybe the webpart-connection failure and Sharepoint deletes the involved webparts?

Maybe you've got some hints for me?
Bye
Christian

Anonymous said...

Chris-

Great post! I've got a custom content type that inherits from Article Page and a custom layout that uses my new content type. I'm trying to deploy all of this in a site definition and calling the features (site columns, content type, content type binding) in there. For whatever reason, my site definition isn't firing my feature with the resources I need. I can activate it manually just fine (yes, the GUID is correct :-) ).
It looks like I'm doing everything correctly -- ever run into anything like this?

-John

Anonymous said...

I have a document in the Site Collection Document Library and want the content to show up on other sites since it is our Mission statement and IT Vision.

I know a few different ways to link to it but I would like for it to display on the pages.

I have read and heard that you can put documents at your top-level site and then populate them into other sites so you only have to update one document.

But I have not found a way to do this. I'm I asking to much? I'm goggled out today!!

Thanks
Vonnie

Unknown said...

Hi Chris,

I have the same problem as Kevan but unfortunatly it was left unanswered. I created a page layout using features, after I discovered that it was taking the ".aspx" as a title for the authoring user I simply wanted it to change to something friendly. I added a property title as a child to the file definition. After doing lots of deactivating/activating/uninstalling/installing and iis resetting it still show the aspx title.When I deploy it under a new site collection the title does show up as I want. Do you have any solution for that? Everything is left unghosted.

Thanks it advance,

Marcel

Chris O'Brien said...

John,

First off, apologies for the big delay in replying, I've been away on holiday.

Do you mean you're trying to get the Feature to activate automatically when new sites are provisioned from your definition? Or are you activating the Feature separately on the created site(s)? If it's the former, you need to ensure either the definition's onet.xml file has an entry for the Feature in either 'WebFeatures' or 'SiteFeatures', or you need to staple the Feature to the definition (this is the approach to use if the definition is already in use).

HTH,

Chris.

Chris O'Brien said...

Vonnie,

Again, sorry for the delay in replying (holiday).

If I follow you correctly, it's possible to do what you want using the 'Send to other location' option in the context menu for an item. The document which is copied remains linked to the original, and it will receive the updates unless it is unlinked.

HTH,

Chris.

Chris O'Brien said...

@Marcel,

Oops you're right, I hadn't answered Kevan's post. Maybe this will answer both. Basically I think the problem you're having is that the file has already been provisioned, and so the feature framework effectively ignores your 'File' instruction on subsequent activations.

You say it works against a fresh site collection. What happens if you delete the file and then reactivate the feature?

HTH,

Chris.

Bertrick said...

I want to come back to the problem of Christian of 12 september of the loss of web parts in Page Layouts.

We have created a Pagelayout called MyPageLayout.aspx which had one RichHtml control and one webpart zone with a dataview webpart presenting a custom list view.

Based on that PageLayout we created Page1.aspx

Then we changed the PageLaout. We added another webpartzone with a second webpart. Also a Dataview webpart presenting a custom list.

Based on the updated PageLayout we created Page2.aspx. Page2.aspx now has 2 webpartzones with webparts.

Now Page1.aspx stays the same. The second webpart zone is doesn't show up. We see no possiblity to upgrade Page1.aspx with the new upgarded Pagelayout.

Is it possible to upgrade the Page1.aspx with the new upgraded PageLayout ? Or am I missing the concept behind PageLayouts ?

Bertrick said...

I want to come back to the problem of Christian of 12 september of the loss of web parts in Page Layouts.

We have created a Publishing portal and we have changed an existing PageLayout called WelcomeLinks.aspx so it included 2 webpart zones with standard webparts we would like to have on each default.aspx page.

When we say in the site actions menu create site, a new subsite is created. The default.aspx page is based on the WelcomeLinks.aspx Pagelayout.

So we would have expected to see the 2 webpart zones with standard webparts. But no. The webparts do not show up.

When we go the sharepoint designer and open the default.aspx file we can say detach from pageLayout and insert webpart zones with web parts and then reattach the default.aspx file to the PageLayout. We now have them.

But we want to have them right away via the PageLayout. And not via the detach trick. We have 100 subsites to go through.

Is it possible to change the PageLayout WelcomeLinks.aspx so it includes 2 webpart zones with standard webparts so each default.aspx page of our subsite had them ?.

And why do the webparts don't show up ?

Anonymous said...

Chris -

Like many others, I'm having trouble getting the feature to upgrade successfully; basically, it refuses to update files that are being used.

Just on a whim, I decided to manually check out the documents in the gallery prior to running the feature bat file (it does the retract/delete/add/deploy routine). The files then were successfully updated, though I had to go in and manually check them back in.

Am I missing something in my solution files that would handle this? I haven't touched the site with Designer, so I don't believe it's a case of unghosted files.

Thanks!

Anonymous said...

Chris -

OK, I read the "considerations" article and it would appear that my custom files have become unghosted at some point, though they do not show as such through Designer. Is there another way to tell if the file has been unghosted, besides just not seeing the changes?

Actually, with the site I'm working with, I never get the unghosted icon; I just tested by checking out then checking in a document and nothing. Are publishing sites different in some way?

Anonymous said...

Chris....I had a wierd scenario play out with this. I have the page layout coming out right (I think) However, i also have 3 site templates (stp) created from a set of sites on say (FarmA). In my wsp I install the content types, the page layouts and master pages then load the stp files into the _catalogs/wt folder in FarmB.In the site template (stp) there is a page (Home.aspx) that uses one of the page_layouts installed with the WSP. All installs correctly (it seems) but when I started double checking, if you attempt to open Home.aspx in Designer, it of course informs you that you canonly modify the page_layout in designer, and whenI click OK it proceed to FarmA to try to edit that page_layout.
So it seems the STP kept the hard coded full URl to the FarmA pagelayout and did not keep a relative link to it.
Any thoughts on how to get around that? If you have seen it, can reproduce?

Unknown said...

Hi Chris,

sorry for the late reaction. Yes, I already tried to delete the file and reactivate the feature. Due to deadlines I skipped the "providing page layouts by features". When this project is finished I hope I have some time to reinvestigate this problem. If I solve it myself you will be the first to know.

Thanks for all the effort you put in to this question.

Kind regards,
Marcel Siepel

Chris O'Brien said...

@Collin/Deelpunt/others having difficulty seeing files get updated:

I've replied to these comments in an article at Master pages/page layouts deployed as a Feature not updating.

Cheers,

Chris.

Chris O'Brien said...

@Gouranga,

I've not seen that I'm afraid. It sounds like something isn't quite happening right with gathering the dependencies for the site export. Is it a publishing site? Remember that publishing sites aren't really supported with site templates, so that could be the issue if so?

HTH,

Chris.

Anonymous said...

Hi guys,
I'm trying to find a way to pull reusable content from one site to another. Can you help?

Thanks Vonnie

Anonymous said...

Hi Chris,

to follow up on Marcel and Kevan's issues, we have the same issue here.

If we undeploy the feature, delete the file, and we redeploy the feature, the properties such as title get updated on a file such as a master page or page layout.

Now I understand that if we try to reactivate a file that was already provisionned, the properties won't update. That is however not viable since we may have to change those properties at a later point in time and if content pages are created from those page layouts, you can't just delete them. Is this a by design feature that has no override flags to it?

This is causing us quite a bit of hassle since we can't delete those files anymore and don't want to end up with those files in the database because we have to do those changes manually.

Thanks in advance for your input!

Vincent

Chris O'Brien said...

Hi Vincent,

I'd need do some more testing to see the effects on list item values etc. However, one thing I would say now is remember that you should be safe to modify the list item itself (e.g. title etc.) through the browser - this will not cause the file to be customized (and be placed into the database), since you are not touching the file itself.

HTH,

Chris.

Sam Langdon said...

Any ideas if there are tools out there to automatically package content types, master pages & layouts in an existing Sharepoint site into a feature? I've got a site with quite a lot of items in and it seems like a pretty laborious process copying & pasting all the pages & describing everything manually in an xml file.

Thanks in advance.

Chris O'Brien said...

@slangdon21,

What you've just described is what the Solution Generator element in VSeWSS is intended to do - it's worth checking out as it may well get you well on the way, but it's not perfect.

Other than that AC has some custom STSADM commands to generate the XML from your site columns and content types so you might find these useful.

Remember also that Features aren't the only way to deploy your artifacts. Several factors could go into the decision, but see
STSADM export, Content Deployment, Content Migration API, Features/Solutions - deployment options compared
for some options.

HTH,

Chris.

Sam Langdon said...

Thanks very much for the advice Chris. I've also stumbled across your SharePoint Content Deployment Wizard, which looks like it may do the job, as really all we're doing is exporting the contents of our masterpage gallery & it looks like this pulls through the related content types too. If I ever bump into you in a pub, I owe you a pint!

Chris O'Brien said...

@slangdon21,

Yes, the Content Deployment Wizard will take across the dependent content types for your master pages/page layouts etc.

Hope you find it useful.

Cheers,

Chris.

Anonymous said...

Hi Chris,
Am using the AllUsersWebPart
tag in element manifest to add a CQWP by default and it gives the error as shown below. However if I use any other web part it works ok.

Have you encountered such error?
Would appreciate your advice.

Thanks,
Mo
------ Error message below ------


No parameterless constructor defined for this object. at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle& ctor, Boolean& bNeedSecurityCheck)
at System.RuntimeType.CreateInstanceSlow...

Chris O'Brien said...

@Mo,

Sorry, afraid I've not seen this error. A parameter-less constructor is required in deserialization, and I could believe this occurs in the process of adding web parts from a Feature.

But I can't think why you're seeing this with CQWP - I've certainly done it with no problems in the past. I've uploaded an Elements file which contains the settings I used so you can compare it with yours - see http://sharepointchris.googlepages.com/Module.xml.

HTH,

Chris.

Rod said...

Hi Chris

Could you upload a sample of this piece of work for us

REgards

Rodolfo

Chris O'Brien said...

Hi Rodolfo,

The key thing is really the XML shown above. What exactly are you looking for?

Thanks,

Chris.

Neamat said...

Hello Chris,

I hope you can help me because I've been trying to provision a master page with its images and CSS styles and I've been trying for three weeks now and I still can't make it work except in a test machine. I followed your post at the end and I'm getting this error after feature activation "403 Forbidden" in the website although the activation is done successfully. When I deactivate the feature and use the files that already uploaded after the activation, everything works fine but once for any reason an IISRESET is performed, I lose all the CSS that is applied to the master page and I also lose my images!.

Please Help.. If you need more information please also let me know.

Neamat said...

This is me again.. I was able to figure out the problem I guess :) . The problem was related to the permissions of the feature folder. I inherited the folder permissions and it worked. I hope this is not temporary work as it did before but I tried to perform an IISReset and it worked after that and cleaned my cache to be sure that it's working and it did. So if anything else happens i think i'm gonna send to you a comment :) . Thanks

Chris O'Brien said...

@Neamat,

Glad to hear you got sorted, well done!

Chris.

Dan Blaker said...

You forgot the close tag in the second "Module" element!

Chris O'Brien said...

Oops, thanks Dan!

Shereen Qumsieh said...

Hi Chris,

Very helpful post, I've been looking through your xml file, but what i can't seem to understand is how you would add a document library or a links list to a page layout, so anytime a user users that page layout, those web parts appear by default? I can can add my own custom web parts fine and even the out of the box web parts like the image web part, but i'm not sure how to add any web parts from the Lists & Libraries section.

Is that why you use the content by query web part? is that the only way to add that content to a page?

Chris O'Brien said...

@Shereen,

The typical way to do this is to use the AllUsersWebPart element to provision the web parts you need when a page is created based on the layout. In general terms content either has to be part of the template (master page/page layout) or in a web part or field on the page.

Hope that helps,

Chris.