Managing application specific configuration is mostly done within an application page (aka layouts page). Navigating to these pages is done via custom actions, which adds links to for example the Site Settings page. The challenge starts when the number of application pages grows. Do you keep adding them to the Site Settings page? Do you show them on all Site Settings pages in the web application of every web?
What you need is a centralized administration, like the Central Administration, controlling your application configuration. The Central Administration in SharePoint has two sorts of pages. The homepage (default.aspx) providing an overview and pages like Application Management showing a collection of links related to Application Management.
It’s easy to build your own custom administration site. The image below shows my own administration site. Do you see the resemblance?
Creating these pages is pretty straightforward when using the FeatureLinkSections class together with “LinkSectionLevel1.ascx” and “LinkSectionLevel2.ascx” controls. This web control handles the rendering of the links based on enabled features in the current context. The links are provisioned by custom actions as part of a (enabled) feature.
The Location attribute is an unique identifier indicating the location where links are provisioned. The location is used in the custom action XML (shown below) to point to the location in the FeatureLinkSections control.
<!-- Admin Page - Security -->
The FeatureLinkSections control uses two views controlled by the LinkSectionControl attribute.
Shows a 48×48 icon for the group and links are placed below each other.
Shows a 32×32 icon for the group and links are delimited by the “|” character.
Visual Studio solution
I included the Visual Studio project containing the following components:
- AdminPages_Web feature: Web scoped feature with event receiver updating the welcome page and quicklaunch. The feature contains the following components:
- AdminPage module
- AdminPageActions custom actions
- PBWebTemplate element
- Event receiver
- AdminSite_Site feature: Site collection scoped feature containing the web template for creating the web. The feature contains the following components:
- AdminWebTemplate web template
- AdminPageActions custom actions: All custom actions containing all links displayed in the central adminstration.
- AdminPages module: Provisions the adminpage.aspx and security.aspx pages in the web root folder.
- AdminWebTemplate web template: Contains the web template for creating the web.
- PBWebTemplate element: Property bag element with unique web template id
You can download the WSP package and source code at http://sp2010admin.codeplex.com/.
Posted by Bram de Jager on September 30, 2011
When working with the post of Andrew Connell I faced some challenges with implementing my solution. I wanted to add multiple scripts with dependencies to my pages. When creating one elements.xml containing all three script links the order of the <CustomAction Location=”X” ScriptScr=”Y” /> elements is important.
The following elements.xml is packaged in a feature.
ScriptSrc="~sitecollection/_layouts/project_name/js/ jquery_query-2_1_7.js?rev=20110413" />
This results in the following HTML in your pages.
Important to know is the order in the elements.xml is the opposite sequence in the HTML. Meaning the script “jquery_query-2_1_7.js” is depending on “jquery-1.5.1.min.js” and needs to be the last item in the elements.xml.
In the script link I’m using “~site” and “~sitecollection” tokens to change the link according to the site or site collection where the user is located. This is important when creating a generic feature used on multiple sites.
By using the “?rev=20110413” at the end of your link you can force the browser to refresh its local cache. A (script) file is downloaded the first time accessing the page. As long as the link does not change the browser does not download the file. By changing the query string you can force a download of the script when changes are made. The actual value “20110413” is todays date, but can be your own versioning logic.
The example above also has a version number in the file name, this is another way of forcing a download. I simply wanted to illustrate the possibilities, you probably will use either query string or version number.
Lessons learned / best practices:
- Order in elements.xml for <CustomAction /> elements is of influence of the order of script links in the resulting HTML.
- Use “~site” and “~sitecollection” tokens to control the script link.
- Use “?rev=20110413” query string or version number in filename to force a download of the file.
Posted by Bram de Jager on April 13, 2011