Il y bien bien longtemps (8-9 ans), j'écrivais un tuto sur les tableaux en php(3)... que d'eau passées sous les ponts depuis, avec surtout la révolutionnaire arrivée des itérateurs.
Pourquoi je parle de ceci ?
Une question au boulot hier : j'ai une liste et un tableau. Je veux récuperer les valeurs du tableau en question pour lesquelles les clés sont dans la liste.
Et ce sans faire de boucle en php.
Première réponse qui me vient à l'esprit : filterIterator ou array_ intersect_???
Ca c'était pour la petite histoire et pour un post ulterieur, mais là je vais d'abord passer en revue la famille des array_intersect_*
Fonction | PHP 4 | PHP 5 - - - - - - - - - - - - - | - - - - - | - - - - - array_intersect | >= 4.0.1 | oui array_intersect_assoc | >= 4.3.0 | oui array_intersect_key | non | >= 5.1.0 array_intersect_uassoc | | oui array_intersect_ukey | non | >= 5.1.0 array_uintersect_assoc | non | oui array_uintersect_uassoc | non | oui
retourne un tableau contenant toutes les valeurs qui sont présentes dans tous les autres arguments array2 , ...
retourne un tableau contenant toutes les valeurs qui sont aussi présentes dans tous les autres arguments array2 , ... Notez que les clés sont utilisées durant la comparaison, contrairement à array_intersect().
array_intersect_key() retourne un tableau contenant toutes les valeurs du tableau array1 qui contiennent des clés présentes dans tous les arguments.
retourne un tableau contenant toutes les valeurs du tableau array1 qui sont présentes dans tous les arguments. Notez que les clés sont utilisées dans la comparaison par opposition à la fonction array_intersect().
La comparaison d'index est effectuée en utilisant la fonction de rappel fournie. Elle doit retourner un entier, plus petit que, égal à ou plus grand que zéro si le premier argument est considéré comme étant, respectivement, plus petit que, égal à ou plus grand le second.
retourne un tableau contenant toutes les valeurs du tableau array1 qui contiennent des clés présentes dans tous les arguments array2 , ... Cette comparaison est effectuée en utilisant une fonction de rappel fournie par l'utilisateur. La fonction de rappel doit retourner un entier plus petit que, égal à ou plus grand que 0 si la première clé est considérée, respectivement, comme plus petite que, égale à ou plus grande que la seconde.
<?php
highlight_file(__FILE__);
echo '<hr/><pre>';
$array1 = array("a" => "green", "x"=>"red", "blue", "yellow", "v"=>"brown", "t"=>"purple", "orange");
$array2 = array("b" => "green", "c"=>"yellow", "red", "X"=>"BLUE", "z"=>"a", "gray","v"=>"brown", "T"=>"purple");
print_r($array1);
print_r($array2);
echo '-----' . "\n";
echo 'array_intersect' . "\n";
print_r(array_intersect($array1, $array2));
// quelles valeurs (et leurs clé dans array1) sont dans les 2 tableaux ?
echo '-----' . "\n";
echo 'array_intersect_assoc' . "\n";
print_r(array_intersect_assoc($array1, $array2));
// quels couples clé-valeurs sont dans les 2 tableaux ?
echo '-----' . "\n";
echo 'array_intersect_key' . "\n";
print_r(array_intersect_key($array1, $array2));
// quelles clés (et leurs valeurs dans array1)
// notez que bleu qui avait automatiquement reçu la clé 0
// et yellow la clé 1 sont repris car red avait cette clé 0 et gray la 1 dans array2,
// par contre orange n'est pas repris
echo '-----' . "\n";
echo 'array_uintersect' . "\n";
$array2['T']='purple';
print_r(array_uintersect($array1, $array2, "strcasecmp"));
// ici on va donc comparer les valeurs de array 1 et 2
// si strcasecmp retourne vrai on reprend la valeur et sa clé dans array 1
echo '-----' . "\n";
echo 'array_intersect_uassoc' . "\n";
print_r(array_intersect_uassoc($array1, $array2, "strcasecmp"));
// C'est comme array_intersect_assoc
// mais on donne la fonction qui décide si les clés et les valeurs sont "les mêmes"
// ici strcasecmp rends la comparaison insensible à la casse, du coup t = T et purple s'ajoute au brown
echo '-----' . "\n";
echo 'array_intersect_ukey' . "\n";
$array2['T']='gold';
print_r(array_intersect_ukey($array1, $array2, 'strcasecmp'));
echo ' - - - - -' . "\n";
$array1['T']='black';
print_r(array_intersect_ukey($array1, $array2, 'strcasecmp'));
echo ' - - - - -' . "\n";
print_r(array_intersect_ukey($array1, $array2, 'key_compare_func'));
// C'est comme array_intersect_key
// on ne regarde que les clés mais on donne la fonction qui traite la comparaison
// ici strcasecmp rends la comparaison insensible à la casse,
// du cup t =T et purple s'ajoute au brown alors que la valeur associée au t avait été changée.
// Notez que si on ajoute à array1 une valeur pour T (alors que t existe toujours, c'est purple qui sera retourné et non black
// pour le troisieme exemple on prend une fonction maison qui compare
echo '-----' . "\n";
$array1['t']='PuRple';
$array2['T']='purple';
$array1['x']='silver';
$array2['x']='SilVer';
$array1['y']='yyyy';
$array2['Y']='YYYY';
$array1['G']='G';
$array2['g']='g';
$array1['h']='h';
$array2['h']='h';
$array1['J']='J';
$array2['J']='J';
echo 'array_uintersect_assoc' . "\n";
// La doc n'est pas claire car les 2 fonctions on la même description
print_r(array_uintersect_assoc($array1, $array2, "strcasecmp")); //Calcule l'intersection de deux tableaux avec des tests sur les index, compare les index en utilisant une fonction de rappel
print_r(array_intersect_uassoc($array1, $array2, "strcasecmp")); //Calcule l'intersection de deux tableaux avec des tests sur les index, compare les index en utilisant une fonction de rappel
// et pourtant les résultats differrent.puis que la première accepte x=>silver
// je ne suis pas sur de moi mais je dirait que pour la première strcasecmp s'applique au clé et au valeurs contrairement à ce que dit la doc.
echo '-----' . "\n";
echo 'array_uintersect_uassoc' . "\n";
print_r(array_uintersect_uassoc($array1, $array2, "strcasecmp", "strcasecmp"));
// Dans ce cas on peut choisir une fonction utilisateur pour les clés et une pour les valeurs
function key_compare_func($key1, $key2)
{
if ($key1 == $key2)
return 0;
else if ($key1 > $key2)
return 1;
else
return -1;
}
?>
Array
(
[a] => green
[x] => red
[0] => blue
[1] => yellow
[v] => brown
[t] => purple
[2] => orange
)
Array
(
[b] => green
[c] => yellow
[0] => red
[X] => BLUE
[z] => a
[1] => gray
[v] => brown
[T] => purple
)
-----
array_intersect
Array
(
[a] => green
[x] => red
[1] => yellow
[v] => brown
[t] => purple
)
-----
array_intersect_assoc
Array
(
[v] => brown
)
-----
array_intersect_key
Array
(
[0] => blue
[1] => yellow
[v] => brown
)
-----
array_uintersect
Array
(
[a] => green
[x] => red
[0] => blue
[1] => yellow
[v] => brown
[t] => purple
)
-----
array_intersect_uassoc
Array
(
[v] => brown
[t] => purple
)
-----
array_intersect_ukey
Array
(
[x] => red
[0] => blue
[1] => yellow
[v] => brown
[t] => purple
)
- - - - -
Array
(
[x] => red
[0] => blue
[1] => yellow
[v] => brown
[t] => purple
)
- - - - -
Array
(
[a] => green
[0] => blue
[1] => yellow
[v] => brown
)
-----
array_uintersect_assoc
Array
(
[x] => silver
[v] => brown
[h] => h
[J] => J
)
Array
(
[v] => brown
[h] => h
[J] => J
)
-----
array_uintersect_uassoc
Array
(
[v] => brown
[t] => PuRple
[y] => yyyy
[G] => G
[h] => h
[J] => J
)
Un collègue de bureau vient de réinstaller sa machine (wamp dernière version avec PHP 5.3.0) et récupère notre projet actuel (symfony 1.2.8 et propel).
Sur la page d’accueil du site, une jolie erreur fatale, précédée d’un warning :
Warning: require_once(propel/Propel.php) [function.require-once]: failed to open stream: No such file or directory in C:\wamp\www\projet_symfony\lib\symfony\plugins\sfPropelPlugin\lib\addon\sfPropelAutoload.php on line 22
Fatal error: require_once() [function.require]: Failed opening required ‘propel/Propel.php’ (include_path=’.;C:\wamp\bin\php\php5.3.0\PEAR’) in C:\wamp\www\projet_symfony\lib\symfony\plugins\sfPropelPlugin\lib\addon\sfPropelAutoload.php on line 22
Petite recherche sur Google, pas grand chose comme résultat.
On regarde du côté de la configuration de propel (databases.yml, propel.ini), du côté des modules apache et autres extensions PHP, au cas où. Toujours rien.
Et la solution se trouve en fait du côté de la conf d’apache. Il faut se rendre dans le répertoire conf/extra de votre apache (soit bin\apache\apache2.2.11\conf\extra pour la dernière version de wamp) et éditer le ficher httpd-vhosts.conf.
Vous aviez surement mis
php_admin_value include_path « .;C:\wamp\bin\php\php5.3.0\PEAR »
alors qu’il faut mettre
php_value include_path « .;C:\wamp\bin\php\php5.3.0\PEAR »
La doc de PHP (autrement appelée « site perso de tight »
si jamais tu passes par ici!) est bien claire avec php_admin_value :
Any directive type set with php_admin_value can not be overridden by .htaccess or ini_set().
Comme ça, vous savez maintenant!
Un grave problème de sécurité vient de nous être signalé ; ce problème affecte toutes les versions de SPIP 2.0.x jusqu'à SPIP 2.0.8, ainsi que la branche 1.9. Il permet à un attaquant ne disposant d'aucun mot de passe de prendre le contrôle de votre site SPIP et de votre serveur web.
L'alerte est d'autant plus sérieuse que le "trou" n'a pas cette fois été découvert par un "gentil", mais par un véritable "méchant" qui a pris le contrôle d'un site existant pour y insérer des malwares.
L'attaque a été détectée et analysée par Thomas Sutton et Pierre Rousset.
(L'équipe SPIP rappelle que le meilleur moyen pour leur signaler un problème de sécurité est d'envoyer un mail à la liste spip-team@rezo.net)
L'équipe SPIP à donc aujourd'hui deux versions de maintenance de SPIP, qui corrigent ce bug :
à télécharger sur :
=> http://files.spip.org/spip/stable/
(ou, si vous utilisez spip_loader, en vous rendant à l'adresse http://xxx.example.tld/spip_loader.php)
Pour les spécialistes, le patch de sécurité stricto sensu pour la branche 2.0.x, qui ne corrige aucun autre bug et n'apporte aucune autre fonctionnalité, peut se trouver ici : http://fil.rezo.net/secu-14346-14350+14354.patch (Il s'agit des révisions [14347] [14348] [14349] [14350] et [14354]). Pour la branche 1.9.2x le patch est ici : http://trac.rezo.net/trac/spip/changeset/14354/branches/spip-1.9.2
Si vous n'avez pas la possibilité de procéder à la mise à jour complète tout de suite, l'équipe SPIP vous invite à colmater sans attendre le problème en installant sur votre site l'« écran de sécurité », que vous pouvez découvrir à l'adresse : http://www.spip.net/fr_article4200.html. Cet écran permet de bloquer une éventuelle attaque sans pour autant devoir mettre à jour les fichiers de SPIP.
PHPBenelux meeting Houthalen (B) August 26 2009
PHPBenelux propose une nouvelle réunion prévue le 26 août 2009.
Cette fois, c'est dans l'Est de la Belgique, à Houthalen.
Au programme
Nouvelle version de l'application wampMSS disponible à cette adresse : http://www.uni-d.net
La nouvelle version de wampMSS est disponible en version 1.2.0-b1.
Pour rappel, ce programme basé sur WAMP permet de faire fonctionner APACHE, PHP et MYSQL sur un disque amovible de type clef USB.
Cette nouvelle version contient:
- Apache 2.2.11
- PHP 5.3.0
- MySQL 5.1.36
- PhPMyAdmin 3.2.0.1
- Moteur de configuration 1.4.0
- Un outil d'aide à la création d'alias
Pour plus d'informations rendez-vous sur le site de wampMSS http://www.uni-d.net
Proposé par UNi
Le succès du PHP est entre autres choses dû, comme nous l'explique le blog PHPDev, à une évolution constante et à ses nombreux paquets. Biensûr, l'avenir n'est jamais défini, mais il faudra compter en tout cas sur la présence du langage PHP.
Vous connaissez peut-être FireGestures, l’extension Firefox qui vous permet d’exécuter des commandes avec les mouvements de votre souris?
Et bien, voici l’équivalent pour Eclipse : egest.
Ayant pris l’habitude de faire des mouvements de souris pour descendre en bas de la page (stop la molette!), je me suis surpris à le tenter sous Eclipse devant une page de code un peu trop longue… En vain!
Sachez le, Eclipse n’intègre pas nativement l’extension FireGestures de Firefox
.
Je me suis donc mis à la recherche d’un éventuel plugin, que j’ai trouvé assez rapidement. Il s’agit donc de egest.
Une fois installé, il faut bien entendu le configurer (ouvez la vue « Mouse Gestures » dans « Window », « Show view », « other… »).
Dans la liste des commandes ( »Avalaible commands »), choisissez l’action que vous souhaitez exécuter avec votre souris.
Par exemple, sur mon poste, j’ai activé les actions suivantes :
Vous devez choisir maintenant le mouvement que vous exécuterez avec la souris, dans la partie « Available keys ». Vous devez choisir un point cardinal. Par exemple, si vous voulez que le mouvement de la souris soit « bas » et « droite », choisissez « ES » (pour sud est).
Cliquez enfin sur le petit plus en vert pour prendre en compte l’action.
Le plugin propose pas mal de paramètres (gestion des priorités, conditions, …) mais je n’utilise que le minimum, n’ayant pas le temps (ni le besoin pour l’instant) d’aller plus loin.
Les mouvements que j’ai paramétrés ne fonctionnent pas. C’est normal, doc’?
Pensez à l’activer dans la barre d’outils, sur l’icone avec deux flèches (un peu à la manière de la touche tabulation). Tout de suite, ça marche un peu mieux.
C’est terminé pour la petite astuce du vendredi!
Bon weekend!
Découvert il y a peu, Mehdi's Phpbb THREE bridge vient compléter la liste des extensions bien utiles pour Joomla! 1.5.
En effet, un bridge entre Joomla! et phpBB3 manquait à la bibliothèque des extensions Joomla : c'est maintenant chose faite avec ce bridge qui vous permet une intégration du visuel et de la gestion des utilisateurs de phpBB3 dans Joomla! (vous pouvez choisir le type d'intégration qui vous intéresse dans le fichier de configuration livré avec le composant lors de l'installation).
La procédure d'installation de ce composant est à suivre à la lettre si vous ne voulez pas avoir de soucis, elle est consultable à cette adresse.
Pour les non-anglophones, vous pouvez suivre ces instructions simplifiées :
On regrettera peut-être l'installation et le paramétrage qui aurait pu se faire de façon simplifiée via l'administration de Joomla!, permettant aux plus néophytes de pouvoir effectuer la procédure d'installation de façon guidée. Cependant, ce composant remplis parfaitement la tâche pour laquelle il a été développé : pouvoir intégrer un forum phpBB3 à un site Joomla! 1.5 (et il le fait très bien).
Le composant est téléchargeable à la même adresse que la procédure d'installation, ici : http://www.mehdiplugins.com/misc/phpbbjoom.htm
J'ai découvert il n'y a pas très longtemps la fonction eZContentFunctions::createAndPublishObject() de l'API eZ Publish. Cette fonction bien cachée (et enfin documentée depuis la résolution de ce bug) permet de créer facilement des objets de contenus. Quand je pense que tout le travail est mâché par cette fonction, ça en fait des lignes de codes inutiles... Par exemple, pour créer un objet de la classe de contenu File, ces quelques lignes suffisent :
<?php $params = array(); $params['parent_node_id'] = 52; // node id of /Media/Files $params['class_identifier'] = 'file'; $params['creator_id'] = 14; // admin $params['storage_dir'] = '/tmp/data/'; // don't forget the ended / $params['section_id'] = 3; // section media $attributesData = array(); $attributesData['name'] = 'My file'; $attributesData['file'] = 'my_file.txt'; $params['attributes'] = $attributesData; $contentObject = eZContentFunctions::createAndPublishObject( $params ); ?>
Chaque élément du tableau $attributesData contient les valeurs des attributs du futur objet de contenu sous le format attendu par la méthode fromString() de chaque datatype. Et voila, ce n'est pas plus compliqué que ça ! Dommage qu'il n'existe pas encore l'équivalent pour mettre à jour les objets de contenu existants.
EasyPHP va sur ses 10 ans mais est toujours actif. Trois nouvelles versions viennent d'être lancées.
Comme toujours, EasyPHP peut s'installer n'importe où : disque dur, clé USB ...
Avec ces nouvelles versions, les fonctionnalités précédentes restent (comme la gestions des alias) et d'autres apparaissent : possibilité de modifier directement via l'interface d'administration le répertoire DocRoot d'Apache et de déclarer le TimeZone pour PHP.
EasyPHP est maintenant traduit en 7 langues (et d'autres vont venir).
Website : http://www.easyphp.org
Facebook page : http://www.facebook.com/pages/EasyPHP/100608599258
Twitter : http://www.twitter.com/easyphp
Sourceforge : http://www.sourceforge.net/projects/quickeasyphp/
Les trois nouvelles versions (dorenavant le numero de version d'EasyPHP suivra le numero de version de PHP qu'il contient) :
** EasyPHP 5.2.10 **
- PHP 5.2.10
- Apache 2.2.13
- MySQL 5.1.37
- PhpMyAdmin 3.2.1
- SQLite 2.8.17
- Pecl 5.2.6
** EasyPHP 5.3.0 **
- PHP 5.3.0
- Apache 2.2.13
- MySQL 5.1.37
- PhpMyAdmin 3.2.1
** EasyPHP 6.0dev **
- PHP 6.0dev [090817]
- Apache 2.2.13
- MySQL 5.1.37
- PhpMyAdmin 3.2.1
Proposé par Laurent Abbal
J'ai mis en place un serveur de développement avec un script qui checkout le code.
Pour ce faire j'avais fait un script shell qui fait tout mes checkout générait quelques infos de logs.
Ce script appelé régulièrement par cron devait garder mon serveur de test synchrone.
quand j'appelais ce script en direct tout fonctionnait correctement, mais le cron lui ne mettait jamais à jour.
Je me suis alors décidé de regarder les mails envoyés par cron et j'y ai vu ceci
svn: Can't convert string from 'UTF-8' to native encoding
Une recherche sur le web m'a permi de trouver cet article et la lumière fut.
Ce qui se passe c'est que sur le svn il y avait dans un sous-répertoire des noms de fichier contenant des caractères utf8 !!!.
un set en console m'indiquait LC_CTYPE=en_US.UTF-8
mais pas en cron.
Dans mon script appelé par le cron, J'ai juste ajouté
export LC_CTYPE=en_US.UTF-8
à mon script et tout à fonctionné correctement
Via High Scalability, j'ai découvert cette présentation intitulée Real World Web: Performance & Scalability donnée lors de la MySQL conference 2008 par Ask Bjørn Hansen. Cette longue présentation (189 pages !) est une excellente compilation de la plupart des conseils que l'on peut trouver un peu partout pour améliorer les performances et l'extensibilité (au niveau de l'architecture) d'une application web par exemple à base de MySQL et du langage de votre choix (PHP, Perl, Ruby, ...)
On peut y trouver également quelques petites phrases assez amusantes du type (traduction libre) :
N'hésitez pas à dé-normaliser les données; [...] appelez cela des summary tables, votre DBA n'y prêtera même pas attention.
où encore une jolie manière d'expliquer les concepts de MVC et d'API
- Model : parle le SQL
- View : parle le HTML
- Controller : parle le HTTP
- API : fait des trucs
Bref, ce document mérite de s'y attarder quelques minutes :
Grâce à la recherche de « tips » pour Eclipse de Pascal Martin, j’ai découvert une astuce qui fera gagner du temps à tout le monde.
Terminés les Ctrl + x / Ctrl + v pour déplacer une ou plusieurs lignes de code.
C’est Janusz qui donne le truc : sélectionnez votre code à déplacer (jusque là, rien ne change) et faites Alt + flèche du haut ou flèche du bas pour déplacer votre code où bon vous semble.
Merci Janusz pour l’astuce et Pascal pour la recherche de tips
!
I answered this question today on IRC and a colleague asked me the same thing about two weeks ago... it's time to write down the solution :-)
Basically, you just need to tell what design keys you want to use and their value to the template engine of eZ Publish. The design keys are the parameters you will be able to use in an override condition. Let's take an example with a simplistic PHP view (it lacks a lots of checkings) :
<?php require_once 'kernel/common/template.php'; $NodeID = intval( $Params['NodeID'] ); $node = eZContentObjectTreeNode::fetch( $NodeID ); $tpl = templateInit(); $tpl->setVariable( 'node', $node ); // setting up the context to use override conditions $res = eZTemplateDesignResource::instance(); $designKeys = array( array( 'class_identifier', $node->attribute( 'class_identifier' ) ), array( 'parent_node_id', $node->attribute( 'parent_node_id' ) ) ); $res->setKeys( $designKeys ); $tpl->fetch( 'design:mymodule/myview.tpl' ); ?>
In this code, I define two design keys : class_identifier and parent_node_id, so I can write override rules that match on the class identifier or on the parent node id of the node or on both, for example :
[myview_folder] Source=mymodule/myview.tpl MatchFile=myview/folder.tpl Subdir=templates Match[class_identifier]=folder
With this override condition, eZ Publish will use the template located in override/templates/myview/folder.tpl in the design when the node is a folder, otherwise it will use the default one (templates/mymodue/myview.tpl).
Pour la plupart des projets, l’utilisation de echo et de var_dump() suffit pde our debugger vos scripts. Le mode web est en « page à page », il est donc rare d’avoir des scripts de plusieurs milliers de lignes comme on pourrait en avoir avec les langages compilés. Il peut toutefois parfois être intéressant de faire du debuggage pas à pas et de pouvoir jouer avec les valeurs de vos variables. Je me propose donc de vous montrer comment configurer cela avec WampServer, l’extension XDebug et l’IDE PDT (Php Developpment Tool).
INSTALLATION DE XDEBUG AVEC WAMPSERVER
Commençons par installer l’extension XDebug. XDebug permet de faire trois choses :
- améliorer la gestion des erreurs de PHP (afficher plus d’informations lors d’erreurs PHP, optimisation de la présentation de var_dump());
- faire du profiling (à utiliser avec kcachegrind ou wincachegrind);
- debugger vos scripts.
Téléchargez l’extension sur le site de XDebug : http://www.xdebug.org
ATTENTION : pensez bien à télécharger la version qui correspond à la branche de PHP que vous utilisez (PHP 5.2 ou PHP5.3) et à prendre la version thread-safe.
A l’heure où j’écris ces lignes,
pour PHP 5.2 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.2.dll
pour PHP 5.3 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.3-vc6.dll
XDebug n’est pas un extension standard de PHP, nous n’allons donc pas la mettre dans le répertoire /ext/ de PHP afin d’éviter d’éventuels conflits avec le menu de WampServer. Je vous propose donc de la déposer dans le même répertoire que l’exécutable de PHP (php.exe), typiquement :
c:\wamp\bin\php\phpx.x.x\
Renommez l’extension en php_xdebug.dll, elle sera plus facile à manipuler.
Nous allons maintenant l’activer. Pour cela nous allons devoir ajouter des commandes dans le fichier php.ini. Dans WampServer, le fichier php.ini utilisé se trouve dans le même répertoire que le binaire d’Apache (apache.exe). Le plus simple pour l’ouvrir est de passer par le menu de WampServer.

