[SharePoint 2010] Limitation du nombre d’élément de navigation dans un site de publication
Mise à jour 23/01 : Suite à des remarques constructives, j’ai pu voir que je n’avais pas mis l’accent sur les risques de cette manipulation. On ne dira jamais assez que les modifications des limitations par défaut ne sont pas sans conséquences. J’ai donc modifié mon article pour bien faire comprendre en quoi cette modification était nécessaire dans mon cas.
L’un des principes des sites de publication est la création d’articles. La navigation joue un rôle important dans ce type de site. Cependant il arrive que la navigation fasse des siennes lorsque qu’il y a beaucoup de sous-sites et pages accessible par la navigation. Par exemple des sites qui possédaient des sous-sites, se retrouveraient, au niveau de la navigation, avec des sites enfants au même niveau que le site parent.
D’où vient ce fonctionnement ?
En cherchant, un peu sur le net, je suis tombé sur cette propriété : la propriété DynamicChildLimit.
Cette propriété est utilisé par les providers de sitemap :
GlobalNavSiteMapProvider
CombinedNavSiteMapProvider
CurrentNavSiteMapProvider
CurrentNavSiteMapProviderNoEncode
Elle permet de configurer le nombre "maximum” d’enfant qu’il va retourner (à savoir qu’il compte les sites et les pages). Par défaut cette valeur est à 50. Ce qui veut dire que le sitemap va retourner les 50 premiers sites/pages dans l’ordre de la navigation, et s’arrêter. Du coup les sites qui n’en font pas partie seront placés au mauvais endroit.
Comment modifier ce comportement ?
La première méthode qui nous vient à l’esprit est donc de modifier cette limitation. Il suffira donc de changer cette limitation dans le fichier web.config. Voici un exemple de méthode pour appliquer cette modification : msdn et Reza.
DynamicChildLimit = 50 : Limite le nombre d’élément du sitemap à 50
DynamicChildLimit = 150 : Limite le nombre d’élément du sitemap à 150
DynamicChildLimit = 0 : Désactive la limite
A savoir
Attention, il faut bien comprendre l'impact d’un tel changement. En effet les limitations par défaut ne sont pas mise au hasard. Le provider va parcourir les sites existants et aller en profondeur pour récupérer toutes informations. Le problème, comme nous l’indique les blogs de Stefan Gossner et TheMit, c’est l’utilisation de la mémoire par le provider et donc le risque de ce qu’on appel “Memory Pressure”. Ce qu’il faut savoir c’est que le provider lorsqu’il va parcourir les sites ne va pas fermer et libérer les sites dans lesquels il passe. L’un des moyens de savoir si la modification de cette limite va impacter votre serveur est d’effectuer des tests de charges sur le serveur. Vous saurez si cette solution vous convient.
D’autres méthodes ?
Si cette solution ne convient, il y a toujours moyen de corriger ce phénomène autrement.
Par exemple, l’une des solutions serait de recoder le provider, ou, comme le préconise stefan grossner, de passer par un fichier XML statique qui sera mis à jour une fois par jour. Ce ne sont pas les seules solutions, il faudra regarder les avantages et les inconvénients de chacune pour choisir celle qui correspond au mieux.
Jicay
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
