World is now on Opti ID! Learn more

Shamrez Iqbal
Dec 16, 2014
  2514
(0 votes)

Changing the tooltip in the Page Tree

A customer wanted to show some more data in the page tree tooltip. This obviously meant extending the user interface in some way, but the first step was to figure out where the tooltip was set.

Where Are You being made?

We started digging in using the F12 tools in Chrome to figure out the where the tooltip was generated.

clip_image002

We started by unpacking the clientresources archives and searched for the attach-points in the markup, such as “rowNode” but the files were minified so it was a hopeless task – and we got many matches.

After looking at a page here on World, it turned out that there was a nuget package with the unminified debug version javascript files. After installing this package the they could be enabled by changing web.config the following way:

<episerver.framework>
<clientResources debug="true" />
.
.
.
</episerver.framework>

An interesting thing was that this seems to work regardless of installing the nuget package.

Things got slightly easier and we eventually figured out that the tooltip was being set in

\epi-cms\component\PageNavigationTree.js

 getTooltip: function (item) {
            // summary:
            //        Overridden function to select data for the tooltip
            // tags:
            //        public, extension

            //We create a content reference and use the id to hide the provider key for the user.
            var reference = new ContentReference(item.contentLink),
                baseTooltip = this.inherited(arguments);
            return baseTooltip + ", " + headingResources.id + ": " + reference.id +
                " (" + headingResources.type + ": " + item.contentTypeName + ")";
        },

Where can we fix you?

The next task was figuring out how to change this,

One way to fix it would be to modify the js directly in the zip but that change would be lost the minute a new nuget package was available – which meant about 2 weeks.

An extension point was needed, and after lots more digging we found one

this.contentRepositoryDescriptors = this.contentRepositoryDescriptors || dependency.resolve("epi.cms.contentRepositoryDescriptors");
var settings = this.contentRepositoryDescriptors[this.repositoryKey];

var componentType = settings.customNavigationWidget || "epi-cms/component/ContentNavigationTree";

Using F12 debugging we figured out the values in settings-object which came from a a contentRepositoryDescriptor

the RepositoryKey was set to “pages”, and the extensionpoint would be settings.customNavigationWidget.

Now, the hard part was to figure out how to set the customNavigationWidget, we looked at creating Components, ContentDescriptors, ContentRepositories and eventually found a class called PageRepositoryDescriptor which was where the settings-data came from.

How can we fix you?

There are four classes which inherit from ContentRepositoryDescriptorBase and they are all registered in StructureMap using the ServiceConfiguration-attribute. And they are exposed as an enumerable.
We started by adding our own class which inherited PageRepositoryDescriptor and changed the customNavigationWidget setting

 

public class OurDescriptor : PageRepositoryDescriptor
    {

        public override string CustomNavigationWidget
        {
            get
            {
                return "alloy/widget/foo";
            }
        }
        
    }

 

We tried adding the serviceconfiguration attribute to this but this broke the application because the Key-property wasn’t unique so what we instead wanted the container to do was to provide our implementation each time PageRepositoryDescriptor was requested.

This was achieved by creating a configurationModule

 

[InitializableModule]

[ModuleDependency(typeof(EPiServer.Web.InitializationModule))]

public class DescriptorInitialization : IConfigurableModule

{

public void ConfigureContainer(ServiceConfigurationContext context)

{

context.Container.Configure(ConfigureContainer);

}

private static void ConfigureContainer(ConfigurationExpression container)

{

container.IfTypeMatches(type => type.Equals(typeof(PageRepositoryDescriptor))).InterceptWith(i => new OurDescriptor ());

}

}

 

Building and testing this was a success and there was a request to alloy/widget/foo which we now had to implement.

The following lines were added to modules.config

<clientResources>

<add name="alloy.widget.foo" path="Scripts/foo.js" resourceType="Script" />

</clientResources>

And finally a the javascript file called foo.js

We started with a copy and paste of the existing ContentNavigationTree, but all methods except the tooltip method was removed, the define function was changed, and ContentNavigationTree was added as a dependency and provided as the base class for this component (first parameter in declare(..) )

 

define("alloy/widget/foo", [

// dojo

"dojo/_base/array",

"dojo/_base/connect",

"dojo/_base/declare",

"dojo/_base/lang",

"dojo/dom-class",

"dojo/topic",

"dojo/when",

// epi

"epi/dependency",

"epi/string",

"epi/shell/ClipboardManager",

"epi/shell/command/_WidgetCommandProviderMixin",

"epi/shell/selection",

"epi/shell/TypeDescriptorManager",

"epi/shell/widget/dialog/Alert",

"epi/shell/widget/dialog/Confirmation",

"epi-cms/_ContentContextMixin",

"epi-cms/_MultilingualMixin",

"epi-cms/ApplicationSettings",

"epi-cms/contentediting/PageShortcutTypeSupport",

"epi-cms/command/ShowAllLanguages",

"epi-cms/component/_ContentNavigationTreeNode",

"epi-cms/component/ContentContextMenuCommandProvider",

"epi-cms/contentediting/ContentActionSupport",

"epi-cms/core/ContentReference",

"epi-cms/widget/ContentTree",

"epi-cms/component/ContentNavigationTree",

"epi/shell/widget/ContextMenu",

// resources

"epi/i18n!epi/cms/nls/episerver.cms.components.createpage",

"epi/i18n!epi/cms/nls/episerver.cms.components.pagetree",

"epi/i18n!epi/cms/nls/episerver.shared.header"

],

function (

// dojo

array,

connect,

declare,

lang,

domClass,

topic,

when,

// epi

dependency,

epistring,

ClipboardManager,

_WidgetCommandProviderMixin,

Selection,

TypeDescriptorManager,

Alert,

Confirmation,

_ContentContextMixin,

_MultilingualMixin,

ApplicationSettings,

PageShortcutTypeSupport,

ShowAllLanguagesCommand,

_ContentNavigationTreeNode,

ContextMenuCommandProvider,

ContentActionSupport,

ContentReference,

ContentTree,

connavtree,

ContextMenu,

// resources

resCreatePage,

res,

headingResources

) {

return declare([connavtree], {

// summary:

// Light weight Page tree component.

// description:

// Extends epi.cms.widget.PageTree to provide global messaging capability.

// tags:

// internal xproduct

getTooltip: function (item) {

// summary:

// Overridden function to select data for the tooltip

// tags:

// public, extension

//We create a content reference and use the id to hide the provider key for the user.

var reference = new ContentReference(item.contentLink),

baseTooltip = this.inherited(arguments);

return baseTooltip + ", " + headingResources.id + ": " + reference.id +

" (" + headingResources.type + ": " + item.contentTypeName + ")" + "Changed: " + item.changed;

}

});

});

 

And now the tooltip shows the changed date of the page as well.

Dec 16, 2014

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |