Cool, c'est exactement ce qu'il fallait. En pour l'emplacement des fichiers, ça parait logique

Oui, le message doit être en anglais.



Pourquoi pas en fait.

Bon, je dois dire que je te comprends BJ, d'un autre codé, j'ai pris l'habitude de code en "anglais" pour les noms de variable, du coup le plus souvent je mets des commentaires en anglais. Et il n'y a pas beaucoup de caractères spéciaux utilisés en anglais, c'est d'ailleurs la cause des problèmes avec les accents :P

Pour le BOM, je conçois que ce soit la pire connerie créée en informatique depuis la date codée sur 2 chiffres :P



Voilà l'argument qui tue et qui coupe court à la discussion: c'est parfaitement vrai que s'il n'y a que des caractères de base (ASCII 7bit) dans un fichier, on ne fera jamais la différence entre de l'UTF-8 ou du ANSI. De ce fait je n'ai plus rien à dire sur le sujet et normalement, un merge des modifications faites (pour les modules entre autre) vers la 2.0.1 ne devrait engendrer des problèmes que sur les commentaires, ce qui est clairement acceptable.

Ma réticence était surtout sur le fait que l'encodage des fichiers allaient varier en fonction du fichier, mais en fait on peut rester sur le fait que:

1. Tout est en UTF-8
2. Les BOM sont interdit
3. Les fichiers de code php (sauf les fichiers de langue) n'ont aucun caractère autre que des caractères compatible UTF-8 / ANSI

Présenté sous cette forme je pense que ça met tout le monde d'accord non ?

Genova> désolé pour le coup de gueule dans mon message précédent, mais ces temps-ci, au boulot, on doit importer des fichiers qui sont encodé dans un encodage avec certains caractères spéciaux puis ré-exporter en XML encodé UTF-8 ce qui cause des problèmes avec certains des caractères spéciaux... Du coup j'ai un peu les crocs en ce qui concerne les encodages. Toutefois je pense que ce qui a été dit depuis a été constructif pour tout le monde, moi y compris.

Et il le refera... on est passé (vers la RC4 ou RC5) d'ASCII à UTF-8 en suivant la logique même de l'encodage de fichier. Maintenant on fait un retour en arrière pour certains fichiers seulement (ce sera juste pire au niveau du support et des problèmes). Et dans une ou deux versions il faudra bien, enfin, avoir un format indépendant de la langue, donc UTF-8 ou similaire... et on rechangera.

En ce qui me concerne, à la sortie de la 2.0.1, mes modules seront mis à jour une fois que j'aurais fait la mise à jour de mon forum en fonction du temps que j'ai... et de nouveau, les pauvres qui attendent la nouvelle version et qui ont par malheur installé un bout de code que j'ai écris vont devoir encore attendre... (mais bon, mon avis n'est pas nouveau et ne va rien changer, c'est juste pour meubler un peu).

Regarde dans l'administration -> fsbcode
Tu édites le fsbcode code et tu regardes que le "Contenu de la liste" ait plusieurs valeur. Si c'est pas le cas le problème peut venir de là.

Il y a ça. Mais dans mon cas c'est plutôt que je refais mon thème et je vais présenter les statistiques totalement différemment de ce qui est fait. Pour ce faire j'ajoute des clés dans le fichier de langue correspondant.

Comme BJ l'a si bien dit, c'est une petite fonction simple qui peut juste apporter plus de souplesse à FSB2. Pour ma part ce n'est pas vital, comme j'ai l'habitude de modifier un peu partout. Ce serait surtout pour les créateurs de thème que ça serait utile. ^^

Je suis en train de revoir mon thème pour FSB2, et je tombe sur le cas suivant:
Je veux remettre en forme la partie statistiques et utilisateurs connectés mais pour cela je dois ajouter des clés de langues.

Le problème, c'est que les créateurs de thèmes vont aussi se heurter à ce problème à un moment donné. Ma suggestion serait d'avoir un fichier de langue dédié au thème lui-même et qu'il soit chargé automatiquement. Il pourrait y avoir un répertoire tpl dans lang/fr et le nom du fichier serait "Nom du thème".php ? Évidemment si le fichier est absent tout fonctionne comme maintenant.

Note: on pourrait imaginer que ce fichier soit le dernier chargé, de ce fait, pour un thème donné, il serait même possible de remplacer un des textes (pour des questions de présentation par exemple.

Dans l'administration, tu choisis, dans le menu, "Déco du jour" et tu édites la décoration que tu as ajoutée.

Ce que tu dois changer c'est le style de la décoration dont voici la valeur par défaut:



C'est un bout de CSS qui est ajouté à l'image pour la positionner. Dans la valeur par défaut, "top" indique le nombre de pixel qu'il y a entre le haut de la page et le haut de l'image, "left" le nombre de pixel entre la gauche de la page et l'image. Tu peux facilement changer ces valeurs pour mettre ce qui te convient en fonction de l'image. Il est possible de remplacer "left" par "right" pour avoir une référence depuis la droite.

En plus, si tu que l'image soit en arrière plan (en supposant que l'image de fond de l'en-tête ait une partie transparente), il est possible d'ajouter "z-index: -1;".

J'espère avoir répondu à ta question ^^

J'ai eu le même problème dernièrement. Et comme le dit Spark, le message d'erreur ne devrait pas être le même pour la taille du fichier trop grande ou le quota dépassé.

C'est marrant de vouloir déplacer les sujets d'un forum qui n'en a pas O.o
Il manque un test avant cette requête pour ne la faire que s'il y a des sujets :P

Et pour précision à ce que NumberEight a dit, le post-it correspond au type "Note".

J'avais en son temps fait un module pour FSB1. Je l'avais porté pour FSB2 en RC4, mais au vu des changements arrivés depuis je n'ai pas fait de mise à jour. Il faudrait peut-être que je m'y (re)mette. Mais je pense attendre la 2.0.1, mettre à jour mes modules (déjà existants) et ensuite on verra, si Genova n'a rien fait d'ici là ^^;;

A mon avis, si Genova ne veut pas le faire dans la version de base, c'est une excellente idée de module ^^

A voir vous avez vraiment pas de chance en France avec vos hébergeurs O.o
Bon, en même temps vous payez pas non plus le même prix :P