If anyone is interested you can access them via https://www.valtech.com/en-gb/insights/going-live-with-jss/

The topics cover things like what it’s like to move from being a traditional Sitecore dev to a JSS dev, how to get everything deployed, any gotchas we didn’t estimate for when we started and some key design decisions we made along the way.

I hope you find them useful

The post JSS Blog post series appeared first on blog.boro2g .co.uk.

By the end of this post we’ll have run through how you can get JSS up and running locally, with dependencies all wired together using a DI container and any functional aspects written in TypeScript. For us this is a key set of requirements – we’ve worked with many projects that have grown over several years. By putting in some key rules and requirements up front should mean with good discipline that the codebase can scale over time.

Why JSS?

Imagine a standard Sitecore development team, typically based around C# developers and some front end devs. In the default approach to building a site you’d need everyone to contribute Razor files with the markup and associated styling and functionality. This is the approach you would probably have seen for several years until more recently with the demand for richer front end technologies. Think Vue, Angular, React and so on.

This is what JSS facilitates.

Is this right for everyone?

Just because technologies exist, it doesn’t always make them the right platform to jump on. E.g. if you have a very established Sitecore development team that doesn’t have the appetite for these front end technologies, then JSS might not be the thing for you.

Getting started

The quick start from the docs site provides 4 tasks to get you started:

npm install -g @sitecore-jss/sitecore-jss-cli
jss create my-first-jss-app vue
cd my-first-jss-app
jss start

Provided you have node installed, once you run ^ you should then see http://localhost:3000 fire up.

Why TypeScript?

I wouldn’t consider starting a new web project now without TypeScript as it provides so many useful features for a codebase. Refactoring is just like if you were using C#, variables have types, classes can implement other abstract classes or interfaces. If you’ve not used it before, I’d highly recommend it.

In terms of designing your application, another key factor to consider is the coupling between the different layers. Core functionality being one layer, your UI framework being another. If you structure things so that e.g. you can peel out Vue without too much trouble, moving up through different technologies or versions will be a breeze.

Changes to the default app

Here we’ll add things like some demo services, some DI registrations and a few other bits we’ll need.

1.First up lets include some extra dependencies:

npm install -d inversify-inject-decorators, vue-class-component, inversify, vue-property-decorator, reflect-metadata, ts-loader, typescript

2. In src/AppRoot.vue, before the export default line add import "reflect-metadata"

3. Add a tsconfig.json file to the root folder (a level above src):

{
    "compilerOptions": {
        "outDir": "./built/",
        "sourceMap": true,
        "strict": true,
        "module": "es2015",
        "moduleResolution": "node",
        "target": "es5",       
        "lib": [
            "es6",
            "dom"
        ],
        "types": [
            "reflect-metadata"
        ],
        "experimentalDecorators": true,
        "emitDecoratorMetadata": true,
        "baseUrl": "./src",
        "paths": {            
            "@di_ids": ["DependencyInjection/Identifiers"]
        }
    },
    "include": [
        "./src/**/*"
    ]
}

4. Update the webpack config, in the Vue world this is done in vue.config.js

//at the top of the file:
let path= require('path');

//alongside the graphql includes:
config.module.rules.push({
    test: /\.tsx?$/,
    loader: 'ts-loader',
    exclude: /node_modules/,
    options: {
      appendTsSuffixTo: [/\.vue$/],
    }
  });

config.resolve.extensions.push('.ts');

//note, this is required for alias'ing to work for your references - a nice way to avoid crazy import statements. Same change exists in tsconfig

config.resolve.alias["@di_ids"] = path.resolve(__dirname, 'src/DependencyInjection/Identifiers')

5. Now add a vue-shim.d.ts (in the src folder)

declare module "*.vue" {
    import Vue from "vue";
    export default Vue;
}

6. Next, some dummy TypeScript dependencies:

// /src/scripts/processors/TestProcessor.ts

import { IService } from "../services/TestService";
import { inject, injectable } from 'inversify';
import {SERVICE_IDENTIFIER} from "@di_ids";

@injectable()
export default class TestProcessor
{    
    constructor(@inject(SERVICE_IDENTIFIER.IService) private service:IService) {        
        
    }

    public DoSomething() : string {
        return this.service.DoIt();
    }
}

// /src/scripts/services/TestServices.ts

import { injectable } from 'inversify';

