Après un site relativement simple, basé sur un thème corporate légèrement modifié, voici un site complexe, basé sur un thème WordPress existant mais complétement transformé.

Le site de ma partenaire en Allemagne, Simone Bull, Marketing- und Werbeagentur für Gütersloh a été mis en ligne cette semaine. Le site a été créé en deux étapes, d’abord un blog seul, avec l’objectif d’apprendre à maîtriser l’outil, puis un site complet présentant l’offre de service et un portfolio complet.

Le theme, Centivio de Template Square, a été acheté chez ThemeForest, et choisi pour son graphisme, clean, épuré, et corporate. J’avais vérifié préalablement à l’achat que le thème était prêt à l’internationalisation. Le thème est livré avec plusieurs schémas de couleur, tous sous forme de thème enfants, un fichier psd pour d’éventuelles modifications et une documentation très légère. Le forum du thème signalait que des acheteurs avaient eu des difficultés à mettre le thème en place et trouvaient qu’il y avait beaucoup de travail pour arriver au même rendu.

En effet, le décompactage du fichier .zip apporte pas mal de déceptions :

• pas de prise en compte de l’internationalisation : non seulement il n’y a pas de fichier .pot ou .po, mais les fonctions gettext ne sont pas incluses dans le thème. Après récriminations, l’auteur parle d’une erreur et propose de remettre en ligne une version « gettextisée », trop tard nous avions déjà fait le travail, nous convenons en compensation de pouvoir utiliser le thème sur plusieurs sites.
• la conception de la page d’accueil est très basique, puisque le contenu est… tout simplement à insérer en code HTML dans les options du thème.
• d’une manière générale la documentation du thème est extrêmement pauvre, et il faut repartir sur l’aperçu du thème chez Centivio pour trouver les classes et les id à utiliser pour afficher les éléments dans la sidebar tels qu’ils apparaissent dans la démonstration
• si certaines options du thème (notamment l’adresse, le téléphone, etc.) ne sont pas remplies, ce sont les coordonnées de l’auteur du thème qui apparaissent « par défaut » (y’a pas de mal à se faire des liens…)
• les fonctions spécifiques du thème ne sont pas d’excellente qualité : par exemple les actions ajoutées à wp-head() doublent, voire triplent le title sur la homepage dès qu’on a l’outrecuidance d’utiliser un plugin de SEO, comme AIOSEO ou l’excellent WordPress SEO de Yoast, le code Google Analytics, qui peut être renseigné par les options du thème apparaît dans le footer, alors qu’il vaut mieux le mettre avant </head>, etc…
• une erreur dans la gestion des menus qui rend les sous-menus impossibles à cliquer (stay tuned pour l’astuce technique !)
• une structuration sémantique assez mauvaise, avec deux H1 sur une page d’accueil pauvre en contenu, et un passage direct de l’un des H1 à H3, et des H2 comme titres de sidebar (ça c’est un défaut de WordPress, mais bon…)

Par ailleurs, les fonctionnalités présentes (portfolio et témoignages client), après revue, ne correspondent pas aux besoins.

Alors on se retrousse les manches, et on en profite pour refaire le cahier des charges « from scratch »… au lieu de se glisser dans les options du thème.

L’utilisation combinée des custom post type et des custom taxonomy

Le site présente très classiquement les différents produits et services, ainsi qu’un portfolio de réalisations. Qui dit portfolio dit aussi clients, et qui dit clients dit témoignages. Quelques pages statiques, très classiques (contact, informations légales…) et un blog, alimenté irrégulièrement depuis près d’un an.

En plus des catégories et des tags, on va rajouter deux types de taxonomies : l’ID client, et le type d’offre. L’intérêt est de pouvoir faire le lien entre les différents types de contenus.

La présentation de chaque service offert est faite sur une page, très classiquement. (Seul le template de la page est spécifique). Cette page doit avoir la taxonomie ‘services’ renseignée.
Un élément de portfolio sera donc obligatoirement rattaché à un service, et à un (ou plusieurs) clients.
Enfin les articles de blog peuvent être rattachés à un client et/ou un service.

Grâce à ces deux classifications, les pages de services présentent la liste des éléments de portfolio, ainsi que les articles du blog, les pages clients présentent la liste des travaux faits pour un client, et les articles de blog.

Aux types de contenus sont associés des champs personnalisés, et la saisie est facilitée par des meta box dans l’admin. Pour cela j’ai utilisé WPAlchemy, une classe php très utile, accompagnée de templates pour les meta boxes que l’on peut modifier à loisirs. La sélection des taxonomies clients et services se fait par une liste déroulante …. dont les éléments sont déterminés par une requête sur la base, listant les pages ou les contenus clients, évitant ainsi les erreurs de saisie.

