Le problème m’arrive régulièrement lorsque je développe mes propres fonctions dans SPIP, soit dans mes_fonctions.php et mes_options.php, soit dans un plugin :
— certains liens de l’espace privé me mènent à une page qui m’indique un « Type 302 » (login, effacer un message, changer le statut d’un article...) et me demande de cliquer pour poursuivre l’opération (et revenir à l’interface privée « normale »),
— j’obtiens un message d’erreur PHP de genre « Headers already sent »,
— je vois apparaître dans mes pages publiques des caractères bizarres, généralement la série «  ».
Ces trois problèmes viennent généralement de la même source : un fichier PHP ou un squelette encodé en unicode (utf-8) démarrant par l’insertion d’une indication de « BOM » : « Marque d’ordre des octets ».
Ce marqueur est un caractère inséré en début de fichier unicode, automatiquement : il est utile en utf-16 et utf-32, mais pas indispensable en utf-8 (qui est le format d’encodage des caractères que l’on utilise désormais de plus en plus sur le Web - et que j’utilise désormais sytématiquement pour ne plus avoir à coder les caractères sous formes d’entités HTML du genre é).
C’est ce caractère qui est inséré en tout début de fichier provoque les erreurs :
— dans un squelette, il peut devenir un caractère « visible », et sur un site qui n’est pas lui-même en utf-8, on voit apparaître la série  (qui est sa translittération en iso-8859-1),
— dans un fichier PHP, cela provoque l’envoi de caractères avant le démarrage du PHP, avec notamment l’interdiction d’envoyer des entêtes PHP par la suite ; dans notre cas : les entêtes qui provoquent une redirection vers une autre page.
La solution est simple :
— ouvrir le ou les fichiers fautifs avec l’éditeur et forcer la sauvegarde dans le format « UTF-8 NO BOM » ; c’est la meilleure solution ; le fichier est ainsi sauvegardé correctement en Unicode utf-8, mais sans ce caractère ; en général, il suffit de traiter mes_fonctions.php et mes_options.php pour corriger tous les dysfonctionnements ;
— si vous ne pouvez pas sauvegarde en UTF-8 NO BOM, sauvegarder le fichier en ISO-8859-1, mais en prenant soin de transformer d’abord les caractères accentués en entités HTML. Ça n’est pas la solution idéale, surtout si comme moi on fait des fonctions PHP testant des chaînes multi-bytes. Mais pour beaucoup de sites, c’est souvent très suffisant. (Mais idéalement, adoptez un éditeur de texte qui vous permet de sélectionner la sauvegarde au format UTF-8 NO BOM.)