WordPress Francophone

Supporter · 20-01-2009 17:55:24

Bonjour,

Je me permet de faire un résumé des modifications a faire sur Wordpress 2.7 pour que tout ou presque fonctionne le mieux possible. Si jamais les modérateurs veulent supprimer certains sujets en double... Le but ici est de tout rassembler et d'épingler wink

Donc:
Edition du fichier wp-config.php et mettre 4 clés personnalisés:

/**#@+
* Clefs uniques d'authentification.
*
* Remplacez les valeurs par défaut par des phrases uniques !
* Vous pouvez générer des phrases aléatoires en utilisant
* {@link http://api.wordpress.org/secret-key/1.1/ Le service de clefs secrètes de WordPress.org}.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
/**#@-*/

Exemple: (Ceci est un exemple, mettre des clés différentes en allant ici : Liens Secret key Personalisées )

define('AUTH_KEY', '=}jPU|aBxn^Vx:06!0HCuaCobm4_b|y;?rwy-[!IUTyMJOvI+<*o%f(;}U-wK569');
define('SECURE_AUTH_KEY', '_~,Bp]I.W&*r92j.NA7Y|Aq.?$5rSr;3nXV=rwaX_@ KCSD$6<jNY$ku;v-;YX~&');
define('LOGGED_IN_KEY', '@9;BV.mY]-j|7~U~GQt73<T6El=h~Vj-K188nhc-294`+(Om27*$~| NA6%_B(t,');
define('NONCE_KEY', 'g~AX2/<9UP-)DebND,B[w/#W[E#b}yQ-95w#=[l~tp9?z,rNhc|Cnh+|Y >2b5;b');

==================================================

Ensuite:Edition du fichier fr_FR.php et remplacer:

<?php
$wp_default_secret_key = 'mettez ici une phrase unique';
?>

Par exactement ceci ( donc sans aucune modification):

<?php
$wp_default_secret_key = 'put your unique phrase here';
?>

=============================================================

Ensuite les BOMS:
BOM Définiton

