Sitecore Tip O' The Evening

Using this in SC 6.5, pretty sure it works with all the current versions...

If you have a lookup field type and need to filter at the child level of the current parent by template name, use this: query:./parent::*[@@templatename='Activity']. Works like a charm. Basically this will allow you to have a mix of TemplateA and TemplateB under the same parent (more for content tree and SEO purposes than anything else) and be able to only allow the content editors to select from like templates in your lookup field.

Sitecore 6.5 Upgrade follow-up

Overall the upgrade went really well. From a public-facing perspective it was pretty seamless and our content editors are definitely happy that they can now use the browser of their choice to do content editing. The only caveat I have found so far is that when I was trying to import windows-encoded csv files using chrome on the mac and my custom tool the characters were getting jacked up. Running the same code with the same file in IE on windows had no problem.

The biggest setback we suffered in the upgrade process was that our site search stopped working cold. This probably should have been obvious given the amount of articles from Alex & Sitecore about the Lucene Search impending obsolescence but I missed it for the most part. I pretty much thought that 'depricated' meant 'will still work' but for whatever reason our search just gave up the ghost. I had config errors with the indexes I had previously defined in our web.config so just commented it out in the initial pass and then forgot about the whole deal. I guess I should have reviewed the first note in my previous upgrade post but we got busy and it slipped off the list. Finally circling back around to this topic, I've been hunting the web for good info. The best info I found is a combination of these two links:

• Index config: http://briancaos.wordpress.com/2011/10/12/using-the-sitecore-open-source-advanceddatabasecrawler-lucene-indexer/
• Index rebuild: http://svn.sitecore.net/AdvancedDatabaseCrawler/Trunk/Scripts/RebuildDatabaseCrawlers.aspx.cs 

The first helped by getting me a config file that works:

 <configuration xmlns:x="http://www.sitecore.net/xmlconfig/">  
  <sitecore>  
   <databases>  
    <database id="web" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">  
     <Engines.HistoryEngine.Storage>  
      <obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">  
       <param connectionStringName="$(id)" />  
       <EntryLifeTime>30.00:00:00</EntryLifeTime>  
      </obj>  
     </Engines.HistoryEngine.Storage>  
     <Engines.HistoryEngine.SaveDotNetCallStack>false</Engines.HistoryEngine.SaveDotNetCallStack>  
    </database>  
   </databases>  
   <search>  
    <configuration>  
     <indexes>  
      <index id="web" type="Sitecore.Search.Index, Sitecore.Kernel">  
       <param desc="name">$(id)</param>  
       <param desc="folder">web</param>  
       <Analyzer ref="search/analyzer" />  
       <locations hint="list:AddCrawler">  
        <master type="Sitecore.SharedSource.Search.Crawlers.AdvancedDatabaseCrawler,Sitecore.SharedSource.Search">  
         <Database>web</Database>  
         <Root>/sitecore/content</Root>  
         <IndexAllFields>true</IndexAllFields>  
         <fieldCrawlers hint="raw:AddFieldCrawlers">  
          <fieldCrawler type="Sitecore.SharedSource.Search.FieldCrawlers.LookupFieldCrawler,Sitecore.SharedSource.Search" fieldType="Droplink" />  
          <fieldCrawler type="Sitecore.SharedSource.Search.FieldCrawlers.DateFieldCrawler,Sitecore.SharedSource.Search" fieldType="Datetime" />  
          <fieldCrawler type="Sitecore.SharedSource.Search.FieldCrawlers.DateFieldCrawler,Sitecore.SharedSource.Search" fieldType="Date" />  
          <fieldCrawler type="Sitecore.SharedSource.Search.FieldCrawlers.NumberFieldCrawler,Sitecore.SharedSource.Search" fieldType="Number" />  
         </fieldCrawlers>  
         <!-- If a field type is not defined, defaults of storageType="NO", indexType="UN_TOKENIZED" vectorType="NO" boost="1f" are applied-->  
         <fieldTypes hint="raw:AddFieldTypes">  
          <!-- Text fields need to be tokenized -->  
          <fieldType name="single-line text" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="multi-line text" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="word document" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="html" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="rich text" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="memo" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="text" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <!-- Multilist based fields need to be tokenized to support search of multiple values -->  
          <fieldType name="multilist" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="treelist" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="treelistex" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <fieldType name="checklist" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
          <!-- Legacy tree list field from ver. 5.3 -->  
          <fieldType name="tree list" storageType="NO" indexType="TOKENIZED" vectorType="NO" boost="1f" />  
         </fieldTypes>  
        </master>  
       </locations>  
      </index>  
     </indexes>  
    </configuration>  
   </search>  
  </sitecore>  
 </configuration>  

