ceci pour essayer de réaliser une barre de navigation
"intelligente", un bien grand mot. Et pour ça, il faut pouvoir
exécuter un code php et non une boucle spip.
Hmmm... comment ça ? Que fait ta barre de navigation "intelligente" ?
En fait rien, pour l'instant, je n'arrive pas à le faire en langage spip. Mais j'aurais voulu pouvoir tenir compte des stats d'accès aux articles pour préconiser la lecture de certains articles. J'imagine que ça doit être frustrant de se donner du mal de rédiger un article jamais lu. L'idée était donc de promouvoir les articles les moins lus pour leur donner une chance, et encourager les rédacteurs à me proposer d'autres articles. C'est de la "Gestion Assistée d'Encouragement des Rédacteurs" (GAER), un nouveau concept. J'en suis le référent mondial car je viens de l'inventer et je peux vous proposer du conseil à un prix délirant 
Par ailleurs, dan sle cadre d'un développement futur, ne pourrait-on
pas laisser le choix d'utiliser une boucle spip ou une requête MySQL
écrite en php si on le souhaite?
Tu peux certes inclure des requêtes MySQL dans tes squelettes,
mais elles seront exécutées à chaque appel de page, indépendamment
du cache....
Ça ne me gêne pas, c'est le métier de mon serveur de bosser à la fabrication des pages. C'est pour ça que je le paye. Blague mise à part, tout dépend de ce que fait ta requête, ça peut concerner des tâches vraiment légères. La génération des textes formatés est effectivement lourde, mais il est également très lourd de dupliquer des menus de navigation dans chaque page. Il devient impossible de garantir l'homogénéité de la présentation, et il est vraiment difficile de faire des ajustements graphiques. J'ai eu le cas récemment. Ma barre de navigation égrénant les rubriques possède trois items supplémentaires: Accueil, tout à gauche, Plan du site et Recherche tout à droite, et la série des rubriques entre les deux. Il s'est trouvé que suite à l'ajout d'une rubrique, l'item "plan du site" s'est retrouvé sur deux lignes, ce que je trouvais moche et nuisible à sa visibilité. Je me suis paluché une dizaine de squelettes pour ajouter des espaces insécables entre ces mots. Franchement chiant et tellement facile d'oublier une correction dans le lot.
Je me rappelle aussi les débuts du site, il m'a fallu revoir plusieurs fois mes choix de police et de couleur pour tenir compte des différentes plateformes. A la fin, juste avant de devenir fou, j'ai rajouté des variables dans le format des textes, des couleurs affichés, du genre <font="<?php echo $font_texte_standard ; ?>" size="<?php echo $size_texte_standard ; ?>">, etc., plus un fichier de configuration global car les feuilles de style css ont des résultats souvent imprévisibles selon les navigateurs. Bref, aujourd'hui, je peux changer une police dans tout le site d'un coup de baguette magique, mais quel boulot au départ! Et boujour la lisibilité du code! Des appels de fonctions auraient été plus judicieux, mais ils ne marchent pas dans le cas d'inclusions.
Enfin, ceci dit, j'utilise spip avec beaucoup de plaisir, et je le recommande volontiers. Je regrette seulement certaines lourdeurs peut-être évitables. Mais je reconnais que pour l'essentiel, spip remplit sa mission
Proposer une syntaxe en standard pour intégrer des requêtes
me semble une mauvaise idée, car cela ne permet pas de garantir
la compatibilité ascendante (changement de structure de base
=> requêtes cassées).
Certes, mais si on imagine une simple fonction capable de renvoyer le résultat en php d'une boucle, une sorte d'assistant de requête? Après, on assume ses risques. Il y a quand même des choses qu'on ne peut pas faire en langage spip, et celui qui veut ou qui a besoin d'aller au delà sort du cadre normal pour lequel spip est conçu; en principe il sait corriger lui-même son code, sinon c'est inquiétant ;-). C'est dommage de régler 90% de ses problèmes avec un outil performant comme spip et de buter sur des conneries dans la dernière ligne droite
Spip est un produit remarquable pour
les non-informaticiens, mais souffre de limitations, en particulier si
on veut pouvoir gérer des variables dans les boucles ou si on veut
inclure des bouts de pages pour simplifier la gestion graphique et
ergonomique du site.
Il serait possible de proposer une syntaxe spécifique pour
intégrer du code PHP exécuté lors du calcul de la page, non
à chaque appel du cache (avec une syntaxe type <PHP>...</PHP>).
Mais l'ajout de ce type de code serait tout de même assez casse-cou
pour le webmestre (interférence avec les variables et fonctions
SPIP...).
C'est en très faible priorité dans le TODO (je ne sais même pas
si c'est dans le TODO, en fait).
Dommage, dommage... Je pense que spip commence à séduire des informaticiens ou au moins des gens près à s'investir dans de la vraie programmation, mais qui n'ont pas envie de se cogner une gestion d'arborescence ou la création d'un éditeur de texte, puisque vous l'avez déjà fait. Spip offre un vrai gain de productivité en terme de gestion de site, et peut valablement être utilisé par un webmestre professionnel qui aura nécessairement d'autres exigences qu'un novice en programmation. Ça doit être possible de rajouter des tags disant à spip de laisser faire php et de ne pas se mêler de le stocker en cache ou de perturber l'exécution d'une fonction qui ne le concerne pas. C'est aussi un moyen pour vous de ne pas se noyer dans des développements trop spécifiques qui risquent d'alourdir spip sans utilité collective majeure.
Mais bon, c'est vous les chefs, hein...