Erreur spécifique à un problème de BOM: Warning: Cannot modify header information
( Cette erreur peut aussi avoir d'autres causes )
A noter que plusieurs fichiers du theme Défaut de Wordpress 2.7 contiennent des BOMS.

Enlever les BOM:
Comment?
En utilisant le programme: delete-tag-utf8-bom
Téléchargeable ici: Delete Tag
Ensuite le dezipper sur le bureau.
Ensuite lancer l'exécutable: delete-tag-utf8-bom-win.exe dans le dossier bin\Debug
Cliquer sur choisir la cible, parcourir, et aller chercher le dossier Wordpress version 2.7
Ensuite lancer le scan: le programme va corriger les fichiers

Ou:

Lumière de Lune a écrit:
Enormément de messages suite à l'affichage de cette erreur.

Dans la plupart des cas, cela provient du fichier wp-config.php

Pour fonctionner correctement celui ci doit être enregistré en UTF-8 sans BOM , ou sans identification.

Car le caractère d'identification est mal compris, et génère l'erreur en question.

Le mode d'enregistrement dépend de l'éditeur de texte utilisé.

Sous Notepad : enregistrer sous, codage UTF 8
Sous Notepad +, dans le menu fichier, choisir "Codage" et UTF-8 (et pas UTF-8 avec signature)
Sous Word (si, si) : c'est pas possible (le fichier est en TXT, mais il n'y a pas moyen à ma connaissance de spécifier l'encodage)
Sous Dreamweaver : Menu modifier, Propriétés de la Page, Titre / encodage

Si le fichier wp-config.php est correctement enregistré en UTF-8 sans signature, alors il peut y avoir un autre problème.

===================================================

Pour la compatibilté des themes avec Wordpress 2.7
De nouvelles fonctions avec les commentaires avec Wordpress 2.7

Une astuce intéressante:
Le fichier comments.php du theme default est parfaitement compatible, avec les nouvelles fonctionnalités de Wordpress 2.7
Donc simplement remplacer le fichier comments.php de votre theme par celui du theme default wink
PS: ne pas oublier d'enlever les BOM ( voir plus haut)

=====================================================

Forum BBpress
La version stable de bbpress actuelle:0.9.0.4 n'est pas compatible avec Wordpress 2.7
La prochaine version stable sera compatible

Pour le moment donc seule la version Alpha de bbpress est compatible avec Wordpress 2.7.
Actuellement c'est la version: 1.0 alpha6.
Téléchargeable ici:
Télécharger le forum bbpress

=====================================================

Dans certains cas exceptionnels: Solution de secours mais radicale:
1- Faire une sauvegarde de la BD.
2- Sauvegarder le dossier contenant les fichiers de votre Thème (présent dans le dossier wp-content/themes/) sur votre Disque Dur.
3- Sauvegarder le fichier config.php ( Pour reinstaller Wordpress avec les mêmes paramètres ! )
4- Vider la BD
5- Reinstaller Wordpress 2.7 ( En utilisant les même paramètres et donc les mêmes clés d'authentifications)
6- Mettre la sauvegarde de la BD.
7- Mette le dossier contenant les fichiers de votre thème dans le dossier wp-content/themes/ si necessaire !
8- Activer le Thème

======================================================

PS: Pour les problèmes d'encodage de BD, voir la suite...

MISE A JOUR: LE 05/02/2009

Dernière modification par Supporter (05-02-2009 22:38:07)

krysttof · 20-01-2009 21:49:42

Le logiciel cité pour supprimer les BOM fonctionne que sous Windows. Existe-t-il des équivalents pour Mac et Linux ?

yorigami · 02-02-2009 09:37:30

Bonjours à tous,
Tout d’abord, bravo pour le formidable travail accompli et pour l’ai que vous apportez par vos interventions.

Je suis confronté au même problème que krysttof. J’utilise Wordpress depuis plus d’un an, je bosse sur Mac (Intel et G4) et la mise en place de la nouvelle page config.php avec l’activation des nouveaux paramètres comme les clefs uniques d'authentification provoque inexorablement un mauvais affichage de la table des caractères de mes sites.
J’ai naturellement essayé de mettre en pratique toutes les préconisations proposées dans cette discussion (et sur d’autres discussions), mais pour l’instant j’ai fait chou blanc à chaque tentative. J’ai dû me résigner à conserver la page config.php initiale pour conserver un affichage correcte.

Questions
Ces nouvelles clefs uniques d'authentification sont-elles la condition sine qua non à l’évolution pérenne de mon CMS préféré (qui pour l'instant fonctionne très bien)? Qu’apportes-t-elles concrètement ?

Très curieusement, quand je supprime la ligne « define('DB_CHARSET', 'utf8'); » de la nouvelle page config.php mon affichage redevient normal (c’est la solution que j’ai adoptée pour l’un de mes sites pour voir dans le temps si tout fonctionner normalement).

Y a-t-il une solution ou un programme efficace testé par Mac-user ?

Merci pour vos réponses.

Dernière modification par yorigami (04-02-2009 10:57:47)

Supporter · 02-02-2009 12:51:04

C'est simple:
Si tu as mis à jour ta Wordpress en 2.7, il faut évidemment utiliser tous les nouveaux fichiers de Wordpress 2.7 et donc bien sur le nouveau fichier config.php qui utilise des nouvelles clefs uniques d'authentification.
Si tu n'as pas mis a jour ta Wordpress ou installé Wordpress 2.7, les modifications dans cet article ne sont pas à prendre en compte....

============================================================
Sinon:
define('DB_CHARSET', 'utf8'); = Définit uniquement l'encodage de ta BD ( Base de données) et non l'encodage de tes pages html et/ou php.

Le problème vient surement du fait que ta base de données n'est pas encodée en UTF8.

Tu as deux solutions:
Important: faire une sauvegarde de la base de donnée avant toute modification !

Première solution: Accéder a ta base de données avec PhpMyAdmin ou autre... et changer l'encodage de ta BD en UTF8 ( tu trouveras des tutoriaux et aides sur le net) et donc laisser: define('DB_CHARSET', 'utf8');

Deuxième solution: tester en mettant: define('DB_CHARSET', 'latin1');

==============================================================
Sinon:
Pour l'encodage UTF8 sans Bom sous Mac:
Je ne sais pas sous Mac, mais il existe des Editeurs sous Mac aussi:
Donc voir si ces logiciels existent sous Mac et utiliser cette methode ou trouver un Editeur sous Mac et utiliser une methode equivalente:
Sous Notepad +, dans le menu fichier, choisir "Codage" et UTF-8 (et pas UTF-8 avec signature)

Dernière modification par Supporter (02-02-2009 14:45:14)

yorigami · 02-02-2009 13:56:37

Merci pour ta réponse Supporter.
Oui je suis bien sous 2.7, et c’est pour cette raison que je cherche à placer cette nouvelle page config.php.
J’ai fait des tests en local et sur MAMP (un émulateur de base PHP MySQL pour Mac) et si j’applique le nouveau fichier config.php de la version 2.7, je n’ai pas de problème d’affichage si toutes mes tables et leurs interclassements sont bien en UTF8.

Après vérification mes sites qui étaient tous sous l’encodage UTF8 à leurs mises en service sont passés en latin-swedish-ci sur certaines tables. Je pense que c’est suite au changement d’hébergeur et à la migration de la base de données que le problème est apparu.
Et je pense que c'est cet encodage qui est responsable des problème d'affichage et que les BOM n'ont rien à voir avec cela. Sous TextEdit (l'équivalent de NotePad) il n'y a qu'un version d'UTF8 proposé et aucune information sur la spécificité du codage.
Petite question :
Si je passe du « latin-swedish-ci » à UTF-8 par ma base de données, cela risque-t-il pas de provoquer des problèmes ?

