WordPress, je t’aime moi non plus !

Ce qui manque à WordPress !

Voici un article qui pourrait bien créer la polémique. Même si c’est ce n’est évidemment pas le but !

Bien au contraire !

Mais, qui aime bien, châtie bien…

WordPress est un excellent CMS, même, s’il lui manque un certain nombre de choses pour être LE CMS !

En tant que développeur WordPress nous pestons tous un jour ou l’autre sur le fait que WordPress fait preuve d’un certain nombre de manques ou d’approximations.

Même si la communauté de développeurs de WordPress est sans aucun doute la plus vivante et la plus importante des CMS actuellement en vigueur, même si WordPress continue d’évoluer dans le bon sens, il est encore possible de l’améliorer grandement.

Et plutôt que de faire quelques replâtrages… il nous semble qu’il serait plus bénéfique de le revoir en profondeur…

Voici donc quelques pistes de réflexions pour faire de WordPress le CMS incontournable, certes, mais surtout un CMS abouti à un point jamais égalé …

Toutes les idées évoquées ici ne sont pas à prendre au pied de la lettre. Principalement, notre objectif est de créer le débat, la discussion, et d’apporter modestement notre pierre à l’édifice.

Modèle de données

Ce n’est un secret pour personne, un modèle de données optimisé est un plus pour toute application. Dans le cas de WordPress, certaines bizarreries persistent. Donnons donc un bon coup de balai pour nettoyer, et surtout améliorer ce modèle.

Les objectifs sont d’une part d’améliorer les performances et d’autres part d’étendre les capacités fonctionnelles de WordPress.

Dans un premier temps, nous pouvons remarquer que WordPress utilise une table pour gérer les articles et les pages, une autre pour gérer les liens, mais que les catégories et les mots-clés utilisent le même jeu de table (wp_terms and co) … Pourquoi ? Il serait préférable de gérer les différentes notions (catégories, mots clés, etc.) dans des tables séparées, et donc de créer une table pour les catégories.

Une table spécifique aux catégories : wp_categories

• category_id
• category_name
• category_slug
• category_description
• category_image (url de l’image affectée à la catégorie)
• category_parent_id

De ce fait il conviendra de modifier la table wp_posts en y ajoutant la colonne category_id. Au passage, on peut imaginer également que les pages pourront de ce fait être associées à des catégories sans devoir passer par un plugin WordPress.
[03 / 12 /2010] En fait, cela ne marcherait pas, car un article peut être associé à plusieurs catégories. Il faudra donc prévoir une table décrivant les relations entre les articles (et les pages) et les catégories, ou… réutiliser la table wp_relationships

[27/02/2012] Autre possibilité, tout simplement stocker les catégories dans la table wp_posts avec comme post_type ‘category’ 

Ajouter des tables dédiées aux menus : wp_menus et wp_menu_elements

Table wp_menus

• menu_id
• menu_name
• menu_slug
• menu_decription

Table wp_menus_elements

• menu_id
• menu_element_id
• menu_element_type (post, page, category, link, url)
• menu_element_id (sauf si url)
• menu_element_parent_id
• menu_element_order
• menu_element_title
• menu_element_description
• menu_element_slug

Par ailleurs, dans le cas où WordPress est utilisé comme un véritable CMS (et c’est aujourd’hui bien plus qu’une tendance), il devient nécessaire de pouvoir créer des tables spécifiques (par exemples : acteurs, films) et de gérer ces tables depuis le back-office de WordPress. Pour gérer (ce qui entre autre, signifie créer, modifier, supprimer…) ces tables, il faudrait des tables telles que wp_tables, wp_table_columns, wp_table_relationships :

Une table décrivant des tables personnalisées : wp_tables

• table_id
• table_name
• table_description

Une table décrivant les colonnes des tables personnalisées : wp_table_columns

• table_id
• column_id
• column_name
• column_description
• column_format
• column_length
• column_key_type (primary key or not)
• column__increment (true or false)

