In this post, I am going to describe a technique that allows end users to control multiple SharePoint pages from a central location. As the title suggests, the cornerstone is the Content Editor Web Part.
When deploying SharePoint in your organization, you’ll rely on site templates, either the OOTB ones or – most likely – your own set. At some point you’ll certainly be confronted with the following issue: how to roll out updates across multiple existing sites?
SharePoint 2007 offers various options (and btw brings significant improvements compared to SharePoint 2003). You can modify Master Pages or the CSS. You can also rely on features, a powerful option, especially interesting for customizations applied on a site by site basis.
In many cases however, you’ll find out that these options don’t work for you, for various reasons. First of all, you may not have access to these tools, for example if you are in a hosted environment, or part of a big, standardized organization. Also these are heavyweights, and they are an overkill for simple changes.
So here is an additional, lightweight method accessible to end users. It doesn’t replace all of the above, but it comes in handy and is very responsive for light adjustments.
My proposal: a Content Editor Web Part for every home
The idea is to include a remote control on your SharePoint pages. See the picture below:
In each site template, I have included a hidden CEWP at the bottom of the home page. This CEWP is linked to a file stored in a central location – CentralScript.txt – through the “Content Link” option in the CEWP menu. All users have read permissions on CentralScript.txt.
Each site based on my templates will have this CEWP. So through the scripts added to CentralScript.txt, I can remotely control the content of the home pages.
Note that site owners may not be aware of the purpose of your remote control Web Part, and could be tempted to remove it from the home page. To avoid this, you’d better find a catchy name that clearly states the purpose of the Web Part and/or states that it should not be deleted.
The above picture shows a simplified implementation with a single site collection. It can be extended to work with multiple site collections or even multiple servers.
When working on a SharePoint architecture, I usually create a central “Utilities” site. This site will host various content that is shared across teams: logos, icons, scripts, etc. All the users are given read access to this site that contains no confidential information. This is where the CentralScript.txt file resides.
This technique can also be applied to an existing environment. But in this case each site owner will have to add the CEWP manually.
Note that CentralScript.txt doesn’t have to contain scripts, you can start with an empty file. The idea is to anticipate, and to give your architecture the flexibility to accomodate future needs.
How can you share a list of links across sites? If you create a SharePoint list of links, it is not easy to share it across sites within a site collection, and it is even more challenging to share it across site collections or across servers.
Let’s see how I can achieve his using my remote control. I’ll add to CentralScript.txt a script that:
– creates a list of links
– displays it as a drop-down menu, adopting the look and feel of each SharePoint site
– positions it as a tab on the top right of each page
Here is the expected result:
If you already see a “Site Actions” menu in the top right, the cross-site menu will be added next to it:
You’ll notice that the menu adopts the theme of each site (resp. Breeze and Lacquer in the two above screenshots).
To write the script, I adapted a post I wrote last year :
How can you quickly forward breaking news to your users community? A natural way would be to display a message on top of each home page:
Well, that’s something our central script can handle. Add the following code to CentralScript.txt:
Many of the scripts published on this blog or other blogs can be injected in the page through this central control. Of course you can also include styles.
For example, you could decide to adjust the columns width on the home page, or add a toggle button to the QuickLaunch menu. You could also use this for random quotes, a shared calendar, etc.
If your design relies on jQuery plugins, you could use CentralScript.txt to reference them. Version upgrades will be far easier in this central location than if you call the plugins from each site!
I have applied this example to my demo sites. CentralScript.txt is stored in a central location, along with other utilities. This demo file includes 3 scripts: the cross-site menu, “Breaking News”, and the expand/collapse buttons. It interacts with:
– the top level home page
– the sub-sites (click on the tabs)
– a site located on a different server
Comparison with other methods
If you rely on client side scripts for your design, a centralized control will greatly facilitate the maintenance of your sites. I already mentioned the example of jQuery plugins, which need to be regularly updated.
Compared to other design methods like Master pages or CSS, the approach described here is more flexible and responsive, especially in hosted environments or if your team is part of a large organization. The changes are applied through a CEWP, which means that they are non-destructive, and can easily be rolled back (activate version history on the library where you store the CentralScript.txt). Another key advantage, it can work across multiple site collections or multiple servers.
However, this method won’t be robust enough for heavy lifting.
Also, keep in mind these two constraints:
– Customizations only apply to the pages that have the CEWP. In comparison, a Master page or CSS change would apply to all pages.
– The link to the central script is hardcoded in the template. It means that the location of the script cannot be changed easily.