Reprise du message précédent :
c'est pas php qui chie dans la colle ?

stune blague drôle

Tu as configuré ta base de donnée et mis un "SET NAMES utf-8" après chaque connexion ?

dans le singleton de connexion :

private function __construct() {
            if (! ($tmp = mysql_connect(self::host, self::user, self::passwd)))
                throw new Exception("Connexion impossible : ".mysql_error(MysqlDB::$lien)) ;
            MysqlDB::$lien = &$tmp ;
            if (! mysql_select_db(self::base, MysqlDB::$lien))
                throw new Exception("Sélection de la base impossible : ".mysql_error(MysqlDB::$lien)) ;
            mysql_query("SET CHARACTER SET 'utf8'", MysqlDB::$lien) ;
        }

ya bien un set character set 'utf8'

SET NAMES utf8

SET CHARACTER SET 'utf8' ça sert à rien, c'est à la création de la table ça

ca change pas

Tien j'avais loupé le "passent bien avec phpmyadmin"

Si t'as des "?" à l'affichage c'est que les données en base sont en ISO, mais que tu les affiches bien en UTF-8, typiquement (le navigateur inteprete comme utf-8 des caractères qui n'existent pas en utf-8).

Tes tables sont bien encodées en UTF-8 ?

Tu as changé récemment l'encodage de la BDD, et si oui comment ?

 
via outils dans phpmyadmin, c'est latin... donc iso, mais si je met unicode, ca passe paas non plus

On met pas en UTF-8 simplement comme ça, ça ne fait que changer l'encodage pour les prochains enregistrements...

Il faut convertir les données existantes, soit en exportant la BDD, enregistrer le fichier en utf-8 et réimporter, soit avec un outil plus moderne que je ne connais pas

Par contre autant pour moi, SET CHARACTER SET n'est pas ce que je pensais : http://dev.mysql.com/doc/refman/5. [...] ction.html
Mais perso je ne l'ai jamais utilisé, et jamais eu besoin.

SET NAMES par contre est important car il précise l'encodage des réquêtes rentrant dans la base (donc l'encodage des données rentrantes aussi)

Bref, si tu veux laisser ta base en ISO ya sûrement d'autres moyens, mais si tu la veux elle aussi en UTF-8 va valoir la convertir.

Charactères utf-8 convertis en iso-8859-1 par mysql, charactères de la plage 0x7f-0xff, interdits en utf-8. T'as oublié le set names après la connexion :

mysql_connect(...);
mysql_query('SET NAMES utf8');

Note que c'est utf8, et pas utf-8

EDIT : Merde y'a une page 9

Et c'est pas ça le problèmes

mysql_connect(...);
mysql_query('SET NAMES utf8');

J'ai commencé à écrire pareil ( le "set names" ) avant de voir qu'il y avait une page 9

Donc y'a plus qu'à convertir. La fois où je l'ai dais, j'ai fais un dump complet, que j'ai ouvert avec un éditeur, j'ai passé l'éditeur en UTF8 et j'ai sauvé, et réimport \o/

Je sais pas si y'a plus simple, ou si y'a des outils prévu pour faire ça, mais en tout cas ça avait bien marché.

Edit : Je ne sais plus quel éditeur j'ai utilisé, Notepad2 peut être. Parce que certains, quand tu passes l'encodage de ISO à UTF, ne convertissent pas les caractères, et donc tu te retrouve avec les chars de merde dans le dump.

J'ai dû faire pareil une fois Au moins c'est sûr ça fonctionne

Question existentielle d'un n00b de la poo

Je me fais un petit script de publication de news.

Voici une partie de mon index.php de la partie administration :

switch ($_GET['action']) {
    
        case "add" :
            $instance->AddNews();
            break;
            
        
        case "view" :
            $instance->ViewAdminNews();
            break;
        
        
        case "del" :
            $instance->DelNews();
            break;
            
            
        default :
        echo "Veuillez choisir parmi les actions suivantes :<br />";
        echo "<li><a href=\"?action=add\">Ajouter une news</a><br />";
        echo "<li><a href=\"?action=view\">Supprimer une ou plusieurs news</a><br />";
        break;
        
    }