L’un des gros points faibles de WordPress concerne la gestion des sites multilingues. Pour améliorer cet état de fait, il conviendrait de disposer d’une table gérant les langues (wp_languages) et de d’une table, wp_translations, contenant les traductions des différents éléments (posts, pages, terms, categories, links, etc.)

Une table définissant les langues du site : wp_languages

• language_id
• language_code
• language_name

Une table wp_translations, contenant les traductions :

• language_id
• item_type (post, category, link, menu, term, etc.)
• item_id (post_id, category_id, term_id, menu_element_id …)
• translation (texte de la traduction)

=> Prévoir dans les options générales le comportement de WordPress quand un contenu n’existe pas dans toutes les langues : afficher le contenu par défaut, ou n’afficher que le contenu existant dans la langue de l’internaute

Modifier la table wp_posts pour ajouter l’url de la vignette de l’article ou de la page

Administration

Gestion de la blog roll :

Donner la possibilité à l’utilisateur de sélectionner une image comme il peut le faire dans un article ou une page, et augmenter la taille de la description. Ajouter la possibilité de traduire le titre et la description des liens.

Gestion des liens internes

Dans un article ou une page, ajouter une fonctionnalité permettant de lier une sélection à une autre page, un autre article, une catégorie, un mot-clé ou un lien de la blogroll (cf. plugin link-to-post)

Gestion des catégories :

Ajouter la possibilité de sélectionner et d’affecter une image à une catégorie

Ajouter l’éditeur wysiwyg pour décrire la catégorie (en lieu et place d’un simple texte)

Divers

