23 December 2010

Sitecore Terminology maps to Umbraco

Here at ProWorks we have built a web site using the Sitecore CMS (Wasatch Funds) and had a great experience. We are Sitecore Partners and like to use Sitecore when it makes sense. Sometimes the web sites we are asked to build have budget constraints or are just to small to warrant using Sitecore. In that case we typically have been using Sitefinity to build smaller, simpler sites (Forest Seedling Network).
We like Sitefinity, but an open source project called Umbraco recently caught our eye. The similarity to many of the Sitecore like functions is great because we like the Sitecore experience generally. Of course, the functionality may be similar but the terminology is not. Therefore, I’m creating a terminology map to help me keep some of this straight.
This will be a work in progress and here is what I have so far:
Sitecore Umbraco
Templates Document Types
Visual Rendering editor Templates
Layout Master Template
SubLayout Sub Templates
Edit Rich Text Editor settings Stylesheets (can add generated styles to Rich Text Editor)
Renderings (XSLT/Web Controls) Macros (XSLT/Web Controls)
Similar to using items as picklists (somewhat) Data Type to create new field editors
So far there doesn’t appear to be an equivalent to Sitecore SubLayouts in Umbraco (to be able to have placeholders inside of controls/macros).
EDIT: Sub-templates seem to perform the general functionality of Sitecore Sublayouts.
Anything I’m missing or confused on?
Author :- by Jason.
Source:- http://www.proworks.com/blog/2009/07/15/sitecore-vs-umbraco-terminology/

15 December 2010

Sitecore Media URL

For one of my the latest projects the content editors were always trying to get the actual URL to a Sitecore media library item, but there is no easy way to see this in Sitecore. As developers we know it is in the form of /~/media/[ShortID].ashx or /~/media/[Path].ashx, but editors don't want to think about that. They just want it figured out and displayed in front of them.
What I wanted was something similar to the "Quick Info" section that gives develoeprs/admins a quick view into the important properties of a Sitecore item. This is what I came up with.

This minor change to the editor will allow a user to click on the URL of their choice and copy it to the clipboard.
To add this to your site you need a single class and a change to a pipeline.

   1:  /// <summary>
   3:  /// The ShowMediaPath class.
   5:  /// </summary>
   7:  public class ShowMediaInfo
   9:  {
  11:      private static readonly string SECTION_NAME = "MediaInfo";
  15:      /// <summary>
  17:      /// Gets a value indicating whether this section is collapsed.
  19:      /// </summary>
  21:      /// <value>
  23:      ///  <c>true</c> if this section is collapsed; otherwise, <c>false</c>.
  25:      /// </value>
  27:      private static bool IsSectionCollapsed
  29:      {
  31:          get
  33:          {
  35:              UrlString collapsedSections = new UrlString(Registry.GetString("/Current_User/Content Editor/Sections/Collapsed"));
  37:              string value = collapsedSections[SECTION_NAME];
  39:              return (string.IsNullOrEmpty(value) || (value == "1"));
  41:          }
  43:      }
  47:      /// <summary>
  49:      /// Processes the specified args.
  51:      /// </summary>
  53:      /// <param name="args">The args.</param>
  55:      public void Process(RenderContentEditorArgs args)
  57:      {
  59:          Item current = args.Item;
  61:          if (current != null && current.Template.FullName.StartsWith("System/Media"))
  63:          {
  65:              MediaItem mediaItem = current;
  69:              if (mediaItem != null)
  71:              {
  73:                  bool renderMediaInfo = !IsSectionCollapsed || UserOptions.ContentEditor.RenderCollapsedSections;
  77:                  args.EditorFormatter.RenderSectionBegin(args.Parent,
  79:                      "MediaInfo",
  81:                      SECTION_NAME,
  83:                      "Quick Info (Media)",
  85:                      "People/32x32/atom.png",
  87:                      IsSectionCollapsed,
  89:                      UserOptions.ContentEditor.RenderCollapsedSections);
  93:                  if (renderMediaInfo)
  95:                  {
  97:                      RenderMediaInfo(args, mediaItem);
  99:                  }
 103:                  args.EditorFormatter.RenderSectionEnd(args.Parent, renderMediaInfo, true);
 105:              }
 107:          }
 109:      }
 113:      /// <summary>
 115:      /// Renders the media info.
 117:      /// </summary>
 119:      /// <param name="args">The args.</param>
 121:      /// <param name="mediaItem">The media item.</param>
 123:      private static void RenderMediaInfo(RenderContentEditorArgs args, MediaItem mediaItem)
 125:      {
 127:          StringBuilder sectionText = new StringBuilder();
 131:          sectionText.Append("<table cellpadding=\"4\" cellspacing=\"0\" border=\"0\">");
 133:          sectionText.Append("<col style=\"white-space:nowrap\" align=\"right\" valign=\"top\" />");
 135:          sectionText.Append("<col style=\"white-space:nowrap\" valign=\"top\" />");
 139:          // we will give them absolute URL's
 141:          MediaUrlOptions o = new MediaUrlOptions { AbsolutePath = true };
 145:          // Get the path of the media item using it's path
 147:          o.UseItemPath = true;
 149:          sectionText.Append("<tr><td>Url by Path:</td><td>");
 151:          sectionText.AppendFormat("<input class=\"scEditorHeaderQuickInfoInput\" readonly=\"readonly\" onclick=\"javascript:this.select();return false\" value=\"{0}\"/>", MediaManager.GetMediaUrl(mediaItem, o));
 153:          sectionText.Append("</td></tr>");
 157:          // Get the path of the media item using it's ID
 159:          o.UseItemPath = false;
 161:          sectionText.Append("<tr><td>Url by ID:</td><td>");
 163:          sectionText.AppendFormat("<input class=\"scEditorHeaderQuickInfoInput\" readonly=\"readonly\" onclick=\"javascript:this.select();return false\" value=\"{0}\"/>", MediaManager.GetMediaUrl(mediaItem, o));
 165:          sectionText.Append("</td></tr>");
 169:          // is it File or DB media?
 171:          sectionText.Append("<tr><td>Media Location:</td><td>");
 173:          sectionText.Append(mediaItem.FileBased ? "File System" : "Database");
 175:          sectionText.Append("</td></tr>");
 179:          sectionText.Append("</table>");
 183:          args.EditorFormatter.AddLiteralControl(args.Parent, sectionText.ToString());
 185:      }
 187:  }
