Comment définir ce qui manque à WordPress ?

Le beurre, l’argent du beurre, le sourire de la crémière, les omegas3 et l’absence de cholestérol

Il y a deux façons de voir ce qui manque à WordPress : raisonner par rapport aux fonctionnalités qu’on souhaiterait avoir, et qui ne sont pas implantées, ou raisonner par rapport à ce que la structure de données ou le core de WordPress empêchent de faire facilement, ou complètement.

En effet, WordPress n’a jamais prétendu être un système complet. Il y a un compromis nécessaire entre la facilité d’utilisation et l’étendue des fonctionnalités standard. Et plus vous en mettez en standard, plus l’installation de base est complexe, et plus elle est difficile pour un débutant. Il suffit pour s’en convaincre de comparer l’installation d’un Drupal ou d’un Typo3 avec celle d’un WordPress. Il faut nettement plus de cinq minutes pour avoir un Drupal fonctionnel, même quand on maîtrise ce CMS. Et je reste là dans le domaine des CMS, je ne m’aventure pas vers des monstres comme SAP…

Une des raisons pour lesquelles je suis fan de WordPress et n’ai jamais réussi à le quitter pour autre chose, c’est justement cette balance entre simplicité et extensibilité, et la robustesse de son modèle de données (je reconnais que l’organisation des fichiers et du code pourrait être améliorée, mais le modèle de données est très bien). Par ailleurs, quand on regarde ce qui « manque à WordPress », il ne faut pas non plus oublier la compatibilité ascendante, très rare, où en clair un site développé avec WP xx continue à marcher avec WP yy (à quelques exceptions près, comme le changement majeur dans la gestion des termes). C’est assez remarquable de voir qu’un système né pour le blogging à une époque où on ne connaissait même pas les tags n’a pas eu besoin de totalement modifier l’organisation de sa base.

Core ou plugin

Personnellement, j’ai tendance à considérer que ce qui est dans un bon plugin solide n’est pas un manque de WordPress. « Tout » n’a pas besoin d’être dans le core. Même des fonctions très standard, comme le breadcrumb, que demande Rémy ne sont pas une « obligation », je ne les utilise pas partout. Donc faut il charger le core, avec une option à activer ou désactiver ? Et quand on voit à quel point on a du mal à faire comprendre à certains néophytes les concepts de base (page, catégorie, article, menu), rajouter les explications pour les possibilités du breadcrumb ?

Dans mes top plugins, il y a la classe WPAlchemy, pour toutes les metaboxes, WPML pour la traduction (bien qu’il soit payant, le support est derrière, et je n’ai rien trouvé d’aussi bien en gratuit), WordPress SEO de Yoast (quelle originalité) et une batterie de plugins pour la gestion des images. Pour l’admin, je rajoute CodePress Admin Columns, des extensions de Tiny Mce, et pour le SEO, en plus de Yoast, quelques plugins qui jouent sur les urls, pour les sites complexes, post to post, et j’ai généralement 98% de mes besoins couverts.

Vous noterez que je n’utilise pas de plugins pour la définition des custom post types et des custom taxonomies : je n’en vois pas l’utilité, mais beaucoup de contraintes, et un peu de code ne fait pas de mal !

Débutant ou expert

Les manques ne vont pas être les mêmes selon qu’on est débutant ou expert. Or en lisant certains articles de la chaine, j’ai eu l’impression que certains confondaient un peu les deux niveaux : quand Daniel demande que WordPress explique les implications SEO de certains champs, je crois qu’on va trop loin pour des débutants, et que pour ceux qui connaissent, c’est parfaitement inutile. Nous utilisons WordPress comme des professionnels. Mais n’oublions quand même pas qu’une large partie des blogs WordPress sont fait par des gens qui cherchent simplement à communiquer avec leurs proches, sans être des addicts au référencement. Par ailleurs, quand je vois le mal que j’ai pour faire comprendre à mes clients l’importance de la réécriture du titre et du permalien, ou des h2 et des liens internes, je crains qu’une brève explication sur « alors la le slogan ça va être la meta description de votre home et c’est important pour les moteurs » soit pire que son absence. (Passez un peu plus souvent sur wordpress-fr.net, vous verrez qu’on est très loin de tout ça…)

