Welcome to the first post in a new series called “A Different Approach”. Often when I search for a solution to an issue, I find multiple posts that solve the issue in a similar fashion. Since I have a strong need to be unique, I try and come up with a different approach. In this new series, I’ll share the most common solution found, cite the source(s) and explain my unique alternate approach. In the event my approach is not all that unique and is similar to another, please inform me and comment below. I will happily update my post giving credit to the developer and providing a link to their post.

Last week in my “Mister Rogers” themed post, I presented an issue a client had with the Experience Editor and then showed you my solution to that issue. My code contained some HTML markup with custom CSS classes. In order to complete the video demo by the end of last week, I took a shortcut and hardcoded the style definitions above the markup in processor. This is unacceptable for numerous and obvious reasons.



Other Possible Solutions:

Add these styles to Sitecore’s “webedit.css” file. However, this doesn’t follow anything remotely considered a Sitecore “best practice”. Keep in mind that any customizations to Sitecore files isn’t considered a best practice as it makes upgrading more difficult. These modifications could be overlooked and wiped out altogether. Find or create a view that is used on every page, add a reference to the custom stylesheet and then wrap that with the following code: Sitecore.Context.PageMode.IsExperienceEditing. Although the code smell isn’t as pungent, it’s still not the best solution. Inject the assets needed using a Pipeline.

Obviously, I went with solution #3 and as it turns out, it’s really easy to implement.

I Googled “Sitecore Injecting Resources Experience Editor” and found a few similar posts (click here for links to those) that looked like they would accomplish what I was attempting to do. However, I could not get these examples to work the way I needed them to. I could inject the stylesheet resource into the ribbon (which is loaded via iframe), but I needed the resource on the main page. It was late, I was sleepy and I could have simply overlooked that crucial step to get it working. If I did overlook an important piece, please leave a comment below.

After some time inspecting the Sitecore assemblies, items in the Core Database and other Sitecore Experience Editor related files, I found the “different approach” I was hoping to find.

Injecting Resources into the Experience Editor via a Client Pipeline

What is a Client Pipeline? Client Pipelines work like normal pipelines but they are written in JavaScript 😮. I will integrate with the “InitializePageEdit” as it seemed to be the most logical entry point as it is used when the Experience Editor is loaded.

The Client Pipeline JavaScript

We need to create the Client Pipeline JS. I will name mine “InjectCustomExperienceEditorAssets.js”. In this example, I am keeping it basic. I don’t like that I am hardcoding the stylesheet’s path. Ideally I would like to make this more dynamic maybe by using a config (as shown in the posts listed below) or I could make it more content editable and utilize Sitecore.

Create a PipelineProcessor item in Sitecore

In Sitecore, we need to create a Pipeline Processor item. Set the database to core and using the the Content Editor, navigate to the following item: /sitecore/client/Applications/ExperienceEditor/Pipelines/InitializePageEdit. Right click on that item and create a new pipeline processor item. In the “ProcessingFile” field, add the path to the InjectCustomExperienceEditorAssets JavaScript file. In this example the Processor Name isn’t required.

Switch the database to master and open a page in the Experience Editor. Using the browser’s developer tools, you should be able to see your stylesheet load. You can also “View Source” to verify.

I learned a lot writing this post and I barely skimmed the surface. Sitecore’s Client Pipelines, Speak and related concepts are extremely new to me. When it was new, documentation was scarce, so I shelved this topic. Now that documentation is more prevalent, I decided to give it another shot. For every piece of Sitecore knowledge gained, the areas I need to research multiples tenfold. I am glad I love everything Sitecore, lol.

Update: 7/8/17 2:24 PM

After the initial posting from Friday, I spent the rest of that day doing more research. I determined utilizing the “InitializePageEdit” pipeline and related code wasn’t as flexible as I was hoping. I will continue researching this and when I come up with a solution, I will blog about it.

Update: 7/14/17 1:07 AM

Good news everybody, A better solution can be found here: A Better Solution: Injecting Resources into the Experience Editor.

Thanks for reading. If you found this post useful, please share via your social networks.

Injecting Resources Related Posts:

Pavel Veller posted a great blog on BrainJock’s blog entitled “Injecting Resources into Sitecore Content and Page Editor” in 2014. Pavel’s posts are always great and informative, once you finish my post, head on over and read all his.

Mike Reynolds, winner of the “Mike Reynolds of the Year” award 4 out of the last 5 years (🤪😝) and the best Australian Sitecore Developer/Chief Architect I know. He wrote a similar post years ago in early 2013. You can find that post here: “Add Content to All Sitecore Pages Using a Custom PageExtender“. It maybe 4 years old, but it’s still worth a read.

Kamruz Jaman blog post “Adding custom JavaScript and Stylesheets in the Content Editor” was informative, but wasn’t the solution I was looking for. After you read that post, be sure to read all his newer posts. We seem to blog about the same topics, but our solutions differ in the approach.

Additional Reading

Making Sense of Speak Pipelines – by Anders Laub

Deep drive into the Sitecore Client Pipelines with SPEAK – by Benjamin Vangansewinkel