Supporter · 02-02-2009 14:02:22

A mon avis non, avec une sauvegarde de ta base de données, tu n'as rien a perdre a essayer de toute façon.

Perso, c'est ce que je ferais, pour que tout soit au même encodage, et aussi car à la base Wordpress utilise l'encodage UTF8...

PS: Quand on voie les caractères des nouvelles clefs uniques d'authentification..., en effet l'encodage doit jouer un role à ce niveau...

Dernière modification par Supporter (02-02-2009 14:48:16)

yorigami · 02-02-2009 15:21:00

Merci beaucoup pour ton aide précieuse,
Je viens de faire la correction de toutes mes tables et interclassement en UTF-8, tout à bien fonctionné, mais, dès que je dépose la nouvelle page config.php (version2.7) avec les clefs authentification le même problème d’affichage de caractères accentués intervient. sad

Je ne comprends pas, car en local ça semble bien marcher.

Question :
Si je conserve l’intégralité du code de la page config.php sauf cette ligne :
define ('DB_CHARSET', 'utf8'); qui semble poser le problème d’affichage, est-ce que je risque de gros problèmes dans les mises à jour ou de fonctionnement dans le futur, est-ce un bon compromis en attendant que je trouve une solution ?

Supporter · 02-02-2009 15:40:18

Dirige toi sur ton blog, ensuite affiche la source de la page à partir de ton navigateur:

Dans les premières lignes de la source tu devrais trouver cette ligne:
<meta http-equiv="Content-Type" content="text/html; charset=

Il faut que cette ligne soit comme ceci:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Ensuite:
Connecte toi en tant qu'admin et va sur cette page:
http://www.ton-blog.com/wp-admin/options.php

Et verifie la clé: blog_charset
la valeur en face doit être: UTF-8

Il se peut que ton hébergeur est configuré l'encodage Php autre qu'en UTF8.
Tu peux donc tester en mettant un autre encodage que UTF8 devant la clé: blog_charset comme: iso-8859-1

Tout en laissant UTF8 dans le ficher config.php: define('DB_CHARSET', 'utf8'); ...

Assure toi aussi que le fichier config.php ne contient pas de Boms.
Exemple: edit le fichier config.php présent sur ton serveur à partir de ton logiciel FTP, tu devrais visionner les caractères BOMS de cette façon, et supprime les, il ne faut aucun caractères avant le <?php

Fait tous ces tests et dit moi...

PS: je voudrais signaler aussi le fait que la mise à jour de Wordpress ne se fait pas seulement en remplaçant les anciens fichiers manuellement par les nouveaux...
Il existe une procèdure pour la mise à jour de Wordpress...
J'espere qu'à la base tu as suivis la procédure de mise à jour officielle... Et donc qu'ensuite tu as remis ton ancien fichier config.php à cause de ce bug d'affichage...

Dernière modification par Supporter (02-02-2009 16:30:17)

yorigami · 02-02-2009 16:40:30

Tous les points cités ci-dessus sont corrects chez moi (bien UTF-8 de partout).
Si je passe mon blog_charset: iso-8859-1, les caractères partent en live dès qu’il y a un accent ou autre, dès que je reviens en UTF-8 tout s’affiche normalement.

