Actually I came up with a request to disable the scroll bar for the site welcome page which was using the custom master page and had a full screen slider. but there were no need to scroll bars on the first page.

Just to mention, I had created the page using SharePoint designer (Right click on master page > new from master page) because it had it’s own scripts and not specific SharePoint content ( you know it was a Welcome page 😉 ) for example the page had the ribbon because it was created by a master page. after I put the scripts I found that the SharePoint fake scroll bars is visible however the page didn’t need to scroll at all and scrollbars make the page obscene.

So here I found the solution written by Stephan and in my case to customize and summarize it:

  1. In your master page and body tag, remove scroll=”No”
  2. add the following CSS styles to the page. Either using a CSS file or add styles inside the page.
body #s4-workspace{
    overflow: inherit !important;

During these 2-3 weeks I was designing an Intranet site based on SharePoint 2010. Although it was an Internal site but the design and look of the site was important for the managers and in some cases we needed to use CSS3 techniques. The users were using IE 9.

To do this you know that the META tag in master pages should be changed as most of the designers know.

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

I found that changing this tag has some side effects and finally we come come up to not to use CSS3 in SharePoint 2010 if it’s not really necessary. In other words if the functionality is more important than the look and feel, ask the company to meet you in halfway in terms of look and feel.

Some sections that are affected in IE 9 by changing META  tag content property.

  • InfoPath forms services ( In our cases, the customized list forms, the submit button stopped working in IE )
  • Ribbon look and feel ( in our case, it lost her background and became transparent)

When you have your own custom master page in SharePoint 2010, maybe you’d come up with this issue when saving a simple wiki page in Site Pages or a Wiki library.

“you must specify a value for this required field”

new wiki page error
new wiki page error


I googled and found the reason is because of a missing folder which I had removed (better to say hided incorrectly). and it is this place holder:

<asp:ContentPlaceHolder id=“PlaceHolderPageTitleInTitleArea” runat=”server”></asp:ContentPlaceHolder>

What I had done was I had put this code inside an ASP Panel and set the visibility of the panle to hidden.
I found that I should do this with CSS like this.

<asp:Panel runat="server" CssClass="hidden" >
<asp:ContentPlaceHolder id="PlaceHolderPageTitleInTitleArea" runat="server" />

I found these posts helpful :


This question was always a challenge for me. One day I was searching about this challnege and I found a good blog post here. Thanks to Nirav Sanghvi. I will summerrize it here.

  • One way is by going through all the links and observing the URL for all the Pages and the Folder structure where all these pages are stored (especially the /Pages/PageName.aspx pattern). This Pattern indicates a SharePoint Publishing Site. You may know All publishing pages in SharePoint 2007 and 2010 are stored in the “Pages” document library. In SharePoint 2010 we also have a new document library that is named SitePages and it’s for all the simple wiki pages.
  • so try to seach for URLs with patterm /Pages/ or /SitePages/.
Observing URL is really great but not always gives true and satisfactory result.
  • If you are using FireFox as browser with FireBug, open up console and view JavaScripts of page. If you see init.js, core.js etc. It’s confirm now its SharePoint site.
  • Another way is just do “View Source” from any browser of your site. If it’s SharePoint site (Publishing most cases) you will see something like

<head><meta name=”GENERATOR” content=”Microsoft SharePoint” /><meta http-equiv=”Conten ……
Dont forget to check Javascript section just after <Title> you will see reference JS from
well thats our 12 hive.

Good enough as proof. But still what if site has its own master pages and have customized in such way that these meta tags and core.js file are not in used or are removed. Since most public facing SharePoint sites redesign masterpage as per their company brand. Its strong chance you will see their masterpage, not default one.

BUT most of them never delete the default css and images that comes with default install of SharePoint.

  • So if you spoof the URL little like

http://<<Site name>>/_layouts/images/homepagetopzoneimage.jpg
you can see your SharePoint friends 😉

  • Check any image name from “12\TEMPLATE\IMAGES” folder in url with format like