De plus, le témoignage qui était un custom post type, est maintenant constitué de trois champs personnalisés du client, ce qui permet de mettre en place une logique pour l’affichage de ceux ci : si on est sur une page client, on affiche le témoignage de ce client ou un témoignage au hasard, si on est sur une page de service ou de portfolio, on cherche si il y a un témoignage pour un client pour lequel ce type de service a été fait, (idem pour un article du blog avec une de ces taxonomies cochées), et dans les autres cas on affiche un témoignage au hasard.

Prendre le temps de bien penser ses customs post types et custom taxonomies permet d’aller beaucoup plus loin dans le cross-linking interne que des plugins « related posts ».

Création de custom post types pour la page d’accueil

Il suffit de créer des custom post types pour la page d’accueil, et ses différentes composantes se retrouvent gérables dans l’admin, sans obliger ma cliente à saisir du code html pur et dur. C’est une solution largement préférable à n’importe quelle classification de type catégorie ou tag. On peut en théorie utiliser des champs personnalisés indiquant la position que doit avoir l’élément.

Ici le choix a été fait pour des post type parce que :

• il y avait le besoin de pouvoir faire pointer ces éléments vers n’importe quelle url dans le site (via un champ personnalisé).
• ces éléments n’avaient pas de contenu autre que le texte affiché sur la page d’accueil, et n’avaient pas vocation à être affichés seuls (il suffit de ne pas afficher le permalien dans la boucle)
• ils devaient pouvoir être ordonnés facilement (via un champ personnalisé)

Techniquement, on avait donc le choix entre rajouter des champs personnalisés à tous les contenus existants, et faire une requête passant sur tous les types de contenus, en cherchant ceux pour qui les metas existaient, et faire un type de contenu spécifique. La deuxième solution avait l’avantage de la simplicité, et de permettre à l’utilisateur de voir d’un seul coup, dans son admin, tous les éléments de la page d’accueil. Le texte qui apparaît à droite du slider est aussi un contenu de ce type (dans le thème d’origine, il était à coder en dur).

La modification des custom post types fournis pas défaut

Le thème fournissait trois types de contenus personnalisés :

1. Slider, pour les photos qui défilent en carrousel sur la page d’accueil
2. Portfolio
3. Témoignage

L’élément Slider a été modifié pour rajouter le texte en surimpression et l’url de destination (pas de lien sur les images dans le thème de destination).

Les témoignages et le portfolio ont été désactivés (show_ui et show_in_nav_menus passés sur false) pour ne pas apparaître dans l’admin. Pourquoi ? Le contenu portfolio n’était pas utilisable « en l’état », car de nombreux tests codés dans le template généraient un affichage différent. En réalité, il aurait fallu, en attendant la 3.1, utiliser un plugin comme Custom Post Type Archives qui permet d’afficher des pages d’archives spécifiques pour un contenu donné.

Quand on contenu témoignage, comme précisé plus haut, nous avons préféré l’intégrer au contenu client.

La structuration des fichiers functions.php

En théorie, les fonctions du thème incluent l’activation de fonctions standard de wordpress, les vignettes, les menus, les custom types et custom content.

En pratique, cela veut dire que le « thème » contient beaucoup plus que l’apparence, mais aussi des éléments de définition des données, donc du contenu, que l’on risque de perdre en changeant de thème. Si les vignettes appartiennent bien au domaine de l’apparence, tout le reste, à mon avis, doit être rapatrié dans un fichier functions.php indépendant du thème.

Il a donc été créé un plugin spécifique, qui regroupe tout ces aspects. L’avantage, en plus d’une organisation du code « plus propre » est qu’une mise à jour du thème ne risque pas de modifier les données.  En pratique, cette partie a été un peu « crispante », mais nécessaire, parce que le thème a éclaté les fonctions entre différents fichiers (pas absurde a priori), dans lesquels il fallait partir à la pêche, vu l’absence quasi-totale de documentation. (et ça, c’est mal !)

L’affichage des témoignages, les liens entre contenus sur la base des taxonomies sont gérés dans ce plugin, que j’appelle « site-management ». Leur affichage dans le thème se fait par des templates et/ou des fonctionnalités intégrées dans le fichier du thème. La désactivation des fonctions du thème parent (centivio) a été faite dans le fichier du thème enfant (centivio-light blue). On a donc un ensemble logique :