Allez à la fin du fichier et ajoutez les lignes suivantes :
zend_extension_ts="c:/wamp/bin/php/phpx.x.x/php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_host="127.0.0.1"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_mode=req
où x.x.x est votre version de PHP.
En complément, vous pouvez également ajouter
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = "c:/wamp/tmp/"
afin d’activer les fonctions de profiling, ou encore
xdebug.collect_params = On
xdebug.show_local_vars = On
afin d ‘améliorer les informations fournies lors de l’affichage des messages d’erreur.
Une fois ces lignes ajoutées, refermez le fichier php.ini et redémarrez votre service Apache, XDebug devrait maintenant être chargé.
Pour le vérifier, affichez votre phpinfo(). Vous devriez voir apparaître l’information ci-dessous :
Si ce n’est pas le cas, vous avez certainement fait une erreur dans le chemin d’accès au fichier php_xdebug.dll
A ce stade, vous pouvez dors et déjà profiter des fonctions d’amélioration des messages d’erreur de XDebug. Pour cela, essayez d’afficher un message d’erreur et un var_dump().
CONFIGURATION DE PDT AVEC XDEBUG
Nous allons maintenant configurer PDT pour qu’il utilise les fonctionnalités de debuggeur de XDebug.
Si ce n’est pas déjà fait, commencez par télécharger et installer PDT : http://www.eclipse.org/pdt/
Lors du lancement de PDT, choisissez « c:\wamp\www » comme WorkSpace.
Dans le menu du haut, choisissez window -> preferences.
Rentrez maintenant dans le menu « PHP » et cliquez sur « debug ».
Il existe deux façons de debugger du PHP avec PDT. La première (server) passe par votre serveur web en faisant un appel à localhost. La deuxième (PHP executable) fait un appel direct à l’exécutable de PHP.
Nous allons travailler avec la première solution qui nous offre plus de fonctionnalités et permet, notamment, d’utiliser les méthodes GET et POST.
Par défaut, PDT est livré avec des configurations type pour fonctionner avec XDebug et Zend Debugger. Comme le montre la capture d’écran ci-dessus, choisissez XDebug.
Si votre serveur n’est pas local (localhost), il faudra également modifier la configuration de votre serveur identifié sous PDT par « Default PHP Web Server« .
Voilà, la configuration de base de PDT est terminée, nous allons maintenant pouvoir utiliser PDT pour debugger en mode pas à pas et avec des points d’arrêt.
UTILISATION DE PDT COMME DEBUGGEUR
Voyons maintenant comment utiliser tout cela. La première chose à faire est de créer un nouveau projet PHP au sein de PDT. Pour cela cliquez sur file -> new -> PHP Project.
Donnez un nom à votre projet (dans la suite de cet article, notre projet s’appellera « test_debug »).
Un répertoire du même nom va être automatiquement créé dans votre répertoire « www ». Vous allez placer ou créer vos scripts PHP dans ce répertoire. Si nécessaire, appuyez sur F5 dans PDT pour que vos scripts apparaissent.
Ouvrez votre script PHP en double cliquant dessus. Votre code source devrait apparaître dans la fenêtre centrale de PDT.
Nous allons maintenant passer en mode debuggage. Cliquez sur l’icône en forme d’insecte sur la barre d’outil et choisissez Debug As -> PHP Web Page.
Cela devrait ouvrir une fenêtre de votre navigateur par défaut (Firefox par exemple) et vous faire basculer sur une perspective de debuggage dans PDT (vous pouvez retrouver les perspectives en haut à droite de PDT).
Cette perspective est découpée en 5 fenêtres :
- en haut à gauche, une fenêtre de « debug » qui vous donne des informations sur le debuggage en cours et dispose de la barre d’outils de debuggage.
- à droite de cette fenêtre, une autre qui vous donne accès aux variables de votre script et aux points d’arrêt définis.
- en dessous, une fenêtre qui présente votre code, vous montre la ligne courante et permet de définir/annuler des points d’arrêt
- encore en dessous, la fenêtre de console.
- et enfin, à droite, la fenêtre d’Output.
Pour debugger, utilisez la barre d’outils de la fenêtre « debug ».
Vous pouvez également ajouter des points d’arrêt dans votre code. Pour cela double-cliquez sur la barre grise se trouvant à gauche de votre code (idem pour retirer les points d’arrêt). Des petites boules vont apparaitre pour signaler ces points d’arrêt.
Au fur et à mesure que vous allez avancer dans le debuggage de votre page, vous pourrez voir le résultat s’afficher directement dans votre navigateur.
MODIFIER LES VARIABLES EN COURS DE DEBUGGAGE
Il va souvent être utile de modifier le contenu de vos variables en cours de debuggage. Pour cela sélectionnez la variable souhaitée dans la fenêtre d’affichage des variables et modifiez simplement sa valeur.
TRAVAILLER AVEC GET ET POST
En utilisant PDT avec XDebug, j’ai rapidement eu besoin de jouer avec les tableaux $_GET et $_POST. Malheureusement, je n’ai rien trouvé à ce sujet dans la doc ou dans Google. J’ai toutefois persisté et ai trouvé une astuce pour pouvoir m’en servir.
Commençons par $_GET. Pour le remplir, faites tourner le débuggeur sur votre script et allez jusqu’au bout de votre script. Allez ensuite dans la fenêtre de navigateur ouverte par le debuggeur. Vous devriez vous retrouver avec une barre d’URL de ce type :
Ajouter les variables que vous souhaitez dans cette url et relancez la page. Retournez maintenant dans PDT, et, magique…la session de debuggage est relancée et les variables sont maintenant disponibles sous $_GET.
Pour $_POST, lancez un debuggage sur le formulaire permettant de faire votre POST et allez au bout du script. Allez dans la fenêtre de navigateur, votre formulaire sera affiché. Remplissez le et validez le. Retournez dans PDT, vous devriez maintenant avoir une session de debuggage sur le script de réception du formulaire.
Il existe certainement d’autres méthodes plus simples pour utiliser nativement $_GET et $_POST avec PDT et XDebug, si vous les connaissez, n’hésitez pas à ajouter votre commentaire à cet article.
De mon côté, j’ai trouvé une autre solution plus efficace et plus pratique pour gérer mes sessions de debuggage, l’utilisation de l’extension XDebug Helper pour Firefox.
UTILISATION DE L’EXTENSION XDEBUG HELPER POUR FIREFOX
L’extension XDebug Helper pour Firefox va vous permettre de lancer vos sessions de debuggage directement depuis Firefox.
Commencez par installer l’extension que vous pourrez trouver ici :
https://addons.mozilla.org/fr/firefox/addon/3960
Cela va ajouter deux icônes en bas à droite de Firefox.
Le premier bouton va vous permettre de lancer des sessions de debuggage. Pour cela, il va falloir configurer PDT pour qu’il accepte le lancement externe de sessions de debuggage. Retourner donc dans la configuration de PDT :
Window -> preferences
puis PHP -> debug -> Installed Debuggers
Sélectionnez « XDebug » et cliquez sur « configure« .
Dans le menu déroulant « Accept remote session (JIT) » sélectionnez « localhost » (ou « any » si votre serveur est distant).
Vous allez maintenant pouvoir lancer vos sessions directement depuis Firefox.
Pour cela, cliquez sur le bouton de XDebug Helper qui ressemble à une croix dans Firefox (en bas à droite). Celui-ci devrait devenir vert et jaune.
Tapez l’URL du script que vous souhaitez debugger(ex : http://localhost/….) et lancez son execution. Retournez dans PDT, votre session de debugage devrait être lancée.
CONCLUSION
J’espère que ce petit tutoriel vous permettra de développer plus efficacement. A mon avis, tout développeur devrait avoir XDebug installé par défaut. J’ai bien pensé à le fournir directement avec WampServer, mais pour le moment, la structure de WampSever et son mode de fonctionnement « multi-PHP » ne me le permettent pas. Peut être dans une version future…
Pour la plupart des projets, l’utilisation de echo et de var_dump() suffit pde our debugger vos scripts. Le mode web est en « page à page », il est donc rare d’avoir des scripts de plusieurs milliers de lignes comme on pourrait en avoir avec les langages compilés. Il peut toutefois parfois être intéressant de faire du debuggage pas à pas et de pouvoir jouer avec les valeurs de vos variables. Je me propose donc de vous montrer comment configurer cela avec WampServer, l’extension XDebug et l’IDE PDT (Php Developpment Tool).
INSTALLATION DE XDEBUG AVEC WAMPSERVER
Commençons par installer l’extension XDebug. XDebug permet de faire trois choses :
- améliorer la gestion des erreurs de PHP (afficher plus d’informations lors d’erreurs PHP, optimisation de la présentation de var_dump());
- faire du profiling (à utiliser avec kcachegrind ou wincachegrind);
- debugger vos scripts.
Téléchargez l’extension sur le site de XDebug : http://www.xdebug.org
ATTENTION : pensez bien à télécharger la version qui correspond à la branche de PHP que vous utilisez (PHP 5.2 ou PHP5.3) et à prendre la version thread-safe.
A l’heure où j’écris ces lignes,
pour PHP 5.2 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.2.dll
pour PHP 5.3 : http://www.xdebug.org/files/php_xdebug-2.0.5-5.3-vc6.dll
XDebug n’est pas un extension standard de PHP, nous n’allons donc pas la mettre dans le répertoire /ext/ de PHP afin d’éviter d’éventuels conflits avec le menu de WampServer. Je vous propose donc de la déposer dans le même répertoire que l’exécutable de PHP (php.exe), typiquement :
c:\wamp\bin\php\phpx.x.x\
Renommez l’extension en php_xdebug.dll, elle sera plus facile à manipuler.
Nous allons maintenant l’activer. Pour cela nous allons devoir ajouter des commandes dans le fichier php.ini. Dans WampServer, le fichier php.ini utilisé se trouve dans le même répertoire que le binaire d’Apache (apache.exe). Le plus simple pour l’ouvrir est de passer par le menu de WampServer.

Allez à la fin du fichier et ajoutez les lignes suivantes :
zend_extension_ts="c:/wamp/bin/php/phpx.x.x/php_xdebug.dll"
xdebug.remote_enable=1
xdebug.remote_host="127.0.0.1"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.remote_mode=req
où x.x.x est votre version de PHP.
En complément, vous pouvez également ajouter
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = "c:/wamp/tmp/"
afin d’activer les fonctions de profiling, ou encore
xdebug.collect_params = On
xdebug.show_local_vars = On
afin d ‘améliorer les informations fournies lors de l’affichage des messages d’erreur.
Une fois ces lignes ajoutées, refermez le fichier php.ini et redémarrez votre service Apache, XDebug devrait maintenant être chargé.
Pour le vérifier, affichez votre phpinfo(). Vous devriez voir apparaître l’information ci-dessous :
Si ce n’est pas le cas, vous avez certainement fait une erreur dans le chemin d’accès au fichier php_xdebug.dll
A ce stade, vous pouvez dors et déjà profiter des fonctions d’amélioration des messages d’erreur de XDebug. Pour cela, essayez d’afficher un message d’erreur et un var_dump().
CONFIGURATION DE PDT AVEC XDEBUG
Nous allons maintenant configurer PDT pour qu’il utilise les fonctionnalités de debuggeur de XDebug.
Si ce n’est pas déjà fait, commencez par télécharger et installer PDT : http://www.eclipse.org/pdt/
Lors du lancement de PDT, choisissez « c:\wamp\www » comme WorkSpace.
Dans le menu du haut, choisissez window -> preferences.
Rentrez maintenant dans le menu « PHP » et cliquez sur « debug ».
Il existe deux façons de debugger du PHP avec PDT. La première (server) passe par votre serveur web en faisant un appel à localhost. La deuxième (PHP executable) fait un appel direct à l’exécutable de PHP.
Nous allons travailler avec la première solution qui nous offre plus de fonctionnalités et permet, notamment, d’utiliser les méthodes GET et POST.
Par défaut, PDT est livré avec des configurations type pour fonctionner avec XDebug et Zend Debugger. Comme le montre la capture d’écran ci-dessus, choisissez XDebug.
Si votre serveur n’est pas local (localhost), il faudra également modifier la configuration de votre serveur identifié sous PDT par « Default PHP Web Server« .
Voilà, la configuration de base de PDT est terminée, nous allons maintenant pouvoir utiliser PDT pour debugger en mode pas à pas et avec des points d’arrêt.
UTILISATION DE PDT COMME DEBUGGEUR
Voyons maintenant comment utiliser tout cela. La première chose à faire est de créer un nouveau projet PHP au sein de PDT. Pour cela cliquez sur file -> new -> PHP Project.
Donnez un nom à votre projet (dans la suite de cet article, notre projet s’appellera « test_debug »).
Un répertoire du même nom va être automatiquement créé dans votre répertoire « www ». Vous allez placer ou créer vos scripts PHP dans ce répertoire. Si nécessaire, appuyez sur F5 dans PDT pour que vos scripts apparaissent.
Ouvrez votre script PHP en double cliquant dessus. Votre code source devrait apparaître dans la fenêtre centrale de PDT.
Nous allons maintenant passer en mode debuggage. Cliquez sur l’icône en forme d’insecte sur la barre d’outil et choisissez Debug As -> PHP Web Page.
Cela devrait ouvrir une fenêtre de votre navigateur par défaut (Firefox par exemple) et vous faire basculer sur une perspective de debuggage dans PDT (vous pouvez retrouver les perspectives en haut à droite de PDT).
Cette perspective est découpée en 5 fenêtres :
- en haut à gauche, une fenêtre de « debug » qui vous donne des informations sur le debuggage en cours et dispose de la barre d’outils de debuggage.
- à droite de cette fenêtre, une autre qui vous donne accès aux variables de votre script et aux points d’arrêt définis.
- en dessous, une fenêtre qui présente votre code, vous montre la ligne courante et permet de définir/annuler des points d’arrêt
- encore en dessous, la fenêtre de console.
- et enfin, à droite, la fenêtre d’Output.
Pour debugger, utilisez la barre d’outils de la fenêtre « debug ».
Vous pouvez également ajouter des points d’arrêt dans votre code. Pour cela double-cliquez sur la barre grise se trouvant à gauche de votre code (idem pour retirer les points d’arrêt). Des petites boules vont apparaitre pour signaler ces points d’arrêt.
Au fur et à mesure que vous allez avancer dans le debuggage de votre page, vous pourrez voir le résultat s’afficher directement dans votre navigateur.
MODIFIER LES VARIABLES EN COURS DE DEBUGGAGE
Il va souvent être utile de modifier le contenu de vos variables en cours de debuggage. Pour cela sélectionnez la variable souhaitée dans la fenêtre d’affichage des variables et modifiez simplement sa valeur.
TRAVAILLER AVEC GET ET POST
En utilisant PDT avec XDebug, j’ai rapidement eu besoin de jouer avec les tableaux $_GET et $_POST. Malheureusement, je n’ai rien trouvé à ce sujet dans la doc ou dans Google. J’ai toutefois persisté et ai trouvé une astuce pour pouvoir m’en servir.
Commençons par $_GET. Pour le remplir, faites tourner le débuggeur sur votre script et allez jusqu’au bout de votre script. Allez ensuite dans la fenêtre de navigateur ouverte par le debuggeur. Vous devriez vous retrouver avec une barre d’URL de ce type :
Ajouter les variables que vous souhaitez dans cette url et relancez la page. Retournez maintenant dans PDT, et, magique…la session de debuggage est relancée et les variables sont maintenant disponibles sous $_GET.
Pour $_POST, lancez un debuggage sur le formulaire permettant de faire votre POST et allez au bout du script. Allez dans la fenêtre de navigateur, votre formulaire sera affiché. Remplissez le et validez le. Retournez dans PDT, vous devriez maintenant avoir une session de debuggage sur le script de réception du formulaire.
Il existe certainement d’autres méthodes plus simples pour utiliser nativement $_GET et $_POST avec PDT et XDebug, si vous les connaissez, n’hésitez pas à ajouter votre commentaire à cet article.
De mon côté, j’ai trouvé une autre solution plus efficace et plus pratique pour gérer mes sessions de debuggage, l’utilisation de l’extension XDebug Helper pour Firefox.
UTILISATION DE L’EXTENSION XDEBUG HELPER POUR FIREFOX
L’extension XDebug Helper pour Firefox va vous permettre de lancer vos sessions de debuggage directement depuis Firefox.
Commencez par installer l’extension que vous pourrez trouver ici :
https://addons.mozilla.org/fr/firefox/addon/3960
Cela va ajouter deux icônes en bas à droite de Firefox.
Le premier bouton va vous permettre de lancer des sessions de debuggage. Pour cela, il va falloir configurer PDT pour qu’il accepte le lancement externe de sessions de debuggage. Retourner donc dans la configuration de PDT :
Window -> preferences
puis PHP -> debug -> Installed Debuggers
Sélectionnez « XDebug » et cliquez sur « configure« .
Dans le menu déroulant « Accept remote session (JIT) » sélectionnez « localhost » (ou « any » si votre serveur est distant).
Vous allez maintenant pouvoir lancer vos sessions directement depuis Firefox.
Pour cela, cliquez sur le bouton de XDebug Helper qui ressemble à une croix dans Firefox (en bas à droite). Celui-ci devrait devenir vert et jaune.
Tapez l’URL du script que vous souhaitez debugger(ex : http://localhost/….) et lancez son execution. Retournez dans PDT, votre session de debugage devrait être lancée.
CONCLUSION
J’espère que ce petit tutoriel vous permettra de développer plus efficacement. A mon avis, tout développeur devrait avoir XDebug installé par défaut. J’ai bien pensé à le fournir directement avec WampServer, mais pour le moment, la structure de WampSever et son mode de fonctionnement « multi-PHP » ne me le permettent pas. Peut être dans une version future…
Petite astuce dans Eclipse pour effectuer une recherche en temps réel (comme dans Firefox, ce que vous saisissez est recherché immédiatement).
Dans la fenêtre de recherche (qui s’ouvre avec Ctrl+F), cochez « Incremental« . Plus besoin d’appuyer sur la touche « Entrée » pour valider la recherche.
C’est pas grand chose, mais ça facilite les recherches.
Et puis vous connaissiez peut-être. Mais pour ceux qui ne connaissaient pas, ça peut servir