Managed Navigation and Incremental publishing

Does anyone else think that changes to Navons etc. in the Managed Navigation should be updated during an Incremental publishing run?

If so, please vote…

Cara

The main reason not to do this is performance. Navigation changes involve a re-processing of the entire nav tree.

For Percussion.com, we use SSI for the Nav so it is a separate file (that is, we do not update any pages when the nav changes, just the SSI file that has the nav markup in it). However, even with that, the edition that publishes “just the nav” is 90% as long as our “full publish” edition. That is, 90% of the time of our “full publish” is just the time it takes to walk up and down the tree re-assembling the nav fragments.

If in your case, the time makes it worth it, you could certainly create an “update nav only” edition, particularly if your site uses SSI or some equivalent for navigation changes (without something like that, the Navigation for the entire site is stamped onto every page in the site and you’re forced to do a full publish of all pages whenever the nav chantges).

We just run a full nonbinary publish to make sure the nav is included. It only takes our site about 12-15 minutes to do this publish and we have about 1500 content items.

I do think a managed navigation incremental option could be useful though, especially in a site with 10000 or more items.

One thing about SSI - it still doesn’t really solve the problem for in-context nav, where the navbars need to change. In a large, 10K page site even if SSI were used, it would only cut the publishing time down some portion because the processing on publishing would only be navbar content.

I realize that by building the nav in templates (which we do) to include files that aren’t managed by managed nav in a section’s nav that we have to then run a full-nonbinary. I just wish there was a way for the incremental to pick up any of these dependencies.

The other option seemed to be forcing maintainers to create a folder for every item that needed to be on the navbar. This could make a site far more complex than originally intended.