- Publié le 26 Novembre 2007 à 18:54
Via Planète GNOME-FR, j'ai vu un petit topo très imagé et très drôle des différentes variantes du métal, extrait :
HEAVY METAL Le chevalier arrive sur une Harley Davidson, tue le dragon, boit quelques bières et baise la princesse en rotant.
SPEED METAL Chevalier-tue-dragon-sauve-princesse-la-baise.
HARD ROCK Le chevalier arrive en short avec une casquette. La princesse se casse dégoûtée.
[...]
La suite dans Pour bien comprendre le monde du Heavy Metal.
- Publié le 26 Novembre 2007 à 00:37
About my URL Aliases problem, on #ezpublish@freenode, November 25, 2007 :
21:48 <tigrou> grrrr
21:48 <tigrou> i can't upgrade a 3.9.0 site to 3.10.0
21:49 <tigrou> URL Alias are transformed into numbers :(
21:51 <tigrou> don't understand where is the problem
22:39 <tigrou> ah i am stupid
22:48 <_buz> ez has its way of making you feel like that
22:48 <_buz> in fact, whomever called it ez had a very strange kind of humour
A little bit hard for eZ Publish, but it's just funny :-)
- Publié le 26 Novembre 2007 à 00:20
After the slowness of the PHP upgrade script and the disappearance of the URL Wildcard translation (these problems are corrected in the future 3.10.1 release), eZ Publish 3.10.0 gives me another problem when I try to upgrade a 3.9.0 site. Running the updateniceurls.php PHP script transforms the nice URL aliases into numbers. Another developer seemed to have the same problem in the forum, but no solution was provided...
In fact, for this site I configured one var directory for each siteaccess (I don't know why...), so when I cleared the cache using ezcache.php script only the cache of the default siteaccess was really cleared and obviously I specified the one with a dirty cache to run upgrade scripts ! That's why updateniceurls.php didn't find the URL transformation commands and made strange things...
We can sometimes read " Remember to clear the cache", now I would say " Remember to clear the cache for all siteaccesses" :-)
- Publié le 20 Novembre 2007 à 00:21
Encore une belle Microsofterie qui n'est certes pas toute neuve mais qui commence à avoir des effets (pervers) puisque les concepteurs d'Outlook 2007 se sont dit qu'il serait bien d'utiliser le moteur de Word pour rendre les mails HTML à la place du moteur d'Internet Explorer pour, paraît il, améliorer la sécurité de leur logiciel malgré les tares de ce pauvre traitement de texte dans le domaine du rendu HTML et CSS...
Mais au moins, avant aujourd'hui, j'étais ignorant, je croyais que le navigateur le plus sécurisé produit par Microsoft ces derniers temps était Internet Explorer 7, mais maintenant je sais et vous pouvez tous le répéter autour de vous : " Le navigateur le plus sécurisé produit par Microsoft est ... Word 2007" :-) Y'a du boulot
- Publié le 19 Novembre 2007 à 23:25
Via PHPIndex, j'ai lu aujourd'hui un article très intéressant sur la mise en cache côté serveur et la manipulation du cache côté client en PHP plus une introduction au package PEAR Cache_Lite. Hormis ce dernier chapitre, la majeure partie de l'article est applicable avec d'autres langages pour peu que ceux-ci soient capable d'envoyer des en-têtes HTTP au navigateur via un équivalent de la fonction header.
Mais au détour de cet article, en page 2 pour être exact, l'auteur explique un des bugs d'Internet Explorer intervenant lorsqu'on force le téléchargement d'un fichier via un script côté serveur en employant un code du type suivant (souvent employé lors de la génération de d'exports en tout genre) :
<?php
// différentes opérations
header( 'Content-Disposition: attachment, filename=fichier.ext' );
// ici je génère mon fichier
// ...
?>
L'envoi d'un en-tête de ce type provoque sous IE un comportement complètement aberrant. En fait, ce navigateur (si on peut appeler cela comme ça) fait une première requête pour télécharger le fichier puis en exécute une seconde avant de proposer effectivement à l'utilisateur d'ouvrir le fichier et donc si vous envoyez d'autres en-têtes pour éviter la mise en cache côté client du fichier et bien IE efface le fichier qu'il vient de télécharger lors de la seconde requête HTTP !
La solution est donc d'envoyer des en-têtes HTTP indiquant la mise en cache du fichier généré soit de manière permanente si celui-ci ne change pas (via les en-têtes Pragma et Cache-Control) ou sur une durée plus moins longue (via l'en-tête Last-Modified)... Voila une belle Microsofterie à classer dans un coin de la tête sous peine d'y perdre encore 2 bonnes heures la prochaine fois...
