Migrer d’un squelette SarkaSPIP

Certains webmestres débutants peuvent trouver plus facile de choisir des fonctionnalités par menus, appelant des noisettes préparées intégrées par calculs de composition avant génération des squelettes de pages, dans un contexte de développement en Z.
Mais outre que les squelettes sont plutôt abscons (avec la présence de très nombreuses lignes de calculs en balises à la SPIP avant inclusions des boucles, il s’avère que le site devient bien plus lent, voire peut présenter des difficultés d’affichages des pages publiques, rencontrées en particulier avec l’usage croisé du plugin Accès Restreint intégré.
Enfin l’absence de maintenance évolutive peut faire craindre un blocage brutal du site lors d’une mise-à-jour de SPIP ou de l’un de ses plugins, avec les conséquences...

Le souhait de migration peut dès lors s’entendre ! Mais comment faire :
- d’abord réviser les principes de base des noisettes
 et lire les explications d’usage de Zcore (qui permet une migration progressive..)

 Dump de la configuration

SarkaSPIP étant un jeu de squelettes configurable, sa configuration est enregistrée dans des métas ; plutôt que de passer par une visualisation répétée de tous les écrans de configurations, à mettre en regard avec la documentation, il serait utile de faire un dump des valeurs enregistrées :
un simple [(#CONFIG{sarkaspip_XXX}|var_dump)] dans un squelette config_sarka.html pour les divers ’casiers’ de config existantes, que l’on contrôlera par un

.

 Migration des évènements

En sarkaSPIP les événements sont directement créés comme des articles d’un secteur spécialisé (paramétré en Configuration) ; ces "articles" gagneront à être désormais gérés comme évenements, avec le plugin Agenda géré et maintenu par la communauté.

 Démarche de migration des squelettes

Meme si Sarka intègre déjà l’architecture Z, la compositions des blocs, autrement dit l’appel des noisettes dans les blocs type extra/dist.html ... sont souvent paramétrées par valeurs...
Une solution simpliste serait d’identifier toutes les seuls noisettes "finales" qui sont effectivement appelées dans les divers blocs ( ./content/sommaire, ./aside ./extras ...), et de ré-intégrer leur appel direct dans chaque noisette nommée (ou sinon dans la noisette par défaut dist.html) de ces dossiers (rappel : voir les articles comme Utiliser Z-core, le futur de Zpip pour Spipr , concernant Z pour information).
Pour visualiser plus facilement les appels, (au vu de quelques sources) une solution serait déjà, puisqu’il existe généralement déjà des #REM de commentaires
 1. s/ [(#REM) <!---/[ <!-- (#CONFIG{sarka ...})
 2. valoriser les variables lues
 3. remplacer par les appels directs aux noisettes

reste les pièges des fonctions calculées, entre dates et secteurs spécialisés