• Donner la possibilité à l’utilisateur de réorganiser l’ordre des menus
• Dans chaque menu, trier les options par ordre alphabétique
• Ajouter des raccourcis clavier dans les menus
• Donner la possibilité « enregistrer sous » pour les articles, les pages, les catégories, les liens, etc.
• Créer une fonction permettant aux intégrateurs, installateurs, développeurs, etc. de « dupliquer »/ »cloner » une installation de WordPress (options, thèmes, plugins).
• Gestion des newsletters en standard, sans extension…
• Intégration Facebook et Twitter, et autres, en standard.
• Intégrer un véritable système de cache en standard (cf. wp super cache ; w3t, etc.)
• Générer automatiquement le fichier sitemap.xml (avec, pour les gros sites Internet comportant plusieurs dizaines ou centaines de milliers de pages, un index des sitemaps) et donner aux développeurs une fonction permettant de générer ce fichier à la demande.
• Faire évoluer la fonction d’importation : permette au développeur de préciser / décrire un format d’importation à partir d’un fichier CSV
• Intégrer une fonction de pagination similaire au plugin wp-navi ou autre
• Ajouter l’intégration de Google Analytics en standard
• Intégrer une gestion de workflow pour le contenu
• Améliorer la gestion des utilisateurs (ajout de champs tels que adresse, date de naissance, téléphone, etc.)
• Revoir la procédure d’installation : une installation facile (comme actuelle) et une installation personnalisée, dans laquelle l’administrateur peut paramétrer les fonctionnalités, notamment celles évoquées dans ce chapitre. Prévoir éventuellement plusieurs profils types d’installation : blog, CMS, CRM, réseau communautaire, e-commerce, full (toutes fonctionnalités activées)… Voire, donner la possibilité de combiner plusieurs profils (ex. CMS + Blog + réseau communautaire).
• Ajouter en standard l’équivalent de lightbox pour les images, les vidéos, et tout contenu multi-media, ainsi que pour les formulaires
• Améliorer l’éditeur wysiwyg, par exemple en intégrant automatiquement les styles du thème courant.
• Intégrer en standard un système anti-spam pour les formulaires
• Intégrer un système de statistiques tel que statpress
• Ajouter phpMyAdmin ou un équivalent dans le back-office de WordPress
• Améliorer la recherche d’articles, de pages, de catégories dans le back-office de WordPress en permettat notamment de rechercher dans les champs personnalisés (par exemple, on définit un type de pages personnalisé, annonces, contenant notamment un champ « référence »…. il serait souhaitable de pouvoir rechercher sur ce champ « référence »
• De la même manière, permettre à l’administrateur de sélectionner les champs personnalisés à afficher dans le back-office de WordPress pour la gestion des articles et des pages. Permettre le tri sur ces champs personnalisés.

Formulaires

• Intégrer une interface utilisateur permettant de créer facilement des formulaires (cf. contact 7 form)
• Les données saisies dans les formulaires devront pouvoir être enregistrées dans la base de données (il faudra donc un outil de reporting) et être envoyé sur un email, eventuellement spécifique à chaque formulaire.
• Chaque formulaire devra pouvoir être multilingue.

SEO

Pour chaque article, page, catégorie, mot-clé, donner la possibilité de définir les meta balises (title, description, keywords).

De la même manière, donner la possibilité de définir la balise title utilisée pour les liens (cf. All in One SEO Pack)

Générer automatiquement le fichier sitemap.xml

Articles, pages, etc.

• Ajouter, en standard, la gestion de la vignette, et incorporer dans la table wp_posts l’url de la vignette.
• Donner la possibilité d’affecter une page à une ou plusieurs catégories.
• Donner la possibilité de modifier l’url AVANT la sauvegarde de la page ou de l’article
• Interdire la sauvegarde si le titre n’est pas renseigné
• Inclure automatiquement les styles du thème dans le menu idoine de l’éditeur Wysiwyg (cela peut éventuellement être une option dans WordPress)
• SEO : ajouter la saisie des meta balises, avec les limitations d’usage (titre : maximum 60 caractères, description : maximum 160 caractères)

Options / réglages

• Ajouter la possibilité de choisir d’activer / désactiver les sauvegardes automatiques des articles et des pages
• Ajouter la possibilité (en fonction de la question précédente) d’indiquer la fréquence de sauvegarde
• Ajouter la possibilité de définir la sauvegarde, l’optimisation et la réparation de la base de données (cf. wp-db-manager)

Thèmes

Ajouter une fonction permettant de définir simplement des options pour un thème. L’idée est de faciliter le travail du développeur ou de l’intégrateur pour qu’ils puissent se concentrer sur l’essentiel et surtout pour qu’ils puissent développer plus vite.

Intégrer une fonction permettant de traduire le thème (cf Po Edit plugin). De ce fait, modifier la manière dont WordPress gère actuellement les traductions (__e ou _e) … en permettant d’utiliser des instructions de type %name%, %toto% où name et toto sont des chaînes définies dans les fichiers de traductions

Actuellement le développeur doit préciser dans le fichier functions.php les menus, les barres latérales (sidebars). Pourquoi ne pas donner la possibilité de créer les menus et les barres latérales dans les options du thème, charge au développeur de les utiliser ensuite correctement dans le thème… Par exemple, création d’un menu my_menu (ID=1), et de deux sidebars, sidebar-1 (ID=1) et sidebar-2 (ID=2)… Le développeur peut ensuite utiliser directement dans le thème les éléments qu’il aura créer dans le back-office de WP…

=> On peut d’ailleurs envisager l’ajout d’une table wp_menus et d’une table wp_sidebars. NE pas oublier, particulièrement pour les menus, la gestion des langues

Moteur de recherche

• Donner la possibilité au développeur de créer un formulaire de recherche multi-critères (ex. choisir une ville, un type de bien immobilier, un nombre de pièces, un budget minimal, un budget maximal)
• Donner la possibilité de relier les tables et champs personnalisés à ce moteur de recherche

Conclusion

Nous venons de voir qu’il est grandement possible et surtout souhaitable de faire évoluer ce qui est à l’heure actuelle l’un des meilleurs CMS du monde. Malgré ses grandes qualités, WordPress, s’il veut s’imposer comme le CMS incontournable, se doit dévoluer en profondeur. C’est tout le but de cet article, et nous aimerions créer le débat, et nous vous encourageons à nous faire part de vos remarques et de vos commentaires.