Je vais essayer de trouver un PC avec FileZila pour voir si je peux localiser les Boms depuis le fichier config.php en ligne, sur Mac les deux gratuiciels que j’utilise n’ont pas cette option de correction en ligne.

Pour chaque mise à jour, j'ai suivi la procédure du document html joint avec chaque version supérieure (ainsi que la désactivation puis réactivation de mes plugins avant et après chaque mise à jour).

Merci une fois de plus pour ton aide.

Supporter · 02-02-2009 19:09:41

J'ai vue plusieurs posts au sujet de bugs à la suite d'un changement d’hébergeur ou d'un changement de serveur et à la migration de la base de données...

Certains ont finalement résolus le problème de cette façon:

Solution de secours mais radicale:

1- Faire une sauvegarde de la BD.
2- Sauvegarder le dossier contenant les fichiers de votre Thème (présent dans le dossier wp-content/themes/) sur votre Disque Dur.
3- Sauvegarder le fichier config.php ( Pour reinstaller Wordpress avec les mêmes paramètres ! )
4- Vider la BD
5- Reinstaller Wordpress 2.7 ( En utilisant les même paramètres et donc les mêmes clés d'authentifications)
6- Mettre la sauvegarde de la BD.
7- Mette le dossier contenant les fichiers de votre thème dans le dossier wp-content/themes/ si necessaire !
8- Activer le Thème

Dernière modification par Supporter (02-02-2009 19:32:08)

yorigami · 02-02-2009 20:07:43

C’est un peu ce que je craignais, je vais donc essayer cela ce week-end en espérant que tout fonctionne aussi bien après la remise en place de la base de données.
Je vous tiens informé de la suite des évènements.

yorigami · 03-02-2009 09:37:00

Après re-vérification, je suis complètement désappointé, sur les 3 CMS WP deux sont restés intègres au code UTF8 et le troisième (bien entendu le plus important) lui est passé partiellement dans un autre codage.
Ce matin, j’ai donc refait une tentative de mise en place du nouveau fichier config.php (version 2,7) sur les deux WP qui avait conservé l’UTF-8 (quelques tables étaient passées en latin-swedish-ci, mais visiblement cela n’a pas provoqué de dégâts) et le nouveau fichier config.php s’est cette fois intégré sans générer de problème d'accent.
Par contre pour le troisième site le fichier SQL est, je pense, inexploitable pour une restauration de base de donnée du fait de la modification partielle du code.
Donc a priori les problèmes d’affichage ne sont pas provoqués par la présence de Boms dans le fichier config.php, mais bien à un problème de codage ou de configuration de table UTF-8 de la base SQL.

Si quelqu'un a une suggestion pour la reconstruction de ma base de données, je suis preneur.

Dernière modification par yorigami (03-02-2009 09:37:29)

Supporter · 03-02-2009 12:26:58

Soit plus précis stp, modification partielle de quel code exactement?
Le code php? Si oui quels fichiers?
Le code en rapport avec la base de données? Si oui, plus de détails...

Sinon effectivement, voila la raison du bug...

PS: tu aurais du le spécifier dès le départ, cela nous aurait fait gagner du temps wink

Dernière modification par Supporter (03-02-2009 12:59:33)

yorigami · 03-02-2009 14:18:49

Désolé, je ne suis pas très clair…
C’est bien ma base de donnée SQL qui est partiellement mal codée.

Quand je l’exporte depuis phpMyAdmin depuis le serveur de mon hébergeur, je récupère une base moitié UTF-8, moitié latin-swedish-ci (je pense que c’est le code [les accents sont comme ceci : Ã© pour é ; Ã¨ pour è, Ã§ pour ç…).
Mais c’est très curieux, car certain mots ont une graphie juste. Si j’ouvre le fichier SQL sur un éditeur de texte, ce dernier perçoit soit le fichier en partie UTF8 et Latin-swedish-ci soit uniquement en latin-swedish-ci, ce qui me fait alors disparaître tous les accents (cela dépend de l'éditeur).

À force de me prendre la tête sur le fichier SQL, je pense avoir trouvé une solution.

J’ai trouvé (après de nombreux tests de petits programmes freeware pour mac) ce petit gratuiciel ConvertEncoding
Il voit le fichier SQL avec les mêmes défauts d’affichage, mais si je place ses deux boutons d’encodage de UTF-8 vers UTF-8, il corrige toutes les fautes d’accents. Mais cela provoque un autre problème, le fichier enregistré n’est plus lui-même en UTF-8. Je suis donc obligé de l’ouvrir depuis DreamWeaver et par les propriétés de page le re-coder en UTF-8 (sans Boms).
Là, mon fichier peut enfin être renvoyé sur le serveur de base SQL de mon hébergeur.
J’ai alors créé une nouvelle base, j’ai importé mon fichier SQL corrigé sur cette nouvelle base, réinstallé WordPress 2.7 dans un nouveau répertoire renommé du nom du répertoire de mon site à problème (lui même renommé) pour que ce dernier indique le bon chemin.
A priori à la connexion tout est rentré dans l’ordre et le fichier config.php ne pose plus de problème d’affichage.
Il faut que je vérifie l’intégrité de tous les fichiers, mais pour l’instant tout fonctionne bien.
La méthode est sans doute pas très claire et certainement empirique mais elle semble marcher.

PS. Je l'aurai bien fait, mais le problème d'encodage n'est pas visible immédiatement, car il est situé en plein milieu du fichier, et comme à chaque fois je regardais les premières lignes du fichier SQL, je n’ai rien détecté.
j'ai cherché le problème du côté des Boms, car cela me semble le plus cohérent compte tenu de ce que je voyais.

Dernière modification par yorigami (03-02-2009 14:23:35)

Supporter · 03-02-2009 14:23:52

Essaye de tout réinstaller avec la base SQL sans correction de ta part...
Il arrive que certaines bases de données soient comme la tienne et cela fonctionne tout de même...
Si jamais cela bug toujours, alors oui la solution que tu viens d'enoncer sera peut-être suffisante... wink

yorigami · 03-02-2009 14:38:32

C'est la première chose que j'ai tentée ce matin, mais l'affichage restait incorrect avec la page config.php (version WP 2.7).

Dernière modification par yorigami (04-02-2009 10:59:32)

Supporter · 03-02-2009 14:42:42

Ok ben, je ne sais pas ce qui s'est passé avec ta base SQL =)
Sinon félécitation pour les recherches et la correction...
Laisse comme ca, ca devrait fonctionner, de toute façon tu n'as pas trop le choix wink

yorigami · 03-02-2009 15:06:35

Bon à priori tout fonctionne, tout est rentré dans l'ordre et pour ce qui est des problèmes d'accents tout est OK.
Attendre la prochaine mise à jour pour être plus catégorique. wink
Merci pour ton aide et pour tes conseils qui m’ont bien aidé pour régler ce problème.

Lumière de Lune · 03-02-2009 15:08:48

C'est un cas de figure qui arrive effectivement de temps en temps, cela arrive par exemple quand la base a un codage par défaut qui n'est pas de l'utf8, certaines tables seront codées en utf8 et d'autres en "autre chose".

En plus quand tu as une base qui n'est pas en utf8 avec un blog qui l'est, les routines mysql s'occupent du transcodage, et celui ci est modifié par la ligne DB charset.
Il y a une autre commande qui peut être utile dans ces cas là, c'est mysql_query("SET NAMES 'utf8'") pour indiquer que la base va renvoyer de l'utf8.
De mémoire, je crois aussi que le traitement de l'utf8 est différent entre php4 et php5, mais je n'en suis pas certaine.
Bref, beaucoup de choses peuvent expliquer une base codée de façon hétérogène, et la seule façon de s'en sortir était celle que tu as prise.

yorigami · 03-02-2009 19:37:19

Merci pour ces explications Lumière de Lune
J’ai contacté mon hébergeur pour lui demander des explications, sur le pourquoi du comment de ce problème après migration. Comme je ne suis pas à l’origine de la première mise en ligne, je ne suis pas certain de la configuration de la base de données ou des tables à l’installation, mais je suis persuadé d’avoir vérifié ce point qui semblait correct juste avant la migration.
Un détail sur la base que j'ai récupérée, je ne suis pas parvenu à utiliser celle générée par PHPMyAdmin accessible par la fonction exportation, j'ai utilisé celle générée par le petit plug-in "WordPress Database Backup" et c'est celle-là que j'ai passée dans la moulinette ConvertEncoding puis dans DreamWeaver pour la restauration.

Supporter · 03-02-2009 21:20:51

Ton hébergeur a surement recréé une BD et ensuite importé la bd dans la bd nouvellement créée sans tenir compte des mêmes encodages et/ou configuration durant la migration...
Donc gros bordel ensuite...
On leur donnera des cours un jour peut-être wink

Plus serieusement:
Laisse faire, le problème est resolut wink

Dernière modification par Supporter (03-02-2009 21:30:52)

Lupi · 04-02-2009 13:58:01

Ensuite les BOMS:
BOM Définiton

Enlever les BOM.
Comment?
En utilisant le programme: delete-tag-utf8-bom
Téléchargeable ici: Delete Tag

Ou:

Lumière de Lune a écrit:

Enormément de messages suite à l'affichage de cette erreur.

Dans la plupart des cas, cela provient du fichier wp-config.php

Pour fonctionner correctement celui ci doit être enregistré en UTF-8 sans BOM , ou sans identification.

Car le caractère d'identification est mal compris, et génère l'erreur en question.

Le mode d'enregistrement dépend de l'éditeur de texte utilisé.

Sous Notepad : enregistrer sous, codage UTF 8
Sous Notepad +, dans le menu fichier, choisir "Codage" et UTF-8 (et pas UTF-8 avec signature)
Sous Word (si, si) : c'est pas possible (le fichier est en TXT, mais il n'y a pas moyen à ma connaissance de spécifier l'encodage)
Sous Dreamweaver : Menu modifier, Propriétés de la Page, Titre / encodage

Si le fichier wp-config.php est correctement enregistré en UTF-8 sans signature, alors il peut y avoir un autre problème.

A noter que plusieurs fichiers du theme Défaut de Wordpress 2.7 contiennent des BOMS.
Erreur spécifique à un problème de BOM: Warning:Cannot modify header information
( Cette erreur peut aussi avoir d'autres causes )

Ce logiciel on le télécharge où à la base du site ou dans plugin?

Supporter · 04-02-2009 14:14:53

Pour les Boms présents dans les fichiers du theme default:

Télécharge le fichier ici:
Delete Tag

Ensuite dezippe le sur ton bureau.

Ensuite lance l'exécutable: delete-tag-utf8-bom-win.exe dans le dossier bin\Debug
Clique sur choisir la cible, parcours, et va chercher le dossier contenant les fichiers du theme default de la version 2.7
Ensuite lance le scan: le programme va corriger les fichiers
Ensuite upload et donc écrase les fichiers déja existants du theme default de ton site avec un logiciel FTP.
Ensuite tu peux utiliser le fichier comments.php du theme default pour ton theme.

Dernière modification par Supporter (04-02-2009 14:18:32)

Supporter · 05-02-2009 13:15:35

Mise à jour du Résumé ( Premier Post )

Lumière de Lune · 05-02-2009 17:28:13

Excuses moi mais je ne suis pas d'accord pour ton htaccess

Tout dépend des hébergeurs et des configurations, notamment le rewritebase et le rewriterule qui dépendent de l'adresse du blog.

WordPress Francophone

La référence en matiere de moteur de blog.

Le multi-blogs devient un jeu d'enfant !

La communauté, c'est vous qui la faites !

WordPress et vous !

Annonce

#1 20-01-2009 17:55:24

Cannot modify header & Compatibilité WP 2.7 -> résumé

Lumière de Lune a écrit:

#2 20-01-2009 21:49:42

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#3 02-02-2009 09:37:30

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#4 02-02-2009 12:51:04

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#5 02-02-2009 13:56:37

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#6 02-02-2009 14:02:22

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#7 02-02-2009 15:21:00

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#8 02-02-2009 15:40:18

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#9 02-02-2009 16:40:30

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#10 02-02-2009 19:09:41

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#11 02-02-2009 20:07:43

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#12 03-02-2009 09:37:00

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#13 03-02-2009 12:26:58

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#14 03-02-2009 14:18:49

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#15 03-02-2009 14:23:52

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#16 03-02-2009 14:38:32

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#17 03-02-2009 14:42:42

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#18 03-02-2009 15:06:35

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#19 03-02-2009 15:08:48

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#20 03-02-2009 19:37:19

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#21 03-02-2009 21:20:51

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#22 04-02-2009 13:58:01

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#23 04-02-2009 14:14:53

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#24 05-02-2009 13:15:35

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

#25 05-02-2009 17:28:13

Re: Cannot modify header & Compatibilité WP 2.7 -> résumé

Pied de page des forums