Thursday, August 27, 2009

Favorites and Links not working


Just noticed a minor issue in 6.1 with Favorites and Links buttons from the Navigate tab not working.
To fix that, simply go to the “core” database and clear our the “command” field for both items:
/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Navigate/Links
/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Navigate/Favorites

Good that everything is so (re)configurable in Sitecore ;-)

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.