You will need also to modify a pipeline. I would suggest creating a ShowMediaInfo.config in the /App_Config/Include directory with the following:

   1:  <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
   3:    <sitecore>
   5:      <pipelines>
   7:        <renderContentEditor>
   9:          <processor patch:before="processor[@type='Sitecore.Shell.Applications.ContentEditor.Pipelines.RenderContentEditor.RenderSkinedContentEditor, Sitecore.Client']"
  11:                     type="NAMESPACE.ShowMediaInfo, ASSEMBLY" />
  13:        </renderContentEditor>
  15:      </pipelines>
  17:    </sitecore>
  19:  </configuration>

The idea for this was based on some code that a colleague of mine at Hedgehog Development had written.
Author:- Sean Kearney
Source:- http://seankearney.com/2010/08/default.aspx

Visual Studio Projects and Sitecore

This is a topic that I've been meaning to cover for some time now, but it is this post by John West that pushed me to do it sooner rather than later.
There are basically two ways of working with Sitecore.
  1. Your solution, and code, is fully immersed in the Sitecore web site.
  2. Your solution, and code, is outside of Sitecore's web site and you use some post build process to deploy.
John's post, and Sitecore documents, suggests that you go with option 1. I, however, do not agree that this is the right way to go. I feel that my code should not be mixed in with over 6,000 of Sitecore's files. Here are some reasons:
  1. The most important advantage is a clear understanding of the ownership of files in the solution. Everything checked into source control is explicitly owned by the solution being developed. All other files are owned by Sitecore or a third party package installed in Sitecore.
  2. I want to be able to distinguish my files from Sitecore's just by looking on the file system.
  3. If I need to ship the code to my client I simply want to zip up my 'workspace' and not have to wade through out-of-the box Sitecore files.
  4. I want my development environment to be as close as possible to a production environment. This means no .cs files in my web root
I've been working outside of the web root for three years now and wouldn't consider it being any other way. In fact, I am always wondering why you would want to work out of the web root as Sitecore suggests. I spoke to a client recently, while proving support for Team Development for Sitecore, and their answer was simply, "we didn't know better." That isn't acceptable.
Here is the way I work and highly suggest you work as well.
  1. Use IIS and configure Sitecore somewhere other than C:\[Workspace]\[Client]\trunk\. For example, C:\Sitecore\[Client]\Website
  2. Create your Visual Studio solution (and projects) outside of the web root. i.e. C:\[Workspace]\[Client]\trunk\ClientWebsite.sln
  3. Add references to any Sitecore assemblies as needed. Make sure to set "Copy Local" to false as John West suggests.
  4. Use a post build step to copy the output of your compiled Web Application project to the location specified in step 1. Or, better yet, use Team Development for Sitecore to handle the deployment for you.
  5. To debug, you will need to make a change to the Web Application project. On the 'Web' tab of the properties for your Web Application project you should choose the "Use Custom Web Server" option and enter in your development Sitecore URL. Once this setting has been specified you can now press F5 to build your project and debug normally. This may require some IIS components to be enabled, depending on your system. This will also work for IIS running on a remote machine (and virtual machines) as long as remote debugging components are installed on the remote machine.
Taking this one step further, you NEED to be using source control and automated builds in your development. Continuous Integration is also a good practice and possible using Team Development for Sitecore! Cost shouldn't be an excuse either as there are free tools out there to help you with this!
We, at Hedgehog Development, have done a good number of Sitecore sites this way and we do consider this a best practice. We are able to bring new developers onto a project in minutes and can roll out builds effortlessly.
I would love to get some feedback on this. Please let me know if you love working out of the web root as Sitecore suggests.
Author :- Sean Kearney
Source:- http://seankearney.com/2010/10/default.aspx

5 worst code smells in Sitecore

