Cliquer ici pour voir la vidéo.

« After a quick overview of some of the new features in PHP 5.3, he gives us a detailed and practical look into PHP performance pitfalls. He walks us step by step through the tools and techniques to optimize an application, showing us some remarkable improvements in the performance and throughput of WordPress installation. You can view the slides online at talks.php.net/​show/​digg. »

http://ie6update.com/

Dans la série on en apprend tous les jours, j’ai découvert aujourd’hui (et je n’ai pas honte de l’avouer ) un paramètre introduit dans PHP5.2.0 mais qui ne figure pas dans le php.ini par défaut des systèmes. Il s’agit de allow_url_include qui, comme son nom l’indique, permet d’inclure un fichier commençant par http://…

J’ai découvert ça suite à ce brillant message d’erreur

Warning: xxx: URL file-access is disabled in the server configuration

mais en ayant tout de même l’option allow_url_fopen = On dans mon php.ini

Honnêtement, qui connaissait ce paramètre ?

En voici une justement qui m’est arrivée pas plus tard que tout à l’heure: pour un site fraîchement mis en production, un fournisseur veut envoyer une emailing contenant une invitation à jouer pré-remplie avec nom et prénom. Jusque là, rien de sorcier. Sauf qu’au lieu d’encoder correctement l’url, le prénom et le nom de famille des joueurs est transmis tel quel dans un bon vieux « nom=tonton&prenom=rené »

Au sein de mon formulaire d’inscription, je récupère et j’affiche ces valeurs avec un ptit urldecode (inutile dans ce cas là of course) et un html_entities avec charset réglé en UTF-8

Sur certains browser, » tonton rené » devient « tonton ren » suivi d’un carré ou d’un @ selon les cas. Mais uniquement sur PC ! Sous macosx, tout va bien …

Safari et FF version Macosx considèrent donc que les paramètres de l’url sont encodés en UTF8, mais IE6 et FF sous Windows considèrent qu’il s’agit d’ISO. La solution est alors de tester l’encodage des paramètres passés dans l’url et d’utf8_encoder tout ce petit monde s’il ne s’agit pas déjà d’utf8

Au passage, voilà une fonction trouvée sur php.net qui permet de tester ce genre de chose:

function is_utf8($string) {
// From http://w3.org/International/questions/qa-forms-utf-8.html
return preg_match('%^(?:
[x09x0Ax0Dx20-x7E] # ASCII
| [xC2-xDF][x80-xBF] # non-overlong 2-byte
| xE0[xA0-xBF][x80-xBF] # excluding overlongs
| [xE1-xECxEExEF][x80-xBF]{2} # straight 3-byte
| xED[x80-x9F][x80-xBF] # excluding surrogates
| xF0[x90-xBF][x80-xBF]{2} # planes 1-3
| [xF1-xF3][x80-xBF]{3} # planes 4-15
| xF4[x80-x8F][x80-xBF]{2} # plane 16
)*$%xs', $string);
}

Et voilà encore du boulot qui aurait pu être évité si les fournisseurs extérieurs développaient correctement leur business…

Internet Explorer refuse d’ouvrir un pdf généré par fpdf en https ?

hop hop, voici la solution magique:

header(’Cache-Control: maxage=3600?);
header(’Pragma: public’);


Pourquoi ? Voici un exemple avec ZendFramework trouvé ici :

Paul M. Jones spotted something interesting a couple of weeks ago: « The difference between the 1.0 release and the 1.5 release of the Zend Framework is quite dramatic: a 25% drop in responsiveness. And then another 10% drop between 1.5 and 1.6″. According to Paul, the Zend Framework lost 35% of their requests per second between 1.0 and 1.6 releases. This means that a Web server will serve 65 instead of 100 requests per second.

L’avantage des frameworks est cependant non négligeable : gagner du temps sur certains développements ou obliger plusieurs collaborateurs à utiliser une base et des conventions communes.

Cependant, j’estime qu’un framework, c’est comme un Mac: c’est très très bien, mais ça ne sert pas à tout le monde.

Pour ma part, pour les projets que je gère (qu’ils soient personnels ou pour mes clients), je ne pense pas qu’utiliser une framework soit essentiel. J’y vois les freins suivants:

- temps d’apprentissage pour exploiter pleinement toutes les possibilités de l’outil
- possibilités de l’outil justement souvent inexploitées (vous sortez souvent un bazooka pour tuer une mouche vous ??)
- sécurité et performances pas toujours au rendez-vous, de plus, les failles de sécurité étant publiques avec des outils open-source, cela oblige à faire des mises à jours (plus ou moins fréquentes) et donc vendre un contrat de support que les clients ne veulent pas toujours … 

Bref, pour moi, beaucoup de désavantages qui ne suffisent pas à compenser les avantages.

Je reverrai ma position quand j’aurai le temps de vraiment essayer ce genre d’outil…

Exporter dans un CSV des données venant d’une base Mysql en UTF8 (avec des accents un peu partout) avec un script lui même encodé en UTF8.

Et bien vous pouvez me croire et demander confirmation à Ludo, c’est pas si simple, à tel point que la solution est perdue dans un message du site www.php.net sur la page de l’extension mbstring: utiliser le charset UTF-16LE

Pour faire court, voici un exemple de code PHP qui fonctionne:


header("Content-type: application/vnd.ms-excel; charset=UTF-16LE");
header("Content-disposition: attachment; filename=candidats-" .date("Y-m-d").".csv");
$out = fopen('temp.csv', 'w');
$line = array('nom', 'prénom', 'âge', 'matricule');
fputcsv($out, $line);
fclose($out);
$ret = file_get_contents('temp.csv');
echo chr(255).chr(254).mb_convert_encoding( $ret, 'UTF-16LE', 'UTF-8');