Combo button sub-items use wrong context item

[lundebro]

Hi, I've stumbled onto a very strange and potentially very dangerous issue with SPE and combo buttons, where it basically seems that a "sub" button script may use the wrong context item when running the script. Obviously depending on the script this could have very bad consequences so I hope you'll be able to reproduce it and figure out what's going on.

Expected Behavior

Scripts added as combo buttons in the ribbon should correctly resolve the current context item when using Get-Item . regardless of whether it is the "main" button or a "sub" button.

Actual Behavior

A combo "sub" button using Get-Item . incorrectly resolves the context item until the "main" button has been clicked. If a "sub" button is clicked before the "main" button has been clicked, the item resolved is incorrect.

Steps to Reproduce the Problem

• Create a new script and store it under Script Library/something/Content Editor/Ribbon/something/something and name it Combo$something (just following the instructions from https://doc.sitecorepowershell.com/modules/integration-points/content-editor#ribbon)
• Create another new script as sub-item to the Combo$something
• Set the script body of both scripts to the following:

$item = Get-Item .
Show-Alert -Title $item.Name
Close-Window

• Rebuild integration points
• Recycle the app pool
• Select the "sitecore" item in the content editor and click the sub button directly

The expected result is that the alert displays "sitecore" but the actual result is that the alert displays "inetsrv" followed by an error. It doesn't matter which context item is selected. As soon as the "main" button is clicked (which will correctly display the name of the context item), the "sub" button will behave correctly until another context item is selected in the content editor. At that point, the "sub" button will display the name of the last "main" button clicked context item. For instance:

• Select the "sitecore" item and click the "main" script button (alert displays "sitecore")
• Click the "sub" button (also correctly displays "sitecore")
• Select the "content" item in the content editor and click the "sub" button (alert will incorrectly display "sitecore" instead of "content")

Super weird. It's like the item resolving part of the "sub" button script is somehow cached, and the only way to clear it is to recycle the app pool. Clearing all Sitecore caches doesn't make a difference.

Tested with: Sitecore PowerShell Extensions 6.2.0.34182 Clean Sitecore 9.3 Windows PowerShell 5.1

• [x] Tested issue with clean install of Sitecore and the latest available version of SPE.

• [ ] Asked questions on the Sitecore Slack Chat channel.

• [ ] Reviewed questions and answers on the Sitecore Stack Exchange.

[michaellwest]

In general, the use of Get-Item . is problematic. The context is never guaranteed. I do realize that we have examples all over using this.

Consider using $SitecoreContextItem instead. If you must use Get-Item be sure to provide the database name like Get-Item -Path "master:" since the default provider could be the FileSystem instead of the Sitecore provider.

https://doc.sitecorepowershell.com/working-with-items/variables

[lundebro]

Thanks for the reply Michael, that was useful information. However, I still feel that there is something strange going on with the combo buttons specifically. If I replace Get-Item . with $SitecoreContextItem in the script examples above, the same strange "cached" behavior occurs. And the first time after an app pool recycle, clicking a "sub" button results in:

Empty strings are not allowed. Parameter name: value

regardless of the item selected in the content editor. Another interesting thing is that when the parent/main button is clicked, the current item's children are expanded. This does not happen when the child/sub button is clicked. I don't understand why the behavior of the parent/main button and the child/sub buttons of a combo button differs. Do you have any explanation?

[WDrake98]

I'm having this exact same issue. When I run the script directly, I get no issues. However, clicking any sub button under a combo button results in the error. My Script is simple and does not rely on get-item . , as I use Get-item master-id itemID.

Empty strings are not allowed.Parameter name: value --

Powershell Version: Name : Sitecore PowerShell Extensions Host 5.0.0.42513 on Windows PowerShell 5.1 & Sitecore 9.0 Version : 5.0.0.42513 InstanceId : e3662ed4-63f9-4f58-8002-e50349fa106f UI : System.Management.Automation.Internal.Host.InternalHostUserInterface CurrentCulture : en-US CurrentUICulture : en-US PrivateData : Cognifide.PowerShell.Core.Host.ScriptingHostPrivateData DebuggerEnabled : True IsRunspacePushed : Runspace :

Script: $TaskItem = "{66F3E7EB-DECE-4BD3-9566-591C8283E2DA}" $taskName = "Task" $response = Show-ModalDialog -Control "ConfirmChoice" -Parameters @{btn_0="Yes"; btn_1="No"; btn_2="Cancel"; te="Are you sure you would like to trigger the $taskName"; cp="My Caption"} -Height 120 -Width 500

if ($response -eq "btn_0") { $item = Get-Item master: -id $TaskItem if($item) { $schedule = Get-TaskSchedule -Item $item Start-TaskSchedule -Schedule $schedule } }

close-window

Full Error from logs: 44240 20:21:42 ERROR Application error. Exception: System.Web.HttpUnhandledException Message: Exception of type 'System.Web.HttpUnhandledException' was thrown. Source: System.Web at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.sitecore_shell_applications_content_manager_default_aspx.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.<>c__DisplayClass285_0.<ExecuteStepImpl>b__0() at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Nested Exception

Exception: System.Reflection.TargetInvocationException Message: Exception has been thrown by the target of an invocation. Source: mscorlib at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor) at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at Sitecore.Reflection.ReflectionUtil.InvokeMethod(MethodInfo method, Object[] parameters, Object obj) at Sitecore.Nexus.Pipelines.NexusPipelineApi.Resume(PipelineArgs args, Pipeline pipeline) at Sitecore.Web.UI.Sheer.ClientPage.ResumePipeline() at Sitecore.Web.UI.Sheer.ClientPage.OnPreRender(EventArgs e) at Sitecore.Shell.Applications.ContentManager.ContentEditorPage.OnPreRender(EventArgs e) at System.Web.UI.Control.PreRenderRecursiveInternal() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Nested Exception

Exception: System.ArgumentException Message: Empty strings are not allowed. Parameter name: value Source: Sitecore.Kernel at Sitecore.Diagnostics.Assert.ArgumentNotNullOrEmpty(String argument, String argumentName) at Sitecore.Data.ID.Parse(String value) at Sitecore.Shell.Applications.ContentManager.ContentEditorForm.Tree_Refresh(String id) at Sitecore.Shell.Applications.ContentManager.ContentEditorForm.HandleMessage(Message message) at Sitecore.Shell.Framework.Commands.MessageCommand.Execute(CommandContext context) at Sitecore.Web.UI.Sheer.ClientPage.SendMessage(Message message) at Cognifide.PowerShell.Client.Commands.MenuItems.ExecutePowerShellScript.Process(ClientPipelineArgs args)

[michaellwest]

I believe I found the issue. Not exactly sure why the context item is different (null) but it does turn out that if you run one that works correct first the subitems will then work (with the wrong context).

Testing out a change that could help avoid the issue.

[michaellwest]

A simple test would be to make the following change:

Open this item /sitecore/system/Modules/PowerShell/Script Library/SPE/Core/Platform/Internal/Integrations/Content Editor Ribbon

Then remove the $Item out of line (around 157) such that you see id=.

Save. Then rebuild script integration points.