Last year I wrote a blog post on doing code reviews on Sitecore. While dealing with conceptual issues it doesn’t really say what to look for in code, when evaluating the quality or to evaluate if any wrong decisions have been made when developing the solution.  Therefore I wanted to wright a post about the top 5 code smells I look for, when I am trying to evaluate or trouble shoot a Sitecore solution. These code smells often indicate that the developers have gone down the wrong road and there is something fundamentally wrong in the architecture.
So here goes:
1) Using the descendant axes in xpath expressions:
This one I especially look for, when I am looking at a site which doesn’t perform. It may be used in some cases, but very often I find that a developer has used this to generate relations between content and thereby iterating over the complete content tree. This works fine in development where there are a few hundred content items. However in production where thousands of items are created this simply breaks the performance of the site – especially after publishing which clears the HTML cache.
The descendants can be accessed in multiple ways. In XSLT it normally looks like this:
<xsl:for-each select=”$sc_currentitem/descendant-or-self::item”>
</xsl:for-each>Or like this:
<xsl:for-each select=”$sc_currentitem//item”>
In C# using the Sitecore API it is most often accessed like this:
2) XSLT Import:
This is related to a point in the post about code reviews on Sitecore, where I argue that overcomplicated functionality and logic in XSLTs, is a problem. If you need to do an import of another XSLT in your rendering, you probably do it to call a method or in another way try and reuse functionality. If you want to do this, don’t use XSLTs! XSLTs should only – if you really want to use them at all – hold simple presentations.
XSLTs can be imported like this:
<xsl:import href=”YourOtherXslt.xslt” />
3) Explicitly accessing the master database
Although this can be needed in some cases and especially in scheduled tasks or other backend functionality, most often it is because the developer haven’t thought the issue through or if they have made a wrong decision of how data entered by the user should be stored.
The master database is most often used like this in c#
Database masterDatabase = Database.GetDatabase(“master”);
If you see a call like this, your solution is most likely not ready for staging, where there is no access to the master database from the content delivery server. You should generally use something like this:
Database database = Sitecore.Context.Database ?? Sitecore.Context.ContentDatabase;
This means you operate on the context database and on the content delivery databases this will be the web database and in preview you will use the master database, which is probably what you want.
If you need to write something to the master database, you first need to decide if this is a good idea at all. If you write to the master database from your frontend, you make yourself vulnerable for malicious attack, as people from the outside can enter data into the master database. Normally we handle user entered data in a custom database or parse all user created content to ensure that the master database won’t be flooded with data.
If you really need to access the master database, you should create a service that handles access to the master database, so that your solution is ready for staged environments.
4) XSLT extension over 100 lines of code:
This point is closely related to point number 2, but I really see a lot of issues with XSLTs which have been used wrong and this creates a lot of issues later on in the project lifecycle. If you have an XSLT extension with over a hundred lines of code, chances are, that the developer made a wrong decision when creating the XSLT; instead he/she should have created a sublayout.
XSLT extensions are functional programming and you should use an object oriented approach, so my advice is not to use XSLTs at all, unless you are doing something really simple. Otherwise your solution will become harder and harder to maintain, as utility methods like the XSLT extensions are very hard to understand and couplings in the renderings themself are difficult to map.
You can find all registered XSLT extensions in the web.config under xslExtension and it looks something like this:

   1:  <xslExtensions>
   3:    <extension mode=”ontype=”MyNamespace.XslHelper, MyAssemblynamespace=”http://www.example.net/helpersingleInstance=”true/>
   4:  </xslExtensions>
5) Clearing of cache
This may seem obvious to some, but I have seen surprisingly many methods, which cleared the entire Sitecore cache including the data and item cache. If you see this in your code and it is needed, chances are, that you have an architectural issue in your solution. It should most rarely be needed to clear the cache, unless it is after a publish and Sitecore handles this automatically. I have heard many reasons for clearing the cache including an issue, where the developer argued that it was necessary, as he wrote directly to the Sitecore database with a SQL statement, and then Sitecores cache wasn’t updated.
If you experience something like this, the issue is of cause not the cache, but that you don’t use the Sitecore API to read and write data from the database.
The caching is most often cleared like this:
This is just some of the things I have seen many times, but I know there are many other bad code smells when developing Sitecore solution. Do you have any other code smells to share?
~ by Jens Mikkelsen
Source:- http://mcore.wordpress.com/2010/08/03/5-worst-code-smells-in-sitecore/

Publishing strategies

