In 7.1 a lot of work has been done to resolve some long standing issues that allow errors and user behavior we do not prevent or make clear, to cause the system, and in particular the structure of the navigation to become inconsistent or just simply confusing. Things that could go wrong are
[ul]
[li]Navon items are created and immediately orphaned (Not in any folder but still searchable) if they cannot be put into a folder
[/li][li]Navon items can be moved to any folder but the parent Navon remains the same, this causes the navon hierarchy to become inconsistent with the folder hierarchy, this can be very confusing to users and analysis can only be done using Impact analysis tool.
[/li][li]A user can add a Navon item to the submenu slot of more than one parent in trying to link to different sections from a left nav. The system then does not know which parent to use when rendering navigation e.g. breadcrumb.
[/li][li]A user can remove a Navon from the submenu slot thinking this is the way to remove the link from the navigation. This breaks the structure though and causes any pages under the removed folder to not be able to find the Navtree causing a broken breadcrumb.
[/li][li]Users will remove navon items from a folder, but this does not remove the link to the parent item. This can cause at the least a confusion where the parent navon appears to be linked correctly to a subfolder but in fact it is linked to an orphanded item.
[/li][li]
[/li][/ul]
The following changes now make sure the structure remains consistent
A Navon cannot be independently removed from a folder. Once a navon is created in a folder it is tied directly to that folder. The folder itself can be moved with the Navon within it but the navon itself cannot be. We found that users would rename a folder, create a new folder and then try and copy or move all the old items into the new folder, often the Navon would be copied with the rest of the content but would fail as the new folder usually had a navon already created this would cause some confusing broken navigation state.
A folder containing a Navon cannot be moved to another folder if the destination does not have a Navon. Moving to a folder without a Navon would cause the navigation structure of all the items to no longer be linked correctly to any parent breaking the navigation. One exclusion to this is these folders can be moved under //Folders as this area would not normally be published as part of a site so can be used to temporarily store/remove a whole folder structure from the site without permanently purging it. The folder could be moved back to the site and linked in correctly when required.
Purging of Navons should not be allowed. Purging a Navon item breaks the navigation for all descendent children. The new Purge All menu action does not allow purge directly on Navon or NavTree but will purging a folder with its contents and navigation will guarantee consistency. Purge Navigation can be used to remove just the navigation elements in a consistent way. The old “Remove from Folder” for folders would purge all descendent folders and Navigation but leave the rest of the content in an orphaned state, this is generally not expected or good. Providing purge and remove from folder to general users has always been risky for all but draft items. The suggested behavior now is to instead allow users to move items/folders to a location under //Folders which will remove them from the site, these can be then manually/automatically removed later by an administrator. The latest version of the PSOTookit provides a Trash scheduled task that can be used to automatically remove these items after a period of time. This also allows an entire folder structure to be restored if in error.
The submenu slot on a navon is still used for ordering of navigation components, but the decision we have made is that adding and removing from the submenu slot manually in most cases should not be required by users and is very dangerous. Often the need to do this arises from the need to fix up some of the above issues, so we have provided a way to both prevent and automatically fix up the navigation.
Some users may be using navigation in a different way that may require manual modification of this slot and we will provide a patch that will allow you to disable this restriction if there is no good alternative approach. Most customers should look at why they need to add and remove from this slot and see if the recommended approaches to their functionality are sufficient for there needs as the benefit of increased system consistency should not be overlooked.
Here are some use cases why you may currently be editing this slot and ways you should be doing this.
1) I have a Navon that is not correctly linked to the navon in its parent folder, I need to fix this up.
Whenever a folder is now moved any inconsistencies with the navigation structure are automatically resolved. Although we currently do not have a tool to scan and fixup the whole tree, if you move a folder to a different location and move it back, the item will be correctly linked to its folder parent.
2) I have an images folder that is showing up in my navigation unless I remove it from the submenu slot.
Folder structures that contain only items that do not have any publishable templates using navigation do not require any Navon items. This would be folder structures containing only images, documents, or items that are used as snippets only e.g. briefs. Normally when a new folder is created or a NavTree item is initially created the whole folder structure is populated with navons including any images folder. The process of removing (purge) these navons (remember remove from folder will only orphan them) can be difficult for a deep folder structure. 7.1. adds a “Purge Navigation” menu action which can be used for this purpose. It is recommended that this only be used by a few System level administrators as it will totally wipe away Navon items and any information stored in them, day to day usage of this function should not normally be required.
3) I have a folder That I do not want to appear in my top level site navigation/ left nav so I used to remove it from the submenu slot.
Doing this before would have caused issues for any page under the folder being removed so was a bad idea. The way to provide this functionality is to put the removal logic in the navigation template itself. Often when this functionality is requested the user does not want the item totally removed from the navigation i.e. they still want a working breadcrumb but they want it to be removed from a specific navigation template, e.g. top nav, left nav etc. Ways of providing this is to provide some indication on the navon item of the intended behavior this could be a “hide from left nav” checkbox or could simply be adding something like [hidden] to the start of the Navon sys_title. This can be picked up by the appropriate navigation template and maintains the hierarchal structure of the navigation. You can use $rx.nav.findProperty(node,propertyname) to see if any parent property has a value selected.
4) My users want to have full control over the left navigation and add links between sections, external links etc.
One way of doing this is by creating a subfolder for the entry in the left nav you want to be to a different page or external link. You can then just set the landing page of that new navon to page anywhere in the system, or to an external link item. This does require the creation of that folder though, landing pages can link anywhere.
If even more control is required by the user it is suggested that a separate slot for left nav etc. is created in the Navon. The left nav template code can then see if the user has placed anything in that slot, if they have the contents of the slot would be used instead of the regular mechanism to get the navigation children. See http://forum.percussion.com/showthread.php?2562-Macros-for-propagating-slot-contents-from-Navons
I hope this helps resolve some confusion and will result in a lot less navigation issues and orphaned items. Please respond with any ways you are using navigation that would be inconsistent with this behavior.