Kioob

Hello, là comme ça, c'est phpMyAdmin qui semble le plus fiable : il conserve la valeur courante de l'auto_increment, et les sauts de lignes dans les données sont échapés par sécurité. Mais généralement ce n'est qu'une histoire d'options : si un des scripts de sauvegarde utilise "mysqldump", il y a une très grande quantité d'options permettant de sauvegarder ses données sans casse, et de manière bien plus efficace que phpmyadmin.

Hello, Les emails de l'utilisateur "ovh" sont redirigés vers une boite externe ou non ? Si ce n'est pas le cas, ça m'étonnerait fortement qu'OVH se connecte à la machine pour checker tout ça (à moins que ce soit fait par l'outil de monitoring OVH remarque...). dans le doute tu peux faire en sorte qu'il pointe sur les deux comptes, en séparant d'une virgule : "root:ovh,toto".

Yep, pour ce qui est du fait que seul le smtp d'Orange fonctionne, c'est "normal". C'est aussi le cas chez AOL et Free par exemple. Chez Orange pour avoir le droit de se connecter à un autre serveur smtp il faut prendre l'option (payante) "IP fixe" : même si cela n'a rien à voir, le fait de prendre l'option "ip fixe" désactive leur filtre. De même, les lignes "pro" n'ont pas ce filtre. Une autre solution plus simple est de changer le port TCP sur lequel ton serveur smtp écoute ; ou encore de s'y connecter via SSL (sur le port 465 si je ne m'abuse). Cela te permettra uniquement d'envoyer des mails "normaux" ; pour tout envoi de masse je te laisse voir avec Wefficient.

Hello, htmlentities() pour le stockage en base ne sert à rien, si ce n'est empêcher toute recherche dans la base de données. de même, mysql_real_escape_string() ne sert qu'au stockage en base, et certainement pas à l'affichage. Pour les différentes options d'htmlentities(), tout dépend du contexte d'utilisation de la variable. Si c'est pour la coller dans un champ "attribut" d'un tag HTML, alors ce n'est pas forcément la même chose que le fait de la mettre entre deux tags HTML. Le fait d'utiliser des simples quotes ou bien des doubles quotes pour les attributs affecte également ce choix. Dans tous les cas, il n'existe aucune fonction qui "protège de tout contre tout" ; chaque fonction a un rôle très spécifique.

Hello, la seule fois que j'ai vu ce genre de bug c'était parce que le formulaire était (mal) géré en JS. Mais sans le code en question comme le suggère marcb on ne pourra guère t'aider plus.

Hello, hériter de PDO est plutôt lourd et chiant au final, et certainement contre-performant : ouvrir une connexion à la base de données pour chacun des objets que tu vas instancier, ce n'est pas génial comme approche. Pour de petits sites/projets, une simple fonction/méthode retournant un singleton de la connexion devrait suffire. Après pour ce qui est du mapping type Doctrine, c'est histoire de goût. Je préfère pour ma part conserver la maîtrise du SQL utilisé. Sinon pour le choix du "Framework", il me semble que Jelix intègre une couche d'abstraction à la base de données, ainsi qu'un moteur de template ; ce qui peut éviter d'avoir à jongler entre les docs de Zend Framework, Doctrine et Smarty.

Hello, tu as une erreur d'écriture disque à priori : la partition ne serait pas pleine à tout hasard ? ou bien verrouillée en lecture seule ?

Oui oui, j'ai bien vu que ça "bouclait à l'infini". Pour ma carte de visite, bah de toutes façons il n'y a jamais eu de site à cette adresse. Je ne fonctionne que sur le bouche à oreille, avec des clients assez "spécifiques" qui sont heureusement contents du service. Tout comme les clients du Hub à priori.

Yep Nicolas pour moi faire attention à l'internaute tiens aussi compte de sa connexion : un PDA avec un CPU très limité et une connexion Edge par exemple, je préfère qu'il ait une image fixe (s'il n'a pas de JS actif) et qu'il fasse moins d'accès réseau. Tout est question de compromis : généralement on compresse les pages web pour en accélérer le transfert. Mais cela consomme évidement plus de ressources CPU coté serveur et client. Pour ce qui est du client, j'ai tendance à pencher sur l'économie des accès et transferts réseaux, qui me semblent de loin les plus pénalisants. Question de point de point vue on va dire ; le "débat" est clos. Pour ce qui est de mon domaine "daevel", bien que je ne vois pas le rapport, oui il est en carafe, comme probablement la plupart des domaines "non utilisés" que je possède. C'est si grave que ça ? En tous cas si ça peut vous rassurer, il n'y a pas la moindre règle de rewriting sur ces domaines.

Oulah, grand dieu non. J'accepte volontiers tous les arguments pertinents ; et je ne pense pas m'être "venté" d'être l'auteur de la moindre solution évoquée ci dessus. Cette fonctionnalité est peut être essentiel pour l'auteur de ce post, tu as raison. Mais sans plus d'info, je reste sur la "dégradation propre" comme pour les CSS. Mais ce sera effectivement au client de choisir. Aucune polémique : explication de procédés. Et je suis certain de moi oui. Là je demande à voir alors : comment, sans le moindre entête "expires" envoyé le navigateur procède t-il ? A moins de fixer arbitrairement une valeur fixe de quelques heures, ce qui pour le coup décale dans le temps le changement d'image. Pour ce qui est du "plus propre", je suppose qu'il s'agit d'un problème de point de vue. Je ne suis pas fan du JS, mais faire reposer une technique d'affichage sur une technologie du serveur web ne me semble pas plus propre non plus. La consommation des ressources fait parti de mon boulot, et le nombre de hits HTTP joue un assez grand role dans les sensations de vitesse des internautes. S'il s'agit d'une fonction primordiale, bien, on fait avec, on prévoit éventuellement une machine plus puissante (bien que la machine plus puissante n'apportera pas grand chose coté client). D'ailleurs, ce n'est certes pas la même échelle, mais ça va plutôt dans le sens des recommandations de Yahoo. Mais si tu y tiens, j'en reste là.

Hello ! Le gestionnaire de session de PHP y va déjà à coup de serialize/unserialize, et gère évidement parfaitement les tableaux. Pourquoi diable vouloir refaire le serialize()/unserialize() ? Commence par supprimer le session_register() (comme conseillé depuis PHP 4.1...) ; et utilises ton tableau directement comme tu le souhaites. Exemple, ce bout de code utilises un tableau "gonflant" à chaque actualisation : session_start(); if(!isset( $_SESSION['test'] ) ) $_SESSION['test'] = array(); $_SESSION['test'][] = time(); print_r( $_SESSION );

Absolument pas Dan : il s'agit d'une bidouille graphique, cela me semble non essentiel. Donc que cela ne fonctionne pas chez certains, ça ne me dérange absolument pas. Mais que cela implique 1 hit supplémentaire chez tous les visiteurs, juste pour ce "petit plus", ça me gène beaucoup plus.

Soit, je vais tenter d'expliquer en détail dans ce cas. Cas n°1 : on a la page "index.php", qui gère correctement le cache navigateur (via ETag uniquement, cas le plus simple). Elle utilise une feuille de style "versionnée à la volée" (cas le plus simple encore), et donc chargée par exemple via "toto.121212.css" (121212 étant le timestamp de la feuille de style). Cette feuille de style étant "versionnée", je peux évidement y coller un "expires" assez long, du genre 6 mois. J'ajoute à cela mon énorme JS (en supposant que le site n'en ai pas déjà un). Comme la feuille de style : j'inclus le timestamp dans le nom, et j'y colle un long temps d'expiration. Le système reposant sur le JS, j'ai donc deux versions de l'images : test1.png et test2.png ; chacune ayant un expires de 48 heures. Au premier accès j'ai donc 4 hits HTTP, avec des transferts complets. Lors du deuxième accès à la page 2 heures après, je n'aurais qu'un 1 seul hit HTTP (index.php) qui retournera simplement un 304. 10 heures après, je ré-accède à ma page, j'ai toujours le hit pour la page "index.php" mais cette fois mon script JS "déclenche" le téléchargement de test2.png. Lors du quatrième accès, 1 seul hit (index.php) sera à nouveau effectué. Désormais le navigateur ne demandera confirmation que pour la page "index.php", et ne demandera les versions des images que toutes les 48 heures. La CSS tout comme le script JS ne seront retéléchargés qu'en cas de modification. === Cas n°2 : meme page "index.php", CSS sur le même principe et pas de script JS. Par contre cette fois nos deux images ont une URL commune, donc impossible d'utiliser "Expires". Au premier accès j'ai donc 3 hits HTTP, avec des transferts complets. Lors du deuxième accès à la page 2 heures après, j'aurais 2 hits HTTP (index.php + image) qui retourneront tout deux un 304. 10 heures après je ré-accède à ma page, cette fois l'image change : on a le hit pour index.php, ainsi que le téléchargement de l'image. Au quatrième hit ça se complique : le navigateur va faire deux requetes, pour index.php il aura toujours son 304 ; mais pour l'image difficile à prévoir : si le navigateur a remplacé l'ETag par la nouvelle version, alors toutes les 12 heures il retélécharge l'image. Mais s'il conserve plusieurs versions (cas de Firefox à priori), effectivement il y aura à nouveau un 304. === Dans le premier cas on a donc une diminution du nombre de requêtes faites par le navigateur, avec le surcout de l'exécution du JS (qui peut également être en cache sous Firefox d'ailleurs). Et pour un serveur dédié "classique" avec du Apache prefork + PHP en front, un gain d'autant plus interessant. Sans oublier que si le site utilisait déjà un script JS pour son interface, le surcout ci dessus devient quasi nul. Dans le deuxième cas on a le double de hits HTTP, en permanence sur toutes les pages utilisant cette image de fond. Un "hit HTTP", et ce hit HTTP consomme évidement des ressources coté client comme serveur. Pour peu que le navigateur ne gère pas les ETag multiples pour une même URL, on a même un retéléchargement régulier de la dite image. === Pour répondre à : Je ne pense pas avoir dit le contraire ; mais comme expliqué ci dessus s'en servir pour servir du contenu "dynamique" via les méthodes "statiques" d'Apache cela empèche l'utilisation d'un délai d'expiration adéquate, et peu fosser la gestion du cache selon les navigateurs. Quand au fait que les serveurs dédiés sont plus puissant que les machines du grand commerce, j'aurais tendance à être d'accord même si ce n'est pas forcément le cas des Dedibox et autres machines d'entrée de gamme. Et c'est bien pour ça que j'évite le plus possible au client de refaire des hits qu'on pourrait facilement éviter. Je ne pense pas pouvoir faire plus clair ici. Mais si tu vois une erreur dans mon raisonnement, n'hésites pas. Etant tous deux sur Lyon, on peut même voir ça autour d'un verre si tu veux. PS : merci d'éviter les mini attaques personnelles, à priori tu n'en sais pas plus sur moi que j'en sais sur toi.

Alipp : et à ton avis, qu'est ce qui consomme le plus de ressources pour le navigateurs : ré-interroger à chaque page le serveur et retélécharger puis décompresser l'image toutes les 12 heures, ou bien simplement exécuter une ligne de JS ce qui déclenchera... absolument rien de plus ? Faire sauter une partie de la chaîne de mise en cache à la fois coté serveur et coté client, juste pour une bidouille graphique, tu penses vraiment que ça consomme moins de ressources que le script JS qui maintient cette chaîne intacte ? Je suis loin d'être un défenseur du JS, mais je maintiens qu'il s'agit très probablement de la meilleure solution ici ; encore plus si le site fait déjà appel à un script JS. Quand à la solution du mod_rewrite en elle même, elle est effectivement très intéressante, mais pour moi elle n'est pas adaptée à ce cas ci.

Les serveurs DNS de nombreux FAI sont assez nazes à mon gout (Neuf, Free, Orange, Numéricable) ; dans ce cas une solution est d'utiliser des serveurs DNS plus fiables (un serveur _AT_home, ou encore les services d'OpenDNS).

Justement, pour le coup on ne peut pas utiliser mod_expires donc on augmente de manière démesurée le nombre de hits, et on prend le risque que le navigateur ne gère pas le "double ETag". A ma connaissance firefox le gère bien, mais si ce n'est pas le cas sous IE cela veut dire que 2 fois par jour 60% des visiteurs re-téléchargent l'image en question. Pour ma part je trouve ça complètement contre productif.

Par contre je serais curieux de voir l'impact sur le cache du navigateur : l'image est re-téléchargée par tout le monde toutes les heures non ? Entre l'ETag et la date de modification, je ne sais pas si tous les navigateurs vont gérer correctement ce genre de contenu récurent. Afin d'utiliser au mieux le cache du navigateur, j'opterais pour la solution JS pour ma part. A moins que les pages PHP n'aient aucun cache et dans ce cas le changement de classe via PHP semble le plus simple.

Hello, utilises preg_replace_callback() à la place (surtout que ereg_replace est déconseillée au moins depuis PHP 4, et disparaitra de PHP 6). Mais même comme ça, j'aurais tendance à procéder en deux étapes pour éviter des remplacements "en boucle".

Nicolas : j'ai effectivement plusieurs clients qui raisonnent comme ça : ils préfèrent prendre un hébergement discount sans support avec une prestation d'infogérance à coté plutôt qu'un hébergement milieu de gamme avec infogérance partiellement incluse. Moi qui suis fan de l'équipe Sivit, je trouve ça dommage, mais d'un autre coté je préfère ça plutôt qu'ils se passent de mes services.

Oui enfin les Kimsufi actuels sont plus puissant que les serveurs dédiés qu'on gérait il y a 3 ans ; du coup pour ma part j'accepte aussi les VDS, même si l'infogérance coute 5 à 10 fois plus cher que l'hébergement. La puissance des serveurs double tous les 18 mois il parait, mais le temps d'administration n'est pas réduit pour autant.

De ce coté Eclipse est vraiment sympa : il fonctionne partout (Windows, Linux, et probablement Mac OS X), il existe une tonne de plugins pour pouvoir faire ce qu'on veut avec, et il gère de manière très poussée la plupart des langages. Son seul "défaut" à mon sens c'est qu'il ne peut pas être utilisé comme éditeur d'appoint : si on a juste un petit truc à modifier/lire rapidement, il n'est vraiment pas pratique.

Erf pas glop, même comme ça il ne veut pas utiliser "points". Il faudrait lui spécifier directement d'utiliser cet index (je te laisse te reporter à la doc pour la syntaxe exacte). Et as tu essayé de créer un index unique sur username + points ainsi que points + username ? Parce que c'est quand même étrange d'avoir une requête si longue avec si peu de données. PS : si on devait rechigner, perso je trouve dommage d'être obligé d'ajouter un "username != ''" alors qu'il s'agit à priori de la clé primaire.

Si je demandais le "show indexes" c'était pour avoir le détail (indexes multiples, uniques, clé primaire...). On va donc supposer que la clé primaire est le champ "username" : et dans ce cas MySQL n'utilise pas le "bon" index pour sa requête. Précises lui d'utiliser l'index "points" pour voir ce que cela donne. Une autre approche pourrait être : EXPLAIN SELECT username, points, sexe FROM membres WHERE points = ( select max(points) where points <= 49 and username!='' AND username!='toto' AND active=1 AND moderateur!=1 ) and username!='' AND username!='toto' AND active=1 AND moderateur!=1 ORDER BY points DESC LIMIT 0, 1 Pas certain que ce soit beaucoup mieux, mais au moins ça devrait forcer l'utilisation de l'index sur "points", et fortement limiter le nombre d'enregistrements traités. Quitte à utiliser une vue après pour rendre le code plus clair.

Essayes de faire un explain (et fais nous un copier/coller du résultat) : EXPLAIN SELECT username, points, sexe FROM membres WHERE username!='' AND username!='toto' AND active=1 AND moderateur!=1 AND points<='49' ORDER BY points DESC LIMIT 0, 1; Idem, pour être certain de tes indexes : show indexes from membres Et à tout hasard, après le premier copier/coller, lance ça pour voir : optimize table membres; EXPLAIN SELECT username, points, sexe FROM membres WHERE username!='' AND username!='toto' AND active=1 AND moderateur!=1 AND points<='49' ORDER BY points DESC LIMIT 0, 1

Au contraire je pense qu'un index sur "points" serait utilise ici. A vérifier à coup d'explain, mais je ne vois pas ce qui clocherait dans ce cas. (Si ce n'est que l'index sera probablement mis à jour très souvent).