affichage_final, c'est lorsque la page entière a été calculé, y compris si elle est sortie directement du cache, et on peut alors faire des modifs juste avant de l'envoyer chez les gens.
Est-ce qu'il existe un pipeline pour modifier ce qui sera affiché mais AVANT la mise en cache ? C'est-à-dire APRES que recuperer_fond ait compilé un squelette et avant de le mettre dans le cache.
Ça permet notamment de pouvoir faire des modifs sur le HTML (ou autre) généré, mais sans que ce soit couteux pour le serveur puisque ça sera mis en cache !
le pipeline recuperer_fond
mais ça ne garanti pas que ce soit sur la page complete.
notamment si tu as des <inclure> ou des balises dynamiques qui n'apparaissent que sous forme de <?php include ?>
Ça c'est pas grave si les traitements ne sont à faire que sur des petits morceaux et pas sur la page complète.
Là par exemple ça serait pour scanner tous les liens, quelque soit leur provenance (dans la rédac ou dans le squelette en dur). Ça te dit quelque chose ?
affichage_final, c'est lorsque la page entière a été calculé, y compris si elle est sortie directement du cache, et on peut alors faire des modifs juste avant de l'envoyer chez les gens.
Est-ce qu'il existe un pipeline pour modifier ce qui sera affiché mais AVANT la mise en cache ? C'est-à-dire APRES que recuperer_fond ait compilé un squelette et avant de le mettre dans le cache.
Ça permet notamment de pouvoir faire des modifs sur le HTML (ou autre) généré, mais sans que ce soit couteux pour le serveur puisque ça sera mis en cache !
heu, ca s'appellerait pas un filtre ca ?
[(#INCLURE{fond=toto}|monfiltre)]
ben oui sauf que c'est pas garanti
<a href="<php echo calcule_lien_vers_truc(...)>">
tu peux pas être sur de savoir si c'est un lien interne ou externe avant affichage final ...
(typiquement sur la dist qui n'utilise que <INCLURE>)
Donc il faut de toute façon le faire dans affichage_final
Donc ça ne sert à rien de le faire N fois
Mais
Le parsing des liens en php n'est pas facile et guère moins couteux qu'en js, difficile de comparer en général :
- d'un côté c'est un serveur, de l'autre les machines des utilisateurs
- d'un côté c'est du texte à parser, de l'autre on a un arbre DOM en mémoire dans le navigateur
...
Bien pesé, je pense que l'option js est encore la meilleure, mais tu peux bencher, en testant les cas extrêmes déjà :
- serveur mutu lent, et pc rapide à la mode ...
- serveur dédié rapide, et pc lent ie6 ...
Puis les combinatoires, les cas moyen, faire des stats, etc ....
Pour décider qu'au final on sait pas, ça dépend.
Et qu'en l'occurence ça s'écrit bien et vite en jQuery, non ?
Ça je le sais très bien et je sais le faire. mais le but c'était de ne PAS utiliser javascript justement. Pour que les modifs soient bien dans le HTML, pour tout le monde, quelque soit la config.
Non car le but c'est que ce soit actif partout, tout le temps, sur toutes les pages. Sans avoir besoin de modifier ses squelettes (et que corrélativement quand on désactive le plugin, ça ne casse pas les squelettes).
Ça je le sais très bien et je sais le faire. mais le but c'était de ne PAS utiliser javascript justement. Pour que les modifs soient bien dans le HTML, pour tout le monde, quelque soit la config.
#FILTRE{xx} permet de le faire squelette par squelette. Regarde où il
s'applique et tu auras la solution (mais je te donnerais dans ce cas
précis le même conseil que Cédric).
Faire cela de façon accessible nécessite de coller le picto ou la mention textuelle *dans* le HTML (et non pas dans un JS et/ou CSS), ce qui est fastidieux à faire à la main, d'où l'idée de considérer les possibilités de génération auto en PHP/SPIP. Ce n'est pas vital, mais j'étais curieuse des possibilités...
