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….