Je suis donc en train de faire le script pour ajouter une news dans la BDD, soit ma fonction AddNews(). Dedans, j'affiche donc le formulaire, c'est OK. Par contre, je pêche au niveau du traitement pour insérer ma news dans la BDD ...
Ne faisant pas de POO avant, j'avais l'habitude d'insérer un champ invisible dans mon formulaire. Si le champ est vide, c'est que le formulaire est vierge. Si le champ n'est plus vide (donc possède une valeur quelconque qui est passé avec $_POST) c'est que l'utilisateur à cliquer sur le bouton submit, donc j'insère en BDD.

BREF §§§§§

Tout ça pour demander où est-ce que je devais faire mon traitement pour insérer la news ? Toujours dans ma fonction AddNews() ? Ou bien je créé une autre fonction "AddNewsSuite" par exemple, et sur mon index.php, je fais :

switch ($_GET['action']) {
    
        case "add" :
        
            if ( !empty($_POST['mon_champ_invisible'] ) {
                $instance->AddNewsSuite();
            }
            else {
                $instance->AddNews();
            }
            
            break;
            
        
        case "view" :
            $instance->ViewAdminNews();
            break;
        
        
        case "del" :
            $instance->DelNews();
            break;
            
            
        default :
        echo "Veuillez choisir parmi les actions suivantes :<br />";
        echo "<li><a href=\"?action=add\">Ajouter une news</a><br />";
        echo "<li><a href=\"?action=view\">Supprimer une ou plusieurs news</a><br />";
        break;
        
    }

Grosso-modo, je ne sais pas si je dois toucher à mon fichier index.php ou a ma classe ...

Je suis pas sûr de comprendre. Sans parler de POO ou pas, il te servait à quoi ton champ supplémentaire ? Pour savoir si un formulaire a été posté, tu as juste à regarder si le tableau $_POST est vide

Mais dans tous les cas je ne vois pas le rapport avec la POO

Sachant que de toute façon la méthode AddNews va être appelée après le traitement du formulaire (cas 1 : ya des erreurs, cas 2 : message de succès), autant le faire dedans, comme ça c'est elle qui s'occupera de tout le processus d'ajout, et le gèrera comme elle le veut (au lieu de déléguer ça à son père qui a autre chose à foutre).

C'est du MVC (ou pseudo-) ?

Das ist nicht gut. Un truc bien est de tester le type de requête (dans un scénario classique GET/POST) :
 

switch($_SERVER['REQUEST_METHOD']) {
 
  case 'GET'
     // Affichage initial
     break;
 
  case 'POST':
    // validation puis affichage des erreurs ou insertion
    break;
 
  default:
     header('405 Method Not Allowed');
     header('Allowed: GET, POST');
     exit;
 
}

 
Là on est correct au niveau du protocole. D'un point de vue HTTP, on ne clique pas sur des boutons submit; on "post" une "entité" (les données) à une ressource identifiée par l'URI spécifiée

switch($_SERVER['REQUEST_METHOD']) {
 
  case 'GET'
     // Affichage initial
     break;
 
  case 'POST':
    // validation puis affichage des erreurs ou insertion
    break;
 
  default:
     header('405 Method Not Allowed');
     header('Allowed: GET, POST');
     exit;
 
}

On va encore te traiter d'entreprisey  

Wé me suis emballé, aucun rapport avec la POO, mais c'était juste pour exposer ma technique et que vous puissez comprendre mon pb
 

Pas sûr que AddNews soit appelé après le traitement. Genre message de confirmation, pas besoin de l'appeler nan ? Même pour une erreur non ? J'affiche l'erreur et le user revient en arrière ...
 
Et pseudo MVC pourquoi pas, et encore ...

switch($_SERVER['REQUEST_METHOD']) {
 
  case 'GET'
     // Affichage initial
     break;
 
  case 'POST':
    // validation puis affichage des erreurs ou insertion
    break;
 
  default:
     header('405 Method Not Allowed');
     header('Allowed: GET, POST');
     exit;
 
}

 
Très intéressant, j'te vole cette technique
 
 
Vindieu Y a donc une parade ?

Dépend de ce que tu veux faire, en tout cas pour les erreurs c'est quand même mieux de les avoir au dessus du formulaire, dans la même page. Et ça te permet de le reremplir avec les données fournies en POST (l'user a plus qu'à corriger)

if($_POST) {
 
}

Donne le même résultat

Wé cay clair, rien de plus chiant qu'un formulaire qui redevient vierge à cause d'une erreur et d'un retour en arrière sur la page
 
D'ailleurs, vous avez une technique ou un tip pour afficher l'erreur qui va juste en dessous de l'input qui a été mal rempli ?
 

if($_POST) {
 
}

Cay trop simple pour être vrai

Ben ya plein de manières, mais basiquement ce sera toujours un "if erreur_machin est là alors je l'affiche" avant chaque champ... A près à toi d'automatiser comme tu veux sans copier-coller, ou pas.

Et pourtant

if($_POST) {
 
}

 
Pas forcément quand même
 
Tu peux appeler une page en POST avec un POST vide
 
Mieux faut vérifier le $_SERVER['REQUEST_METHOD']

Quand t'as un formulaire, c'est quand même ballot à moins de n'avoir que des checkboxes vides et un submit non nommé ça ne m'est jamais arrivé

 
La question n'est pas de savoir si ça arrive souvent ou pas, le fait que c'est techniquement possible, donc à prendre en compte

Oui mais le but ici n'est pas de savoir si la requete s'est faite en méthode POST, mais simplement si un formulaire précis a été envoyé.

On utilisera REQUEST_METHOD quand on voudra savoir si un formulaire quelconque et de format inconnu a été envoyé, oui, là ça vaudra les 50 caractères en plus

Question à propos d'un truc auquel max et moi ne sommes pas d'accord : dans le cadre du dév du forum, pour la table sujets, je pensais mettre un champ avec la date de la dernière réponse mais  max pense qu'avec une jointure et l'ID du dernier message, ce champ n'est pas utile. Qui qu'a raison ?

L'ID du dernier message qui serait stocké où exactement?

mais t'as une table topic et une table messages ?
Et l'ID serait dans la table messages ?

Dans la table des sujets

Ouaip, là c'est pour la page où sont listés les sujets

 
Dans ce cas je dirais que vous avez tous les deux faux, et tous les deux raison  
 
Stocker des données d'une réponse dans la table des sujets (que ce soit la date de dernière réponse ou son id) c'est de la dénormalisation du design de la DB, donc une optimisation (et en théorie à ne faire que quand les perfs normalisées sont trop basses et qu'il a été déterminée que cette requête spécifiquement posait problème), mais la sienne demande de faire un join, donc aura des perfs inférieures à la tienne pour faire la même chose (si c'est juste utiliser/afficher la date de la dernière réponse). Par contre elle sera plus flexible si besoin de faire des choses plus complexes (genre afficher le nom du derner posteur en plus de la date du dernier post).

Oui, en fait c'est afficher le nom du dernier posteur et la date de son dernier message et le lien ramène vers le dernier message (grâce à l'ID).

Ben dans ce cas, si et seulement si aller chercher le dernier post dans la db normalisée a un impact trop important sur les perfs, stocker l'id du dernier message dans la table du topic et joiner dessus est probablement une meilleure idée.

Je note

Non pas du tout. Quand Apache reçoit un HEAD, c'est silencieusement transformé en GET classique. Puis il renvoit juste les headers après avoir supprimé l'entité. Donc pas de probs

Je trouve le dernier débat assez stérile niveau "bonnes pratiques" ..
C'est pas bien de modifier les headers, pas bien !!!