Get a parent folder of SPListItem

There is a difference how to get parent folder for a list item when the list item is in custom list or in document library.
We can use File.ParentFolder property of SPListItem in document library :


SPFolder parentFolder = listItem.File.ParentFolder;


But in custom list the SPListItem.File property is NULL.
And instead of File.ParentFolder we can get a parent folder this way:


SPFolder folder = ((SPListItem)li.FirstUniqueAncestorSecurableObject).Folder;

How to change size of Sharepoint Rich Text Editor (RTE) in list form

The default size of Sharepoint Rich Text Editor (RTE) in a list form is too small to work with large texts. It's width is about 350 px, which is really inconvenient. To change RTE properties we can use a new JSLink attribute added to many Sharepoint artefacts in version 2013.


1. Add JSLink attribute to your list's forms declaration section in schema.xml file:
<Forms>
    <Form Type="DisplayForm" Url="DispForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" JSLink="~layouts/jquery/jquery-1.4.3.min.js|~layouts/zzzzz/scripts/DocItemView.js" />
    <Form Type="EditForm" Url="EditForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" JSLink="~layouts/jquery/jquery-1.4.3.min.js|~layouts/zzzzz/scripts/DocItemView.js" />
    <Form Type="NewForm" Url="NewForm.aspx" SetupPath="pages\form.aspx" WebPartZoneID="Main" JSLink="~layouts/jquery/jquery-1.4.3.min.js|~layouts/zzzzz/scripts/DocItemView.js" />
</Forms>
The attribute value contains | - delimited reference to jquery and custom .js files.


2. Create JS file and deploy it into ~layouts folder :


$(document).ready(function () {
    $('#onetIDListForm').width('100%');
    $('#WebPartWPQ2 > table').width('100%');
    $('#WebPartWPQ2 > table .ms-formtable .ms-formbody').width('90%');
});


3. Deploy solution and open the list form.


BTW: using this approach we can provide any design customization of standard list form without creating custom list forms.

Sharepoint 2013 Search- only one crawled item after full crawl

Suppose you have a Search service application provisioned in your Sharepoint 2013 site. Suddenly it stops providing search results.
The diagnostics shows:
- No errors in ULS
- No errors in crawl log
- Local Sharepoint Sites Content Source is pointed to hostname in Default AAM zone
- Crawler account has set a Full Read user policy in web application
- I'm able to login and browse the site using crawler account
BUT, a full crawl finished successful with a very suspicious result: only one item was crawled!

The reason is following: the MicrosoftSharePointTeamServices response header was missing in IIS site for default zone! The Central Administration site had that header, but application site hadn't. Normally each Sarepoint application's IIS site should have this header set after creation.
After adding the MicrosoftSharePointTeamServices header the full crawl finished successful with all site pages been crawled. The value of the header must be a current version of Sharepoint 2013 Server installed (including service packs).

Http request user-agent header's value of Sharepoint 2013 Search crawler

Can be found here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0\Search\Global\Gathering Manager in UserAgent key.

By default it's set to Mozilla/4.0 (compatible; MSIE 4.01; Windows NT; MS Search 6.0 Robot in Sharepoint 2013.

Get rid of OpenQuery Failed with status ID: 0x800007d0 in ULS

After provisioning Search Application you might see a lots of errors in ULS:

mssearch.exe (0x13C0)                    0x1250 SharePoint Server              Unified Logging Service        9saa Unexpected OpenQuery Failed with status ID: 0x800007d0. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_1_0_Portal_Content)\Transactions Completed. instanceHandle: 3.
mssearch.exe (0x13C0)                    0x1250 SharePoint Server              Unified Logging Service        9saa Unexpected OpenQuery Failed with status ID: 0x800007d0. QueryPath: \Search Gatherer Projects - SharePointServerSearch(Search_Service_Application_1_0_Portal_Content)\Transactions In Progress. instanceHandle: 3. 

To fix the problem follow the step below:

1. Fix Usage and Health Data Collection Service Application Proxy as described here: http://tristanwatkins.com/fixing-the-usage-and-health-data-collection-sa/
2. Check if an account of crawl component is a member of "Performance Monitor Users" local security group.

Fix Usage and Health Data Collection Service Application Proxy

1. start Sharepoint management shell as administrator
2. run the script:

$sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”} $sap.Provision()
3. restart IIS

4. open Search Service Administration in SP Central Administration
5. click on Index Reset, then Reset Now
6. check the ULS if the error dissapeared.

SPList.ParentWebUrl != SPList.ParentWeb.Url

These two proerties looks similar and expected to be equal, but they don't.

SPList.ParentWebUrl   - server relative url;
SPList.ParentWeb.Url - absolute URL for the website.

SPList.ParentWebUrl != SPList.ParentWeb.Url :)

URL format in New-SPSite

When creating a new site collection using PowerShell:

New-SPSite $siteCollUrl -Name $siteCollName -Template $template -OwnerAlias $siteCollAdmin –Language $siteCollLanguage

you might get an exception:

New-SPSite : The URL '/sites/sitecollname/' is invalid.  It may contain illegal characters, or be too long.

The problem is caused by the trailing slash in the new site collection URL. It should be removed.