Kioob

Perso je vois 3 possibilités : - attendre que le script utilisant la v1.2.0 évolue vers la version 1.2.1 - faire toi même (ou faire faire) les modifs dans le script en question pour être compatible avec la 1.2.1 - utiliser des scripts basés sur quelque chose de plus "stable", tel que Dojo ToolKit par exemple. Au taff on a abandonné Mootools justement parce qu'on ne se voyait pas tout redévelopper / vérifier / contrôler à chaque mini évolution de mootools. Avec Dojo on a plus ce genre de soucis, même si l'approche est radicalement différente. Après je suis loin d'être un expert en JS... mais Mootools, on a vraiment vite déchanté.

Une autre solution serait de sortir l'artillerie lourde, c'est à dire les expressions régulières. Un preg_replace(), en précisant "\b" autour du mot ou les marqueurs de début ou de fin phrase, et c'est partit. Tu peux même y mettre plusieurs mots si tu en as plusieurs à supprimer.

Bonjour, oui, il y a plusieurs méthodes répandues : - utiliser les fonctions de MySQL : unix_timestamp() pour convertir un datetime au format timestamp unix (ce qu'utilise PHP), et sa réciproque from_unixtime() qui fait donc l'inverse. - utiliser les fonctions PHP : strtotime (à vérifier...), ou encore y aller à coup d'explode() / preg_match() puis mktime()

Pour moi assimiler le contenu d'un autre à son propre site (logo de son propre site, mise en page, marque, etc) c'est radicalement différent de la modif d'URL à laquelle (trop) peu d'internautes prêtent attention.

Pour moi le problème de droit d'auteur intervient quand on se sert des frames pour intégrer le contenu d'un autre site dans le siens. C'est quand même très différent d'une "web barre", non ?

<HS>Prélude : visiblement tes benchs ont été fait en mode "auto commit" non ? Ce qui expliquerait les perfs catastrophiques. Je serais curieux de voir la même chose en tirant parti du transactionnel. On peut d'ailleurs rencontrer le même problème avec SQLite : sans transaction les perfs sont catastrophiques.</HS>

Bonsoir, comme indiqué dans le message d'erreur PHP n'arrive pas créer son fichier de session dans le dossier /tmp, le considérant comme inexistant. A tout hasard il n'y aurait pas un autre message d'erreur juste avant concernant "open_basedir" ? Dans tous les cas, quelle est la valeur actuelle de la directive open_basedir ? (à consulter via un phpinfo() par exemple) et safe_mode ? Et le dossier /tmp, il existe ?

Oui il faut bien sûr faire une jointure entre les deux tables, mais je ne te donnerai pas la réponse "pré-machée"

Bonjour, regarde du coté de l'instruction GROUP BY, qui devrait répondre à ton problème.

Hello, tu parles de "wget" non ? Pour ce qui est de l'utilisation du chemin absolu, il y a des avantages comme des inconvénients : Les avantages de l'accès direct : *) en direct, on a pas de problème de timeout, et comme PHP utilise alors un fichier de configuration différent on peut avoir plus de mémoire ou encore utiliser des extensions différentes. *) via http on passe généralement par le module PHP d'Apache qui ne libère pas aussitôt la mémoire consommée. Donc si le "cron" est gourmand en mémoire, il risque de pénaliser longtemps le serveur. *) via http on squatte un slot Apache pendant toute la durée du traitement ; or avec un Apache en "prefork" ces slots ne sont pas si nombreux... dommage d'en utiliser un rien que pour ça. Les avantages de l'accès via http : *) d'un autre coté via http on "hérite" de la pseudo sécurité "safe_mode" / "open_basedir" du site. Et c'est un minimum si le serveur n'est pas sécurisé. *) de la même façon le script utilisera la même configuration que "sur le site", ce qui peut parfois faire gagner du temps. Généralement quand ça a été prévu pour, je pense qu'il vaut mieux utiliser l'accès direct oui. Mais certains scripts s'y prêtent très mal, le passage par "http" est donc la méthode la plus simple dans ce cas.

Hello, pour ce genre de choses je miserais surtout sur la fiabilité : *) du RAID 6+0 chez GANDI par exemple ; mais faut prévoir un deuxième "disque" pour la sauvegarde. 20€ par mois pour 10Go + 20€ pour 10Go de plus. *) un filer classique avec "option sauvegarde" chez un hébergeur mutualisé (infomaniak ?). Aucune idée des tarifs, ni des clauses de "squattage" de l'espace. *) un RPS OVH pour le stockage iSCSI clusterisé (à confirmer) ; mais quid de la sauvegarde ? 10€ par mois pour 10Go. *) un dédié en RAID pour le stockage, ainsi qu'un deuxième dans un autre data center contenant les sauvegardes incrémentales beaucoup plus cher à priori. *) passer par un prestataire spécialisé ? Mais d'un autre coté si c'est déjà une sauvegarde, t'as peut être pas besoin de souscrire à une sauvegarde de sauvegarde A titre perso, un dédié chez OVH avec deux disques de 500Go en raid soft, crypté via "dm-crypt". Et un joli backup incrémental là dessus. Histoire de rentabiliser un peu le tout il sert à toute la famille, dans des dossiers bien séparés.

