Kioob

tu me fais peur là : je n'ai évidement pas tester tous les clients mail, me contentant du "testeur" de CampaignMonitor. Aurais tu un exemple de client email ne supportant pas l'UTF-8 et/ou des stats ?

Hello, chez nous on utilise parfois ça : function maFonction( $param1 = null, $param2 = null, $param3 = true) { if( $param1 === null ) $param1 = 'http://www.bijdsfjlsdfl.com/dfjdfhjfd/hdfjhjdf.js'; if( $param2 === null ) $param2 = '/home/web/procedures/monfichieraunomcompliqué.php'; // [...] } Ainsi tu peux utiliser plusieurs combinaisons, du genre : maFonction(null, null, false); maFonction('toto', null, false); Même principe que pour certaines fonctions internes de PHP quoi.

ils seront rétrogradés, tout comme les autres sites du genre l'ont été jusqu'à maintenant

Bonjour, c'est lié au fait que vous utilisez la version dotdeb de PHP au lieu de la version Debian ; en effet sous etch php5-imap dépend normalement de libc-client2002edebian pas de libc-client2007b (cf : http://packages.debian.org/etch/php5-imap ). Parmis les solutions, vous pouvez installer la version de "libc-client2007b" présente dans etch-backports (comme indiqué ici). Voir remplacer ces paquets dotdeb (PHP, MySQL, etc) par ceux issus de backports. L'idéal étant certainement de tout migrer en Debian Lenny, étant donné que Debian Etch ne sera plus maintenu à compter de février 2010.

beurk Je ne suis pas suffisamment pédagogue pour refaire les bases, mais il y a du boulot. Si tu as une page blanche sans message d'erreur c'est probablement que l'hébergeur masque les erreurs (comme recommandé). Il faudrait vérifier cela via un phpinfo() puis le cas échéant ré activer les options nécessaires ; par exemple : error_reporting(E_ALL); ini_set('display_errors', true); La solution "à la goret" serait de remettre ces anciens appels via http, en utilisant cette fois readfile(). Mais c'est très lent, et vraiment crade.

Hem. Je ne pense pas que tu faisais des appels include() via http, si ? En tous cas, je ne comprends pas ce que tu veux faire avec le bout de code que j'ai cité : tu forces un chemin absolu à partir du dossier du fichier courant, auquel tu "ajoutes" un autre chemin absolu. Ca donne l'impression que tu mélanges un peu toutes les solutions, sans chercher à comprendre quel est le problème. Bref, essaye en donnant plus de détail : quel est le chemin absolu du fichier dans lequel est placé l'include, et quel est le chemin absolu du fichier que tu veux inclure ? La solution indiquée par ton hébergeur - bien que non portable - a au moins le mérite de fonctionner ; mais quand tu dis "sauf que certaines pages ne chargent plus", que veux tu dire par là ? quel est le message d'erreur exact ? et quelle est la ligne de code correspondant au message d'erreur ?

include(dirname(__FILE__)."/home/users/web/b2761/glo.monuser/thematiques/alaune.php"); Ce code a de toutes façons très peu de chances de fonctionner. Que cherches tu à faire ici ?

Tu peux donc utiliser la même chose pour changer les parametres display_errors, error_log et log_errors ; voir également error_reporting. Quelques explications : http://fr.php.net/manual/fr/errorfunc.configuration.php

Je ne connais pas les spécificités de l'hébergement infomaniak, fournissent ils un quelconque moyen de changer la configuration de PHP ? La méthode par htaccess ne fonctionne généralement qu'avec la version module de PHP. Sinon il reste la méthode ini_set(), mais ça ne fonctionnera pas pour les erreurs de syntaxe par exemple.

Hello, ta variable $errno n'est initialisée nul-part, tu ne te serais pas trompé ? Sinon en passant : - un switch / case serait probablement plus parlant pour tes conditions sur $errno - le error_reporting n'est appelé que si le code est exécuté, ce qui n'est pas le cas lors d'un parse error - de manière générale error_reporting(0) est fortement déconseillé. Il vaut mieux privilégier un error_reporting(E_ALL) voir error_reporting(E_ALL | E_STRICT) mais par contre en désactiver l'affichage via display_errors tout en activant le traçage dans des logs.

Sinon en PHP readfile() peut faire l'affaire... selon ce que tu cherches à faire.

Sympa mais avec Firefox 3 sous Linux mon CPU est à 100% quand cette page est affichée, même si la photo ne bouge pas. Encore plus gourmand que Flash, c'est pour dire Enfin de là à ce que ce soit répandu, ce genre de "soucis" sera peut être corrigé.

Hello, à ma connaissance MySQL ne gère pas la récursivité (contrairement à Oracle). Mais il y a probablement moyen de gérer ça via les procédures stockées, as tu regardé de ce coté ? Chez nous on a résolu ce problème en utilisant une table "précalculée" contenant les résultats de traitements récursifs PHP... mais ce n'est pas adapté à toutes les applications.

Je n'ai pas été très clair mais comme le dit captain_torche il te suffit de changer de doctype, vu que de toutes façons tu n'utilises pas du "vrai" XHTML.

Bah que tu peux très bien utiliser les iframes comme suggéré par Dan

text/html pardon. Mais oui. Donc ça n'a pas grand chose de strict finalement

En javascript, c'est l'intégration toute simple du tag de pub via <script src="XXXX" type="XXX"></script>. PS : du XHTML "strict" avec un content-type en text/plain alors, non ?

Hello, j'ai eu quelques VDS Sivit et je n'ai pas rencontré ce soucis non. As tu contacté le support pour avoir de plus amples informations ? (il y a une "mini offre infogérance" inclus dans les prestations Sivit, autant s'en servir)

Bonsoir, essaye de commencer par regarder le contenu de $_GET : var_dump($_GET);

Si le but est juste de gérer le timeout PHP, il y a une variable pour ça : ini_set('default_socket_timeout', 3); @readfile('http://url.de.ta/pub.php'); Par contre pour ma part je ne vois pas l'intérêt de ta méthode : - site plus lent, aucun parallélisme et empêche certainement toute mise en cache de tes propres pages - l'internaute risque de ne pas être "tracké" comme il faut (IP du serveur + pas de cookie), donc tu risques de ne pas être payé Tout ça pour quoi ? - éviter d'utiliser du javascript alors qu'une grande partie des tags des régies l'impose - éviter d'utiliser une iframe parce que ce ne serait pas "valide". Tiens c'est nouveau ça... à moins que tu utilises du XHTML Strict, mode dans lequel les publicités des régies ne fonctionnent pas non plus (document.write oblige...) A mon avis tu t'embêtes pour de mauvaises raisons là.

Dans cette gamme de prix, tu as forcément au moins 8Go de mémoire. Il y a fort à parier que l'intégralité de ta base de données tienne dans ces 8Go non ? Dans ce cas grâce aux divers caches (utilisés par l'OS ou le SGBD) le gain de vitesse en lecture sera nul, et pour l'écriture dépendra d'autres facteurs (par exemple : MyISAM vs InnoDB, réglages d'InnoDB, système de fichier, contrôleur RAID). La plupart des lenteurs MySQL sont dus à des problèmes de verrous (souvent erreurs de conception de la bdd ou d'écriture des requêtes), et le fait de passer à du matériel 10 fois plus rapide n'y change malheureusement rien. Tout ça pour dire que je n'ai pas encore rencontré de cas de site "classique" (oui c'est très vague) qui à priori en tirerait vraiment parti. Mais je suis loin de connaître tous les usages, mon raisonnement vient principalement des cas rencontrés sur les sites de mes clients.

Hello, à mon avis ça n'est réellement intéressant qu'à condition d'avoir un serveur qui fait beaucoup d'écriture et/ou dont les données ne tiennent pas intégralement en mémoire. Et là ça limite déjà pas mal. Après je n'ai toujours pas testé, mais mes seuls clients qui auraient vraiment un intérêt en terme de vitesse à passer au SSD se heurtent à un autre soucis : le volume d'écriture. Je n'ai pas réussi à trouver de message clair là dessus, mais j'ai cru comprendre que ces disques étaient destinés à un certain quota d'écriture par jour (genre 20Go), et qu'au delà de ça les perfs diminuaient dramatiquement (afin d'assurer les 5 ans de longévité). Mais ça frole la rumeur là... et je n'ai pas envie d'exposer le site d'un client à ce genre d'aléas.

Hello, il n'y a pas toutes les infos que tu demandes et la base est très incomplète (c'est "communautaire"), mais l'API du site Les-horaires réponds au moins partiellement à ton besoin : Par contre je n'ai aucune idée des tarifs (si toutefois c'est payant).

Bonjour, la technique que je préfère pour ma part (ainsi que mes clients) est d'installer un "reverse proxy" sur l'ancienne machine, de façon à ce que les requêtes soient dirigées vers la nouvelle dans tous les cas.

Hello, OVH utilise des kernels avec le patch GRSEC qui désactive l'accès à plusieurs trucs du genre, ça ne m'étonnerait pas que ce soit lui qui bloque cela. Pour ma part je le vire car je préfère avoir des outils de monitoring opérationnels et un kernel suivi par Debian (ou par moi) plutôt que celui d'OVH ; mais je te laisse faire ton choix. En tous cas grâce au netboot tu peux "facilement" tester avec un autre kernel pour voir si cela vient bien de cela (attention de prendre le bon).