Catégorie « XML »

Vu qu'on m'a posé certaines questions là dessus cette semaine, ça va faire le sujet de l'article d'aujourd'hui.

Ajouter une seconde zone de widgets

Depuis la version 2 (il me semble) de WordPress, si le thème est bien fait, on peut depuis le panneau d'administration ajouter des widgets dans certaines zones bien définies. Dans le thème par défaut, il y a une zone unique pouvant accueillir des widgets, qui se trouve dans la barre latérale. Mais on peut vouloir en ajouter d'autres.

Pour ajouter une nouvelle zone, il faut effectuer deux modifications dans le code du thème :

1. Premièrement, il faut "enregistrer" une nouvelle zone pour que celle-ci soit disponible dans le menu de sélection des zones. Pour cela il faut en général se rendre dans le fichier functions.php du thème et rechercher où est appelée la fonction register_sidebar (dans le thème par défaut, c'est tout en haut du fichier) et l'appeler une fois de plus pour enregistrer une nouvelle zone.

   Cette fonction peut optionnellement prendre en argument un tableau de paramètres permettant de personnaliser le code HTML qui enrobera la liste de widgets. Dans la plupart des cas on n'en a pas besoin mais au cas où c'est bon de savoir que c'est possible, notamment pour éventuellement spécifier une classe particulière à l'une ou l'autre zone en vu d'appliquer des styles différenciés.

   Une fois cela fait, la nouvelle zone est disponible dans le menu de sélection des zones du panneau d'administration (cf la capture d'écran ci-dessus).

2. Dans un deuxième temps, il faut inclure cette zone dans le rendu de la page à un endroit ou un autre (sinon, forcément, ça sert pas à grand chose). Pour cela il suffit d'intégrer le code suivant dans l'un des fichiers de template : <?php dynamic_sidebar(n); ?> en prenant garde de bien remplacer le paramètre "n" par un entier représentant le numéro de la zone que vous voulez afficher.

   Par exemple, si vous venez d'ajouter une zone et qu'il y en avait une seule avant, la nouvelle aura fort logiquement le numéro 2 et le code à insérer sera le suivant : <?php dynamic_sidebar(2); ?>

N'afficher certaines choses que sur la page d'accueil

Afin de ne pas trop surcharger les pages, on peut ne vouloir afficher certaines informations et liens que sur la page d'accueil. Par exemple sur ce site, les encarts "Mes autres sites", "News du serveur" et "Divers" ne s'affichent que sur la page d'accueil (et les pages de contenu fixe).

Pour restreindre l'affichage d'une portion de code d'un fichier de template, c'est très simple :

<?php if ( [CONDITION] ) { ?>
  [CODE HTML À RESTREINDRE]
<?php } ?>

WordPress propose quelques fonctions PHP qui testent dans quel type de page on se trouve et qui peuvent servir à composer la condition (qui remplacera la portion "[CONDITION]" du code ci-dessus). Ces fonctions sont définies dans le fichier wp-includes/query.php et comprennent notamment :

• is_home() disant si l'on se trouve sur la page d'accueil.
• is_page() disant si l'on se trouve sur une page de contenu fixe.
• is_search() disant si l'on est dans la page de recherche.
• is_404() disant si l'on se trouve sur la page d'erreur 404.
• etc.

Pour composer la condition, il suffit d'appeler une ou plusieurs de ces fonctions séparées par une double barre verticale (||) qui représente un "ou" en PHP.

Par exemple pour ajouter une zone de widgets qui ne sera affichée que sur la page d'accueil et les page de contenu fixe, on utilisera le code suivant :

<?php if ( is_home() || is_page() ) { // Home and pages only. ?>
  <?php dynamic_sidebar(2); // Home and pages sidebar. ?>
<?php } ?>

Et ça marche que pour la barre latérale ?

Bien entendu ces deux "astuces" sont valables aussi bien pour la barre latérale que pour n'importe quelle autre partie de votre site. Mais c'est dans la barre latérale que c'est le plus souvent utilisé.

Quelques petits trucs que je n'ai appris que récemment. Peut-être étais-je le seul à les ignorer... ou peut-être pas, donc dans le doute...

Sortir de plusieurs boucles à la fois