Bref à chaque outil son rôle, et même si ça nous ferait plaisir, celui de WordPress n’est pas de former au référencement (ou même au HTML, alors que, là encore 80% des demandes de support « wordpress » soient en fait des problèmes de codage HTML ou CSS).

Bon, tout ça c’est bien joli, mais qu’est-ce qui manque à WordPress alors ? Rien ?

Oh que si…

En vrac, je suis assez d’accord avec les points principaux : la gestion des images est « pauvre », la sécurité pourrait être un peu améliorée, et WordPress n’est pas vraiment une solution E-​​commerce. Maintenant dans mon utilisation, deux choses me manquent vraiment, c’est à dire qu’elles sont dans l’état actuel des choses, quasi-​​impossible à faire sans toucher les fichiers core de wordpress.

WordPress totalement multilingue

Il existe des plugins pour traduire le front-​​end. Après de multiples tests, j’ai choisi WPML, il y en a aussi un nouveau, que je n’ai pas testé (et dont je ne retrouve même plus le nom…). On peut aussi quand on fait un plugin, traduire ses pages d’admin. Mais il y a une chose qui est impossible à faire aujourd’hui, c’est un login complètement multilingue.

Imaginions que vous ayez un site bilingue, avec la langue par défaut en français, urldusite.fr . Votre wp-config.php définit donc la langue du blog en fr_​FR. Vous avez une version anglaise, que vous avez installée sur un sous-​​domaine, en.urldusite.fr ou mieux sur urldusite.com. Quoi que vous fassiez, l’url de l’admin sera toujours sur urldusite.fr, ce qui veut dire que, à moins de modifier le processus d’inscription, en rajoutant la langue en paramètre, et en modifiant la valeur de la langue par défaut de l’utilisateur (chose que permet WPML), votre utilisateur anglophone, qui se sera enregistré via urldusite.com se retrouvera sur urldusite.fr/wp-admin, et en français (il y a un plugin pour choisir sa langue sur la page de login, quand même).

Pour l’utilisateur lambda, monolingue, ça peut être très gênant. Encore plus si une des deux langues du site est l’arabe ou le russe…

Or cela vient d’un certain nombre d’url hard-​​codées dans les fichiers core de WordPress. « Insurmontable » a priori.

Sinon, il manquerait bien effectivement une obligation d’internationaliser ses plugins et ses thèmes, en tout cas pour les voir accepter dans wordpress.org. Mais <mode joke on> ce sont des américains, ne rêvons pas <mode très bête off>

Enfin certains plugins peuvent générer des contenus assez difficiles à identifier pour les modules de traductions. Ceux ci se basent en effet sur les structures standard de WordPress pour aller identifier les chaînes et les contenus à traduire. On traduira ainsi les posts, mais pas les auteurs (sauf la biographie…) etc.

Quand des plugins rajoutent des tables, où vont loger leurs données à des endroits bizarres, la traduction devient difficile. J’ai ainsi abandonné l’utilisation de GD Custom Posts and Taxonomies parce qu’il était « de fait » monolingue. Son interface ne permettait pas la traduction des étiquettes (l’argument ‘labels’), et allait les stocker dans un enregistrement sérialisé sur plusieurs niveaux dans la table options. Un cauchemar pour faire le lien avec WPML, et une impossibilité pour les autres plugins de traduction. Or les « labels » sont aussi utilisés dans le front-​​end, notamment dans certains widgets…

La gestion transversale des taxonomies

