The legend that is John West, a.k.a. SitecoreJohn.
Following the move of the blog posts from the old site to the Community Site last year things have not been quite right. Luckily John West had an archive of the code samples, so I’ve put them on all Github:
I’ve uploaded both the protoype code samples and compressed archives, hopefully this will make it easier to quickly view the code rather than having to download/extract the zip files like before!
You might also be looking for these handy gems:
Thanks you John West for providing the archive of the code samples!
A few weeks ago on Sitecore Slack chat, fellow MVP Neil Shack discovered a tucked away setting in the
renderField pipeline. Enabling this causes the field name to be rendered in the default placeholder text in Experience Editor mode:
tl;dr; Custom HTML Helper to wrap Glass Edit Frame and JS code to immediately open the modal dialog for editing
As I’m sure most of you are aware, I 😍 Glass Mapper. So much so that I struggle with the native Sitecore API 😂
Version 4 of the framework added an amazing feature which allows you to very simply and quickly create/bind to Edit Frames purely from code. Normally this is a bit of an annoying and long winded processing: switch over to the core database, create an item with names of the fields, serialize/sync to source control, do this for every combination of fields you have, hook it up to EditFrame code that until recently did not work in native Sitecore MVC 😆
I’m sure you’ve been using this feature, it’s super simple from code to add an EditFrame wherever you need and the best part is it’s bound against your strongly typed model:
@using (BeginEditFrame(Model.Page, "Edit Metadata", x => x.DisplayInMenu, x => x.Closed))
<div>Let's add an Edit Frame around our rendering</div>
If you need to add another field then simply add it to the list of fields and Glass handles everything for you.
Whenever possible I try to extend Sitecore as cleanly as possible, such as trying to patch into pipelines and event handlers or overriding dialog without replacing the default ones. It’s not always possible and sometimes you just have to dive it and get things done. You’ll see the same thing in my blog posts, some are more “cleanly” implemented than others.
There have been a number of times when I need to supplement some existing code or to fix a bug in some Sitecore code. The usual way I have done this is to get dirty and edit the JS files directly. Not great, but it was quick 😀 It’s also the exact same thing that Sitecore Support does whenever we have to apply a JS fix.
I’ve generally found that it’s easier to extend C# code, since it’s where I am more familiar. But usually with the JS I have hacked and updated the default Sitecore files. Cos you know, when you simply need to add an extra 9 characters, you can’t be spending the whole day trying to figure out “a more clean way”. Ain’t nobody got time….
A real quick post on something that stumped me and had me scratching my head last week. A colleague mentioned that when browsing the Production site with
?sc_mode=edit appended to the URL then the site would attempt to redirect the user to
/sitecore/login page. In some cases it would cause an infinite redirect and cause the browser to throw a “redirected too many times error”.
In and of itself, it didn’t cause any security issues – the CM server was only accessible to our internal network and we had followed server hardening best practices and blocked access to the CMS interface on the CD servers (we actually just return a 404 rather than anything specific related to access denied).
We had also correctly followed the guide to configure a CD server so was pretty sure it was not related to having missed disabling a file.
So I asked on Slack if it was expected behaviour that appending
?sc_mode=edit would attempt to redirect to login page on the CD servers, I would have expected it to do nothing. Having then dug a little into the Context code, turns out there is a setting for this which we had completely overlooked.
One of the most common customizations that I have seen in Sitecore is the addition of custom processors in the
httpRequestBegin pipeline, usually to add is some custom logic to resolve the context item, maybe to deal with custom URLs or wildcard items. Since this pipeline runs for every single request, there are plenty of reasons to customize here.
Most often I’ve seen , you plug in after the
Sitecore.Pipelines.HttpRequest.ItemResolver processor with whatever your custom requirements are. However, if you are using Sitecore MVC (and I hope you are) then you may find that your custom logic has not been applied and the Sitecore.Context.Item has been reset back to default Sitecore logic.
This has come up a number of times on Slack and caught a few colleagues out. It also caught me out a while back when I was doing some wildcard work with MVC:
In January 2017 I presented at the Sitecore London User Group. Since I work freelance, I don’t have a deck of corporate PowerPoint slides that I need to pimp out for presentation or demos. Apparently those default Microsoft themes are also boring.
So I got round to creating a slide deck. And since I was presenting at a Sitecore usergroup, why not make it Sitecore themed and make it like the desktop! A couple of people asked for it, so here you go.
Download: Sitecore Presentation Template
I recently got a ping back from Eric Stafford on an old blog article of mine, the first one I had ever posted! He was working on some code and needed to inject in some custom CSS into the Experience Editor. We had several conversations on Slack, and I thought I’d post up some powerful ways in which to achieve this. Be sure to check out Eric’s posts, he’s done a fair amount of research into different ways of achieving this as well.
tl;dr; Ensure you include an Assert.CanRunApplication(“/path-to-application”) check in your custom application to enforce security
Have you created any customs application in Sitecore? Do you use Sitecore Roles to restrict access to those applications?
Often only certain roles should have access to certain pieces of functionality, which is fairly standard requirement, and a common way to restrict access to applications is to remove Read access to the item in the Core Database.
Take for example default out of the box Sitecore applications such as the Indexing Manager. Your average author really should not have access to this more developer centric functionality. And if they did, then nothing too bad could happen, they’d just be able to kick off the re-indexing process. Nothing too bad, but it would be both unexpected and use up server resources for no particular reason.
Following a conversation on the #helix-habitat channel over on Sitecore Slack Chat a few days ago, I thought it would be worth penning a quick post…
A question was asked about “How to organise your CM vs CD config in a Helix Solution”. This was about configs in your specific implementation, not the default Sitecore configs that need to be enabled or disabled for a specific Sitecore environment.
For example, you may have some specific custom pipelines or event handlers that should only run on the CM instance.
Some suggested that these custom configs should be enabled/disabled/modified as part of the deployment process using PowerShell, possibly using an XML file which provides a mapping of files for the environments. This could then be maintained by the developers.
I suggested a different approach, and “tagging” your config nodes to make them easier to patch… The approach was new/unknown to some so I thought I would (re)blog it.