Kioob

Les fonctions imap de PHP doivent être "installées" là où est exécuté PHP : c'est PHP qui en a besoin pour pouvoir dialoguer avec un serveur IMAP (ou POP). Coté fréquence, aucune idée... comme toutes les extensions PHP, c'est au bon vouloir de l'hébergeur. Si PHP est installé en CGI, tu peux tenter de charger toi même l'extension via la fonction dl(), mais je n'y crois pas trop : if(!extension_loaded('imap')) dl('imap.so'); Pour ton erreur : Couldn't open stream {pop3.free.fr.ext:110/pop3}INBOX Il y a un .ext dans l'URL qui ne me semble pas normal du tout, c'est toi qui l'a mis non ? Pour ce qui est des autres solutions, comme d'hab on peut se palucher le protocole complet à coup de socket, ou opter pour une classe "toute prête" (si cela existe) comme l'indique LiFi, ou encore contacter/changer d'hébergeur...

Hello, les fonctions imap_*() nécessitent l'extension imap, qui n'est visiblement pas fournie chez Free.

<troll>L'autosurf, c'est mal .</troll> Ma boule de cristal me dit que non, pas vous ? Plus sérieusement, je ne connais pas les services de Hiwit mais généralement un serveur est livré avec les paramètres "d'origine" qui ne peuvent pas être adaptés à toutes les utilisations. C'est comme prendre un costume "taille unique" et croire qu'il ira à tout le monde. Pour la mémoire, ça dépend si Webmin tient compte des caches et buffers ou non... Si ce n'est pas le cas, cette info est fortement "biaisée". Pour ton soucis de navigation, je mise sur un problème de register_global (ça aussi c'est le mal) ; mais difficile d'en savoir plus là comme ça. Sinon pour les services activés : - pour l'envoi d'email c'est soit SendMail soit Postfix (ou autre...), mais pas les deux - tu as besoin de la réception de courrier ? si non, vire Dovecot - si tu n'as pas besoin de la réception ou pas besoin du filtre antispam, vire spamassassin Pour le reste, il te faudra beaucoup de lecture ou très probablement faire appel à un professionnel. Avoir un VDS se résume pour certains à "la puissance d'un mutualisé avec la complexité d'un dédié" ; il faut bien se renseigner avant d'opter pour une solution ou une autre. Bon courage.

Bonsoir, à ce propos, quelqu'un a t-il déjà testé le Gandi SiteMaker ? Je me demandais justement quelle était la cible exacte (neophite, ou nécessite un minimum de connaissances ?).

Hello, pourquoi ne pas utiliser la méthode indiquée par Sora, mais en utilisant simplement des requêtes imbriquées ?

Hello, pour limiter les problèmes perso je ferais directement : "UPDATE combattant SET force = force + 1 where login='$login'" De plus cela t'évite le SELECT pour récupérer la force actuelle. Quant au fait que l'UPDATE ne fonctionne pas, as vérifié ta variable "$login" comme le précise captain_torche ? D'ailleurs est elle correctement échapée ? (cf mysql_real_escape_string())

Hello, Pingwy propose ça entre autre, avec un mois d'essai gratuit.

Bonsoir, Quel est le message d'erreur exact ? Car la solution se trouve probablement là...

En tous cas perso je n'ai pas trouvé de solution magique à ce gros problème. Le code des régies est complètement obsolète et cela pose effectivement beaucoup de soucis dès lors qu'on essaye de faire les choses proprement

Et si tu veux le désactiver de manière générale, tu peux carrément virer le module "negociation" d'Apache 2. Sur du Debian : a2dismod negociation suivi d'un /etc/init.d/apache2 reload.

Bah ça ne fait pas partie des services que propose Dan ? Une migration ça ne se fait pas à la légère quand même... En tous cas pour la machine actuelle, je ne pourrais guère t'aider plus... désolé.

Ah wachement pratique ça, je t'aurais bien dit d'y aller à coup de yum mais si tu utilises une Fedora je suppose que tu as cette saleté de Plesk qui tourne aussi

Sous Fedora je ne sais absolument pas où cela peut être stocké. Pour le message d'erreur rapporté par OVH, c'est un peu balot mais je le trouve un poil incomplet. Au pifomètre un "not syncing" je dirais que c'est un soucis de disque mais bon, sans plus d'info... "smartmontools" est installé sur la machine ? (essaye un smartctl -a /dev/sda éventuellement). Sinon tu as déjà le dernier kernel "made in OVH", et sans grsec, donc à priori pas de raison que cela vienne de là (sinon il y aurait beaucoup de clients concernés...). En dernier recours / solution temporaire / crade, ajouter un "panic=5" dans les paramètres de boot du kernel pour qu'il redémarre tout seul en cas de crash.

Pour un problème de kernel si info il doit y avoir c'est dans les logs kernel (/var/log/kern.log* pour Debian). Sinon à moins que tu ais activé le reboot auto en cas de kernel panic, il doit y avoir un joli message d'erreur à "l'écran", et quand OVH intervient généralement ils "notent" le message d'erreur et l'indiquent au client. Ce n'est pas le cas pour toi ?

Hello, d'après mon expérience : kernel / driver buggé, ou barrette de mémoire défectueuse. Rien dans les logs ? Aucune info de l'hébergeur ?

Hello, le problème c'est que les logiciels utilisés ne vont pas se configurer tout seul de manière automatique, il faut forcément que quelqu'un cas le fasse. Et toutes les solutions "intermédiaires" auront ce problème : certes les logiciels seront déjà installés, mais auront la configuration par défaut... qui est bien souvent complètement inadaptée.

Justement non, je ne lui demande pas de l'interpréter. Une simple option dans l'interface de dreamweaver pour dire que ce fichier doit être intégrer dans un autre pour le rendu me suffirait amplement.

A moins que je me sois (encore) mal exprimé, je vois pas ce que je pourrais t'envoyer de plus en fait. Je voudrais simplement que l'éditeur interprête un fichier de ce genre : {load:'/templates/header'} <div class="page" id="redirections_ajout"> <form action="/redirections/ajouter.php" method="post" id="formulaire"> <p>Saisissez l'identifiant de la redirection à créer (sans espaces).</p> <p kore:if="erreur" class="error"> Erreur durant la création de la redirection :<br /> {erreur} </p> <label for="redirection_nom">Nom</label> : <input type="text" name="redirection_nom" id="redirection_nom" size="20" maxlength="80" /> <input type="submit" disabled="disabled" id="redirection_submit" value="Créer cette redirection" /> </form> </div> {load:'/templates/footer'} comme s'il s'agissait en fait de ce code : <?xml version="1.0" encoding="UTF-8" ?> <?xml-stylesheet type="text/css" href="/include/default.1224781183.css" ?> <?xml-stylesheet type="text/css" href="xxx_zzz.1224781183.css" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr"> <head> <title>template</title> <meta http-equiv="content-type" content="application/xhtml+xml" /> </head> <body> {load:'/templates/header'} <div class="page" id="redirections_ajout"> <form action="/redirections/ajouter.php" method="post" id="formulaire"> <p>Saisissez l'identifiant de la redirection à créer (sans espaces).</p> <p kore:if="erreur" class="error"> Erreur durant la création de la redirection :<br /> {erreur} </p> <label for="redirection_nom">Nom</label> : <input type="text" name="redirection_nom" id="redirection_nom" size="20" maxlength="80" /> <input type="submit" disabled="disabled" id="redirection_submit" value="Créer cette redirection" /> </form> </div> {load:'/templates/footer'} </body></html> Bref, qu'il tienne compte d'un header et footer pour le rendu ; principalement pour la CSS. Et je ne lui demande même pas t'interpreter le moindre tag du moteur de template, juste que si je lui dit "ce fichier sera intégré dans tel gabarit" - le gabarit en question étant un fichier statique local au poste du maquetiste, pas un template non plus - qu'il en tienne compte pour le rendu. On a justement opté pour une syntaxe de type flexy, afin que les IDE de ce genre n'aient pas à se soucier du code du template. Cela reste "compatible HTML", et peut donc parfaitement être ignoré par le moteur de rendu. Mais sans la CSS, le rendu ne sert à rien.

Bah justement ça ne me semble pas du tout spécifique

Justement une prise en charge plus simple (sans le moindre parsing) indépendante de tout moteur de template, ça n'a rien de choquant, si ?

Je continue à trouver ça bizarre qu'il n'y ait à priori rien en standard pour gérer ce type "d'inclusion" relativement basique. Et encore comme je disais je ne demande même pas à ce qu'il sache traiter les balises du moteur de template, mais juste qu'on puisse lui dire que le template en question fait partie d'un gabarit bien défini. Actuellement, la personne qui s'occupe des maquettes crée sa page sous Dreamweaver en fonction d'un "modèle" qu'il s'est fait, une fois qu'il a terminé il nous redonne la page et on se charge de reproduire le même rendu avec un code CSS/HTML radicalement différent. Et s'il a une retouche à faire après, Dreamweaver est bien incapable d'afficher le rendu que ça aura. Au final Dreamweaver - ou le moteur de template, question de point de vue - nous fait perdre pas mal de temps, alors que le but est justement l'inverse. Et je ne me vois vraiment pas former cette personne aux rouages du CSS/HTML... ce n'est pas non plus son rôle de passer du temps là dessus. Enfin comme tu l'indiques je regarderai du coté de la gestion PHP interne de Dreamweaver voir s'il y a moyen de mettre en place quelque chose, mais ça me semble terriblement compliqué pour pas grand chose. Perso ça me semble quand même très simple pour ce genre de soft de considérer que tel "fichier de template" sera injecté entre deux portions de code de ce genre : <?xml version="1.0" encoding="UTF-8" ?> <?xml-stylesheet type="text/css" href="/include/default.1224781183.css" ?> <?xml-stylesheet type="text/css" href="xxx_zzz.1224781183.css" ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr"> <head> <title>template</title> <meta http-equiv="content-type" content="application/xhtml+xml" /> </head> <body> et </div> </body></html> Quitte à ce qu'on ajoute un <base href="" /> dans ce pseudo gabarit d'ailleurs. Pour le moment la piste qu'on envisageait c'était de faire en sorte (sur l'environnement de dev) que le moteur injecte le code correspondant aux includes dans le source du template directement, avec un balisage spécial pour dire d'ignorer certaines portions de codes. Sur le principe ça fonctionnerait et répondrait en partie au problème, mais ça va poser des soucis avec subversion qui détectera de "fausses" modifs. Bref, je cherche toujours une solution "simple"

Hello, 1) avant de faire ton mysql_fetch_assoc() tu devrais tester le résultat de mysql_query() et afficher les erreurs MySQL 2) cela t'aurait permis de voir que as oublié de mettre un FROM dans ta requête.

Mais pourtant je pense que DreamWeaver et autres continue à (très) bien se vendre ; tout comme l'utilisation de moteurs de templates me semble de plus en plus répandue. Je trouve donc étrange d'être le seul à priori confronté au problème. Ou bien c'est notre gestion des templates qui est farfelue ?

Typiquement ça donne ça : {load:'/templates/header'} <div class="page" id="redirections_ajout"> <form action="/redirections/ajouter.php" method="post" id="formulaire"> <p>Saisissez l'identifiant de la redirection à créer (sans espaces).</p> <p kore:if="erreur" class="error"> Erreur durant la création de la redirection :<br /> {erreur} </p> <label for="redirection_nom">Nom</label> : <input type="text" name="redirection_nom" id="redirection_nom" size="20" maxlength="80" /> <input type="submit" disabled="disabled" id="redirection_submit" value="Créer cette redirection" /> </form> </div> {load:'/templates/footer'} Je ne demande évidement pas à l'éditeur de savoir interpréter ces tags "{load}" ; mais qu'on puisse lui préciser que ce fichier fait partie d'un "gabarit" donné (dans lequel le code d'entête et pied de page manquant sera indiqué).

Il m'arrive au contraire très souvent d'ouvrir un onglet que je lis plusieurs heures (ou jours) après. On a également eu un soucis au boulot sur des formulaires qui étaient limités à 30 minutes entre l'affichage et la validation, et qui posaient donc soucis : visiblement nos utilisateurs cliquaient sur le lien dans leur email le matin, mais ne remplissaient le formulaire que plusieurs heures après. Je ne pense donc pas que ce soit une pratique si inhabituelle que cela. Maintenant reste à savoir si dans ton cas cela vient du site (un problème de javascript ?), de ton poste, ou encore de IE (dont je ne connais pas le comportement).