« Au commencement était le blog, et l’article qui avait des catégories, et le lien dans la blogroll, qui avait des catégories de liens (les potes, les blogs que je lis), et l’image, qui n’avait rien du tout ».

Puis sont venus les tags, toujours pour les articles, et pour le reste ça ne bougeait pas.

Puis est venue la gestion des termes, avec des plugins qui permettaient d’appliquer des catégories et des tags aux pages, et d’autres plugins qui créaient des tags pour les medias.

Puis sont venus les CPTCT (Custom Post Types et Custom Taxonomies) avec la possibilité de taguer /​ catégoriser comme on veut.

Mais toujours avec cette idée de base que chaque type de contenu avait « sa propre classification ». D’ailleurs cela se voit bien dans l’admin, où les taxonomies sont des sous-​​menus d’un type de contenu.

Quand nous en avons discuté sur la chaine WordPress, pour certains c’était normal : à chaque type de contenu sa classification. Pour moi j’ai plutôt tendance à voir le contenu d’un site comme un énorme cube, que je peux « analyser » selon des dimensions de type de contenu, de catégories, de schmilblick et de gloubi boulga. Autrement dit, j’aurais tendance à ne pas comprendre que sur un site qui me parle de cuisine, on me mette une blogroll qui me parle de mécanique des fluides, ou des images qui représentent la migration des lemmings. Si certaines taxonomies peuvent être spécifiques à certains types de contenu, il me semble logique que les taxonomies de base s’appliquent à l’ensemble des contenus d’un site.

C’est réalisable, via un plugin (ou le fichier functions.php du thème, mais il faut mieux éviter cette solution). Mais cela restera toujours bancal. En effet, si on peut même modifier dans le thème les pages de « taxonomie », ou les templates category.php ou tag.php pour qu’ils incluent tous les types de contenu, dans l’admin, on n’aura pas cette vision globale.

Imaginons une catégorie « mon titi à plume », avec trois articles, deux « pedigrees » et un « concours » (deux types de contenus spécifiques). Le compteur de WordPress vous indiquera 6 éléments classés dans « mon titi à plumes », mais vous n’en verrez que trois, deux ou un selon le type de contenu à partir duquel vous les appelez.

En effet l’url de la page listant les valeurs d’une taxonomie est :

/wp-admin/edit-tags.php?taxonomy=xx&post_type=yy

et l’url pour voir tous les éléments classés dans le « titi à plume » sera

/wp-admin/edit.php?xx=titi-a-plume&post_type=yy et si vous avez l’idée d’enlever le paramètre &post_type=yy WordPress considère que vous voulez voir les articles. Si vous essayez de lui dire &post_type=all, il vous répond gentiment qu’il ne connait pas ce type d’article.

Il est donc impossible d’avoir une vision globale sur tous les contenus d’une taxonomie donnée, sans refaire entièrement les pages d’admin du core.

Les articles de la chaine WordPress :

  1. 27 février – SeoMix, Que manque-​​t-​​il à WordPress ?
  2. 28 février — Boiteaweb, Que manque t-​​il à WordPress en sécurité ?
  3. 29 février — Wabeo, Que manque t-​​il à WordPress en WebDesign ?
  4. 01 Mars — WP Themes Pro, Que manque t-​​il aux thèmes WordPress ?
  5. 02 Mars — Insidedaweb, Que manque t-​​il à WordPress en ecommerce ?
  6. 05 Mars — WPChannel, Que manque-​​t-​​il à WordPress ?
  7. 06 Mars — The Loop, Les lacunes de l’expérience utilisateur WordPress
  8. 07 Mars — Screenfeedfr, Que manque-​​t-​​il à WordPress ? Idées d’interfaces
  9. 08 Mars — Lumière de lune, c’est ici !
  10. la semaine prochaine,  GeekPress

Et pour conclure, un grand merci à Daniel, qui a eu cette idée folle d’organiser la chaine, et de la porter à bout de bras !

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire