Attention, ce qui suit ne s'adresse qu'aux développeurs PHP. Qui utilisent les PCRE (Expressions rationnelles compatibles Perl). Qui manipulent de très gros fichiers (par exemple des bons gros fichiers XML à analyser)

Depuis PHP 5.2.0, il existe une nouvelle option de configuration dans le php.ini, concernant les PCRE :

pcre.backtrack_limit

Cette option de configuration, définie par défaut à 100 000, détermine la longueur maximale des chaines à traiter et à retourner par les fonctions PCRE PHP (preg_match, entre autres).

Concrètement, si vous avez un fichier de 50 Mo à analyser en PHP (en CLI hein, pas via Apache, ne soyez tout de même pas trop barbare), et que les blocs que vous cherchez à extraire via une RegExp font plus 100 Ko, cette limitation vous empêchera de les avoir.

Le pire, dans tout ça, c'est qu'aucune alerte ni même notice ne vous est renvoyée. Rien. Que dalle. Nada.

Seul moyen de vérifier ça ? Placer un appel à la fonction preg_last_error() après chaque RegExp. Lourd, et inutile, à mon sens.

Maintenant, je comprends mieux pourquoi mon catalogue produit ne retrournait qu'un seul élement, au lieu des 350 présent réellement dedans.

Maintenant, vous êtes au courant, ça vous évitera de perdre 2 bonnes heures à chercher où ça coince ;) (comment ça, c'est du vécu ?)

Je ne sais pas si vous êtes comme moi, mais j'aime de plus en plus Wordpress (même si je ne pense pas quitter mon Mavblog ici avant un moment). De même, j'aime de plus en plus Safari 4, du moins, la beta, disponible depuis quelques semaines.

Là où ça coince, c'est quand il s'agit d'utiliser les deux en même temps.

Dans l'ensemble, tout roule. Sauf quand il s'agit d'utiliser l'éditeur de texte de Wordpress (TinyMCE, pour ne pas le nommer). En effet, depuis cette beta, plus moyen d'utiliser l'éditeur WYSIWYG pour créer un lien. Un voile noir remplit la page, et impossible de le fermer.

La solution ? Hmmm, utiliser l'éditeur HTML pour créer un lien. Pas terrible, mais ça fonctionne.

Il semblerait que le bug provienne de Safari (heureusement que c'est une beta :) )

Du coup, j'ai une autre solution à vous proposer : télécharger la nightly build de Safari, dans lequel le bug a été résolu.

Tout se passe par là : http://nightly.webkit.org/

Elle est pas belle la vie ? ;)

Il y a des soirs comme ça où l'on a des envies de meurtres.

J'étais déjà énervé à la base. Le stress, la journée, tout. Bref. Peu importe.

Je viens juste de passer 3 HEURES à essayer de débugger une page sous IE

Pour vous remettre dans le contexte : 3 div côte à côté, tous trois en float:left. Dans un navigateur correct, ces trois divs doivent s'aligner les uns à la suite des autres.
Mais pas sous IE6. Pourtant, c'est pas faute d'en avoir manipulé des DIV... Mais là pas moyen.

Je tente de virer tout le reste du code de la page, en ne laissant que la CSS. Même résultat.

Je fais le tour des bugs "reconnus" d'IE6. Non ce n'est pas le coup du texte qui disparait. Là, c'est le DIV complet qui n'apparait pas. Cerise sur le gâteau, en remettant tout le HTML, ce sont les 3 DIV qui disparaissent...

Alors après avoir saccagé mon markup, ruiné ma CSS, j'ai enfin trouvé le coupable.

BODY {
font-family: Arial, Helvetica, serif;
font-size: 11px;
letter-spacing: 1px;
}

Quelque chose vous choque là dedans ? Moi non.

Et pourtant IE, quelque chose le chagrine là dedans, le pauvre biquet.

Sachez donc que cette bouse (désolé, mais là, il ne reste plus vraiment d'autres mots) ne peut pas faire un float correct avec un letter-spacing défini sur le BODY.

J'ai monté une page d'exemple pour l'occasion à cette adresse

Faites moi donc plaisir :

ARRÊTEZ D'UTILISER EXPLORER 6

UPDATE, plus tard

IE 7 ne s'en sort pas non plus...