Use the command
Hide the Icon
stsadm -o setproperty -pn days-to-show-new-icon -pv 0 -url http://machinename/sites/teamsite.
Change the duration from default "2" days to "10"
stsadm -o setproperty -pn days-to-show-new-icon -pv 10 -url http://machinename/sites/teamsite.
Hide New Icon or Change the Duration SharePoint
on Friday, March 19, 2010Get All the Checkedout documents sharepoint
on Monday, March 15, 2010
using Microsoft.Office.Server.Search.Query; ResultTableCollection rtc = null; DataTable retResults = new DataTable(); string fullTextSql = "SELECT ModifiedBy,Title,owsCheckoutUser,FileExtension,owsFileLeafRef,Path FROM SCOPE() WHERE owsCheckoutUser IS NOT NULL" using (SPSite site = new SPSite(http://servername)) { using (FullTextSqlQuery query = new FullTextSqlQuery(site)) { query.QueryText = fullTextSql; query.ResultTypes = ResultType.RelevantResults; query.RowLimit = rowLimit; rtc = query.Execute(); if (rtc.Count > 0) { using(ResultTable relevantResults = rtc[ResultType.RelevantResults]) retResults.Load(relevantResults, LoadOption.OverwriteChanges); } }
Mange WebPart Resources (Linked vs Embedded)
on Friday, March 12, 2010One of the most common questions I get in class and see in the forums is how best to deal with Web Part resources. By resources, I mean those necessary files that your Web Part depends on. These include JavaScript files, images, CSS, Flash, or even Silverlight apps. With the packaging and deployment model of SharePoint, it may be challenging to figure out where to store and how to reference these files. This article will overview your deployment options and give you enough information to make the best choice for your resource needs. With resource files, you have two basic options: linked or embedded. Linked means your Web Part will point to the file that lives somewhere in the file system. This is the most common approach. Embedded means you store the actual resource file inside your Web Part assembly. While less common, this can be very useful in many cases. We’ll look at each of these in more detail. Linked resources work best if you’ll need to modify the resource file separately from the Web Part. For example, say your Web Part references a JavaScript file and you continually need to tweak it and don’t want to recompile and redeploy the Web Part. If you link to it, it’s easy to change, and no changes to your Web Part are necessary. When working with linked resources, SharePoint provides you two primary options. For option 1, you should make sure your Web Part assembly is deployed into the GAC. This is necessary since the _wpresoures virtual directory is used across each SharePoint Web Application. We call this Farm-level scope. For option 2, you should make sure your Web Web Part assembly is deployed in to the bin folder for the Web Application. We call this Web-Application scope. That said, you choose which wpresources folder based on the scope of your Web Part. For both options, you’ll be placing your files inside a sub folder to keep them separate from other files in other Web Parts. The sub folder name needs to be the namespace of your project. For example, with Web-Application scope, it might go here: inetpub\wwwroot\wss\VirtualDirectories\80\wpresources\namespace. Ok, so you’ve chosen the appropriate folder based on the scope. How would you then reference this file within your Web Part code? It’s actually pretty easy and would look like this for a JavaScript file. (Note: this code can be placed in the CreateChildControls method for the Web Part.) Now that you have a good grasp on linked resources, let’s take a closer look at those that are embedded. Embedded resources are physically stored within the Web Part .DLL file. In one way, this is nice as you can always be assured that the resources and the Web Part stay together. The drawback is that if you need to change a resource, you must recompile and deploy an updated version of your Web Part. When the client needs the resource, it is dynamically extracted from the .DLL and provided. You’ll see how. To use an embedded resource, there are three things you need to do. The first is that you need to add the resource file to the project and mark is as an Embedded Resource. This is done via the Build Action setting inside Visual Studio as shown here. The second thing you need to do is declare this resource inside the AssemblyInfo.cs file for your Web Part project. This is an easy one-liner as shown: The parameter string that is used consists of the Web Part namespace followed by the filename of the resource. The next parameter is just the MIME type. If this were an image, it could be image/jpg. The third thing step is make sure you extract the Url to the resource. This is also one line of code as shown: As with linked resources, you’ll then deliver this script to the page with a call to RegisterClientScriptInclude within CreateChildControls. As you would probably guess, the string here must match the name in the AssemblyInfo.cs file. As written here, the resource files need to exist in the root folder of the Web Part project. (Note: technically you don’t need to precede the file with the namespace as long as the string is unique within the project. The common convention, however, is with the namespace). You might be curious how this actually works from the browser’s perspective. Well, what gets delivered to the browser is a link to a special, in-memory page called WebResource.axd along with a querystring to uniquely identify this specific resource. In HTML, it looks something like this: This is how it dynamically finds the resource file, extracts it from the Web Part DLL, sets the content type, and then delivers it to the browser. Pretty cool. In this post, you have seen how to both link to and embed Web Part resources. Each has its own advantages and disadvantages, mostly boiling down to whether you need to maintain the resource separately from the Web Part. In both cases, the resource file can be cached, so there is little performance difference from each option. Feel free to use one of these two approaches for your next web part.Linked or Embedded
Linked Resources
//Path to resource. This is used for a web part deployed into the GAC (Option 1)
string scriptUrl = "~/_wpresources/namespace/file.js";
//Path to resource. This is used for a web part deployed into the bin folder (Option 2)
string scriptUrl = "~/wpresources/namespace/file.js";
//Reference Script for web page
Page.ClientScript.RegisterClientScriptInclude ("file.js", scriptUrl);
Be careful, as these are very similar. You’ll notice for the first one, that you specify _wpresources (with an underscore). Also, make sure you replace namespace with the actual namespace for your Web Part project. For an image, it would work like this:Image myImage = new Image();
myImage.ImageUrl = "~/wpresources/namespace/image.jpg";
this.Controls.Add(myImage);
The last important detail when using linked resources is how should you deploy these files? First off, you should be using SharePoint Solutions to deploy your code. You are doing this, right? Inside the Solution manifest.xml file, there are specific tags to deploy these kinds of resources. The schema looks like this:<Assembly Location="Namespace.dll" DeploymentTarget="WebApplication">
...
<ClassResources>
<ClassResource Location="file.js"/>
<ClassResource Location="image.jpg"/>
</ClassResources>
</Assembly>
Here is where you can see that the DeploymentTarget attribute matches the scoping option. In this sample above, it is WebApplication scoped (option 2). To deploy into the GAC, replace this with GlobalAssemblyCache. To learn more about the schema inside this file, see this link.Embedded Resources
[assembly: System.Web.UI.WebResource("namespace.file.js", "text/javascript")]
string scriptUrl = Page.ClientScript.GetWebResourceUrl(this.GetType(), "namespace.file.js");
<script src="/WebResource.axd?d=ZPJuqJGGI6qgSKsEa2PfIw2&t=633527425956801634"
type="text/javascript">
</script>Conclusion
Introduction It is a common requirement to gather information around the Windows SharePoint site usage. Organizations prefer to find out the popular sites in their organizations are or what external WSS sites attract the most number of visitors. This will provide information necessary for an organization to identify the important sites in their environment and properly manage them with extra resources if necessary. One of the common complains around accessing theses data are the inflexibility of gathering information in a central location. The administrator will have to navigate to the selected SharePoint site administration pages to access the data. This will become a more time consuming exercise when the administrator need to collect usage data from larger number of SharePoint sites. In this article, I am looking at creating an ASP.NET web application that will populate a collection of SharePoint sites in a drop down list for a given SharePoint site collection. The web application will display the usage details of the selected SharePoint site from the list. This will help the SharePoint administrator to gather all SharePoint usage data from a central location with out have to navigate many different SharePoint site locations. Usage Analysis Data Web Report Figure 1 display a Usage Analysis data for a Windows SharePoint site. The users have the option of selecting a monthly or a daily report. Usage Analysis Processing Reports First of all let's have a look at what is Usage Analysis Reports in SharePoint. Theses reports will help the organizations to determine how the web sites are used in their environment. The data is taken from IIS Logs on the front end web servers and stored in to temporary files. The data is merged in to the content database on the back end SQL Servers when the daily log processing takes place. The Usage Analysis is not enabled by default when the organization deploys the Windows SharePoint Services Sites. Organizations should enable the Usage Analysis logging process on the servers when they require gathering usage information. The logs files are created daily and a flag is attached to mark that it has been processed. These logs files are not automatically deleted, they are preserved in "local_drive (C) :\Windows\system32\LogFiles\W3SVC*" where * indicates the Internet Information Server (IIS) instance number of the virtual server as displayed in Figure2. Organizations should consider the advantages against the disk space storage before enabling the Usage Analysis service in their environment. The organization can stop logging process' any time they require to do so. By default the log files are located at "local_drive (C) :\Windows\system32\LogFiles\STS" directory. Separate folders are created under above directory for each virtual server and separate folders for each day as displayed in the Figure 3. Organizations can configure the above Log file store path for their own preferred path and create up to 30 log files. Setting up Usage Analysis Processing Administrators can control the setting of Usage Analysis process using the SharePoint Central Administration page. The user must be an administrator on the local server or a member of the SharePoint Administrators group to configure the analysis processing. If the organization adds a new virtual server after the analysis service been configured, they will need to reconfigure the analysis service to collect the data on the newly added virtual server. View Usage Analysis Reports The user must be an administrator or have the View Usage Data right for a site to view the site usage reports. The reports are available through Site Administration page. The usage data is collected and stored for the entire site collection on a server at a time. The users can see the total number of hits for a site collection on the Site Collection Usage Summary page and for more detailed information, Site Usage Report page for individual sites or sub sites usage information. View Site Usage Report Site usage reports are useful for identifying which content on Windows SharePoint Services sites are being heavily used or used very little. This will help organizations to understand which sites are candidates for archiving and which sites should be kept online. In addition, this report contains information regarding how much storage space WSS sites are using. This page provides a report that contains following information: The users can select a report option and a daily or monthly option to generate a report. Figure 9 displays a monthly report of all the pages accessed and different kind of reports options available. Code Example The web page contains a text box to enter the SharePoint site collection URL. The appropriate sub site will be listed in a dropdown list when user clicks the Submit button. The user then have the option of viewing the daily or monthly usage report of a selected site. First of all you will need to add the Then instantiate the SPSite object as displayed below. The absolute URL is passed in through Then to access an individual site, instantiate the SPWeb object as displayed below. I am passing in the site name as a parameter. After constructing the site SPWeb object, developers can access the information of the site usage data using the public method "GetUsageData" of the SPWeb object as displayed in code example. The GetUsageData method of the SPWeb class returns a data table that contains information about the usage of a Web site based on the specified type of report and time interval. SPUsageReportType Enumeration The SPUsageReportType enumeration specifies the type of information returned in a usage report for a SharePoint site. The following table shows the members of the SPUsageReportType enumeration and a brief description SPUsagePeriodType Enumeration The SPUsagePeriodType enumeration specifies the time interval on which a usage report for a Web site is based. The following table shows the members of the SPUsagePeriodType enumeration and a brief description I am binding the data table return from GetUsageData property to a DataGrid control to display the information. Accessing User daily report Accessing User monthly report Accessing Browser daily report Accessing Browser monthly report Accessing Operating System daily report Accessing Operating System monthly report Accessing refUrl daily report Accessing refUrl monthly report Accessing url daily report Accessing url monthly report Deploying the Web Application to the SharePoint Portal Server Conclusion SharePoint Administrators should be able to use this article as a starting point and develop their SharePoint Usage Analysis data gatherer web application according to their requirements.
Figure 1: Monthly Usage Analysis Report
Figure 2: Preserved log files folder structure with W3SVC* format
Figure 3: Separate directories for each virtual server and for each day
(Please look at Setting up Usage Analysis process for more details.) If an organization decides to store the log
files in their preferred location, they should grant Read, Write and Update rights permissions for STS_WPG user
group for the specified folder. Without the permissions, the usage log files cannot be created or updated by IIS.
Figure 4: Component Configuration section on the central administration page
Figure 5: Configure Usage Analysis Processing page C:\WINDOWS\system32\logfiles\STS
Figure 6: Site Settings page
Figure 7: Top-Level Site Administration page
Figure 8: Site Usage Report page
Figure 9: Different reports available Microsoft.SharePoint.dll to your web application reference list.
This will give us the access to the SharePoint Object Model.
the txtWSSSiteUrl text box. This will populate site collection for the given URL. //Get the site collection
SPSite mySiteCollection = new SPSite(txtWSSSiteUrl.Text); //Get the details of the selected WSS site
SPWeb site = mySiteCollection.AllWebs[siteName]; GetUsageData(Microsoft.SharePoint.Administration.SPUsageReportType, Microsoft.SharePoint.Administration.SPUsagePeriodType) Method. Name Description browser The type of Web browser used to visit the SharePoint site. All usage data refers specifically to visits from referring URLs external to the site. os The operating system used on the client computer. All usage data refers specifically to visits from referring URLs external to the site. refUr External URLs through which users navigated to the SharePoint site. url URLs of pages that are visited or of pages for lists that are updated. Discussions about a page are counted as hits on that page. user Users who visited the site. Name Description day Returns usage information for each day during the past 31 days starting from the previous day lastMonth Summarizes usage information for the last 31 days relative to the previous day //Users who visited the site
DGUsers.DataSource = site.GetUsageData(SPUsageReportType.user, SPUsagePeriodType.day); //Users who visited the site
DGUsers.DataSource = site.GetUsageData(SPUsageReportType.user, SPUsagePeriodType.lastMonth); //The type of browsers used to visit the site
DGBrowser.DataSource = site.GetUsageData(SPUsageReportType.browser, SPUsagePeriodType.day); //The type of browsers used to visit the site
DGBrowser.DataSource = site.GetUsageData(SPUsageReportType.browser, SPUsagePeriodType.lastMonth); //The Operating System used in client computer
DGOs.DataSource = site.GetUsageData(SPUsageReportType.os, SPUsagePeriodType.day); //The Operating System used in client computer
DGOs.DataSource = site.GetUsageData(SPUsageReportType.os, SPUsagePeriodType.lastMonth); //External URL client used to navigate to SharePoint site
DGRefUrl.DataSource = site.GetUsageData(SPUsageReportType.refUrl, SPUsagePeriodType.day); //External URL client used to navigate to SharePoint site
DGRefUrl.DataSource = site.GetUsageData(SPUsageReportType.refUrl, SPUsagePeriodType.lastMonth); //URL's of pages visited
DGUrls.DataSource = site.GetUsageData(SPUsageReportType.url, SPUsagePeriodType.day); //URL's of pages visited
DGUrls.DataSource = site.GetUsageData(SPUsageReportType.url, SPUsagePeriodType.lastMonth); http://portal_site_name/UsageAnalysisData/MonitoringPage.aspx
Figure 10: A list of sub sites of the site collection
Figure 11: Daily Usage Analysis Report of a Windows SharePoint Site
Print ListData SharePoint
on Thursday, March 11, 2010<%@ Page Language="C#" Inherits="System.Web.UI.Page" %> <%@ Register TagPrefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %> <html> <head> <title>SharePoint List Print</title> <link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/core.css" /> <script type="text/javascript" language="javascript" src="/_layouts/1033/init.js"></script> <script type="text/javascript" language="javascript" src="/_layouts/1033/core.js" defer></script> <script type="text/javascript" language="javascript" src="/_layouts/1033/ie55up.js"></script> <script type="text/javascript" language="javascript" src="/_layouts/1033/search.js" defer></script> </head> <body> <% string listId = ""; string referrer = ""; //get the list id (guid in a string format) from the query string listId = Page.Request.QueryString["list"]; //get the http referrer (for the back button\action) referrer = Page.Request.ServerVariables["http_referer"]; //make sure the list parameter was passed if (listId == null) { //if a referrer url exists (since the page may have been opened from a direct link, this is not always the case) redirect the user back if (referrer != null && referrer.Trim().Length != 0) { Page.Response.Write("<p>The list ID parameter ('list') is missing from the address.<br>Please go to the list you want to print and try again.</p>"); Page.Response.Write("<p><a href=\"" + referrer + "\" title=\"Go Back\">Click here to go back to the page you came from</p>"); } else { Page.Response.Write("<p>The list ID parameter ('list') is missing from the address.<br>Please go to the list you want to print and try again.</p>"); } } else { try { //load the web object for the site that the page is now in context of using (SPWeb web = SPControl.GetContextWeb(Context)) { //load the list that was passed in the 'list' querystring parameter to the page SPList list = web.Lists[new Guid(listId)]; //load the query of the default view. note - need to modify code in the future to enable multiple view printing SPQuery query = new SPQuery(list.DefaultView); //write the list to the page Page.Response.Write(list.RenderAsHtml(query)); //add the print script %> <script type="text/javascript" language="javascript"> window.print(); </script> <% } } catch (Exception ex) { Page.Response.Write("<p>There was an error loading the list information:<br />"); Page.Response.Write(ex.ToString()); Page.Response.Write("</p>"); } } %> </body> </html> <?xml version="1.0" encoding="utf-8" ?> <Feature Id="769826dd-9dd2-11db-96ca-005056c00008" Title="Print List" Description="This feature adds a print command in the Actions menu for Windows SharePoint Services lists." Version="1.0.0.0" Scope="Site" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="PrintList.xml" /> </ElementManifests> </Feature> <?xml version="1.0" encoding="utf-8" ?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <!-- Add the action to the List Toolbar Actions Menu Dropdown --> <CustomAction Id="SPSTIPS.PrintListActionsToolbar" RegistrationType="List" GroupId="ActionsMenu" Location="Microsoft.SharePoint.StandardMenu" Sequence="1000" Title="Print List"> <UrlAction Url="{SiteUrl}/_layouts/PrintList.aspx?list={ListId}"/> </CustomAction> </Elements>
Solution Architecture
The solution will be deployed as a wss feature, which allows us an easy way to add a menu item to the sharepoint menus. The feature will define that the item we want to add will be added to the actions menu of all lists, in a site collection. You can ofcourse change it so that it behaves differently and connects only to lists of a certain type if you so wish, or maybe move the menu item to a different place. I recommend reviewing the msdn article on the possible configurations.
The solution is based on 3 files:
Defines the feature, its scope and its title that you will see in the "site features" (or site collection features or farm features - depending on the scope)
PrintList.xml
Defines what action we want to add to what menu and what will happen when the user clicks the menu item. This is where you configure the text of the item, and the link to the page that will print the list. which just happens to be the last file:
PrintList.aspx
Contains the code that shows the list in a print-friendly view. This file should be deployed to the layouts folder and must be called with the site's context (more about that shortly).To the Code!
note - when I talk about the "12 hive" I am referring to the folder C:\Program Files\Common Files\Microsoft Shared\web server extensions\12
Create the page that prints a list:
Log on to the server, and open the template\layouts folder in the 12 hive.
Install the feature
In your editor of choice (notepad is fine) open the feature.xml file and paste into it the following:
In your editor of choice open the printlist.xml and paste the following:Almost done - install the feature and test it!
To install the feature, open command line (start>run>cmd) and navigate to the bin folder in the 12 hive.
Once there, run the following command to install the feature:stsadm -o installfeature -name PrintListMenuAction -force
After you ran that command successfuly, you can activate the feature in the site collection either using the user interface (site actions> site settings> site collection features):
or you can (more easily since you are already in the command line) just run the following command, entering the site path:
stsadm -o activatefeature -name PrintListMenuAction -url [your site url here] -force
That's it! if you now go to any list in that site, you should have the print menu action.
I would highly recoomend ASPOSE.WORDS product to convert word documents into PDF in SharePoint.It is not a free product but is good for the functionality.
http://www.aspose.com/categories/product-family-packs/aspose.words-product-family/default.aspx
I thought I would run through some of the tools that have helped me when branding a MOSS intranet. SharePoint Designer or perhaps better yet Studio can be the primary tool for creating master pages, themes, and page layouts, but your gonna need some help when trying to dig through all the CSS in the core.css file, and all it’s crazy inheritance. Combing through the css is a big chunk of your effort when you are starting with the default master or the default or classic theme. Most corporate organizations that I have worked with take the approach of “skinning” the SharePoint default look to match there colors and branding as opposed to starting from the ground up. So odds are your starting with the default look : -(
A couple of prerequisite tips before I get to the tools…..
When creating or modify styles - always, always, always put them in a new stylesheet. If you just update core.css, you will have a lot of pain in your life when your discover some goofy UI thing happening on a page, and you have to comb through the 4,000+ lines of styles in core.
Be cautious of overwriting or adding images directly in the _layouts/Images directory (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\IMAGES) . If the box has to have MOSS reinstalled or perhaps some obscure patch occurs - you can kiss those image updates goodbye. However, I know that sometimes this is unavoidable….or at least a huge time saver. If your implementing a larger project, then put the images you added or modified in source control, and have a build script that will push the images. This way all the customization can be automatically pushed. OR if is a small implementation, at least document the image changes :- )
So…..oh yeah……The Tools:
IE Developer Toolbar
Certainly the biggest challenge in modifying the UI of MOSS is trying to figure out which style does what…and where is does it. And a good way to discover what MOSS is doing with it’s ginormous style sheet is to look at the rendered pages in the site. The IE Developer toolbar will provide 2 great features that will aid in this discovery process. 1. From the menu select ‘Find’ and ‘Select Element by Click’ which will allow you to click on any element in the page, and see the class used as well as all of the style attributes. So even if you see the class you modified, but say it is still show a incorrect style value (like color, padding, or whatever) then you know your style is being overwritten somewhere else. 2. As you select an element is also gives you a window with the html of the page that is much easier to comb though than viewing source in Notepad - That way you can crawl up and down the html tags to see what styles are being applied at the div, td, tr, table, etc. and……OK #3 - you can also disable scripts with a click so you can see styles without the hover state kicking in (i.e. - Menus)
CSS Finder Code (courtesy of msdn)
Similar to the IE Developer toolbar, you can throw this snippet into a content editor web part, which will allow you to roll over elements on the page and have the css style show up in a div tag on the screen. It is handy and quick, but will not give you as much information as the IE Developer toolbar. I would click on the link above because this page has a css reference chart that is fairly useful - also see Heather Solomon’s CSS Reference to get and idea for some of the major styles.
<script language="jscript"> function ClassInfo() { if (window.event.srcElement.className != null) { stsclass.innerText = window.event.srcElement.className; } else { stsclass.innerText = ""; } } window.document.body.onmouseover = ClassInfo;</script> <div style="border-style:solid;border-width:1px; width: 281px; height: 34px; position: absolute; left: 286px; top: 41px; z-index:15; padding-left:4px; padding-right:4px; padding-top:2px; padding-bottom:2px; background-color:#EEEEF4"> <p id="stsclasstitle"><font face="Tahoma" id="stsclasstitle">Classname: </font> <font face="Tahoma"id="stsclass"> </font> </p></div>
Again another tool for style discovery (are you getting that this is a pain) I will use this little piece of freeware to quickly identify the hex color of an element on a page. Sometimes when you swear up and down that you have changed a color but it just wont show, I will get the hex off the screen, and start start seeing where that color shows up in the various style sheets.
This is a handy tool when you need to create a down and dirty theme - quickly. I’ll admit I have not played with this too much, but it will allow you so change colors and images with a few clicks, and export out a theme. This may also help you get an understanding of what css classes effect what styles, but I find the developer toolbar more efficient for that task.
Features and Deployment
The easiest way to deploy your look and feel to SharePoint is to utilize the Solution Framework MOSS provides. Especially in a farm environment where files need to be pushed to multiple servers. Features are also what I would recommend when including look and feel into site definitions. Many people have posted adding master pages to a Module Element in the ONET file of a site definition, but that will deploy a copy of the master page file to every site provisioned based on your definition. To me, this defeats the point of a template as it can not be globally changed now that you have copies stored in every web. You can create features that utilize receiver classes to programmatically apply a master page or theme when a feature is activated. You can also auto-activate these types of features in a custom site definition. Some good examples of how this is done are here:
Graham Sibley shows how to write a feature that deploys a theme to a site
Paul Papanek Stork shows how to write a feature that apply’s a master page to a site. This feature will apply a mater page from the /_catalogs directory at the root of the site collection.
Now that you are writing all these crazy features you may want a way to take some of the legwork out of the process. My friend Rich Finn has created a WSP Project Template for Visual Studio that will create the wsp along with the manifest.xml, and .ddf files for you. It also has deployment and upgrade scripts built in to deploy your look and feel to the portal. There is another one on CodePlex called SharePoint Feature Packager that will also do the trick, but Rich’s template has less manual steps to get rolling.
These tools definitely make life easier, but before implementing a portal look and feel, be sure to take all the proper planning steps to ensure that what you are implementing will best suit the long term needs of the business. SharePoint has made a lot of headway in how things can be packaged, deployed, and templated, but there are still a lot of gotchas - you don’t want to deploy a look and feel to a ton of pages and later find out something drastic has to change. You may find yourself rebuilding pages manually or basically undergoing a site migration. Each organization needs to consider things like:
Site Definitions vs. Site Templates
Themes vs. Masterpages - one or the other or both
Features and scope of those features
What meta data will be applied in our templates
Carefully document the pros and cons of each of these decisions so that the business can understand the potential impacts of the decisions being made during the design phase of a project.
Subscribe to:
Posts (Atom)