Publishing can be quite an issue for content authors and make an impact on performance. However if you use the right strategy, there really isn’t any issues.
One of the issues with publishing can be performance. When you publish one or more items the HTML cache is cleared, which means that if you have some performance heavy presentations, it will increase the loading time of the page, until the cache has been rebuild. Further if you use the staging module and it is configured to it, all the data caches are cleared as well. This can cause the site to take up to 30 seconds to reload your pages – especially if they are data heavy. You can read more about Sitecore Caching here and read about the issues with cache and the staging module here.
Note that Sitecore recently released a staging module which supports partial item caching, but the HTML cache is still cleared. You can read more about the new module on Alex Shybas blog.
I don’t know if performance impact when publishing is specific to Sitecore or is generally a problem in most CMS’, but I reckon it is the later. However Sitecore has a special problem with regards to caching. As Sitecore isn’t page based as many other CMS’ (this is also one of its biggest advantages), it makes it difficult to have a partial cache clearing – especially with regards to HTML cache. A page can be constructed by several content items, and there are no immediate binding between a page and the items, which it is constructed of, so all HTML caches needs to be cleared even though you just publish one item.
Another issue is the usability for content authors. Some of our clients were complaining about being queued all the time when they initiated a publish and it could take a very long time before they got their content published. What often happened was that when they initiated a publish, the modal dialog reported, that they were queued. Instead of waiting for it, they closed the window and continued editing. A few minutes later they would initiate another publish, but was once again told that they were queued. When this process repeated itself for the 50 active content authors, you can imagine the queue could get quite big.
Another thing we stumbled upon was, that some content authors used publishing instead of preview. Every time they wanted to view their work in progress to check if it looked alright frontend-wise, they published the item and viewed the page as if it was already completed and ready for actual publish.
I know we are not the only Sitecore partner experiencing this, as I have talked to other implementation partners and received questions about it on Learn Sitecore.
So why do I suggest it isn’t a problem? Well… we aren’t really experience any issues with our clients or with performance issues caused by publishing anymore. This is a result of more than one thing, but the primary solution was to use scheduled publish.
I don’t know why, but using this publishing strategy this can be a really big issue for clients. We often heard remarks like: “We need to publish content immediately”… But common! I really haven’t worked with many organizations, where this is an actual issue. What content do these organizations have, which is so important, that they can’t wait 15 minutes (at tops) to be published? I have consulted clients with huge sites, which is absolutely critical to the business and the funny part is that these companies rarely have a need to have immediate publishing. They are normally used to having a longer waiting period for the rest of their web services due to replications tasks between 100s of servers and rebuilding of caching. So why do the smaller companies have a bigger need for immediate publishing? The short answer – they don’t!
So what do we do to convince our client to use scheduled publish? We do more than one thing: First of all we explain to them, what impact publishing has. Then we allow a single or a few admins to have publish rights, so that they can have immediate publishing. Further we set the “do not publish” mark on all newly created items, so that they won’t be accidently published while they’re not finished. The authors will have to unclick the setting, when they think the item is ready for publishing.
Finally we have developed something, which in my opinion is rather cool! We acknowledged that people respond best to waiting time, if they have an indication of when the waiting will come to an end. This fact is also one of the reasons why they have timers on traffic lights in Copenhagen:
Traffic light with timer
7 seconds to green light :)
We decided to use the same strategy for scheduled publishing. If the content authors would know, when the next scheduled publish is due, they would be much more satisfied with the idea of not having immediate publishing. So we – in Pentia – developed a timer which is shown in the task bar in Sitecore:
scheduled publish timer
The scheduled publish timer in action
The “Trinvis udgivelse” is Danish and mean incremental publish. So this timer tells the content author, that there is 12 minutes and 48 seconds to the next incremental publish. The functionality also supports multiple timers, so on some solutions we also use it to indicate, when an import from an external database is due and so forth. Cool, right?
These things combined we really don’t have any issues, with convincing our clients to use scheduled publishing.
~ by Jens Mikkelsen
Source:- http://mcore.wordpress.com/2010/01/22/publishing-strategies/

Sitecore Lucene index viewer 1.2 released

Last week I was contacted by the Sitecore Shared Source coordinator Jimmie Overby and he told me that a guy in the Sitecore Ukraine office had made some changes to the Sitecore Lucene IndexViewer, I released some time ago. At first I was a bit sceptic about it, so I asked to review the code changes and see the new functionality. So I installed the new package and looked through the code, and I discovered that the Sitecore Ukranian Vyacheslav Tronko (don’t ask me to pronounce it:)) had done a fantastic job!
Not only had he added some very nice features but he had rewritten some of the code so the application is more stable and extendable. So I really appreciate his work!
The new features are:
  • Possibility to browse indexes defined in the new search section in the web.config
  • Rebuild indexes through the IndexViewer (which is really nice, as you can’t rebuild the new type of indexes any other way)
  • Optimize indexes.
  • Improved usability and look-and-feel of the application
So go take a look at the changes at http://trac.sitecore.net/IndexViewer
If you want to see some screenshots of the new features, take a look here
What I would like to add next, is extended search functionality.
~ by Jens Mikkelse

Agile Sitecore design

It been a while since my last blog post – my second child Annika was born March 16th and since then I’ve been forced to realize that two children takes up a lot of blog-writing time.
A year ago I wrote a post titled Type before function, which pointed out the very type-centric design of Sitecore. Since then, we have in Pentia tried to develop a design practice which focuses more on isolating logically grouped functionality in our design and thinking outside the type-centric nature of Sitecore. For this purpose, we have “invented” the term component in our design. The purpose of components is to separate the functionality from the type, allowing the developer to focus on one purpose and its interfaces.
The practise has been quite successful – our large-scale solutions have become increasingly easy to maintain and extend. As a side effect of the process, we now have a high degree of reuse – not just knowledge, but actual code – between even seemingly un-similar projects. Not very surprisingly, it turns out that developers are more inclined to reuse code, which is easily overviewed. The design practice is so successful, that we have passed it on to external projects, through our Professional Services.
Here are a few tips on getting you started:

Consistent placement and naming

Not all items belonging to a component can be placed together. Naming and placement makes it easier to identify component items – in a type-centric system.
Keep your files together – we never use the standard Sitecore folders, e.g. /xsl and /layouts. All files in a component are placed below a folder named /Components/[ComponentName]. This makes it easy to identify which files belong together without e.g. garbling the filename with unnecessary prefixes. And if you think about it, it’s not hard to identify a file as an XSLT – so why put it in the/xsl folder? Keeping component items together also goes for templates, renderings and layouts in Sitecore. For the purpose of Sitecore best practice, we still place templates under /sitecore/templates (although I suppose it’s not strictly necessary), and layout items under /sitecore/layouts. But we always use subfolders which are named consistently, e.g. /sitecore/templates/Components/[ComponentName].

Component projects

Each component has a separate Visual Studio project, and therefore a separate assembly. Aside from grouping files even further, this also helps to identify dependencies between components. Use build events on the project to move files from component folders to website folders if needed.

Interface templates

Think of templates in Sitecore as interfaces – never basetypes – which provide your pagetypes or data items with certain functionality. Always refer to these interfaces in the code within the components.
Example: The component Navigation (menu, breadcrumb and sitemap) defines the template Navigable with the fields Menu Title and Show In Menu. This template is assigned to the pagetypes which can be shown in the menu. The renderings Menu.xslt and Breadcrumb.xslt only references the Navigable template by using the XslHelper.IsItemOfType() method (or your own more optimized version).

Common components

There are a number of components which is always in a project, and which brings the functionality of the other components together.
The Design component contains all the graphic design for the project. Do not be tempted to place stylesheets and graphics within each component – the design for a single component is always related to other components, and therefore you will be forced to create unnecessary dependencies.
The PageTypes component brings together the interface templates and renderings and sublayouts in the other components on the actual page type template. Only page type templates are instantiated in the content tree. If you define the page type template News in the News component and not in the PageTypes component, you will be forced to create dependencies to other components e.g. Navigation.

Dependencies and Inversion of control

Keep your dependencies amongst components as few and as obvious as possible. It should not be necessary for a developer to know more than the component he is working on – too many dependencies makes the components too complex and less flexible. The common components is one way to reduce dependencies, another is the use of the inversion of control pattern and possibly an IoC container. Suppose the News component uses the Indexing component for providing data quickly. This could naturally be done by calling the indexing component directly through the News code, thereby creating a dependency. Alternately the News component could provide an appropriate interface which defines its necessary functionality. This interface could be implemented by the Indexing component and instantiated though Reflection or an IoC container like Unity or Spring, thereby inverting the dependency and making the News component more lean.

Introducing the Lucene Index Viewer

I have earlier complained about Sitecore 6 Lucene implementation hard-coding compression, making it impossible to view the index in Luke. Further I have often wanted to view an index in production, where a Luke installation wasn’t allowed.
Therefore I decided to implement an index viewer and I am proud to announce, that it is now released. It has been added to the Sitecore Shared Source modules. Go to http://trac.sitecore.net/IndexViewer to download the package or the source. To see some screenshots go to http://trac.sitecore.net/IndexViewer/wiki/Documentation.
In the IndexViewer it is possible to: See information about an index (Last modified, number of ducuments etc.), browse the documents in an index and search through the index using different Lucene Query types.
Let me know if you have any comments, feature request or similar. Enjoy!

Sitecore Rocks – preview the future of Sitecore development

A new tool called Sitecore Rocks has been released in a CTP (Community Technology Preview) version – a early sneak peek. The tool, although a little rough around the edges, really shows a bright new future for Sitecore development, a future where we as developers do not need to muck about with browsers interfaces, only to connect our code, .NET pages and user controls into Sitecore. Now we can stay within in the tool we use and like, Visual Studio.
Together with the Team Development for Sitecore module from Hedgehog, this tool looks to be a must-have in the Sitecore developer toolbox.

In short, Sitecore Rocks is a Sitecore editing environment in Visual Studio. The environment naturally does not contain the complete set of features of the Sitecore content editor, but is focused on the features we as developers use. This includes for example:
  • Quick and easy navigation in the content tree and on the item editor.
  • Multi-item editing.
  • Linking Visual Studio project to Sitecore, and automatic creating of layout related items in Sitecore from your .NET files.
  • Live Sitecore log viewer.
  • Job viewer allowing you to examine running tasks in Sitecore.
  • Edit rich text fields in Visual Studio HTML editor/designer.
  • Easy interface for layout management.

You can watch a video of Lars Fl√łe Nielsen presenting some of the Sitecore Rocks features here.
In my view, the tool is very nice and definitely a vision of what’s in store for us as developers, but the tool is still in the early phase and still has a lot of unused potential. Personally I feel that one of the most promising features is the ability for everybody to extend the functionality, and hopefully this will create a flood of shared source plug-ins with really useful features. Of the top of my head, I can mention countless possibilities, so drop a comment if you have a lot of time on your hands :-)

The tool is available through the Visual Studio 2010 Extension Managers Online Gallery – just open it up in Visual Studio and search for “Sitecore” – or download Sitecore Rocks from the MSDN:

Posted in Sitecore, New releases

Cleanup html with one button click

It is possible to create your own buttons in the rich text editor. This can be used to create your own functionality. For instance I recently had to make a button that cleans up the HTML entered in a rich text field. Now this functionallity is allready present in Sitecore, but it is devided into 5 steps. E.g. remove font tags, remove span tags etc.
In this particullar case we wanted a button to perform a cleanup tasks, that included three of these methods. Instead of clicking three times to remove font tags, css styling and word formatting, we needed to create a button that did all of these tasks, by clicking one time only. This can be done by:

Step 1:
Create the button in Sitecore. The buttons for the editor is found in here: Sitecore > System > Settings > Html Editor Profiles > Rich Text Default > Toolbar X.
Now copy an existing button and rename it to what ever you like. In this instance we'll call it CustomCleanup. In the field "Click" you can enter a string, that will be fired when the button is clicked. You can later catch when this message is fired. Put in what ever string you like. In this case we'll enter "CustomCleanupTask".

Step 2:
Now we need to catch the message. This is done in the javascript file: sitecore/shell/Controls/Rich Text Editor/RichText Commands.js. Now add the following to the file:

   1:  RadEditorCommandList["CustomCleanupTask"] = function(commandName, editor, tool) {
   3:  /* Fire new events */
   4:  editor.Fire("CSS",tool);
   5:  editor.Fire("FONT",tool);
   6:  editor.Fire("WORD",tool);
   8:  };
P.s. you can alter the icon on the button, by adjusting the Icon field on the button. This path is taken from /sitecore/shell/RadControls/Editor/Skins/*/Buttons

Now you have your new functionality. Remember to clear the cache.

Getting an items rendering

Often you need to get the rendering(s) used to render a given item from a codebehind. You want to get the rendering, that the rendering engines uses. That means, that if there isn't a rendering on the item, you should look at the template and so forth.
I spent some time figuring out, how this is done (I actually ended up asking Sitecore Support), so I thought I would just share it with you:

/*First you need the item you want the renderings from. In this case lets use the current Item */
Sitecore.Data.Items.Item item = Sitecore.Context.Item;
/*We also need the device, so we get the renderings attached to that. */
Sitecore.Data.Items.DeviceItem device = Sitecore.Context.Device;

/*This is how you get the rendering */
Sitecore.Layouts.RenderingReference[] renderings = item.Visualization.GetRenderings(device, true);

This is actually pretty simple,which might be the reason for me not figuring it out. ;)
As you now have an array of RenderingReference, you can look up the rendering by its ID or whatever.

Relational Data 1 - Indexing

All though a bit late (been quite busy), here is the first post about relational data.
As I described you might want to do some relational operations on data structured as a hierarchy in Sitecore. The example was news which might need to be sorted and listed on the frontpage or similar, is the one I am going to address first.

Most of the times when I stumble upon issues like this, I solve it with indexing. That is building a relational data set from the hierarchy. When working for clients, most of the times I have solved this issue using Ankiro. However Ankiro cost money, so I thought I would try it out with Lucene. Below you can see an example of how to do this.

Please note that by default Lucene doesn’t index on publish, but by a scheduled task that as default runs every five minute. However it is possible to customize Lucene to index on the publish event.