hello, tu peux par exemple mettre la date dans le nom du fichier : mysqldump -u$USER -p$PASSWORD -e -q -Q --add-drop-table $i | gzip > $LOCALDIR/$i.$1.`date +'%Y-%m-%d'`.sql.gz

En passant, PHP gère maintenant ça tout seul via PDO

Là on a une vision différente du rôle d'un framework Un système de commentaires, d'inscription, de news, et autres "fonctions très haut niveau" et "très spécifique" n'a pour moi vraiment rien à faire dans un framework. Mais c'est sûrement une affaire de goût... Pour prendre un cas "concret", je ne sais pas si vous connaissez le framework Javascript "Dojo ToolKit". Il est séparé en trois "couches" : Dojo, dijit et DojoX. Ce que je considère comme le framework c'est "Dojo", il fournit une base stable/propre/portable pour tout faire, le reste c'est plutôt de la bibliothèque de fonctions pratiques, basée sur le framework.

Yep yep effectivement (désolé j'ai un peu beaucoup survolé le topic ).

A fonctions équivalentes, j'aurais tendance à dire oui. Seulement voila, une bonne partie du code sert à l'aspect sécurité, la portabilité d'un environnement à l'autre, à la gestion de caches, des entêtes HTTP, audit, débugage, etc. Choses qui sont absentes de 90% des codes "classiques". Faire un code qui inclus toutes ces fonctionnalités (et sûrement d'autres) va énormément plus vite avec un framework que sans. Mais sinon, je n'en suis vraiment pas persuadé non.

Arf forcément si c'est pour du mutualisé, on va pas aller bien loin...

Hello, dans les paquets Debian je vois au moins l'utilitaire "catdoc" qui extrait le texte d'un document Word (mais très probablement sans le moindre formatage). Ou encore d'utiliser OpenOffice pour la faire conversion... après tout, ce doit être faisable. Non ? Edit : sous Debian il y a aussi "docvert" : Le site officiel : http://holloway.co.nz/docvert/

Hello, suExec impose que le CGI soit dans "/var/www", mais normalement n'impose rien pour ce qui est de l'emplacement des scripts PHP. Le message d'erreur en question ne me semble donc pas justifié... essaye de voir avec le support Virtualmin, non ?

Pour un transfert entre deux serveurs vous appartenant, utiliser des certificats "signés" n'apporte rien sur le plan sécurité. Autant en rester aux certificats "auto signés" à mon avis.

L'utilisation d'une connexion HTTPS avec identification du client grâce à un certificat ne serait elle pas "préférable" ? Remarque, ce n'est pas forcément plus simple à mettre en place...

Oui : Lynx ne traite pas du tout la CSS, il ne se fie qu'à l'ordre dans le code HTML.

En fait je place toujours les menus en fin de "code HTML", mais via CSS je les repositionne en haut de page.

Hello, Ca c'est parce que tu as placé tes menus au début de ton code HTML, alors qu'avec les CSS ça n'a rien d'obligatoire. A vrai dire, c'est un peu le but aussi, non ? Maintenant je t'avouerais que vu qu'aucun site (ou presque) ne prête attention à ce genre de choses, les rares fois où je suis amené à utiliser Lynx je fais avec malgré tout. Le coup des menus est très très pénible : sur le site de Nvidia par exemple, il y a plusieurs pages de menus à faire défiler avant d'accéder au contenu... et d'un point de vue visuel c'est la cata : il est assez difficile de voir que l'on a changé de page.

Dudu : en supposant qu'il y ait aussi un "ORDER", alors il y a de grandes chances oui, à vérifier avec un EXPLAIN. Mais attention ça ne fait pas du tout la même chose : les ID auto increment ne se suivent pas forcément, surtout en cas de suppression. Si tu effaces les ID 40,41,42,43 et 44, la première requête ne te retournera plus que 45 enregistrements. Tu es sûr de ton coup ? Les indexes améliorent généralement les perfs des SELECT, mais ralentissent fortement les INSERT et UPDATE. Je me doute bien c'est juste dommage que ce soit également remplacé entre les balises [ code ]. Elle récupère la valeur "position" la plus grande... et la stocke dans une variable MySQL. Mais tu peux parfaitement utiliser une variable PHP à la place.