14 Déc 2013
Posté dans : Tips and tricks

Guide de l’intégrateur qui veut faire gagner du temps à son développeur

J’écris cet article après 3 années de collaboration avec Nicolas Fiascaro (@Co_cola) intégrateur chez BeAPI avec qui nous avons mis en place un workflow de développement qui me semble pertinent. Nous travaillons toujours de la même manière : Nous partons d’une créa, puis un intégrateur transforme cette créa en intégration HTML et un développeur prend le relais pour créer le thème et les extensions sur mesure. J’insiste sur le fait que nous n’empiétons pas sur le travail du voisin. Chacun son job 🙂

L’idée de ce billet est d’encourager les intégrateurs et les développeurs à discuter entre-eux avant le début du travail d’intégration pour se mettre d’accord sur certains points. En effet, même si l’on peut avec WordPress générer la structure HTML que l’on souhaite, il est je pense indispensable d’adapter l’intégration HTML au format WordPress. Il ne s’agit pas de former les intégrateurs au theming ou au développement mais simplement d’imposer lorsque c’est possible une structure précise. Si c’est annoncé en amont cela n’allongera pas le temps d’intégration. En revanche, cela permettra au développeur d’éviter de hacker certaines extensions ou de faire du jonglage avec les hooks de WordPress. Aujourd’hui lorsqu’un développeur débute son projet chez BeAPI, il est certain de partir d’une intégration orientée WordPress et la partie theming (convertir une intégration en thème WordPress) ne prend que quelques heures. Le développeur passe alors la majorité de son temps sur la partie fonctionnelle (modifier le comportement par défaut de l’outil, ajouter des fonctionnalités précises).

Assez de bla-bla, voici concrètement les presque 10 commandements que je vous conseille d’appliquer pour gagner du temps. Si vous (intégrateur) pouvez vous adapter aux structures présentées ci-dessous, votre développeur pourra se concentrer sur autre chose.

1. La pagination

Si vous utilisez une pagination sur votre site, il est fort probable que vous utilisiez l’extension WP-Pagenavi car la pagination par défaut de WordPress est très légère (« Page précédente – Page suivante » uniquement). S’il est simple de modifier le nombre de page ou les labels des liens, il est délicat de modifier la structure HTML générée par l’extension.

Je vous propose donc un Gist avec la structure générée par l’extension.

2. Les sidebars / widgets

Si votre site comporte une ou plusieurs sidebar (zone de widgets administrables par drag & drop) vous allez être contraint d’utiliser une structure commune pour chacun de ces widgets. Vous devez savoir que pour déclarer une sidebar le développeur précise plusieurs paramètres.

$args = array(
'name' => 'nom-de-la-sidebar,
'id' => 'id-de-la-sidebar',
'before_widget' => '< li class="widget %2$s" id="%1$s">',
'after_widget' => '< /ll>',
'before_title'  => '< h2 class="widgettitle">',
'after_title' => '< /h2>' );

– before_widget : Le code qui précède le contenu de tous les widgets de la sidebar. Vous remarquerez qu’un ID et une classe seront automatiquement ajoutés au code en fonction du widget donc vous pouvez tout à faire ajouter votre propre classe à cet endroit.

– after_widget : Idem mais après les widgets

– before_title et after_title : Ce qui entour chaque titre de widget

Vous ne devriez donc pas dans une même sidebar avoir un widget avec un titre en h3 et le suivant avec un titre en h4. Vous devez pour simplifier le développement entourer le contenu de vos widgets de la même manière. A l’intérieur vous pouvez faire ce que bon vous semble.

Voici un Gist d’exemple avec un sidebar et 2 widgets de démo.

3. Pas de classe dans les p !

Lorsque WordPress affiche le contenu d’un article (ce qui a été entré dans l’éditeur visuel), c’est l’outil qui génère les paragraphes et ces paragraphes n’ont pas de classe particulière sauf si l’administrateur passe en mode HTML mais nous allons partir de principe que non.

En résumé, vous ne devez pas faire :

<p class="contenu-delarticle">Contenu</p>