@injectable()
export class ServiceA implements IService {
    DoIt(): string {
        return "ServiceA";
    }

}
@injectable()
export class ServiceB implements IService {
    DoIt(): string {
        return "ServiceB";
    }

}

export interface IService {
    DoIt(): string;
}

7. And the DI container and keys:

// /src/DependencyInjection/ContainerRoot.ts

import { Container } from "inversify";
import getDecorators from 'inversify-inject-decorators';
import TestModule from './Modules/TestModule'

let container = new Container();

container.load(TestModule);

const { lazyInject } = getDecorators(container);

export { container, lazyInject }

// /src/DependencyInjection/Identifiers.ts

const SERVICE_IDENTIFIER = {
    IService: Symbol("IService"),
    Container: Symbol("Container"),
    TestProcessor: Symbol("TestProcessor")
};

export {SERVICE_IDENTIFIER}

// /src/DependencyInjection/Modules/TestModule.ts

import { ContainerModule, interfaces } from "inversify";
import { SERVICE_IDENTIFIER } from "../Identifiers";
import { IService, ServiceA, ServiceB } from "../../scripts/services/TestService";
import TestProcessor from "../../scripts/processors/TestProcessor";

const testServices = new ContainerModule(
    (
        bind: interfaces.Bind
    ) => {
        bind<IService>(SERVICE_IDENTIFIER.IService).to(ServiceA);
        bind<TestProcessor>(SERVICE_IDENTIFIER.TestProcessor).to(TestProcessor);
    }
);

export default testServices;

8. Now a TypeScript enabled Vue component: /src/components/Hello.vue

<template>
    <div>
        <div class="greeting">Hello {{name}}{{exclamationMarks}}</div>
        <button @click="decrement">-</button>
        <button @click="increment">+</button>       
    </div>
</template>

<script lang="ts">
import { Vue, Component, Prop, Inject } from 'vue-property-decorator'
import { Container } from "inversify";
import TestProcessor from '../scripts/processors/TestProcessor';
import { SERVICE_IDENTIFIER } from "@di_ids";
import { inject, injectable } from 'inversify';
import { lazyInject } from '../DependencyInjection/ContainerRoot';


@Component({
    //components: { SubComponent }
})
export default class Hello extends Vue
{      
    @lazyInject(SERVICE_IDENTIFIER.TestProcessor)
    private _testProcessor!: TestProcessor;

// // If you want to use Vue's OTB Inject/Provide you can
    // @Inject(SERVICE_IDENTIFIER.Container)
    // private _container!: Container;

    created (): void {
        //console.log(this._container.resolve<TestProcessor>(TestProcessor).DoSomething());

        console.log(this._testProcessor.DoSomething());
    }

    @Prop() name!: string;
    @Prop() initialEnthusiasm!: number;    

    enthusiasm = this.initialEnthusiasm;

    increment() {
        this.enthusiasm++;
    }
    decrement() {
        if (this.enthusiasm > 1) {
            this.enthusiasm--;
        }
    }

    get exclamationMarks(): string {
        return Array(this.enthusiasm + 1).join('!');
    }    
}
</script>

<style>
.greeting {
    font-size: 20px;
}
</style>

9. And to finally get it showing on a page, edit layout.vue to include your component:

<div class="container">
      <!-- <placeholder name="jss-main" :rendering="route" /> -->
      <Hello :initialEnthusiasm="5" />
</div>

//...
import Hello from './components/Hello'

//...
components: {
    //...,
    Hello
},

After all that, you should see the homepage load up and “ServiceA” getting logged to the console. Not the most impressive output but shows the full flow of dependencies getting configured and resolved, with all the code written in TypeScript

If you are using SSR Renderings, you’ll also need to add |ts into the list of rules that get ‘unshift’ed in /server/server.vue.config.js

The post Setting up JSS with Vue, Typescript and dependency injection appeared first on blog.boro2g .co.uk.

Sitecore provide a good description of doing this in their documentation.

Adding custom fields to the UI

In my demo activity, I needed to include a MessageKey that would be passed through to the backend engine. Getting the field to show was relatively easy if you follow the example. I’d also recommend checking out this repo.

The problem I hit was getting the MessageKey value to render correctly in the UI when I opened a plan for the second time – rather than seeing the Key displayed as expected, you’d see an empty block.

Why was this?

Well, it turns out the MessageKey != messageKey . For some reason, when you write your custom typescript activity, you need to reference ‘this.editorParams.messageKey’, not ‘this.editorParams.MessageKey’. Note the capital, or lack of, M.

