Aucune vérification si le contenu existe dans generer_objet_info et/ou pas le bon typage dans generer_objet_introduction
La fonction generer_objet_info
récupère le SQL du contenu objet/id_objet demandé : https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/filtres.php#L4684
Puis le passe toujours en param des fonctions d'implémentations :
$generer($id_objet, $objets[$type_objet][$id_objet], ...$params)
et
$generer($id_objet, $type_objet, $objets[$type_objet][$id_objet], ...$params)
Or la fonction dédiée generer_objet_introduction
annonce qu'elle attend un array $ligne_sql
. Ce qui… n'est pas le cas quand l'objet/id_objet n'existe pas et du coup ça plante maintenant qu'on déclare ces typages.
Du coup deux possibilités :
- Soit il faut changer le typage de
generer_objet_introduction
pour ne rien mettre ou permettre au moins le null?array
- Soit il faut une vérification du sql_fetsel dans
generer_objet_info
et renvoyer toujours le même type, un array vide si besoin - ouuuu… carrément s'arrêter directement si le contenu n'existe pas ?
Pour le dernier point ça pourrait être légitime SI on décide que l'api #INFO_XX et generer_objet_info n'est QUE pour des "objets SPIP" au sens de l'API objet (ce qui peut être logique vu le nom generer_objet…). Ce qui interdirait de l'utiliser pour totalement autre chose alors qu'actuellement une fonction dédiée pourrait prendre en charge des contenus non SPIP par ex #INFO_PROUT{truc_perso, identifiant_textuel}
. Mais si on dit que c'est QUE les objets SPIP, alors si le sql_fetsel ne trouve rien : bah stop ya même pas à lancer les fonctions dédiées non ?
Mais on peut aussi considérer que les fonctions dédiées peuvent parfois vouloir renvoyer un fallback ou que sais-je si le contenu n'existe pas. Dans ce cas faut quand même résoudre le typage.