Macros for propagating slot contents from Navons

Using the enclosed macros you can simply turn a regular slot into one that looks up the navigation tree to find the contents of a slot if it is not present, or contains no items on the current page. Using this you can set items that will show for an entire section of a site (and a user can locally override them for an individual page). It must be noted that if you do change these the contents of the slot at a navon level it will not automatically know to republish the entire section on an incremental publish, so either a full publish or a “Publish Now” of the section would be required to see the changes. Also remember that the Navon must be checked in to see the changes in preview, and transitioned to a public state for the live site.

The enclosed file contains a series of macros that you can directly place into your User Velocity Macros file.

The changes you need to make to your code are minor

[ul]
[li]change #slot to #prop_slot in templates
[/li][li]change #slot_simple to #prop_slot_simple in templates
[/li][li]Add the slot to the rffSnNavonLink (this template name is slightly different on upgraded and new servers) template
[/li][li]Add items to slot on Navon, All items in subfolders should render the same items
[/li][/ul]

You can also make the code check the landing page of each navon before it checks the navon itself. This can be useful if your users do not have access to the Navon itself. Just remove one of the # before the node_slot_b line as below

#if($landing)##
##node_slot_b($landing $slotname $header $before $after $footer $params $body)##
#end##

becomes

#if($landing)##
#node_slot_b($landing $slotname $header $before $after $footer $params $body)##
#end##

A user should be able to override the default in the local page using Active Assembly, but the Table Editor in Content Explorer has to be used to modify the items on the Navons

Very useful Steve.

Thanks,
Cara

We have a system macro named node_slot, that until recently I had never tried to call directly… until today. After much wailing and gnashing of teeth, I realized that the prop_slot macros which we had downloaded them for a different purpose also have a macro named node_slot, and that it was the user defined version that is being used when I call it. Is it intentional that the node_slot macro is being re-defined here? I works slightly differently, and I’m wondering for my purposes if it will have adverse effects if I rename that macro to something else so that I can regain access to the original system macro.

Can anyone advise?

Thanks,

-Jason