Nonconventional Use of Pipelines in Helix-Based Projects

Sometimes business requirements are hard to implement without violating helix principles and very small visible change requires massive refactoring, often consisting of pushing things down, to Foundation layer.

Let’s say we need a very simple meta title and description implementation. For all pages. We add a base template ‘_Meta Data’ with Meta Title and Description somewhere on Foundation level, add the template as a base to all pages on Project level and, to keep things simple, just render the fields somehow on our ‘Default Layout’.

So far so good. Project is growing, new features are being added and developed and at some point, we have new requirements: ‘Search’ feature should have different metadata on the search result pages and at the same time you need an ability to add a site name to all pages (including search).

So it has to be “Search results for <term> | Useful Site 1” or “About us | Useful Site 2”. Not nice for your helix-based solution?

But there is a workaround that helps you to avoid refactoring and unnecessary dependencies - good old Sitecore pipelines! Sometimes it is a very good idea to add a new pipeline and here we can use them as well.

Let’s define a new pipeline somewhere on foundation level. That will be a configuration, something like:

   ...
<pipelines>
    <group name=”projectPipelinesDomain” groupName=”projectPipelinesDomain”>
        <pipelines>
            <buildMetaTags></buildMetaTags>
        </pipelines>
    </group>
</pipelines>

(Please note the group here, it is a good idea to use a pipelines domain for all your custom pipelines.)

And second thing in the helix foundation is pipeline arguments, can be like this:

      public class BuildMetaTagsPipelineArgs : PipelineArgs
   {
       public Item ContextItem { get; set; }

       public string Title { get; set; }

       public string Description { get; set; }
   }

So we can set Item as an input for the pipeline and get Title and Description as its result.

Now we can

1. Define default metadata behavior as a base processor (in Foundation).
2. Modify/enrich data as needed in Feature modules - define feature-specific processors and make sure they applied after the base one.
3. Add postfix if needed in the end - after all possible modifications.

Maybe you will have to adjust processors patch order in Features so they won’t conflict, and here is where you will have some kind of dependencies between feature modules. That is not the best way, but acceptable in most cases, when modules functionality is not overlapping and order of processors doesn’t matter.

Now, it is time to use the pipeline:

   var args = new BuildMetaTagsPipelineArgs { 
    ContextItem = GetContextItem() 
};
CorePipeline.Run("buildMetaTags", args, "projectPipelinesDomain");
viewModel.MetaTitle = args.Title;

With such pipelines Feature module can use and modify data prepared by other modules, even other Feature modules, without real coupling of modules.

This example is a pretty simple thing, but hopefully, it will help you to understand Sitecore better and will show how to use old approaches together with trendy solutions.