Experience Editor. It’s really great when it’s all working. But it’s not difficult to make mistakes in how you set up your site that lead to difficult to diagnose failures in the WYSIWYG editor. I came across one such issue recently that seemed like just the sort of thing Google needs to know about to save future developers (and probably Future Me as well) from the pain of debugging it. Continue reading
I’ve talked previously about how you can improve your content editors’ understanding of where things live inside your Sitecore content tree by making use of relative queries to specify where the editing UI finds things. You can do it when you set the source property for some types of field (like Multilists for example) and you can do it for Data Sources.
Logically, you’d assume that if a relative query works for a Multilist field in a normal template, it should work in a Parameter Template too? Well, if you set up something like this: Continue reading
Working on some components for a client’s site recently, it struck me that there were circumstances where it would be helpful to editors to allow the “Select Associated Content” dialog to have multiple options without just showing the whole content tree. Scenarios like having both a global shared content folder and a sub-site specific shared content folder that editors could choose between, for example. Something that looked like this: Continue reading
Having spent a bit of time thinking about relative Data Source Locations last week, it struck me that the logical extension of this is to allow the data sources of components themselves to be relative to the context item. This is particularly useful when you need a branch template, that will include some child items of a page and you want to pre-configure the page’s presentation to display these children via the data sources of UI components.
And happily this is a pretty trivial change for Sublayouts.
As someone famous** once said, with great power comes great responsibility – and the power of Sitecore’s component-based page model puts a lot of responsibility on us developers to create a structure for component data sources that makes sense to content editors. The two most common patterns I find myself using are that of having a “shared content” folder somewhere in the content tree which reusable DataSource items live in, and having items as children of the component’s page. When using the “shared content” folder you can easily set the DataSource Location field for your UI component to point to location where all the relevant data gets filed, but you can’t easily do that if you want to have your DataSource items as children of the page. So you tend to end up leaving the DataSource Location field blank to allow the user to pick the current page as the place to create the new item.