1. un thème parent, avec des fonctions que l’on utilise
2. un thème enfant avec la désactivation de certaines fonctions du thème parent, dans un fichier sbm-functions.php (donc pas écrasé par une mise à jour), qui permet de repartir sur une base nette
3. un plugin maison, qui met en place les fonctions utilisées.

Si cela semble un tout petit peu lourd, c’est en réalité assez clair, et en tout cas l’architecture la plus pérenne.

La modification de l’apparence : template et css

Optimiser la sidebar

Une des choses auxquelles je fais très attention (mais pas sur mes propres sites….) c’est d’éviter que la sidebar génère de nombreux H2 « inutiles ». Les titres des widgets n’ont a priori aucune raison de se retrouver en H2, puisque le contenu qui apparait est souvent un court paragraphe, ou une liste, et répétif sur toutes les pages du site : ce n’est pas réellement un élément de contenu appartenant à la page.

La modification a donc été faite, pour l’ensemble des sidebars du thème (il me reste le widget del.icio.us a développer, car la fonctionnalité java proposée par del.icio.us impose un h2).

Simplifier / enrichir les templates

Bien que Centivio ait été « soi disant » mis à jour pour la version 3 de WordPress, il ne gère pas les archives par type de contenu, (ni les affichages single), mais fonctionne avec des tests sur le type de post. C’est très lourd, je trouve, pas facile à modifier.

Par ailleurs, les métas (catégories, tags…) devaient être modifiés, pour intégrés nos taxonomies, et pour supprimer certains éléments inutiles, comme l’auteur. Le thème-enfant, au final, contient 22 fichiers (contre 1 fichier, la feuille de style, dans la version d’origine).  Des éléments répétitifs, comme les meta, sont gérés dans des fichiers à part, et le nom des fichiers a été créé en prévision de la 3.1 pour les archives des custom post types, il suffira de désactiver le plugin « Custom Post Type Archives »

Modifier les css

La modification des css a surtout porté sur la transformation des H2 en div dans la sidebar, sur quelques autres aménagements et… en dernière minute, sur la modification de la couleur des caractères, trop clairs, pas assez de contraste. Les css de certains plugins (comme les boutons sociaux) ont aussi été légèrement modifiés. Au final, il reste du thème d’origine le graphisme de la barre de menu, du slider d’image sur la page d’accueil, et du footer, ainsi que la grille de la page d’accueil.

Néanmoins, nous avons considéré que c’était suffisant pour laisser le nom du développeur dans le fichier css… tout en rajoutant l’indication de nos modifications !

Les autres tâches

A ce stade « y’a plus qu’à … faire du contenu ». Il y a là encore une différence entre ce qu’on peut faire pour un petit budget ou pour un budget plus important.

La préparation des medias

Un certain nombre d’images ne passant pas bien à la moulinette automatique de la bibliothèque des medias, les fichiers individuels ont été retravaillés sur Photoshop et ré-uploadés.

Des fichiers .pdf trop volumineux ont été réduits, et quand il était impossible de passer sous la barre des 8 mega, un fichier « fictif », avec le bon nom, a été téléchargé via la bibliothèque des médias, puis rechargé manuellement avec son vrai contenu.

La gestion des urls indexées et le début du référencement

Des éléments qui étaient des catégories sont devenus des customs taxonomies, des doublons entre les tags et les catégories ont été supprimés… bref un ménage a été fait, d’où la nécessité de rediriger les urls modifiées.

Les comptes pour Webmaster ont été créés sur Google, Yahoo et Bing, le sitemap soumis, les ping mis en place. Le « petit » est prêt à voir le jour.

Le bilan : effort et récompense, le référencement naturel

Par rapport au site simple présenté dans l’article précédent, l’effort (et donc le prix) a été environ quatre fois plus élevé. Le site est nettement plus facile à utiliser et à faire évoluer, il est aussi nettement plus optimisé. Il se positionne « tout seul » sur un certain nombre de requêtes visées, avant même que le link building soit commencé.

Entre un site à 1.000 euros et un site à 4.000 euros, il y a un grand nombre de différences invisibles, dans l’administration du site, dans la façon dont l’agence s’implique dans la préparation du contenu, et des différences qui peuvent se percevoir dans le code qui en résulte et la structure du site.

Il n’est pas obligatoirement justifié d’investir des sommes importantes dans un site : tout dépend du secteur d’activité, de la compétition… et de l’orientation du site, « vitrine » ou site de contenu destiné à être mis à jour régulièrement. Une analyse préalable de la concurrence, de l’activité, de la stratégie marketing sont des plus, qui permettent de bien structurer le site… et donc de maximiser le retour sur investissement.