Classiquement l'instruction break; s'utilise telle quelle pour sortir de la boucle ou du switch courant. Cependant en PHP (et sans doutes dans d'autres langages également), on peut lui adjoindre un paramètre entier permettant de sortir de plusieurs boucles à la fois. Ceci est à utiliser avec parcimonie car ce n'est pas forcément des plus lisible mais ça peut aider à accélérer une recherche dans un tableau multi-entrées par exemple :

// Supposons que $array est un tableau à double-entrée contenant des entiers
// et que l'on en cherche un supérieur à 10.
$result = null;
foreach ($array as $subArray)
{
	foreach ($subArrayas $item)
	{
		if ($item > 10)
		{
			$result = $item;
			break 2;
		}
	}
}

Paramètre de la fonction die

C'est plus une instruction qu'une fonction mais bon, passons. Elle peut prendre en argument un entier ou une chaine de caractère mais cet argument n'est affiché à l'écran que s'il s'agit d'une chaine. Ça n'a l'air de rien mais c'est bon à savoir...

DOM ou SimpleXML ?

SimpleXML c'est bien gentil et comme son nom l'indique, c'est « simple » (du moins dans son interface qui compte très peu de méthodes), mais à l'usage c'est quand même des plus limités. Et c'est plutôt chiant à utiliser parce qu'il faut caster pas mal de choses pour obtenir des chaines de caractère au lieux de nœuds XML (sans compter le bug dont je parlais il y a quelques temps). D'autant qu'il existe une alternative...

En effet, j'en étais resté à PHP4 où l'API DOM se cantonnait l'extension DOM XML non-incluse par défaut, ce qui n'était pas bien pratique... Mais en PHP5, elle a été remplacée par une nouvelle implémentation incluse en natif dans PHP sous le nom de DOM. Bref, en ce qui me concerne, SimpleXML va direct à la poubelle et je n'utilise plus que DOM, avec l'avantage supplémentaire d'être similaires aux bibliothèques DOM présentes dans d'autres langages tels que JavaScript, puisque DOM est un standard, ce qui raccourcit d'autant l'apprentissage.

PHPTAL est un moteur de templates spécialisé dans la production de documents XML (et donc (X)HTML puisqu'il s'agit d'un langage XML).

Les templates qu'il utilise sont définis en XML valide, PHPTAL ajoutant ses propres attributs qui sont ensuite traités par le moteur. Le code des templates est donc purement de l'XML et non un code bâtard XML/PHP comme c'est le cas avec certains autres moteurs.

Avantages :

• il n'accepte que du code XML valide, ce qui permet de détecter rapidement toute erreur d'imbrication.
• le code des templates est de l'XML ce qui donne la possibilité de l'exploiter ou de le générer via les bibliothèques de gestion de fichiers XML habituelles.
• il est installable sous forme de package pear ce qui rend son déploiement et sa mise à jour très simples.
• comme il est entièrement XML il est en général plus accessible pour le graphiste qui pourra être chargé de construire les templates.

Inconvénients :

• il ne permet a priori de générer que du code XML (ou de tout langage XML) ce qui peut être limitatif.
• peut s'avérer limité par rapport à d'autres moteurs pour des traitements complexes.
• le code des templates n'est pas forcément toujours des plus compacts.

Cela fait quelques mois que je l'utilise au boulot et j'en suis globalement satisfait, du moins dans les cas que j'ai eu à traiter avec... Cela dit je n'ai pas beaucoup expérimenté d'autres moteurs (à part celui de phpBB 2 qui est assez limité).

PHP5 inclut de base la bibliothèque SimpleXML qui permet, comme son nom l'indique de gérer de manière très simple du code XML.

Un point est par contre problématique, la gestion des sections CDATA. En effet, supposons que l'on parte du code XML suivant :

<?xml version="1.0"?>
<root>
	<parent>
		<child>123</child>
		<child><![CDATA[456]]></child>
		<child attr="a"><![CDATA[789]]></child>
	</parent>
</root>

Lorsque l'on récupère les enfants d'un nœud via :

$parentnode->child;

On a la mauvaise surprise de ne pas obtenir tous les nœuds... En effet :

• le premier passe sans problème, car il ne contient pas de section CDATA.
• le second contient un CDATA et se perd dans la nature...
• le troisième contient un CDATA mais a également un attribut, il est alors correctement renvoyé (ne me demandez pas pourquoi).

Par contre, dans le cas où tous les nœuds sont basés sur le modèle du second (CDATA sans attribut), le premier est bien trouvé et retourné (au lieu d'un tableau).

Une fois le problème identifié j'ai fait quelques recherches et j'ai pu trouver cette solution consistant à éliminer les CDATA avant le traitement du code XML. Je ne la trouve pas très satisfaisante mais je n'ai pour l'instant rien trouvé d'autre...