Position number of asset in Menu Design Area

(Emily) #1

Matrix Version: 5.4.1

Is there a way to reference (e.g. keyword replacement / print / declared vars), in a Design File - in the Menu Design Area - what position number the asset is?
Sorry, not sure how to explain - I will give context:

I am wanting to assign acessskey to each of the menu links - sequential; only for the top-level menu items.

I have no problem to make it Print an asset attribute, or a declared vars as the assetkey value. However, what would be a good method to get Matrix to identify what position number the link is?

Ideas are very much appreciated.

Thanks,
Emily

(Bart Banda) #2

Hmm, I don’t think so, never heard of anyone having to do that. You could potentially use a metadata field and add the value in there for each top level page and then print that into each menu item that gets printed?

The other alternative is to feed the whole menu into a server side JS function and print the menu using that? A bit tricker to achieve but should be possible… I think!

(Emily) #3

Thanks Bart. Would be useful to have a “menu-position” keyword; I think there is an equivalent in asset listings off the top of my head. Just an idea.

I have currently done it so that it is manually printing the first of the menu line, based off the asset ID, but this isn’t great for future-proof for the client if they delete a top-level menu page. (I had done this also due to the design needing to be different for each menu drop-down, but since that has changed now it is only the position-number issue).

I may go with the metadata version now, and just have to stress to the future editors that if they re-arrange or add/remove the pages, they need to make sure the numbers are in correct order.
I don’t have the time to mess around with javascript to assign the numbers, unfortunately - although this had also crossed my mind as the future-proof solution. Maybe if I have time left over at the end of the project!

(Bart Banda) #4

This is probably your easiest and safest option moving forwards. No point spending time on the other alternatives if they won’t be future-proof because it’ll only be a matter of time before that will break, then you’ll have to spend extra time on implementing an alternative solution anyway. I’d definitely recommend a JS approach.