Showing posts with label MOSS 2007. Show all posts
Showing posts with label MOSS 2007. Show all posts

Tuesday, April 20, 2010

Deleting(Unextending) Extended web applications

When we extend a web application, the extended web application will not appear in the Web Application list. Hence we cannot delete the Extended site through the "Delete Web Application" section of Application Management.
Use this approach to delete the extended web apps:
  1. Start Central Administration
  2. Go to Application Management
  3. Click Remove SharePoint from IIS Web Site
  4. Select the web application that the extended web app was extended from
  5. Select which extension/zone to delete
  6. Keep or delete the IIS Web site
  7. Finally click OK
If you look closely the page is named "unextendvs.aspx" :)

Tuesday, April 6, 2010

Page Layouts & Site Templates

Probably all of you would have used this setting at some point in your projects, this is for those who haven’t.

As most of you would know in MOSS 2007 Publishing sites, each site supports only one Pages Library. As a direct consequence of this the content author/editor would have to navigate to the desired site(For example- if you have a Latest News functionality in your WCM site and as part of your information architecture you would decide to have a sub site called News, so to add a News article, the content author would have to navigate to the News site.) to create/edit a particular publishing page.

When he tries to create a page, he would be presented with a list of page layouts to choose from. If you want to restrict the list of page layouts you can:

Go into any Publishing site's Site Settings page and look under the Look & Feel column for the Page Layouts & Site Templates link. From this page you'll be able to do the following:

• Inherit the parent site's settings for site templates & page layouts.
• Turn off all filtering for the site templates & page layouts that are available to content
• Turn on filtering and customize the site templates & page layouts that are available to content owners and hierarchy managers.

This you allow you to limit the page layouts/site templates available.

This feature also allows you to enable the creation of other “types”(Blog, Wiki, Team Sites, etc.) of sites under a Publishing site which is not available as a default setting.

SharePoint 2010 provides a Content Organizer through which you can organize content based on a rules engine.

Sunday, February 28, 2010

Debugging the "The Resource cannot be found" error

Working with sharepoint often involves a lots of digging into to get to the source of the problem i.e. read Event Viewer, Stack Traces, ULS logs, IIS logs, etc...

Once common error you might come across as a sharepoint developer is the "The Resource cannot be found" error.

Digging into the event viewer or uls logs does not give any clue on the actual error message.

While,breaking my head over this my team mate told me to have a look at the page source.

And there lies the actual error :)

Hats off to sharepoint again!!!!

Wednesday, January 6, 2010

Passing custom arguments to the content query web part


We had a requirement to access the parameters entered by a content author/administrator in the tool pane of the content query web part (CQWP) to in the item style xslt template.
For this we decided to extend the functionality of the CQWP by sub-classing it. We included additional input fields to the tool pane by creating a new tool part class and added out custom tool part class to the out of the box tool pane of the CQWP.
To make the parameters entered in the tool part to be accessible in the ItemStyle.xsl we have to override the ModifyXsltArgumentList method of the CQWP.
protected override void ModifyXsltArgumentList(ArgumentClassWrapper argList)
{
base.ModifyXsltArgumentList(argList);
argList.AddParameter("yourparametername", "namespace", value);
}
Now the parameter can be accessed in the contentquerymain.xsl as a parameter.
<xsl:param name="cbq_isgrouping" />
<xsl:param name="cbq_columnwidth" />
<xsl:param name="Group" />
<xsl:param name="GroupType" />
<xsl:param name="cbq_iseditmode" />
<xsl:param name="cbq_viewemptytext" />
<xsl:param name="SiteId" />
<xsl:param name="WebUrl" />
<xsl:param name="PageId" />
<xsl:param name="WebPartId" />
<xsl:param name="FeedPageUrl" />
<xsl:param name="FeedEnabled" />
<xsl:param name="SiteUrl" />
<xsl:param name="BlankTitle" />
<xsl:param name="BlankGroup" />
<xsl:param name="UseCopyUtil" />
<xsl:param name="DataColumnTypes" />
<xsl:param name="ClientId" />
<xsl:param name="yourparametername" />
You can access the parameter now in the ItemStyle.xsl as follows:
<xsl:value-of select="$yourparametername"/>

Content deployment retry configuration

Only a part of the Content Deployment configuration settings are configurable through the central administration user interface, some of the settings have to be done in the web.config of the central administration website while others can only be accessed through the API.

The settings that can be configured through the web.config are discussed here. These settings relate to the Export phase of the content deployment process.
Options that can be configured through the central administration web configuration:

RetryOption: When content deployment jobs are executed in parallel or if content authoring is in progress when the job is running you may encounter many random exceptions. This is an enumeration ExportRetryOption.
The possible values for RetryOption include:
None (0) - default
SkipFailedWebs (1)
SimpleRetry (2)

Note: The enumeration is marked as internal and hence is not exposed through the API.

ExportRetries: This is used in parallel with the RetryOption. This is a number indicating the number of times the content export will retry before throwing up an error. Possible values are 1-999.

A more detailed explanation is described in Part 3 of the series on content deployment by Stefan Gobner.


Note: These settings are part of the build 12.0000.6315.5000 or later.

Thursday, December 17, 2009

PublishingLayoutPage,WebPartPage and custom Master pages

Page Layouts form an essential part of any Web Content Management (WCM) site built on MOSS 2007.
Page layouts when combined with master pages; define the layout of the page rendered. They also define the editable regions of the page, usually implemented by web parts and Meta data (Field controls) associated with the page.

Let us consider the base class from which the page layouts in any publishing site inherit from, the
Microsoft.SharePoint.Publishing.PublishingLayoutPage class. If we see any of the out of the box page layouts that SharePoint provides, we can see that they all inherit from the PublishingLayoutPage class.
Going a bit deeper into the implementation of the PublishingLayoutPage class, the documentation on msdn indicates the inheritance hierarchy of the class as follows:


System.Object
System.Web.UI.Control
System.Web.UI.TemplateControl
System.Web.UI.Page
Microsoft.SharePoint.WebPartPages.WebPartPage
Microsoft.SharePoint.Publishing.PublishingCachablePage
Microsoft.SharePoint.Publishing.PublishingLayoutPage


So there is the PublishingCachablePage that separates the Microsoft.SharePoint.WebPartPages.WebPartPage which is the class all the pages in WSS derive from and the PublishingLayoutPage.

As we know if we derive out page layout from the PublishingLayoutPage, the master page for the layout is taken from the Site Master Page settings of the current site; this is an implementation of the PublishingLayoutPage class, using a reflector:


[PermissionSet(SecurityAction.Demand, Name="FullTrust")]
public class PublishingLayoutPage : PublishingCachablePage
{
// Methods
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
SPContext current = SPContext.Current;
if (current == null)
{
SPException exception = new SPException(Resources.GetString("ErrorInvalidSPContextCurrent"));
ULS.SendTraceTag(ULSTagID.tag_7ob3, ULSCat.msoulscat_CMS_Publishing, ULSTraceLevel.Unexpected, "PublishingLayoutPage.OnPreInit(): Exception: SPContext.Current is null");
throw exception;
}
SPWeb web = current.Web;
this.MasterPageFile = web.CustomMasterUrl;
}
}


If you want to add new functionality to your publishing page layouts you can extend the PublishingLayoutPage class. This is a good post that describes how this can be achieved:


If you want to specify a custom master page for more than one page layout to be used in a specific site you can override the OnPreInit method of the PublishingLayoutPage class and set the this.MasterPageFile property appropriately.