Admin Menu Id's

[JesseRigon]

Admin menu nodes have a stable UniqueId that never reaches MenuItem.Id

I'm building a Blazor admin on Orchard Core, so I consume the admin menu outside Razor and persist per-item state against it: layout overrides, icon overrides, ordering. That needs a stable per-item key, and I can get one for provider items but not for Admin Menu nodes.

Provider items: the caption literal works as a key

S["Configuration"] produces a LocalizedString with two halves. Text.Name is the literal from the source, Text.Value is the translation for the request. NavigationItemBuilder.Caption() assigns the whole object onto MenuItem.Text, so both halves survive onto the built item, and Merge matches on Text.Name.

That makes Text.Name a culture-invariant key I can read straight off the menu item. It moves if a developer rewords the literal, but that's avoidable: ship an en translation keyed on the literal and the displayed caption changes while the key stays put. English isn't special to IStringLocalizer. So the literal becomes a stable key that happens to read like English.

Admin Menu nodes: no key to read

The node builders construct the caption differently:

// LinkAdminNodeNavigationBuilder.cs
return builder.AddAsync(new LocalizedString(node.LinkText, node.LinkText), async itemBuilder =>

Both halves are the same value, the string the admin typed. These items are localized, but through IDataLocalizer at render time in TheAdmin/Views/NavigationItemText.cshtml, using Text itself as the lookup key:

var context = DataLocalizationContext.AdminMenu(Model.Item.MenuName);
<span class="title">@D[Model.Text, context]</span>

DataLocalizer works like IStringLocalizer: resolve against the current culture, fall back to the key. So the same en trick applies for display. What it doesn't do is leave a key on the item. For provider items the key/translation split lives in the object; here it lives only in the translation store, and the built item carries one raw string. Freezing LinkText by convention doesn't help me, because I still can't tell which built item that frozen string belongs to.

The identifier already exists

public class AdminNode : MenuItem
{
    public string UniqueId { get; set; } = Guid.NewGuid().ToString("n");

Assigned at creation, persisted with the node, unaffected by renames. NodeController already edits nodes by it. AdminNode derives from MenuItem, which has an Id.

But none of the four builders (LinkAdminNode, PlaceholderAdminNode, ContentTypesAdminNode, ListsAdminNode) call itemBuilder.Id(...). They copy MenuName, Url, Target, Priority, Position, permissions and icon classes; UniqueId isn't among them. Since AddAsync constructs a fresh MenuItem rather than carrying the AdminNode through, MenuItem.Id ends up null.

Why I can't bridge it myself

• The built MenuItem is a new instance, so I can't cast it back to AdminNode.
• Registering my own IAdminNodeNavigationBuilder under a stock Name depends on module load order.
• Removing the stock DI registrations reaches into another module's services.
• Registering my own node types only helps nodes created as those types.
• I can load the nodes via IAdminMenuService and see every UniqueId, but then I have to work out which built item came from which node. Merge, AuthorizeAsync and Reduce run after the builders, so what comes back is a filtered, merged version of the node tree. Matching on caption is what started with, doesn't work on translations obviously, and matching structurally is guess work.

Proposal

One line in each of the four builders:

itemBuilder.Id(node.UniqueId);

For ContentTypesAdminNode and ListsAdminNode, which expand one node into many items, qualified per item ($"{node.UniqueId}-{ctd.Name}").

MenuItem.Id is null for these items today and nothing reads it. Merge matches on Text.Name whether or not Id is set, so merging is unchanged. The one visible effect is a NavigationItemText_Id__{UniqueId} shape alternate that no template defines, so rendering falls through as it does now.

Questions

1. Is UniqueId not reaching MenuItem.Id deliberate, or just something nobody has needed?
2. If it isn't deliberate, would a PR setting it in the four builders be welcome?
3. What would it look like to make id's required via module provider menu items too? this is a larger change of course, but then menu merging could be migrated to id based as well.

[Piedone]

Wow, this is elaborate :).

1. I don't think it's deliberate, just nobody thought about it until now.
2. Yes, please, then we'll check.
3. Do you mean to enforce a unique ID for every menu item, regardless how they're built in an INavigationProvider implementation? API-wise this can be achieved with a required parameter on NavigationBuilder.Add(), but I wouldn't do that.

Also:

Registering my own IAdminNodeNavigationBuilder under a stock Name depends on module load order.

You can affect that, though, with the Priority attribute parameter in the module manifest, and the Order property in Startup classes.

[JesseRigon]

Hi,

Yes I figured out the priority system and have used it for my project in a related but different way.

To be clear, I wasn't pushing for required ids on provider items as I know that's a much larger refactor and would affect alot of downstream users. that was just me thinking out loud, since anything built on top of the admin menu currently has to handle two identification systems depending on where an item came from. Since admin menu feature nodes have id's, and my proposal would make them usable as a stable handle, it just sort of made sense to me that the provider menu items might also be keyed on the id as well, rather than the name.

Anyway, I'll work on a PR for the node builders and get feedback there. Thank you for your time.

[Skrypt]

I think it was deliberately kept aside for using simplicity of CSS class selectors. There was no need for using the id on each menu item. Same thing goes for javascript selectors. Normally, because it is using ul > li the DOM elements are already structured in a tree. Now, if you need to trigger a custom action on a single menu item; then Blazor normally should not need a unique id on each of these menu items since the menu DOM can already be parsed.

[JesseRigon]

how do I target one specific admin node item to act on though? Structure isn't guaranteed, classes are shared or absent, captions are localized and editable, and placeholder nodes don't even have an href.

To be clear I mean the Admin Menus feature's DB-backed nodes, not the menu items declared in module code. Also I mean things more like applying a targeted override to exactly that one item, consistently across renders, not DOM event targets or css targeting.

I'm new to orchardcore, maybe I'm missing something here? Is there another mechanism for direct targeting of admin menu items?