Mais :


<div class="contenu-de-larticle">

<p>Contenu</p> <---- Partie générée par WordPress difficilement modifiable

</div>

4. Les menus de navigation

Les menus de navigations générés par WordPress ressemblent nativement à ce qui suit. J’ai simplifié légèrement le code pour vous passer les ID et classes ajoutés aux éléments.

Le développeur peut facilement agir sur plusieurs paramètres qui sont listés sur la page du Codex de la fonction wp_nav_menu et disons que si vous pouvez adopter une structure qui ressemble à celle que je vous ai présentée, vous éviterez à votre développeur de perdre du temps sur la création d’un walker.

5. Body_class

WordPress génère automatiquement des classes sur la balise <body> en fonction du contexte. (« home » pour la page d’accueil par exemple, « single » sur les vues singles etc.) Il faut savoir qu’il est très simple pour un développeur d’ajouter autant de classes à cette balise que nécessaire. Si vous souhaitez décliner vos vues en fonction d’un conteneur générique n’hésitez pas à utiliser ces body classes.

Pour les développeurs qui se demandent comment ajouter des classes à la balise body, lisez cet article par exemple : http://my.studiopress.com/snippets/custom-body-class

6. jQuery

WordPress utilise nativement jQuery en mode noConflict pour éviter les problèmes de compatibilité avec d’autres librairies qui utiliseraient aussi le raccourci $. Ainsi, je vous encourage à ne pas utiliser le signe $ qui ne fonctionnera pas sous WordPress mais à écrire en toutes lettres « jQuery » comme indiqué sur la documentation de wp_enqueue_script.

7. Les commentaires

Il est relativement simple de constituer son propre formulaire de commentaires mais si vous parvenez à adopter ce format vous ferez une fois de plus gagner du temps à votre développeur.

8. Le fil d’ariane

Les deux méthodes qui je pense sont le plus utilisées pour gérer un fil d’ariane sont l’extension WordPress SEO et Beadcrumb NavXT. Nous avons pour habitude d’utiliser celui de WordPress SEO mais je vais vous livrer les deux codes générés.

WordPress SEO :

Breadcrumb NavXT en mode classique :

Breadcrumb NavXT en mode liste :

La modularité de WordPress fait que l’on peut s’en sortir en développement même avec une intégration non optimisée pour l’outil mais si le sujet est discuté avant le début de l’intégration cela en vaut vraiment la peine. En recevant des intégrations qui respectent les points soulevés dans cet article, je passe rarement plus de deux jours sur la partie theming et je peux me concentrer sur la partie fonctionnelle du site.

To be completed with your idées !

4 Commentaires

  • Merci ce guide est vraiment bien rédigé. Je rajouterais tout de même un topo briefing rapide sur le template hierarchy WP qui est le coeur du dev.

    Bien souvent les gens ne comprennent pas les delais pour templater dans WP mais RN effet cela dépend de l’inte de départ qui souvent n’est pas prévue pour, du moins quand le dev et l’inte ne se connaissent pas ou ne se parlent pas assez.

  • Coller au code de base de WordPress permet de gagner énormément de temps, ça je suis effectivement d’accord !

    Néanmoins, généralement je mets un certain point d’honneur à réaliser mon intégration en fournissant une balise solide en référencement à l’aide la structure. Les de titres de widgets ne sont généralement pas très pertinents pour le SEO (ex : archives, articles récents) et parasite un peu les mots-clés importants du site. Du coup, je leur préfère généralement une classe .h1, .h2, .h3 afin de garder le design sans bousiller la structure de mots-clés 🙂

    • Oui c’est tout à faire faisable à partir du moment où tous les widgets on cette même classe .h1, .h2 ou .h3

  • Le développeur qui doit mettre du code html dans la configuration de sa sidebar => LE LOL !

    WordPress me fera toujours marrer XD

    Le 3 est vrai, mais pas spécifique à wordpress… Un éditeur de texte, par défaut, ça fait des paragraphes sans class… voila, c’est tout.

Laisser un commentaire

Rechercher