Thursday, August 13, 2009

Announcement: New Search on SDN


First time writing a blog post from an airplane and such exciting news! I am pleased to inform about new search integration on our Developer Network.

This is initial launch featuring the following capabilities:
- Improved relevancy of search within the HTML documents, PDF, Word and other document types.
- Improved search performance.
rss
- Refine your search by type of the document and location (you can search in release notes for example). 
refinements
-  Ability to search Sitecore Community Blogs and Shared Source Library.
source
- Save search results as RSS and keep yourself updated.
 rss-output
- Search within results, sort, save search query and filter.
- Perform advanced search.
- Rank search results.
search rating
- View cached documents with search term highlighting
- and many more.

All this above is provided by version 6 of Coveo Enterprise Search.

Hope it will make your search experience much better, for example include Forum search.
Please do comment as we are planning on enhancing this functionality further and adding Forum search. So we are eager to hear from you.

Now just logon and experience it!

Saturday, July 18, 2009

Ways to check field type in code


As a “safe check” code operation in Sitecore, you frequently check for expected field type before working with a field.
While there is an easy way to do it via “Type” property of a field returning string, it may not look really nice and considered hard-coding:
if (Sitecore.Context.Item.Fields["featured"].Type == "Droplink")
Plus backwards compatibility of such code is questionable.
 
I suggest you use the Sitecore.Data.Fields.FieldTypeManager class that has “GetField” method where you can pass the instance of your field and use “IS” keyword to check if it is safe to cast:
if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["title"]) is TextField)
if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["text"]) is HtmlField)
if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["featured"]) is LookupField)
if (FieldTypeManager.GetField(Sitecore.Context.Item.Fields["metakeywords"]) is MultilistField)

Just make sure to replace the field name strings with a reference to a GUID class and you will be all set!

Friday, July 17, 2009

Registry Cache for “website”


Applies to 5.3.x and 6.0.x.
Recently discovered issue with disabled “registry” cache can potentially increase chattiness of your Sitecore web server with SQL Server.

Basically what happens is regular SQL selects from ‘Properties’ table that stores user-based registry settings for a current site. The call is initiated by Item.DisplayName property which is frequently used on the delivery boxes too. This is not a problem for the authoring environments that operate in the context of “shell” site by default since the registry cache is enabled there. This is not the case for “website”*** as two places where this may be changed contain zeros:

<site name="website" … registryCacheSize="0" …  />

<cacheSizes>
  <sites>
    <website>
     <html>10MB</html>
     <registry>0</registry>
     <viewState>0</viewState>
      <xsl>5MB</xsl>
    </website>
   </sites>
</cacheSizes>

The way to fix this is to simply adjust the value of registry cache. You can try 1KB and monitor the /sitecore/admin/cache.aspx page to see the actual consumption. From my experience, it is rarely even approaching 1KB in most installations unless you are writing something there with custom code.

This will be officially documented as a known issue and published on SDN.

In meantime, go ahead and put it in your web.config ;-)

*** If you have a multisite environment, change this on the level of your custom site definition responsible for the front-end requests. If in doubt, let me know.

Item, Memory and Timing Thresholds Demystified


There seem to be a lot of confusion on the forums on this topic, so the doc team updated the article about why the warnings are commonly appearing in live environments even when the code is optimized.

The basic idea is that the functionality was not designed for usage under load tests or in production, so the best way would be to simply disable this functionality in production systems. Otherwise, your log files will be just filled with warnings and it will make difficult reading them.
To disable, simply remove the StartMeasurements processor from the “httpRequestBegin” pipeline and “StopMeasurements” from “httpRequestEnd”.

I suggest you do use the thresholds in QA when running tests, just make sure you have a single request test to identify the problematic pages.

Same rules apply to media requests that report threshold violations. If this happens under a single user load, make sure you don’t have a crazy number of items in the requested branch. I’ve seen media libraries when that was the case.

Take it easy.

Tuesday, May 12, 2009

Updated: Standalone apps under Sitecore web root


As this article suggests, it is possible though not officially recommended. Here is an update for what you need to do in Sitecore 6.x to make it happen.

***Updated. (Thanks to the commenters):

The easiest way to do it, especially if you don’t want to inherit anything from the parent Sitecore configuration down to your asp.net app is to use the <location /> config element with inheritInChildApplications="false". With this element you can wrap most config sections like <system.web />, <system.webserver />, etc:

image

It is worth mentioning that not all configuration sections can be wrapped into the <location /> element.

========================================

- Open the web.config of your standalone web app.
- Locate <httpHandlers>section under <system.web> and remove Sitecore specific http handlers:

<httpHandlers>
   <remove verb="*" path="sitecore_media.ashx"/>
   <remove verb="*" path="sitecore_xaml.ashx"/>
   <remove verb="*" path="sitecore_icon.ashx"/>
   ...
</httpHandlers>

- Do the same thing for httpModules section:

<httpModules>
   <remove name="SitecoreHttpModule" />
   <remove name="SitecoreUploadWatcher" />
   <remove name="SitecoreXslWatcher" />
   <remove name="SitecoreLayoutWatcher" />
   <remove name="SitecoreConfigWatcher" />
   ...
</httpModules>

- If you are running on IIS7 in integrated mode, you will need to the same thing for the <system.webServer> section:

<modules runAllManagedModulesForAllRequests="true">
   <remove name="SitecoreHttpModule" />
   <remove name="SitecoreUploadWatcher" />
   <remove name="SitecoreXslWatcher" />
   <remove name="SitecoreLayoutWatcher" />
   <remove name="SitecoreConfigWatcher" />
   ...
</modules>
 
<handlers>
   ...
   <remove name="Sitecore.MediaRequestHandler" />
   <remove name="Sitecore.XamlPageRequestHandler" />
   <remove name="Sitecore.IconRequestHandler" />
   ...
</handlers>
 
- Your standalone app will most likely use its own membership provider(s), so you will need to disable Sitecore membership provider:
<membership defaultProvider="AspNetSqlMembershipProvider">
   <providers>
      <remove name="sitecore" />
      ...
   </providers>
</membership>

- If neither role nor profile providers are used, disable them or if you do use them, add the remove statement the same way as it it shown above for the membership provider.

<profile enabled="false">
   ...
</profile>
<roleManager enabled="false">
   ...
</roleManager>

This way you can easily have an MVC app running in a virtual application (separate pool) of your Sitecore website.