I know there's a button in experience editor to decide whether to use the shared layout or the final layout when adding renderings (and the default is final layout). Is there a setting that forces this to one option or the other to start? I'm thinking mainly during development, a lot of the time I want my team to use the shared layout. If there's a setting I can change using a patch only on my local or development servers, that'd be optimal.
-
There is no such option. One way you could go is use Brian's processor (see link in the previous comment). Alternatively, you can just keep in mind is that the Shared/Final layout switch remembers its last state. So the editors will need to switch into the Shared Layout mode once and it'll stay that way.– Dmytro ShevchenkoCommented Mar 11, 2017 at 9:04
2 Answers
http://jockstothecore.com/defaulting-shared-layout-editing-sitecore-8-1/
A simple setting is not available, but in the blog post above you can find code for a custom processor for the loggedin pipeline that will do the trick. You can still choose on which environments you add the pipeline processor (live only dev).
The code itself will set the Registry value for the EditAllVersions key, to set it to shared for the current user. The value is indeed kept per user (you will also notice that by the fact that Sitecore will remember your choice in the xp editor).
public class DefaultToAllVersions : LoggedInProcessor
{
public override void Process(LoggedInArgs args)
{
if (SkipProcessor(args)) return;
Registry.SetString(Constants.RegistryKeys.EditAllVersions,
Constants.Registry.CheckboxTickedRegistryValue);
}
public virtual bool SkipProcessor(LoggedInArgs args)
{
var user = User.FromName(args.Username, true);
var existing = Registry.GetString(Constants.RegistryKeys.EditAllVersions);
return user == null && string.IsNullOrEmpty(existing);
}
}
and patch you loggedin pipeline:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<processors>
<loggedin>
<processor mode="on"
patch:after="*[last()]"
type="X.DefaultToAllVersions, X" />
</loggedin>
</processors>
</sitecore>
</configuration>
For those using Sitecore 9.1, Gatogordo's answer doesn't work because the loggedin pipeline is not called. In 9.1, users log in through the identity server, and whether by accident or design, Sitecore does not call the loggedin pipeline after login. So, in order to implement Gatogordo's answer, I had to use the httpRequestProcessed pipeline and keep track of whether or not the code has executed through a session variable.
httpRequestProcessed Processor
using Sitecore.ExperienceEditor;
using Sitecore.Pipelines.HttpRequest;
using Sitecore.Web.UI.HtmlControls;
namespace ObligatoryNamespace.Pipelines
{
public class DefaultToAllVersions : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
var session = args?.HttpContext?.Session;
if (session == null ||
!Sitecore.Context.IsLoggedIn ||
session["DefaultToAllVersions"] as string == "done")
return;
// Gatogordo's code (slightly modified)
if (!SkipProcessor(args))
Registry.SetString(Constants.RegistryKeys.EditAllVersions,
Constants.Registry.CheckboxTickedRegistryValue);
session["DefaultToAllVersions"] = "done";
}
// Gatogordo's code (slightly modified)
public virtual bool SkipProcessor(LoggedInArgs args)
{
var user = User.FromName(User.Current.Name, true);
var existing = Registry.GetString(Constants.RegistryKeys.EditAllVersions);
return user == null && string.IsNullOrEmpty(existing);
}
}
}
Patch File
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<httpRequestProcessed>
<processor patch:after="*[last()]"
type="ObligatoryNamespace.Pipelines.DefaultToAllVersions, ObligatoryNamespace" />
</httpRequestProcessed>
</pipelines>
</sitecore>
</configuration>
Regarding the use of the httpRequestProcessed pipeline, I know that is is not as efficient because this pipeline is called for every request. I wake up in cold sweats sometimes dwelling on this fact, but unlike the loggedin pipeline, it works for 9.1. There simply aren't any other effective alternatives that I could find. If you have any better ideas, please leave them in the comments, and if it works out, I'll update the answer.
-
Thanks for the update. I noticed later on that the original answer didn't work for federated authentication scenarios, so I can check this answer against that scenario...it might be better off because it's based on identity server. To clarify, identity server came in starting on 9.1, so you might want to clarify your answer that it's 9.1 or later, though I imagine this would work with 9.0. I wonder if there's a way to detect that the request is using a login page and only run the pipeline code in that case? Thanks for the input and welcome (since it says you're a new contributor)! Commented Mar 20, 2019 at 12:52
-
@KenMcAndrew Confirmed that identity server was introduced in 9.1 and updated answer accordingly. Thanks for the clarification. Commented Mar 20, 2019 at 18:24