I’d be very surprised if you were not using some sort of implementation of dynamic placeholders in your projects already. Most of us have probably been using a variant of Dynamic Placeholders that Nick Wesselman wrote way back in 2011, my personal favourite being Fortis Dynamic Placeholders by Jason Bert. This is also the most requested feature on the Sitecore Developer Uservoice and Sitecore Community Uservoice.
The wait if finally over. Sitecore 9 introduces support for dynamics placeholder implementation within the core product.
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.
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.
a.k.a “Rendering Wrappers”
tl;dr; MVC HTML Helper and custom CSS styling to add chrome highlighting around renderings in Experience Editor mode.
I presented this module at the Sitecore User Group London on 12th January 2017. You can download the slides for that lightning talk here.
A few months ago I presented Session 4 of the Unofficial Sitecore Training sessions that Akshay “Be My Friend” Sura and Mike “Blog All The Things” Reynolds have been hosting. If you’re new to Sitecore or need a refresher course then I suggest you head on over and watch the videos on the series, there’s some really useful info in there from some seasoned Sitecore developers and gurus.
Anyhow, I decided presenting stuff and virtually pointing things out is hard so I added a fairly early version of some code that we had been using and experimenting with on our current project. This would make it easier to see components in Experience Editor mode and therefore easier for the audience to follow along with what I was doing. Some people noticed this at least 🙂
tl;dr; Install the module, set the config value to match your environment, have a stylised login screen and header bar per environment.
Have you ever sat there working on some task and then suddenly someone asks you to take a look at an issue on the Production environment? So you log onto that server, resolve the issue, get distracted for a few minutes by cat videos and then get back to what you were doing. But you suddenly realise that those changes you were just making was not on your local environment, you still had the Production site open in your browser tab! Oh noes!
The problem is that all the environments all looks exactly the same… the only difference being that teeny tiny URL bar, the URL in which probably also looks very similar apart from some environment prefix.
One Sitecore Best Practices is on rendering and sublayouts is to make use of all the setting that are available to make Content Author lives more friendly, namely:
- Setting a thumbnail which is displayed when they select a component to add
- Restrict the datasource location to allow better grouping of content types and direct authors towards where datasources should be created to help keep everything organised
- Associate a template with the component so the correct datasource type is created
- Setting Compatible Renderings to allow authors to easily switch between renderings without causing errors
- Make use of Experience Editor/WebEdit Buttons to add custom funtionality
Did Vasiliy do a Friday Best Practice on this yet?
The launch of Sitecore 8.2 just a few days ago brought with it a a huuuuuge list of updates and enhancements. One of those great new features is an update in the Experience Editor to make the life your content editors much simpler and better to managing the content through workflow.
Component based design/architecture seems to have gained a lot more traction again in recent times especially with the Habitat project. But Sitecore itself has fully support component based design since version 6.4 (at least) with the numerous enhancements that were made to the Page Editor in that release to add better support for Datasources. In order to fully utilize all the analytics and personalisation features, you have to use datasources, you’ll be fighting the framework if you don’t.
Due to its page-based nature, the Page Editor/Experience Editor has also had problems giving appropriate information to the editors when dealing with heavily data-sourced pages and content items that may be used on several pages.
This leads to numerous problems:
- You don’t know where a datasource is used. Making a change on a component in one page may affect several other pages when the datasource is shared or used on multiple pages.
- You can’t be sure that a page will not be broken after publishing. When you workflow content, you don’t know what state a page is in as a whole. Although the page item itself is in the Approved/Final state of workflow, the associated content used on that page may not be. Therefore publishing a page even with the “publish related item” option would still not publish those non-final datasources.