http://<<Site name>>/_layouts/images/<<image name>>
Same goes for JavaScripts files too.

NOTE: When accessing any of the protected paths like _layouts if it asks for authentication also gives indication of SharePoint, as not all paths are having anonymous access.

And now one more last bust not least way.

  • If its SharePoint site there are also web services with it. You can call any of webservice (If banned then see your fav “Unknown Error” page).

You can directly access the error page too like

But coolest part is have some twist in calling these web services. If its SharePoint site there is “_layouts” folder. And if its “_layouts” try this :

http://<<Site name>>/_layouts/Lists.asmx
(Yes I know Lists.asmx is not in _layouts folder) . So you will see something like
Huh !!!! All developers knows this screen ;)

Do you still need proof ? 🙂

  • Here is one more way

Check _layouts/xsl/internal.xsl which is also base include file for all custom xslts
Ohh, few more URL like this

WOW !!!! Enough. I know its SharePoint site now.

BUT, Hey Do you want to know which version it is ?

No Problem, try this:

Happy net surfing !!!!!! 🙂

Last week at the end of the year and last days ( Norouz is coming ! 🙂 ) I was challenging with this error when I was trying to open office docs in Microsoft web apps.

“Word Web App cannot open this document for viewing because of an unexpected error.  To view this document, open it in Microsoft Word”


Finally I configured it successfully and to cut a long story short, the important things I did was:

  1. In Central Administration In the “Manage services on server” check the related services are “started”
  2. I created a separate service account ( I did not use the Farm Admin account | System Account ) for the application pools. ( used in service applications )
  3. I found the service account MUST have privilege on Content Database. I used DB_Owner role.
  4. Add the service account to the local policy “Replace a process level token”. to do this:
    • On the Windows 2008 server, select Start | Programs | Administrative Tools | Local Security Policy
    • Expand Local Policies | User Rights Assignment
    • In User Rights Assignment | Click on the Replace a process level token policy. Click on Add user or group. Type in the service account, resolve the name. Click OK. Click OK. Click apply. Click OK. (Below is a screenshot of the policy)
    • After the permission is set then launch a command prompt and type the following: gpupdate /force
  5. you also may need an IISReset /noforce

After doing this Web Apps should work correctly. you can also check this link and this one. I found them useful during my search for the problem and solution.

good luck 😉 !


“I found this article and one of the comments useful. So I merged and published them again.  The source link is at the end of the post.”

The out-of-the-box SharePoint search results web part doesn’t provide a way to get to the View Properties page for items in a document library. The search results provide a direct link to the document which will open a document in default editor registered within windows.
In the screen shot below notice that both the hyperlinked title (shown in the tool tip) and the url displayed both link to the actual document and not to the View Details page.

The goal is to generate a hyperlink that will allow the user to navigate to the properties display form for documents.

Clicking “View Properties” will take the user to the following page:

Step 1: Add a managed property for the integer ID of list items.

In order for the solution to work properly we must first create a Metadata Property Mapping for the ID of list items. SharePoint out-of-the-box does not include these identifiers in its search index.
Open the SSP
Click Search Administration
Under Queries and Results, click Metadata properties.
Click Crawled Properties:

Search for ows_id. Then edit the crawled property.

Select the checkbox at the bottom of the page to include the property in the search index:

Return to the Metadata Property Mappings screen by clicking on Metadata properties on the left side of the page.
Click New Managed Property and set the values as follows:

  • Property Name: ListItemID
  • Description: Numeric identifier of SharePoint List Items (i.e. documents, pictures, and custom lists).
  • Type: Integer
  • Add ows_id as a crawled property.

Run a full crawl of the content source

Step 2: Add the Metadata property to the search results web part

