Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Experience Sitecore! | January 2017

Experience Sitecore!

Martin Miles on Sitecore

Why am I getting "Item is not a template" error on data items in Content Editor?

Very simple and even stupid error I have met few times, just want to describe it here to make it google-searchable so that it might help someone.

Image you're going across you content items , and when clicking by one of your data items, you see similar screen, saying: Item "/sitecore/content/Home/Data/Simple item" is not a template.



First of all, why does I got yellow screen? Well, the error is quite descriptive, saying that my Simple item is not a template.

Sure, it isn't, we know that and can prove that by clicking Content tab, that will show us exactly the item's data:


But why on earth do I see other two tabs, that shouldn't be there for data item?

The answer can be either of two cases:

1. Simple silly case - the template of you item is either directly inherited from default Template item (located at /sitecore/templates/System/Templates/Template) rather than Standard template (/sitecore/templates/System/Templates/Standard template).


In that case simply replace one with Standard template to fix.

2. More complex case - when you're likely to have a complicated inheritance chain, especially if you are working with Helix or playing around Habitat. It that case your data item is based on a composite template, that is likely to inherit multiple other templates, at least one of which inherits from Template rather than Standard template, exactly as described in a case above. Solution is the same as above - identify the culprit and change inheritance to Standard template.

Finally your data will be based on correct set of templates and you won't evidence unwanted tabs anymore.

Hope this post helps someone!

How to make Content Editor search by plain GUIDs without braces and dashes? (part 1)

How many times while inspecting the code you've encountered something similar to:


Of course, you've guessed that A50CC32DAC854E3D9FC3A6BFDE1C577E is nothing else but GUID of an item being modified for URL. And of course, in order to look up what this item is, you've pasted it into search box of Content Editor, as the easiest way to search. Content Editor in turn did not find anything as obviously that value isn't a properly formatted GUID. As a mature Sitecore developer, probably had to append braces and insert dashes in appropriate format, so that items becomes discoverable via search.

To overcome this, I created animprovement module that will allow you search by both plain and properly formatted GUIDs.

As for a starting point, I decided to find out what exactly happens after user submits value into a search box. Looking up ajax POST call to the backend suggested me that it should be a pipeline somewhere behind Content Editor application. Decompiling Sitecore.Kernel and Sitecore.Client prompted me to search pipeline, that is located at Sitecore.Pipelines.Search namespace of Sitecore.Kernel.

The very first step of that pipeline is called IDResolver and does exactly what he is named for: resolves an item for a search term in case it is properly formatted GUID and exists in database. If not - it passed arguments further down the pipeline.

So the idea is to create an extra processor after IDResolver that will do basically the same business but for search terms that are plain GUIDs. Okay, here's the code:

    public class SearchByPlainGuids
    {
        public void Process(SearchArgs args)
        {
            Assert.ArgumentNotNull((object)args, "args");

            if (string.IsNullOrWhiteSpace(args.TextQuery))
                return;

            if (args.Type == SearchType.ContentEditor && IsPlainGuid(args.TextQuery))
            {
                Item obj = args.Database.GetItem(new ID(MakeGuidQuery(args.TextQuery)));
                if (obj != null)
                {
                    SearchResult result = SearchResult.FromItem(obj);
                    args.Result.AddResultToCategory(result, Translate.Text("Direct Hit"));
                }
                args.AbortPipeline();
            }
        }

        private string MakeGuidQuery(string plainGuid)
        {
            return "{" + plainGuid.Substring(0, 8) + "-" + plainGuid.Substring(8, 4) + "-" + plainGuid.Substring(12, 4)
                   + "-" + plainGuid.Substring(16, 4) + "-" + plainGuid.Substring(20, 12) + "}";
        }

        private bool IsPlainGuid(string query)
        {
            string pattern = @"^[0-9a-fA-F]{8}[0-9a-fA-F]{4}[0-9a-fA-F]{4}[0-9a-fA-F]{4}[0-9a-fA-F]{12}$";

            Regex regex = new Regex(pattern);

            return regex.IsMatch(query);
        }
    }

To make this code function, let's build that into a DLL and reference that DLL from config patch file located within include folder:






      
    
  


Voila! Now you're able to search by item GUID regardless of its format.


Please feel free to download ready-to-use package (5.7KB) for Sitecore 8.1 and 8.2 or source code (9.1KB).

P.S. It all looks and works well, however what can be done better? First of all, we've modifies search pipeline, so our processor is called with every call of given pipeline. Next, we add extra DLL and extra config include file to reference that DLL. Wouldn't it better, if GUIDs were checked and modified right before entering that pipeline, ideally at the front-end? Let's try to make this function at part 2 of this story.