Cette fonction trop large introduisait des codes parasites dans les morceaux de code (dans <code> et <cadre>) dans les <p> d'exemples de source. Par exemple, mon récent tutorial devenait totalement inutilisable.
J'avais introduit une correction précédemment, mais elle avait été effacée.
Du coup, je crains que cette nouvelle façon de procéder ne justifie qu'à la condition d'avoir utilisé le double saut de ligne pour créer des paragraphes. Si on fait les <p> en HTML, il y a des chances que ça ne fonctionne pas.
Cette fonction trop large introduisait des codes parasites dans les
morceaux de code (dans <code> et <cadre>) dans les <p> d'exemples de
source. Par exemple, mon récent tutorial devenait totalement
inutilisable.
Je ne comprends pas : si tu mets du HTML en exemple, ça devrait faire
<p> et non <p> ?! C'est là qu'il faut faire la correction
(ajouter un htmlspecialchars()).
J'ai ajouté un supprimer_tags dans le calcul de #INTRODUCTION,
pour éviter que les images insérées dans un article n'y apparaissent.
Je ne sais pas s'il y a des contre-indications, selon l'objectif que
chacun attribue à #INTRODUCTION ??
J'ai ajouté un supprimer_tags dans le calcul de #INTRODUCTION,
pour éviter que les images insérées dans un article n'y apparaissent.
Je ne sais pas s'il y a des contre-indications, selon l'objectif que
chacun attribue à #INTRODUCTION ??
Non, ça paraît logique. Dommage de se priver des italiques, mais c'est
relativement ingérable, alors...
J'ai pas testé, mais c'est une bonne chose dans le principe.
Seule chose à surveiller: les <p> doivent être transformés en <br>, et les <br> doivent être conservés. Le premier (les <p> supprimés) permet d'obtenir un bloc bien compact dans l'interface graphique, et le second permet de conserver une certaine logique dans la structure (sans parler de la lisibilité, notamment pour les ceusses qui publient de la poésie avec SPIP).