Now that the metadata property has been added to SharePoint we now need to make the property available to the search results web part. In my example I’ve added the search and search results web parts to a web part page but the same steps apply if you are editing the search results web part in the search center.
Open your search results page in edit mode.
Locate the search results web part and click Modify Shared Web Part

In the Results Query Options section, open the editor for the Selected Columns property:

Add a reference to the ListItemId property as follows:

 <Column Name="ListItemID" />

At this point the custom Metadata property we created will now be retrieved with every search query. The value will come back in the xml returned by the query servers and is just begging to be displayed somewhere on the page.

Step 3: Modify the XSL to display the hyperlink to the View Properties page.

The next step it to create a hyperlink to the View Properties page using not only the custom ListItemId Metadata property but also several other properties already available to us: url, sitename, and contentclass.

  1. Click the XSL Editor button in the web part properties panel.
  2. Copy the contents of the editor and paste into an XSL editor like Visual Studio .NET or any text editor.
  3. Near the bottom of the XSL file paste in the following template definition just prior to the </xsl:stylesheet>tag:

<xsl:template name="DisplayViewPropertiesLink">
 <xsl:param name="itemUrl" />
 <xsl:param name="siteUrl" />
 <xsl:param name="listItemId" />
 <xsl:param name="contentclass" />
<!-- you may have issues with case, the doc lib will not matche by the substring functions, so do a translation -->
 <xsl:variable name="itemUrlLower" select="translate($itemUrl, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')"/>
 <xsl:variable name="siteUrlLower" select="translate($siteUrl, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ', 'abcdefghijklmnopqrstuvwxyz')"/>
 <xsl:if test="$contentclass='STS_ListItem_DocumentLibrary'">
 <xsl:variable name="docLibLoc" select="substring-before(substring-after($itemUrlLower, concat($siteUrlLower, '/')), '/')" />
 <xsl:variable name="viewPropUrl" select="concat($siteUrl, '/', $docLibLoc, '/Forms/DispForm.aspx?id=', $listItemId)" />
 <xsl:text disable-output-escaping="yes">&amp;nbsp;-&amp;nbsp;</xsl:text><a href="{$viewPropUrl}">View Properties</a>

  1. This template first checks to see if the item is part of a document library. If so, it parses out the document library name and then builds up a URL pointing to the View Properties page and outputs a hyperlink to the page.Important note: This link is hard-coded to point to the out-of-the-box View Properties page. If document libraries have custom View Properties pages, this solution will need to be modified.
  2. The last step is to include a call to the new StyleSheet template. In my example, I’ve placed the call just after the rendering of the modified date:
<xsl:call-template name="DisplayString">
 <xsl:with-param name="str" select="write" />

<xsl:call-template name="DisplayViewPropertiesLink">
  <xsl:with-param name="itemUrl" select="url" />
  <xsl:with-param name="siteUrl" select="sitename" />
  <xsl:with-param name="listItemId" select="listitemid" />
  <xsl:with-param name="contentclass" select="contentclass" />

<xsl:call-template name="DisplayCollapsingStatusLink">

Step 4: Deploy and test

Now that the XSL StyleSheet has been modified the last step is to copy the XSL back into the web part property and save your changes. Submit a simple search for documents and verify the View Properties link appears after the date.

Special thanks to Doug Perkes  for providing this solution, and Trevor for his comment.

Sometimes because of some customizations or when you’ve worked with SharePoint designer, the page title is disappeared.

in these cases you can change the page title by using these tags. Add the follwing content place holder in the top of your code if not exist.

<asp:Content ContentPlaceHolderId=”PlaceHolderPageTitle” runat=”server”>

Add Title here


You can get title dynamic by add any of this tags into “PlaceHolderPageTitle”

<SharePoint:ListProperty Property=”Title” runat=”server”/>

<SharePoint:ListItemProperty Property=”Title” runat=”server”/>

<SharePoint:ProjectProperty Property=”Title” runat=”server”/>

<SharePoint:ListFormPageTitle runat=”server”/>

I found this solution here.