I have been doing a lot of work recently with publishing site definitions and custom page layouts.  The current project that I am working on requires the creation of custom publishing site definitions and custom page layouts that will be wrapped up into features and deployed as solution packages (.WSP).  In this blog entry I am going to discuss some options that a SharePoint developer has when implementing a custom page layout when a publishing site is created.  Lets first start with a little background on the requirement for this project.

·         The client was requesting that there were some OOTB web parts and field controls that they would like by default on some of their web content publishing pages upon site creation. 

·         The client was also looking to have a custom page layout associated with this custom publishing site. 

·         Custom master page associated to the custom publishing site upon creation of site.

·         The final requirement was that when a new publishing site is created custom lists and a custom document library were to be created.  These lists and the document library would be utilizing custom site columns.  

Now that we had the requirements gathered we had some decisions to make as to how we were going to accomplish these requirements while minimizing the footprint left in the environment.  In the SPS 2003 days I would first look at handling this all through a custom site definition via the ONET.xml file.  In fact my first thought was to create a custom site definition with a custom ONET.xml file that creates all of the requirements above upon the provisioning of the site.  This would work out great for all new sites but what if down the line the client would like to change what custom page layout all of their sites were using quickly and efficiently?  The problem with building this functionality into the ONET.xml file which your custom site definition will use is that SharePoint only references the ONET.xml for these requirements upon site creation.  Thus, not allowing us developers to proactively change sites by re-editing the ONET.xml of our custom site definition once the sites have already been created. 

So, the best approach to the requirements above was a combination of custom site definition development and custom feature development.  At the end of the day even our custom site definitions were wrapped up into a feature so that they were easily deployable via a solutions package (.WSP) into multi-stage environments (dev,staging,prod).  In the next piece of this article I am going to go through which pieces we decided to create features for and which requirements we built directly into the custom site definition.  Unfortunately I am not going to go in-depth into the feature creation process because I was only responsible for the custom site definition requirement in this project.  Even though I consider myself a SharePoint admin/information architect/whatever I need to learn to successfully complete the job I have worked significantly with custom list and site definitions.  I guess I am just an architect stuck in a developer’s world J….. In the next part of this article I am going to talk about the decisions that my team made for the actual implementation of the requirements listed above……Stay tuned!

Cheers!