While the second got me the code necessary to fire off the rebuild. The blog link was passing a string of "web" to the Sitecore.Jobs.JobOptions constructor which was not quite correct. I just copied the Builder object into my project, rebuilt and boom! indexes are rebuilding.

For the actual searching, I pulled down the Advanced Database Crawler code from Trac (http://trac.sitecore.net/AdvancedDatabaseCrawler/browser/Branches/v2/) and integrated that way. Still testing and dialing in but so far this looks promising and was only a couple of hours work to get from old style to new style Sitecore search.

50 Home Crossfit Workouts

Ever since my trip to myrle and the wife's unexpected trip back east, I've been slacking on my exercise. Just saw this list of crossfit workouts which seem doable at home. Now I have no excuse! 50 Home Crossfit Workouts

Sitecore CMS 6.5 migration notes (cont)

More fallout from our migration from Sitecore CMS 6.1 to Sitecore CMS 6.5. So far we've had some roadblocks but everything has been fairly minor and easily solvable.

Problem - Search indexes cannot be rebuilt:
Job started: RebuildSearchIndex|System.UnauthorizedAccessException: Access to the path 'E:\Development\S\SUZ\Sitecore 6.5.0 rev. 111230\data\indexes\__system\segments.gen' is denied.
  at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
  at System.IO.File.Delete(String path)
  at Lucene.Net.Store.FSDirectory.Create()
  at Sitecore.Search.Index.Reset()
  at Sitecore.Search.Index.Rebuild()
  at Sitecore.Shell.Applications.Search.RebuildSearchIndex.RebuildSearchIndexForm.Builder.Build()|Job ended: RebuildSearchIndex (units processed: )

Solution:
Give write permissions on the indexes directory to the application pool identity “IIS AppPool\sitecore_65” (or whatever your app pool is named).

Once this was done, we could then work on updating our indexes from the ‘old’ way to the ‘new’ way. Alex Shyba’s and Brian Peterson’s blog entries are a great resource for this. Since converting, the same search term is only returning 35 results on the dev site vs. 283 on teh current live site so there is definitely more work to do in order to get this wrapped up but it’s a start. My initial guess is that we were indexing more fields in our old, custom index than is happening with the default shared source module.



Problem - Only EN culture in web database:
Once everything above was fixed we started testing the other versions of the sites, namely our en-CA and fr-CA versions. Surprisingly, things didn’t show up properly at all. After some quick investigation, we discovered that there were absolutely no canadian versions of the items in the web db.

Solution:
Use the control panel to add the missing cultures so sitecore knows about them. Kind of weird that they all imported ok as content and then just wouldn’t publish. I would sort of expect to get a warning when importing that the target culture did not exist in sitecore.

Web.Config Fixed

Well, it turns out that a second set of eyes can do wonders for troubleshooting. I filed a ticket with Sitecore and Alexey easily pointed out that the web.config my new site was using was missing the proper XslExtensions mapping. While it was correct in the 6.1 instance, I had missed porting it over to the new 6.5 web.config and then was looking at the old file thinking i had put it in there. Oops, that’s pretty weak on my part. Now that the config has been properly updated things are loading properly and everything is looking good. Alexey also reminded me that this is not their preferred method for upgrading a Sitecore instance but at the end of the day, for my personal situation which is basically a small team and no budget to upgrade from point release to point release manually updating configs and databases, I think that if everything tests out it will be the way we move forward.

Another thing I figured out the hard way via debugging is that any custom handlers you have need to now be set up under in the web.config file when you move to 4.0 of the .Net framework on the server and also switch over to the Integrated pipeline. Not a big ordeal, just took a bit of logic and a second opinion to reason that one out.

Now everything is happy and we’re on to the QA phase.