I have an ongoing struggle (with myself :)) about the design and implementation of parts of the SharePoint system which I'm designing. I have included a diagram below. Effectively there are multiple sites that differ only by the content.

The structure of the sites and libraries (top 2 levels are sites):


Below is the page:


As you can see the page is one that shows an individual customer's document libraries. Logically, this places the page at the level of the individual customer's site.

However, given that the page is identical and points to identical libraries (in name, column layout, etc.) I am currently storing the page at the level of the top box in the diagram. This means that when I need to make changes to the layout I do not have to do it in multiple (1500!!) places.

However it is currently also bringing the challenge that I currently have, in that I am trying to programmatically change at run time 4 web parts on a page to show views of libraries that do not exist at the top level.

As I knock one error down another pops up. My question is more a design one really. Before I spend too much time trying to squash the errors am I going about this in the best way? How would you do it? All the sites currently are built programmatically and are "Blank Site"s containing "Document Library"s. There is no data in them at the moment so it wouldn't be a killer if I had to re-do them.

Thanks in advance for your input


1 Answer 1


I would go with a site definition that would contain all the document library and pages necessary for one customer. That way, through a module, you could provision the pages and you would not have to do some funky logic that would, at load time, change the links to the library.

If you deploy all the solution via a WSP package, you have 2 options :

  1. Using a page layout and a content page based on this one (requires the publishing features to be enabled). Making changes to the page layout would update the content pages that are based on it.
  2. Using a simple webpart page. You could not make changes through the UI, but if you need a new way to present the information, you could modify the page in the solution, redeploy it, and if the associated module was not unghosted, the changes will be pushed down to every page of every sites based on the site definition.

Maybe the publishing infrastructure adds a lot of overhead for that simple requirement, so my choice would probably be #2 if you're not making a lot of changes to the base page. If you want to make frequent changes, I would go with the option #1. For both options, I think it would be a lot easier and you would gain in performance, without the need to change the document library links dynamically on the load time...

  • Thanks Sebastien Thats exactly the answer I was looking for. I will go for option 2 as changes will be infrequent. Perhaps you could clear my understranding of "ghosting". I know the type "GhostableInLibrary" means that a file will show up in a library through the UI. Does this mean that it would or wouldn't be updated with any changes to the site definition? Are there any other things I should know about ghosting?
    – Zak
    Commented Sep 22, 2012 at 11:19
  • The type GhostableInLibrary does not mean that the file will be in a library. It means that the file in the library will be a "pointer" to the real file that exists on the file system. That means that if you update the wsp package, the features folder (in the 14 hive) will be updated, so are the files that are "ghosted" in your library. Be careful, if you unghost a file (edits it) the link between the file in the library and the features folder will be lost, and your updates won't show for this file. Commented Sep 22, 2012 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.