Showing posts with label page editor. Show all posts
Showing posts with label page editor. Show all posts

Wednesday, April 8, 2026

SitecoreAI Content Editor: Replacing Experience Editor and Preview with Working Pages Links

While working through a SitecoreAI implementation recently, I ran into a small usability issue in the good ol' Sitecore Content Editor.

The Experience Editor and Preview buttons are still sitting there in the Publish ribbon, looking as inviting as ever.

There's just one problem:

They don't work. 😄

In the SitecoreAI environment I was working with, clicking either button resulted in the following error:

Connection to your rendering host failed with an Unauthorized error.
Ensure the JSS Editing Secret is configured.

This makes sense considering the editing experience has moved on to Sitecore Pages, but it leaves Content Editor users with two very visible buttons that don't get them where they need to go.

Rather than telling users to ignore them, I decided to repurpose them.

The goal was pretty straightforward:

  • Replace Experience Editor with a SitecoreAI Page Builder button
  • Replace the existing Preview behavior with a working SitecoreAI page preview
  • Open the correct page for the currently selected Content Editor item
  • Carry the current language and version into the request
  • Support multiple sites and environments
  • Do it without building or deploying any custom .NET code

Sounds like a job for Sitecore PowerShell Extensions.


The Existing Ribbon Buttons

The Content Editor ribbon definitions live in the Core database.

The two items we're interested in are:

/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Publish/Page Editor

/sitecore/content/Applications/Content Editor/Ribbons/Chunks/Publish/Preview

Rather than creating entirely new ribbon controls, I opted to reuse these existing items and replace their behavior.

Each button's Click field can execute an SPE script using item:executescript.

For the Page Builder button:

item:executescript(
  id=$ItemID,
  script={YOUR-PAGE-BUILDER-SCRIPT-ID},
  scriptDb=master
)

And for Preview:

item:executescript(
  id=$ItemID,
  script={YOUR-PREVIEW-SCRIPT-ID},
  scriptDb=master
)

Now we just need to give those buttons something useful to execute.


Creating the SPE Scripts

I created a small module underneath the Sitecore PowerShell Script Library to keep everything together.

/sitecore/system/Modules/PowerShell/Script Library/
    SitecoreAI/
        Sitecore Pages/
            Content Editor/
                Ribbon/
                    Publish/
                        Publish/
                            Page Builder
                            Preview

Both entries are standard PowerShell Script items.

For my implementation, I used the following icons:

Page Builder
/~/icon/apps/32x32/Paint.png

Preview
/~/icon/office/32x32/eye.png

Naturally, if choosing the perfect Sitecore icon becomes too difficult, I may know of a website that can help. 😄


Opening the Current Item in Sitecore Pages

The Page Builder script starts with the current Content Editor context item and builds the corresponding Sitecore Pages editor URL.

There are a few pieces of information we need along the way:

  • Current item ID
  • Current language
  • Current version
  • Site name
  • SitecoreAI tenant
  • Organization ID

In my case, the Sitecore solution contains multiple sites, so I determine the appropriate Sitecore site name based on where the selected item exists in the content tree.

Here's a sanitized version of the script:

The result is exactly what I was looking for.

Select a page in Content Editor, click SitecoreAI Page Builder, and the corresponding item opens directly in Sitecore Pages in a new browser tab.

No more hunting for the page again after switching applications.


Fixing Preview

Preview follows the same general idea, although constructing the URL requires a little more information.

In addition to the item, language, version, and Sitecore site, the script determines the route for the current item relative to the site's Home item and generates the appropriate rendering-host request.

Here's the sanitized version:

For the obvious reasons, I've replaced all tenant IDs, hosts, organization IDs, and secrets from my implementation with placeholders in the examples above.

The environment-specific SitecoreAI values can be retrieved from your Sitecore Cloud Portal / Deploy application.



Replacing the Ribbon Buttons

With both SPE scripts created, the last step is updating the original Core database ribbon items.

You can certainly update the fields manually, but since I needed to make the same change consistently between environments...PowerShell again.

The following script updates the Click, Header, and Tooltip fields on both existing ribbon items:

After updating the Core items, I rebuilt the Content Editor ribbon using the SPE utility available under:

Sitecore → PowerShell Toolbox → Development Tools → Rebuild ribbon integration points