Missing bits of Sitecore

One thing the docs doesn’t mention is when you create your custom parameter within the Sitecore tree, you need to set a couple additional fields (Editor ID, Editor Parameters). Have a look at some existing ones for more details.

Debugging the UI

How did I spot the issue with the M? Once you’ve built your plugin js (npm run dev) you get a minified js file to deploy. Alongside this you will also get a sourcemap file:

If you copy this to the same folder as your deployed plugin, you can then do some clever things in chrome:

In order for this to work you need to:

• Deploy the sourcemap file as per above
• Add the folder where the original TS files live into chrome
  • In the diagram above => Filesystem => Add folder to workspace 

Happy debugging

The post Debugging Sitecore Marketing Automation UI appeared first on blog.boro2g .co.uk.

The docs

There is a pretty extensive guide on the Sitecore docs site: https://doc.sitecore.net/developers/xp/marketing-automation/activities/activity-types/create-an-activity-type.html

Alternatively have a look at these really useful 4 blog posts: https://www.brimit.com/blog/sitecore-9-custom-marketing-automation-action

Debugging your code

There are a few ways to run the engine – by default it gets installed as a windows service however if you navigate to:

{xconnectdeployment}\App_data\jobs\continuous\AutomationEngine there is an exe (maengine.exe) you can run instead. Your code deployment will involve copying dll’s from your solution into that same folder.

To debug, run the console app and then attach to the maengine process within visual studio. When the plans run, and your activity is triggered, you should see breakpoints kick in. 

If you want to make attaching to the engine simpler, in Visual Studio ‘Add existing project‘ => Select the maengine.exe on disk => Right click ‘Debug => Start new instance‘

Some developer tips

If you are getting started and can’t seem to get your code to run, try setting up a very simple plan with a loose trigger. An example trigger, where the month is October. 

Also, check the custom config is in place to link your custom code with the GUID of the new activity within Sitecore. This needs to live in 
{xconnectdeployment}\App_data\jobs\continuous \AutomationEngine\App_Data\Config\sitecore\PatchFolder  – you can call the PatchFolder what you need.

And finally, if you want to see what Sitecore is storing under the hood when you save a plan, they live in /sitecore/system/Marketing Control Panel/Automation Plans. You can always un-bucket the folder to see each plan.

The post Debugging Sitecore Marketing automation appeared first on blog.boro2g .co.uk.

Why does it happen?

When you setup Sitecore templates they are typically built up from several other templates eg:

• A content page is comprised from:
• Page Title field section
• Meta Data field section
• etc

Down the line you decide you want to add ‘Page Content – (Header and Body fields)’ to all pages so you setup a new Field Section template along with corresponding fields and __standard values. So that new pages automatically push the item name to the Header field, you set the __standard values to contain $name.

All this gets published and you then come to check the front end of the site – pages created before adding the Page Content field section now have the new header and body fields but the header field shows $name

The reason being these fields are inheriting their value from __standard values – variables such as $name are processed when items are created. See http://adeneys.wordpress.com/2009/12/29/custom-tokens-and-nvelocity-for-item-creation/ for info on how to create custom replacement tokens. There is also more information on http://learnsitecore.cmsuniverse.net/en/Developers/Articles/2010/08/Standard-values-in-sitecore.aspx

How to solve the problem?

When items are created they are processed by a set of pipelines. An example of this is expandInitialFieldValue pipeline. Out the box, this makes use of  the MasterVariablesReplacer.

You now have a couple options, either you can call the MasterVariablesReplacer for the problematic items or you could manually script the same functionality. The following code demonstrates the manual approach:

<%@ Page Language="C#" AutoEventWireup="true" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<%@ Import Namespace="Sitecore.Data.Items" %>
<%@ Import Namespace="Sitecore.Data.Fields" %>
<%@ Import Namespace="Sitecore.Data" %>