Well here it the technical description:
First of all you need to create the index containing the data you want to use as relational data. This is done pretty easy in web.config. Further reading is available on SDN (
Basically you define the index in the <indexes> element :

   1:  <index id="newsIndex" singleInstance="true" type="Sitecore.Data.Indexing.Index, Sitecore.Kernel">
   2:    <param desc="name">$(id)</param>
   3:  <index id="newsIndex" singleInstance="true" type="Sitecore.Data.Indexing.Index, Sitecore.Kernel">
   4:    <param desc="name">$(id)</param>
   5:    <templates hint="list:AddTemplate">
   6:      <!-- Enter the id of your news template -->
   7:      <template>{96479B71-2C0B-4729-8301-080145F28FA6}</template>
   8:    </templates>
   9:    <fields hint="raw:AddField">
  10:      <!-- add the fields you want in your index -->
  11:      <field target="created">__created</field>
  12:      <field target="updated">__updated</field>
  13:      <field target="author">__updated by</field>
  14:      <field target="published">__published</field>
  15:      <field target="name">@name</field>
  16:      <field target="id">@id</field>
  17:      <field target="Title">Title</field>
  18:      <field target="Abstract">Abstract</field>
  19:      <field target="Release date">Release date</field>
  20:    </fields>
  21:  </index>

This defines the index. Now add it to the web database:

   1:  <database id="web" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
   2:  ...
   3:    <indexes hint="list:AddIndex">
   4:      <index path="indexes/index[@id='newsIndex']"/>
   5:    </indexes>

You can now rebuild indexes for the web database through the Control Panel in Sitecore.

Now that you have the index, you can do you relational operations. For instance you might want to sort by date. Here is some sample code to retrieve an arbitrary number of news items from the index sorted by the “Release date” field. (I don’t like to use the system fields __updated or __created as these might change when you upgrade or similar).

public Document[] GetLatestNews(int numberOfNews)


  //Get the Lucene IndexSearcher

  Index newsIndex = Sitecore.Configuration.Factory.GetIndex("newsIndex");

  Database web = Sitecore.Configuration.Factory.GetDatabase("web");

  IndexSearcher searcher = newsIndex.GetSearcher(web);


  //I want to sort by the release date

  Sort sort = new Sort("Release date",true);


  //I want all documents that has the field Release date

  Query searchingxml = new WildcardQuery(new Term("Release date", "*"));


  //Get all the hits sorted

  Hits hits = searcher.Search(searchingxml, sort);


  //How many documents should be returned

  int noOfNews = hits.Length() > numberOfNews ? numberOfNews : hits.Length();

  Document[] docs = new Document[noOfNews];


  //Iterate over the hits and return the number of news I want as documents

  for (int i = 0; i < noOfNews; i++)


    docs[i] = hits.Doc(i);


  return docs; 

This returns the latest news, which you can list in your spot or whatever you want to do.

The advantages of using index’ is:
You got the advantages of a hierarchy in the backend.
The end user doesn’t feel or see any other technology then Sitecore.
It is simple and easy to implement and maintain.

The disadvantages of using index’ is:
It is replicated data. This takes up more space and I often find problems with inconsistency between index’ and Sitecore data.
You got the disadvantages of a hierarchy in the backend.

Relational data in Sitecore - Intro

Content and data in Sitecore are structured as a hierarchy. This gives a lot of advantages, but sometimes you got some relational data, that you fit into a Sitecore structure. This has some disadvantages. First of all the relational data might not be user friendly and intuitively structured, when saved in a Sitecore database. Secondly some operations that you need to perform on the data might be extremely slow, when structured as a hierarchy.

A good example of this, is something I have done on almost every solution: News and news lists. This can be structured as a hierarchy in the backend, but often requires operations on the frontend, that only performs, when the data is in a table. Something that is very normal is a front page spot, which lists the X number of latest news of a special type. This would normally require you to iterate over all items in your content structure, which doesn’t perform unless your site consist of very few nodes.

In a couple of posts on this blog, I will try and show some different solutions to the problem.

Logs and performance

I was recently assigned to monitor and report on some issues with performance. I was told to log some information about how long different requests on pages took. Here I stumbled upon two things that I didn’t find all that well documented on SDN5.

1. Logging with log4net. I needed a separate log file, as I didn’t want all my entries to mess up the standard log file.
2. There are performance counters in Sitecore, but I didn’t know where I could find these.

So I thought I’d just report my findings on my blog to the help of others.

Creating a separate log in log4net is actually quite simple. Go to the log4net section in the web.config. Here you can add a new appender that writes to a separate file:

If you look at the LevelRangeFilter, you’ll see, that you can specify a min and max level. There are different levels and you can specify which levels to write to the given logfile. The level ranges from DEBUG to FATAL. There are as default these levels: ALL, DEBUG, INFO, WARN, ERROR, FATAL.
In this case I only want the DEBUG information written and keep that level out of the Sitecores log file. Therefore I changed the Sitecore appender to range from the level INFO to FATAL:

  <appender name="PerformanceFileAppender" type="log4net.Appender.SitecoreLogFileAppender, Sitecore.Logging">

    <file value="D:/MyPath/Data/logs/Performance.{date}.txt" />

    <filter type="log4net.Filter.LevelRangeFilter">

      <levelMin value="DEBUG"/>

      <levelMax value="DEBUG"/>


    <appendToFile value="true" />

    <layout type="log4net.Layout.PatternLayout">

      <conversionPattern value="%-21t %d %-5p %m%n" />



I then altered the root element to include my appender and altered the level requirements to ALL:


<priority value="ALL" />

<appender-ref ref="LogFileAppender" />

<appender-ref ref="PerformanceFileAppender" />


Now I can write to my custom log file by using the ILog interface and use the method Debug:

ILog perfLog = LogManager.GetLogger("PerformanceFileAppender");
perfLog.Debug(”Hello world!”);

You can read more about it at log4nets page. Here you can also read about different types of appenders and much more.

So now I had a log I could use for debugging. Now I just needed the performance counters. So I looked at the HttpRequestBegin pipeline. There I found a processor called StartMeasurements. Thanks to Lutz Roeder’s Reflector I found that Sitecore starts a timer and stores it like this:

Context.Items["SC_REQUEST_MEASUREMENT_TIMER"] = new HighResTimer(true);
And the requested URL like this:

Context.Items["SC_REQUEST_MEASUREMENT_URL"] = args.Context.Request.RawUrl;

Now all I had to do, was to hook in on the httpRequestEnd pipeline and add my own processor that would log the time elapsed. So I added this just before the StopMeasurements processor:

<processor type="MyNameSpace.MeasurementLogger, MyNameSpace">

I then created a new class and added the debug logging:

public class MeasurementLogger


#region private properties

private static readonly ILog perfLog = LogManager.GetLogger("PerformanceFileAppender");



public class MeasurementLogger


#region private properties

private static readonly ILog perfLog = LogManager.GetLogger("PerformanceFileAppender");



public void Process(HttpRequestArgs args)


HighResTimer timer = Sitecore.Context.Items["SC_REQUEST_MEASUREMENT_TIMER"] as HighResTimer;

string timeElapsed = timer.Elapsed().ToString();

string requestedUrl = Sitecore.Context.Items["SC_REQUEST_MEASUREMENT_URL"] as string;


perfLog.Debug("HTTPRequest time: " + timeElapsed + " Url: " + requestedUrl + " Domain: " + args.Context.Request.Url.Host);



And that’s it. Now you’ll write the elapsed time on all requests to the performance.{date}.txt log file.
Some might see this as overkill, as you can use the stats.aspx or IIS log files etc., but none the less this gives an introduction using log4net as well as hooking into a pipeline.

There will come more posts about relational data, I just haven’t finished them yet.

Sitecore friendly html, css and javascript

Disclaimer: While some of these guidelines may be applied to other Content Management Systems, or .net web forms in general, this is based on my experience with Sitecore.
A common approach of having a CMS based web site implemented usually goes as follows:
  1. Company X (aka 'The Client') approaches a design firm.
  2. Said design firm paints a lot of pretty pictures (also known as wire-frames, mock-ups, etc..), which the client gets sold on
  3. The design firm (or a subcontractor) will cut up those pretty pictures into HTML/CSS/JS files.
  4. That design firm chooses a Sitecore partner to do the implementation of their super clean front-end work.
While I am greatly generalizing, this is a common approach. The point I am hoping to address is that design firms (who aren't familiar with .net or Sitecore) are very likely to make things difficult for the implementation team. Here are a few issues I have seen over the last few projects.
ID attribute on html elements
This is another broad statement, but take it at face-value to avoid problems. Front end developers will reference an element via the id attribute for css styling as well as jQuery (or any other client side framework) manipulations. While this sounds like a very normal approach it can lead to issues when that element gets converted into a .NET Server control and this tag:
<input name="q" id="q" type="text" />
is now this tag:
<input name="ctl00_Main_q" id="ctl00_Main_q" type="text" />
This annoying rewrite of the id attribute will break all pre-written css and javascript written for that id. As back-end developers we know that only id's of server controls (or regular tags with runat="server") will be rewritten, but is easier to have front-end dev's avoid referencing elements by id them all together.
HTML Patterns
In general, repeating patterns are very easy to program. Avoid throwing unnecessary id's and classes on elements. A perfect example would be for navigation elements; a side menu should be a simple nested unordered list with no extra classes. Having classes that change based on content, depth in site, etc... it will require logic, which takes time to implement.
Do this:



<h1>Nav Header</h1>


        <li><a href="#">Level 1a</a>


                <li><a href="#">Level 2a</a></li>

                <li><a href="#">Level 2b</a></li>

                <li><a href="#">Level 2c</a></li>



         <li><a href="#">Level 2a</a>


                <li><a href="#">Level 2a</a></li>

                <li><a href="#" class="selected">Level 2b</a></li>

                <li><a href="#">Level 2c</a></li>




Not this:



<h1>Nav Header</h1>

    <ul class="mainNav">

        <li class="first"><a href="#">Level 1a</a>

            <ul class="subnav">

                <li class="first"><a href="#">Level 2a</a></li>

                <li><a href="#">Level 2b</a></li>

                <li class="last"><a href="#">Level 2c</a></li>



         <li class="last"><a href="#">Level 2a</a>

            <ul class="subnav">

                <li class="first"><a href="#">Level 2a</a></li>

                <li><a href="#" class="selected">Level 2b</a></li>

                <li class="last"><a href="#">Level 2c</a></li>




Obviously this is an overly simplistic menu system that cannot always be accomplished. My main point here is to avoid classes on elements that aren't absolutely necessary. We can use basic css selectors to get at elements without having to provide more classes to denote first and subnav.
If you have ever seen a Sitecore sales demo you have undoubtedly seen the presenter effortlessly change the layout of the page. Possibly adding some 'widgets' to the side or changing the entire layout from two to three columns? Sitecore allows renderings and sublayouts to be placed within placeholders. This introduces a lot of flexibility for the design of site, however, it does require a lot of forethought to make sublayouts look nice in multiple locations.
In order to make your sublayouts (or any other custom 'widgeting' system) work and look great you should follow a couple guidelines.
  1. Keep your html super lean and clean.
  2. Object Oriented Css
Design Images
This is just my preference on how to organize the file system of a Sitecore site and you may have your own system and that is fine. Whatever system you choose, just be consistent as sites can grow big quickly and managing these little files can become daunting.
  • Images referenced from css files should go in an "images" directory underneath the css directory. Furthermore, keep image paths relative to the css file.
  • Any leftover images required for the design should go in a /images directory.
  • Placeholder images should be prefixed with "fpo_" which makes it easy to identify these images as being good candidates to be moved into Sitecore media library.
Multi-Lingual Considerations
Manipulating the DOM with Javascript is trivial with the introduction of client libraries such as jQuery. A potential issue will arise when a developer hard codes in a language specific string (such as 'open,' 'close,' etc...) in a javascript function. In order to avoid this pitfall have the translatable text reside in a hidden span on the page, not in the javascript code.

Author:- Sean Kearney
Source:- http://seankearney.com/post/Sitecore-friendly-html-css-and-javascript.aspx