Suite au travail posté ici le 16 Octobre pour limiter les requêtes SQL aux champs effectivement utilisés, voici une nouvelle version du compilateur de squelettes et ses innovations :

 tout champ SQL est reconnu comme paramètre d’une boucle SPIP ;

 les paramètres comme {1,n-1} où n désigne le nombre d’éléments issus de la requête (voir les spécifications) sont reconnus.

En ce qui concerne le premier point, le principe de base a consisté à extraire du fichier ecrire/inc_base la description des tables SQL et d’en faire des tableaux PHP à présent déclarés dans un nouveau fichier nommé écrire/inc_kreate. Ce fichier est lu par inc_base pour créer les tables SQL comme auparavant, mais est également lu par inc-calcul-squel pour connaître les champs existant dans chaque table. Ces tableaux remplacent donc les tableaux $rows_* homonymes (qui figuraient dans inc-champ-squel) qui en étaient en fait des versions réduites. Ainsi, cette nouvelle version du compilateur a pour effet que l’ajout d’un champ dans une table SQL sera automatiquement répercuté dans l’analyse des paramètres (entre autres le champ URL_REF que j’avais oublié dans la version précédente).

On peut débrayer cet automatisme en ajoutant des éléments au tableau $exceptions_des_tables (si les noms des champs et/ou des tables SQL ne sont pas les homonymes SPIP) ou au tableau $exceptions_des_champs (si l’on veut implanter un traitement ultra-spécifique dans l’aiguillage de inc-index-squel malgré l’homonymie). C’est ce qui a été fait pour les qq cas existants actuellement (par exemple le champ faussement homonyme "LESAUTEURS" , et les synonymes "id_secteur/id_rubrique" dans la table "breves"). A l’inverse, les tableaux $contextes et $tables_doublons ont disparu car désormais inutiles.

Cette simplification a débouché sur l’élimination de la plupart des "AS" dans les requetes SQL ; on peut les remettre éventuellement mais je n’ai pas vu l’intérêt d’alourdir le code avec une telle gestion dans ce cadre.Le fichier spip_log est un peu plus verbeux lors des créations de tables, afin de repérer plus facilement une éventuelle faute dans leur déclaration.

Je signale par ailleurs un bizarrerie : les 2 appels à la fonction maj_base attendent de celle-ci un résultat booléen, mais cette fonction ne contient aucun return dans sa définition, et retourne donc toujours faux. Je suis tombé sur le pb dans mes essais de recréation de la base à l’aide des tableaux PHP, et je l’ai résolu en rajoutant un "return true" final car je n’ai pas réussi à comprendre le rôle de ce booléen. Il faudrait tirer ça au clair.

Bonne expérimentation à tous !