<script runat="server">    

    public void FixNames_Click(object sender, EventArgs e)
    {
        //note, this doesn't error check the root guid is valid item
        Item root = Database.GetDatabase("master").GetItem(new ID(new Guid(RootIdTextBox.Text)));
        int fixes = 0;

        using (new Sitecore.SecurityModel.SecurityDisabler())
        {
            fixes = RecurseAndFix(root);
        }

        ResultsLiteral.Text = String.Format("<hr />Fixed {0} cases of '$name'", fixes);
    }

    private int RecurseAndFix(Item root)
    {
        int fixes = 0;

        if (root.Template != null)
        {
            foreach (TemplateFieldItem field in root.Template.Fields)
            {
                Field existingField = root.Fields[field.ID];

                if (existingField != null)
                {
                    bool fixMe = false;

                    if (existingField.Value.Equals("$name"))
                    {
                        fixMe = true;
                    }

                    if (existingField.ContainsStandardValue && existingField.GetStandardValue().Equals("$name"))
                    {
                        fixMe = true;
                    }

                    if (fixMe)
                    {
                        using (new EditContext(root))
                        {
                            existingField.Value = root.Name;
                            fixes++;
                        }
                    }
                }
                else
                {
                    if (root.Template.StandardValues[field.ID].Equals("$name"))
                    {
                        using (new EditContext(root))
                        {
                            root[field.ID] = root.Name;
                            fixes++;
                        }
                    }
                }
            }
        }

        foreach (Item child in root.Children)
        {
            fixes += RecurseAndFix(child);
        }

        return fixes;
    }

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>'$name' Fixer </title>
</head>
<body>
    <form id="form1" runat="server">
        <p>'$name' Fixer </p>
        <p>
            Running the code on this page searches through all the content in the tree and replaces
            any '$name' values with the item's name.
        </p>
        <h2>Note: Be careful, only run on content nodes and children and not templates!</h2>
        <hr />
        <div>
            Root id: <asp:TextBox runat="server" ID="RootIdTextBox" Width="600"></asp:TextBox>
            <asp:Button runat="server" OnClick="FixNames_Click" Text="Fix '$name'" />
        </div>
        <asp:Literal runat="server" ID="ResultsLiteral" />
    </form>
</body>

Its worth noting this can introduce some interesting challenges if Language Fallback is used on your site. The script above works fine for content items on a single language site. If you need similar functionality when language fallback is in place it may actually be meaningful to set $name = ” for non-primary languages. This will ensure the fallback will occur correctly, rather than finding $name and thinking it is valid content.

The post $name in your Sitecore content appeared first on blog.boro2g .co.uk.

Over time I’d like this list to grow so if anyone has any feedback or suggestions for more items, please let me know.

For each item I will highlight some examples of where I have seen the mistakes and how they can best be avoided.

1. Direct database access
2. Expensive content queries

1. Direct database access
There are several ways to get a reference to a Sitecore database. Note, these are defined within the config (<databases>). In the following example, the first 2 items get a specific database, the last the context database.

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

Sitecore.Data.Database contextDatabase = Sitecore.Context.Database;

Why is this bad?
In larger Sitecore builds one of the common tasks is to run through the ideas stored in the following guides on the sdn: security hardening and configuring production environments.

One of key steps in these documents is that the content delivery site only has a reference to the web database. Typically you would have an independent content authoring environment which has references to core, master and web. In this setup, if your code has a direct reference to master, you will get an exception since master doesnt exist.

When might you want to do this?
It may be that in certain circumstances you do want to target a specific database. Consider an import routine. In this example you would want to ensure that new items are only added to master – note you would need to ensure the import routine is run from an environment which can access the master database.

2. Expensive content queries
Sitecore.Data.Items.ItemAxes exposes a set of methods which can be used to drill up and down through the content tree. Some examples of this are:

namespace Sitecore.Data.Items
{
    // Summary:
    //     Provides access to other items relative to a source item.
    //
    // Remarks:
    //     Implements the Sitecore.Data.Items.Item.Axes property.
    //     You should never instantiate this class.
    public class ItemAxes
    {
        ...

        // Summary:
        //     Gets an ancestor item.
        //
        // Parameters:
        //   itemID:
        //     The item ID.
        //
        //   includeSelf:
        //     if set to true this instance is include self.
        //
        // Returns:
        //     The ancestor.
        public Item GetAncestor(ID itemID, bool includeSelf);
        
        // Summary:
        //     Gets all ancestors.
        //
        // Returns:
        //     The ancestors.
        public Item[] GetAncestors();
        //
        // Summary:
        //     Gets a child item.

        ...

        //
        // Summary:
        //     Gets a list of items that is in descendant axis of the source item.
        //
        // Returns:
        //     The descendants.
        public Item[] GetDescendants();            
    }
}

Within your sublayouts you could then call eg:

Sitecore.Data.Items.Item[] descendants = Sitecore.Context.Item.Axes.GetDescendants();

Why is this bad?
If your content tree contains thousands of content items and you call GetDescendants from the root node – you will effectively be loading every single item in the tree – I can guarantee the bigger the tree, the slower this will go!

When might you want to do this?
If you are comfortable that the result of a descendants call will expose a controlled set of nodes then you may find them more useful than querying direct children. An example of this is if folders are used in the structure you are querying.

Where might you make this mistake?
A typical place I have seen this implemented is building footer navigation. Consider the following: ‘A developer understands your template structure and sees there is a common base template for each page so adds a new checkbox ‘Show in footer navigation’. In the footer control they then start at the home node calling GetDescendants, checking each item for the new checkbox.‘

What can I do instead?
In the footer example, try to consider alternative solutions for defining which items should be shown in the footer. How about a configuration area of the content tree where the footer navigation is defined as its own node (and children if needed). Your descendants call could then target these specific items.

Other alternatives are using shallower axes for your queries for example: direct children or siblings.

The post Common mistakes when programming with Sitecore pt1 appeared first on blog.boro2g .co.uk.

When you click buttons within the Sitecore client, typically Sitecore commands are used to map these actions to c# code. This link is defined in /App_Config/Commands.config. Some sample entries here are:

<command name="item:addversion" type="Sitecore.Shell.Framework.Commands.AddVersion,Sitecore.Kernel" />
<command name="item:archive" type="Sitecore.Shell.Framework.Commands.Archive,Sitecore.Kernel" />

If you want to add your own commands you can either edit this file or setup a patch file in /App_Config/Include. Note the patch file is the preferable option.

The code used for this example is:

using System.Collections.Generic;
using System.Collections.Specialized;
using System.Linq;
using System.Text;
using Sitecore;
using Sitecore.Data.Items;
using Sitecore.Data.Managers;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Shell.Framework.Commands;
using Sitecore.Web.UI.Sheer;

namespace ###.Domain.Cms.Specialization.Shell.Framework.Commands
{
    /// <summary>
    /// Create a version of the current item in all languages
    /// </summary>
    public class CreateVersionInAllLanguages : Command
    {
        public override void Execute(CommandContext context)
        {
            Assert.ArgumentNotNull(context, "context");

            if (context.Items.Length == 1)
            {
                NameValueCollection parameters = new NameValueCollection();

                parameters["items"] = base.SerializeItems(context.Items);

                Context.ClientPage.Start(this, "Run", parameters);
            }
        }

        protected void Run(ClientPipelineArgs args)
        {
            Item item = base.DeserializeItems(args.Parameters["items"])[0];

            if (item == null)
            {
                return;
            }

            IEnumerable<Language> languages = LanguageManager.GetLanguages(item.Database).Where(a => a != item.Language);

            if (SheerResponse.CheckModified())
            {
                //prompt user they want to add versions
                if (args.IsPostBack)
                {
                    if (args.Result == "yes")
                    {
                        foreach (Language language in languages)
                        {
                            Item localizedItem = item.Database.GetItem(item.ID, language);

                            //if Versions.Count == 0 then no entries exist in the given language
                            if (localizedItem.Versions.Count == 0)
                            {
                                localizedItem.Editing.BeginEdit();

                                localizedItem.Versions.AddVersion();

                                localizedItem.Editing.EndEdit();
                            }

                            Sitecore.Web.UI.HtmlControls.DataContext contentEditorDataContext = Sitecore.Context.ClientPage.FindControl("ContentEditorDataContext") as Sitecore.Web.UI.HtmlControls.DataContext;

                            contentEditorDataContext.SetFolder(item.Uri);
                        }
                    }
                }
                else
                {
                    StringBuilder builder = new StringBuilder();

                    builder.Append("Create version for each language?");                    

                    SheerResponse.Confirm(builder.ToString());

                    args.WaitForPostBack();
                }
            }
        }
    }
}

This then needs to be added into the commands section of the config with the following patch file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
        <commands>
            <command name="item:addversiontoalllanguages" type="###.Domain.Cms.Specialization.Shell.Framework.Commands.CreateVersionInAllLanguages,###.Domain.Cms" />
        </commands>
    </sitecore>
</configuration>

If you want this functionality available from a cms button, you need to wire up the button to the command. To do this, switch to the core database.