Refresh the Content Editor and we're back in business!

Experience Editor is now SitecoreAI Page Builder, and the Preview button now launches a working preview for the selected item.


A Small Content Editor Quality-of-Life Fix

None of this changes how Sitecore Pages itself works, and it's certainly not some massive customization.

It simply makes the existing Content Editor workflow make a little more sense for users working in SitecoreAI.

If a button says Experience Editor and clicking it takes you to an error page, users are eventually going to ask why.

If we already know where they actually need to go, we might as well send them there.

And once again, SPE makes it possible to solve the problem without a custom deployment.

I hope this helps anyone else working through a similar SitecoreAI Content Editor setup!

Happy Sitecoring! ✌️

Thursday, March 9, 2017

Sitecore Performance & Troubleshooting Tools

As a consultant within a Managed Services practice, I am often tasked to dig into ancient developer code in search of bottlenecks. Discovering performance issues on Sitecore builds can be tricky because each site you may work on follow different development patterns.

I found that the most common issues only surface after accumulating data, where some components may not have been tested using more than a few items of data.  The fix often ends up being some modification to specific Sitecore queries, or perhaps changing the way data is retrieved from Sitecore (switching to pull from a Lucene index).  Whatever it is, finding the bottleneck is just the first step.

Luckily for us, there are plenty of tools available that make troubleshooting and pin-pointing these issues a thousand times easier.  Regardless of Sitecore version you're working with, here are four performance / troubleshooting tools I often fire up from my arsenal to get to the bottom of slow load times.

SITECORE LOG ANALYZER

This is a given!  If something odd is going on in your Sitecore website, one of the first places to look for clues is the Sitecore logs.  This handy tool developed by Sitecore loads the entire Sitecore log folder and allows you to filter by date, string, message type (ERROR, INFO, DEBUG, etc).    This is often much easier than sifting through flat .txt files.



https://marketplace.sitecore.net/en/Modules/Sitecore_Log_Analyzer.aspx

SITECORE DEBUG TOOL

Built right into Sitecore - I only started utilizing this tool a few years into my career working with Sitecore, but it's been a life saver in a few instances.  My guess is that devs often forget that this exists.  Some features include full trace information for each rendering and profiling - which comes in handy when attempting to identify bottlenecks.  If you're trying to identify which rendering on a page are being pulled from the Sitecore cache, this is one of the best way to find out.

To enable the debugger, the following prerequisites must be satisfied:

  1. Ensure the "allowDebug" and "enableDebugger" attributes for the site are set to true in the site node of the Sites.config.
  2. Ensure you're logged into Sitecore with a user member utilizing the 'sitecore\Sitecore Client Developing' role.



Additional information on how to use the Sitecore debugger can still be found here:
The Sitecore Debugger

APACHE JMETER

Apache JMeter is an open-source Java application which (among other handy features) is great for running load/stress tests and providing the calculated results for analysis.  When configured properly can send multiple HTTP requests to a designated URL location and provides an average load time throughout the increased traffic.  For me, this has been a great way to obtain visualizations of page load time behaviors before and after making caching or other performance enhancement changes.



For more: https://www.digitalocean.com/community/tutorials/how-to-use-apache-jmeter-to-perform-load-testing-on-a-web-server 

 http://jmeter.apache.org/

TELERIK FIDDLER

I'm a big fan of Telerik's suite of developer tools.    Fiddler is one of those tools I always make sure to have installed on my dev box.  If you don't already know, Fiddler logs all HTTP/S traffic between your computer and the web.  This comes in handy when gathering statistics of internal or third-party calls, viewing client headers and/or cookies, viewing results of an API call and more.



http://www.telerik.com/fiddler

TELERIK JUSTTRACE

While JustTrace isn't free, it's definitely one the of easiest .NET profiling tools I've worked with.   Its intuitive tracing mechanism which allows us to identify which .NET components take the most CPU and memory resources which ultimately affect page load times.  In most cases the snapshots provide exact methods to look into and tweak until a more reasonable load time is obtained.




If you haven't tried these tools, I'd recommend playing around with them at some point.  They may become an integral part of your own troubleshooting whether during development or post-production support.  

Have you used any of these in the past?  What are your favorite performance troubleshooting tools?

Let me know in the comments!