In this example we will add to the Language chunk of the ribbon (/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Language). You need to create a new button and then setup the data section paying close attention to the Command field. This wants to be the same value as set in the patch file (item:addversiontoalllanguages).

The post Create a version of an item in all languages in the Sitecore client appeared first on blog.boro2g .co.uk.

An example for the pipeline:

using Sitecore.Pipelines.HttpRequest;

namespace ###.Domain.Cms.Specialization.Pipelines.HttpRequest
{
    public class PipelineDebugger : HttpRequestProcessor
    {
        public override void Process(HttpRequestArgs args)
        {
            
        }
    }
}

Then add your debug point and dig into the args.

Some example usage for checking which site has been resolved:

<processor type="Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel" />
<processor type="###.Domain.Cms.Specialization.Pipelines.HttpRequest.PipelineDebugger, ###.Domain.Cms" />
<processor type="Sitecore.Pipelines.HttpRequest.UserResolver, Sitecore.Kernel" />

The post Debugging Sitecore pipelines appeared first on blog.boro2g .co.uk.

Its easy to build custom gutters – in the example above we have a new item available – ‘Custom Presentation’. When this is active on an item it shows:

Behind the scenes there is very little code to achieve this:

using System;
using System.Linq;
using ###.DataSource.Cms;
using Sitecore;
using Sitecore.Data.Fields;
using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Globalization;
using Sitecore.Shell.Applications.ContentEditor.Gutters;

namespace ###.Domain.Cms.Specialization.Shell.Applications.ContentEditor.Gutters
{
    /// <summary>
    /// Shows icon if layout field on item doesnt use presentation value set on __StandardValues
    /// </summary>
    public class PresentationGutter : GutterRenderer
    {
        protected override GutterIconDescriptor GetIconDescriptor(Item item)
        {
            Assert.ArgumentNotNull(item, "item");

            Field layoutField = item.Fields[FieldIDs.LayoutField];

            //ItemKeys.Home is a hard coded Guid elswhere in the app
            if (layoutField == null || !item.Axes.GetAncestors().Any(a => a.ID.Guid == ItemKeys.Home))
            {
                return null;
            }

            if (!String.IsNullOrEmpty(layoutField.Value) && !layoutField.ContainsStandardValue)
            {
                GutterIconDescriptor descriptor = new GutterIconDescriptor();

                descriptor.Icon = "applications/16x16/document_into.png";

                descriptor.Tooltip = Translate.Text("Item doesn't have same presentation as standard values");

                return descriptor;
            }

            return null;
        }
    }
}

Gutters then need to be added to the core database at ‘/sitecore/content/Applications/Content Editor/Gutters‘

The post Sitecore Gutters for updated presentation appeared first on blog.boro2g .co.uk.

A typical programming model used throughout this is the Provider model – Membership, Roles, Item, Proxy… the list is endless. Unfortunately one provider thats not exposed in the config factory is the MediaProvider.

No problem, thanks to some help from support they suggested a way to get around this, you can tap into the initialise pipeline. Here is the patch file to enable this:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <initialize>
        <processor patch:after="processor[@type='Sitecore.Pipelines.Loader.EnsureAnonymousUsers, Sitecore.Kernel']" type="###.Domain.Cms.Specialization.Pipelines.Loader.InitializeMediaProvider, ###.Domain.Cms" />
      </initialize>
    </pipelines>   
  </sitecore>
</configuration>

This pipeline runs as the application intializes. Next you need the implementation of the pipeline processor:

using Sitecore.Diagnostics;
using Sitecore.Pipelines;
using Sitecore.Resources.Media;

namespace ###.Domain.Cms.Specialization.Pipelines.Loader
{
    /// <summary>
    /// Sets the Provider for Sitecore's MediaManager to a custom version.
    /// </summary>
    public class InitializeMediaProvider
    {
        public void Process(PipelineArgs args)
        {
            Assert.IsNotNull(args, "args");

            MediaManager.Provider = new ###.Domain.Cms.Specialization.Resources.Media.MediaProvider();
        }
    }
}

And finally the custom implementation:

namespace ###.Domain.Cms.Specialization.Resources.Media
{
    public class MediaProvider : Sitecore.Resources.Media.MediaProvider
    {
        public override string GetMediaUrl(MediaItem item, MediaUrlOptions options)
        {
            ...
        }
    }
}

Our customization allowed us to push certain media extensions to known file types.

The post Setup custom Sitecore MediaProvider appeared first on blog.boro2g .co.uk.