Drupal et WordPress : deux logiques proches, mais différentes.
En furetant sur les forums Drupal, je vois que pas mal de personnes envisagent, comme moi, de passer de l’un à l’autre, soit pour migrer leur blog, soit pour construire un autre site web, plus complexe, pour lequel WordPress ne peut pas tout faire.
Or même si les concepts sont après tout assez proches (un CMS reste un CMS), le vocabulaire, et surtout l’organisation des fonctionnalités n’est pas la même, et passer d’un système à l’autre peut être assez déroutant.
WordPress est un excellent système de blog, qui peut faire beaucoup d’autres choses, grâce à des extensions et des plugins.
Drupal est un CMS qui peut gérer un blog, un forum, ou des publication, mais dont les fonctionnalités sont moins “pré packagées” que dans WordPress. (On le verra avec l’installation).
On peut utiliser WordPress out of the box, sans plugin, en choisissant simplement un thème plaisant, et avoir un site “bien fini”. C’est impossible avec Drupal, il va donc falloir rajouter des modules. Et pour rajouter les modules dont on a besoin… comprendre la logique de Drupal.
Les structures de base
Les contenus de WordPress
La structure de base de WordPress, c’est l’article (le “post”), qui se trouve dans la table wp-posts. Il y a quatre types de contenus possibles : l’article au sens “article de blog”, la page (pour la différence entre les deux, voir cet article), la pièce attachée (l’image chargée par la bibliothèque des medias) et la révision (quand la gestion des versions n’a pas été désactivée).
L’article peut avoir des informations annexes, ce sont des “metas”, qui sont stockés dans une table à part. Ces valeurs correspondent aux custom fields, ou champs personnalisés.
Et c’est tout.
Les contenus de Drupal
La structure de base de Drupal, c’est le “node”, ou le noeud.
Le node est lui aussi un contenu.
La première différence avec WordPress, c’est que le type de contenu n’est pas limité.
Drupal est livré avec quelques types par défaut (Page, Article) mais on peut en créer autant qu’on veut dans l’administration.
Or l’avantage de créer des types de contenus différents, c’est qu’on peut ensuite les personnaliser : en y rajoutant des champs supplémentaires (pour ceux qui ne connaissent que WordPress, imaginez des Custom Fields auxquels on peut rajouter des règles de saisie très détaillées), des autorisations, des règles différentes pour la réécriture des urls. Et aussi, des sélections différentes.
L’organisation et la classification du contenu
Là la différence entre les deux systèmes est très forte.
Catégories et tags chez WordPress
Au début était la catégorie, et seulement la catégorie. Depuis sont arrivés les tags. Tags et catégories sont les “termes” (ou taxonomie) qui permettent de qualifier et donc classer un article (et récemment une page).
En conséquence, un article doit obligatoirement avoir une catégorie.
Les pages, elles s’organisent comme un ensemble indépendant, qu’on peut structurer, en donnant une page fille à une page mère (ou père, si vous voulez).
Les catégories peuvent aussi être hiérarchisées. Pas les tags.
Les fonctions qui permettent de lister les catégories et les pages (wp_list_categories et wp_list_pages) sont utilisées pour faire les menus.
Taxonomies et menus chez Drupal
A la différence de WordPress, le truc obligatoire chez Drupal, c’est le menu. En effet, c’est par le biais du menu qu’on va permettre d’accéder aux nodes.
On peut avoir autant de menus qu’on veut, mais il faut avoir un menu primaire.
Et pour chaque node, on décidera de l’affecter (ou pas) à un élément de menu, ou pas (si on ne l’affecte pas à un menu, on pourra quand même y accéder).
Les taxonomies ou termes, sont extrêmement souples. Comme le reste, elles se paramètrent par l’interface d’administration. On peut en créer autant qu’on veut, leur donner des valeur par défaut, … alors que dans WordPress, il faut obligatoirement mettre les mains dans le code si on veut gérer des taxonomies supplémentaires (ce que fait par exemple le plugin Organize Series).
“The Loop” ou les “Views”
Le mécanisme de base de WordPress, c’est la “boucle” qui passe a travers les posts, et qui détermine une sélection à afficher. Les sélections de base sont “tout, en ordre chronologique décroissant”, “les articles d’une catégorie”, “les articles d’une période donnée”, “les articles d’un auteur”, et après si on veut faire plus complexe, il faut mettre les mains dans le code, avec query_posts().
Ce mécanisme ne fonctionne pas de la même façon dans Drupal.
La détermination de ce qui s’affiche se fait par le biais des menus.
Et par les “vues”.
“Views” étant un des modules les plus utilisés de Drupal, un des trucs de base qu’il faut installer si on veut avoir un site un tant soit peu fonctionnel.
Imaginez un système qui vous permette d’utiliser the query, mais d’une façon graphique, un peut comme on trie des champs dans excel.
Et de décider ensuite où vous l’affichez dans votre site.
Les thèmes
La grande différence entre WordPress et Drupal, ce sont les blocs.
Dans WordPress, on a un système de template php assez classique avec une hiérarchie (page d’index par défaut, puis pages spécifiques pour les catégories, les auteurs, les archives), et des fichiers spécifiques qui vont apparaitre sur la toutes (ou certaines) pages, le header, le footer, les sidebars.
Lesquelles sidebars vont présenter des informations comme la liste des catégories ou des pages (des “menus” de Drupal), la liste des derniers commentaires, des meilleurs articles, des articles au hasard (des “vues dans Drupal). Et aussi accueillir des widget, qui peuvent afficher un texte, un compteur, bref, des tas d’éléments “en dehors” de la boucle.
Dans Drupal, il y a aussi a peu près la même architecture, avec des fichiers .tpl.php, le fichier de base étant “page.tpl.php” (à la différence de WordPress, où c’est l’index). Mais avant cela, dans le thème, on va définir des blocs. Ces blocs vont être placés dans les templates.
Et ensuite on va affecter à un bloc un contenu, que ce soit un menu, un noeud, une vue, etc…
Par ailleurs, comme pour WordPress, il est possible de définir un template “spécifique” par rapport à un template général. Pour créer une page d’accueil différente, il me suffit de créer un fichier page-front.tpl.php
Il y a donc beaucoup plus de souplesse et de richesse pour organiser son contenu, sans toucher au code, ou a minima. Mais plus de travail pour préparer la présentation de ce contenu.
Deux modèles de données différents
Cela se voit tout de suite à la taille de la base de données. Une vingtaine de tables pour un site avec WordPress, une centaine pour un site avec Drupal.
Cela a plusieurs conséquences :
- la prise en main et la création du site est plus longue, plus complexe, moins intuitive avec Drupal qu’avec WordPress
- techniquement, il est impératif d’activer le cache sous Drupal
- Le transfert d’un système à l’autre est loin d’être simple
Choisir Drupal uniquement si on en a vraiment besoin
On a vraiment besoin de Drupal si on a besoin :
- D’un site intégré avec un forum, et une identification unique des utilisateurs
- Une gestion réelle des utilisateurs, avec des autorisations un peu plus complexes que les rôles basiques proposés par WordPress
- Un site véritablement multilangue
- Une gestion complexe des contenus
En choisissant Drupal on perdra :
- le pré-packaging de WordPress (éditeur visuel, gestion des médias)
- la richesse des thèmes gratuits prêts à l’emploi
- la possibilité pour ceux qui connaissent php de mettre très simplement les mains dans le cambouis (on peut les mettre aussi avec Drupal mais c’est moins simple)
- la légèreté de la base, qui permet d’héberger WordPress sur des offres bas de gamme, comme free
Migrer de WordPress vers Drupal
Ce n’est pas simple, et beaucoup moins simple que de migrer de Blogger ou MT à WordPress. A une table WP correspondent trois tables Drupal. Il faut par ailleurs savoir ce que l’on va faire des champs personnalisés.
La préparation de la routine d’importation pour des gros sites prend entre un et deux jours.
Pour des petits sites, sans champs personnalisés, cela peut se faire rapidement par le biais des flux xml. Mais pourquoi donc migrer un petit site vers Drupal ?
Et à partir du moment où on utilise les champs personnalisés, la routine d’importation devient nettement plus complexe.
La série d’articles “De WordPress à Drupal” est faite au fur et à mesure de ma prise en main de l’outil. Il se peut donc qu’il y ait des inexactitudes, ou des incompréhensions.
Article tout bonnement excellentissime !
Personnellement, je pense que WordPress vaut Drupal très largement.
WordPress est d’ailleurs en train de délaisser son image de “blog manager” pour celle d’un CMS complet et puissant.
Merci beaucoup :)
Oui, WordPress est un “vrai” CMS très fonctionnel. Le grand saut a été fait avec la 2.5 et l’introduction des taxonomies, qui a permis énormément de choses.
Je suis assez impatiente pour la v3 et l’intégration du multiblog.
C’est d’ailleurs une bonne démonstration que la structure de données est essentielle (c’est un de mes vieux dadas de l’époque où je faisais de la mise en place d’ERP ^^). Une bonne structure de données permet de bâtir énormément de fonctionnalités.
Je n’ai pas regardé Joomla depuis plus d’un an, mais à l’époque son système rigide de classement via les menus (et donc grosso modo l’impossibilité de faire du multicatégorie facilement) m’avair rebuté.
J’vais utiliser quelques passage de ton article pour faire un petit post sur mon blog.
J’espère que tu m’en voudras pas, mais c’est tellement bien écrit que je ne vois même pas l’intérêt de paraphraser :)
Un peu de lecture :)
http://lumlune/copyright
Les méfaits du duplicate content :
http://forum.webrankinfo.com/duplicate-content-peut-couter-tres-cher-t121831.html
Donc si tu dépasses le cadre de la citation avec les liens qui vont bien, je t’en voudrais :)
T’inquiète pas, c’est juste trois/quatre lignes qui m’ont profondément marqué ^^
Merci pour cet article ! Etant moi-même très fan de Drupal, je suis la première à apprécier WordPress et j’ai tendance à prendre pour ligne de conduite “Quand WordPress suffit, WordPress suffit”. Je m’apprête d’ailleurs à lancer mon premier site avec WP, et je pense embrayer sur un blog personnel… avec WP. Je pense que tes critères pour retenir Drupal plutôt que WordPress sont tout à fait pertinents.
Il y a sur drupal.org un débat wp/drupal (au milieu des commentaires https://www.drupal.org/node/671566 ) sur leur évolution respective. Je suis assez d’accord avec le commentateur qui dit que vouloir ressembler à Drupal serait du suicide pour WordPress. Je ne sais pas quelle direction le débat “product/framework” (faire un produit fini ou en rester à un framework) fera prendre à Drupal ; mais je pense que WordPress a largement sa place comme “produit-fini-spécialisé”. Sans compter que les thèmes sont vraiment canons (encore que ça se soit un peu amélioré côté Drupal ces derniers mois).
Merci pour cette belle comparaison, raisonnée et bien menée.
Merci à toi :) J’ai déjà bookmarké ton site, où je vais passer quelques heures je pense. Et je file voir la discussion dont tu parles.
A mon avis de encore newbie Drupal, plutôt que d’en faire un produit fini, il faudrait développer les ressources qui facilitent la prise en main par les non spécialistes.
Juste un exemple, dans les thèmes, justement, j’ai trouvé quelques thèmes portés de WordPress, comme Drupazine ou Revolution, mais aucune doc me permettant d’arriver à un affichage correct. (J’ai peut être mal cherché).
C’est aussi mon avis de déjà-plus-newbie-mais-pas-encore-pro sur Drupdrup. Le démarrage est vraiment ardu, et la francophonie bien moins avancée que sur WP (qui est bien traduit comparé à Drupal)… La difficulté est qu’en fait il y a plusieurs sortes de débutants Drupal, même dans les non-spécialistes : il y a l’amateur du dimanche qui veut vite un site pour son association, le graphiste qui veut vite un site “beau”, le développeur qui veut vite comprendre s’il ira plus vite avec drupal que sans, etc. Comme tu le dis, il est important de multiplier les ressources, qu’elles s’adressent chacune à un type de public, surtout pas de viser le discours unique (parce que le produit ne l’est pas). Mais le résultat est que les infos s’éparpillent, ce qui fait une grosse dépense d’énergie humaine…
Bon, j’arrête de t’embêter je dois dîner :-)
Bonsoir,
Y a quelque jours j’ai installé Drupral je trouve que l’installe est quand même fastidieuse, car malgré le message de renommer: default settings …cela complique pour les novices en CMS comme moi
Hier avec une nouvelle installation, je n’arrive plus a le remettre en ligne: La BDD plus moyen de la re créer.(j’ai posté sur le forum FR dupral).
Je suis revenu avec WP sont install est trop facile avec note d’humour sur les message des étapes.;)
Par contre c’est quand même un peut le parcourt du combattant pour gérer les pages les titres d’article etc.
Pour résumer ma petite expérience avec ces deux CMS, Drupal il est bien à l’emploi: création de site on si retrouve dans le panel admin mais faut arriver a l’installer.
WP installation aisé mais dans le panel admin faut retrousser les manches c’est comme un couloir avec pleins de portes sans lumière lol.
Ce que je voudrai c’est un WP pour l’instal avec le control panel de Dupral ;)
J’ai oublié trop top la MAJ avec WP juste en un clique
Merci ;)
Oui c’est clair, côté installation WordPress est le gagnant. D’ailleurs la différence entre l’installation des deux systèmes va faire l’objet d’un prochain article.
En revanche, je n’ai pas de difficultés pour transférer les bases de données.
Merci pour le topo. J’ai un blog sous WordPress depuis quelques mois, et ca s’est fait en toute simplicité. Je suis très impressionné par leur fonction de mise à jour intégrée dans le logiciel, pour un script php c’est du beau boulot. Et l’ergonomie de l’admin WordPress est proche de la perfection, je trouve.
Je n’ai pas vraiment croisé la route de Drupal, je suis plutôt attaché à SPIP depuis quelques années. J’ai fait quelques tests de Drupal, et j’ai aimé l’installation très propre des langues et des modules, et le principe d’articles / sous articles (histoires, je crois). Néanmoins, avant d’en faire ce qu’on veut, il faut vraiment rentrer dans la logique du script, et l’apprentissage n’a pas l’air rapide.
une 100aine de tables, c’est plutôt l’argument qui m’effraie. Ca me rappelle les boutiques en ligne à la Magento… des usines à gaz pour la plupart des projets. Evidemment, pour des gros projets, ca peut se justifier, mais pour des gros projets, j’aurais tendance à dire qu’un développement spécifique apportera de l’optimisation, plutôt que prendre un truc tout fait. Bref, est ce que le foin qu’on fait autour de Drupal en ce moment est justifié ?
La centaine de tables à mon avis, ce n’est pas “en soi” un truc effrayant. Pour avoir aussi regardé Magento… ça n’a rien à voir. Pour moi, dans le cas de Drupal, c’est plutôt l’indice d’un modèle de données très clean et très flexible, qui a ses avantages. Quand tu désinstalles un module dans Drupal, tout part. Dans WordPress, il se peut que beaucoup de données restent, notamment dans la table wp-options.
Bref, Drupal et WordPress ne répondent pas aux mêmes besoins. Ce serait un peu prendre une enclume pour écraser une mouche que prendre Drupal pour un blog. En revanche, faire une gestion fine des utilisateurs, ou un site vraiment multilingue avec WordPress, c’est impossible. Faire une admin adaptée pour un système complexe avec beaucoup de champs personnalisés, c’est un très gros boulot, alors que cela se fait tout seul avec Drupal.
etc, etc. Il n’y pas un bon système dans l’absolu. Et oui, Drupal est un excellent système.
Désolé : mais Qu’est ce que ne peut faire wordpress ? finalement ?
Je suis du meme avis que les anglais : la simplicité ça compte ! Ca n’a pas de prix.
Et qu’est ce que ne peut faire wordpress ? Servir le café ? Ca doit être possible en un clic.
Il y a pas mal de choses ques WordPress ne peut pas faire. Notamment une gestion fine des utilisateurs. Mais bon, la réponse à cette question étant dans l’article, je n’ai pas trop envie de me répéter.
La simplicité ça compte… tant que ça répond à un besoin. Il ne faut pas non plus être un ayatollah de la simplicité :)
L’installation automatique des modules est ajoutée dans Drupal 7. Il est même possible de donner une URL, sans avoir besoin de télécharger l’archive sur son ordinateur.
Je ne l’ai pas encore testée.
Oui mais Panels ne s’est pas engagé à être prêt pour le jour de la sortie !
Plaisanterie mise à part, je trouve effectivement que les deux CMS convergent.
Ouais, mais nous on a le node reference, et toc ;-) !
N’étant pas un fan de codage html ou php, j’ai testé WordPress, qu’on m’avait conseillé, puis Drupal car il est pas mal utilisé dans la sphère des Linuxiens.
Wordpress était pas mal, mais trop “blog” à mon goût. Drupal me semblait plus souple, et il l’est certainement, mais je suis un gros faignant… Alors je suis revenu à wordpress et c’est vrai qu’avec quelques plugins et le bon thème, cela ne ressemble plus trop à un simple blog. L’utilisation est vraiment simple ! J’attends la version 3 avec impatience.
Concernant la gestion des forum, il y a le plugin Simple:Press forum, assez complet. Le forum bbpress quant à lui est un forum créé par les développeurs de WordPress. Il peut être “synchronisé” avec votre blog, mais c’est hyper simpliste pour l’instant.
Merci pour ces précision :)
Je vais faire baisser le niveau du débat. Débutant, nul chez les nuls en web 2.0, je suis tenté par wordpress par ce que ergonomie, facilité annoncée dans l’apprentissage, mais un peu rebuté par l’esthétique apparemment limitée et pauvre et par trop centrée blog.
Y a t’il possibilité de créer du wordpress formaté en vrai site internet institutionnel (arborescence, qualité de présentation) et d’y ajouter en bouton associé un blog wordpress classique ? Si oui, merci de me communiquer une ou plusieurs adresses de sites remarquables réalisés en wp (mon objectif est de créer un site à tonalité culturelle, sociétale, prospective, d’où ce souci d’image institutionnelle..).
Y a t’il un article quelque part du style “wordpress : sortir du blog pour créer un vrai site”
Merci.
J’ai un peu de mal à comprendre ce que vous voulez dire par “esthétique apparemment limitée et pauvre et par trop centrée blog” ainsi que “arborescence” ?
Vous pouvez avec les pages (et même avec les catégories) gérer une arborescence complexe, sur un de mes sites je gère plus de 100 catégories sur 4 niveaux.
Vous pouvez avec un thème adapté, avoir une présentation qui ne soit pas celle de ce blog.
“bouton associé” ? là non plus je ne comprends pas trop ce que vous voulez dire.
Voici un blog réalisé sous WordPress ^^
http://www.carlabrunisarkozy.org/
Un autre, peut être moins prestigieux
http://www.lozair.net/
Je pense qu’il y a toujours un problème quand on différencie un blog d’un vrai site. Un blog EST un vrai site, qui se présente le plus souvent sous une forme rétro chronologique. Autrement dit, quand vous dites vouloir sortir du blog pour créer un vrai site, vous vous attachez plus à la forme qu’au fond, à la présentation des données qu’à leur structure.
De nombreux thèmes “magazine” ou “corporate” existent, gratuits ou à faible prix, qui peuvent vous donner des idées de présentation.
C’est une solution excellente pour les débutants, car toute mise en forme nécessite des connaissances en langage informatique.
Bonjour,
Pour la gestion des rôles sous WP il y a le plugin role-manager qui permet une gestion des droits et des rôles qui vont avec assez fine.
http://www.im-web-gefunden.de/index.html
Je dirais plutot que la différence entre Drupal et WP ce sont les vues, en effet, le module views permet de créer à peu près n’importe quelle vue dans drupal, sans se salir les mains dans le cambouis.
Voilà sinon, vraiment bon article..
Merci :)
Je trouve que la gestion des rôles dans Drupal est nettement plus poussée qu’avec Role manager, avec notamment la possibilité d’avoir des filtres de saisie par rôle, et des autorisation au niveau de chaque champs de CCK ^^
Mais encore une fois il faut en avoir le besoin…
Merci pour ce comparatif ! C’est très intéressant. J’ai testé Drupal mais je ne l’ai pas trouvé assez intuitif. Je préfère de loin WordPress.
Tu te trompes complètement @d0r1an, Je pense @d0r1an que justement tu n’as pas travaillé sur de réels projets d’envergure ni complexe pour avancer ce genre de chose comme quoi “wordpress” vaut “Drupal”.
Non En aucunes façons d’ailleurs. En terme de puissance wordpress est très modulable cèrte mais ne possède en rien toute la puissance de drupal. La courbe d’apprentissage de drupal est bien plus longue qu’un wordpress.
Drupal convient tout à fait sur des gros projets, des applications personnalisées et pas que de publication.
Drupal se rapproche d’un CMF wordpress est très loin d’en être un, et na pas du tout la même vocation.
Il y a des webagency (c’est chez eux que l’on voit ça le plus souvent) qui ne propose que des sites ou intranet sous joomla, ou bien cela va être que sous drupal ou autre.
Ne s’appuyer que sur un cms ou 2 à proposer aux clients est une réel erreurs typique de consulting à deux balles. J’ai vue souvent des internautes qui pour comparer des cms entre eux ne regardaient que la communauté, le nombre de plugins et les types de plugins.
C’est une approche d’expertise e-business très amateur. Le choix technologique ne se limite pas à ces variables.
Pour le choix d’un cms dans le milieu professionnel on doit déjà partir sur des cms bien conçus et avec une bonne base. Sorti de là on sélectionne des cms en rapport aux types de projets, taille entreprise et type client aux quels on aura à faire.
Je ne donnerais pas de liste de catégorisation de projet car cela se paye ce genre d’informations mais vous pouvez le trouver sur les livres blanc de certaines SSII par exemple et faire l’assemblage de toutes ces informations.
Cet échange s’étale sur 2 ans et je suis surpris qu’il n’y soit pas fait allusion aux améliorations qui ont forcément été apportées de part et d’autres.
Notre projet de portail local dont vous pouvez prendre connaissance sur le site indiqué est un gros projet et je m’interroge si un CMS multiposte (à terme, il pourrait y avoir de 2 à 3000 antennes locales) peut faire l’affaire.
Merci de votre transfert d’expériences.
Alain Duez.
L’article reste intéressant même en 2015, pour moi qui cherche à comprendre la différence de mécanique entre les 2 CMS, que je trouve assez proche.
J’ai utilisé wordpress 2.x pour un blog personnel il y’a quelques années face à dotclear. Puis en 2013/2014, j’ai eu quelques projets avec wordpress 3.x. En dehors de TinyMCE, j’utilise très peu de plugin, je développe tout moi même.
WordPress pour des réalisations sites vitrines reste certainement le meilleur outils à mes yeux:
– Simple et tout de suite exploitable (même par une personne lambda, parce qu’au final c’est eux les utilisateurs finaux),
– Assez souple, si on met la main à la pâte (développement PHP),
– Mise en place facile,
– La possibilité de plugin et donc d’en créer soit même (en codant),
– Ne consomme pas grand chose en ressource.
Par contre, par défaut il n’y a pas de :
– gestion des droits assez fine. Il faut forcément passer par du code pour créer d’autres profils,
– pas de multi-langue,
– pas de système de cache intégré.
Ce que j’aime:
– La structure de la base de donnée cohérente et assez souple, notamment avec les meta pour ne pas dépendre des custom fields,
– Le site de wordpress est assez fourni en information pour que l’on puisse prendre en main les méthodes,
– Pas mal de site d’information sur wordpress.
Ce que j’aime moins:
– La gestion multi-site est assez fastidieuse et l’interface admin est assez déroutante. J’aurai aimé une structure à la Concrete5 qui permet d’avoir une arborescence logique,
– C’est du one shot, la maintenance derrière est assez hasardeuse.
Pour moi WordPress 2.x ca restait un blog. Avec les évolution de la 3.x, il y’a vraiment un socle bien construit et assez modulable pour en faire à peu près ce que l’on veux. C’est parfait pour faire des sites web et du one-shot. En dehors de ce cadre, je n’utiliserai pas WordPress.
Drupal, je n’ai jamais vraiment adhérer… J’ai connu une version 5, 6 et je suis en train de tester la version 7. Et je ne comprends pas l’engouement autour de cet outil. L’idée de modules, j’aime bien. Par contre la dépendance d’un module à l’autre, j’aime moins. Ca rend difficile la maintenance. J’ignore si c’est le cas pour beaucoup de modules. Mais en installant Views, j’ai été obligé d’installer Ctools.
J’aime:
– Le fait que ca soit modulable,
– La structure des dossiers et fichiers,
– La documentation est assez fournis, on finit à peu près à trouver ce que l’on veut,
– La possibilité un thème par défaut pour la partie admin en toute indépendance du thème,
– La possibilité d’utiliser autre chose que MySQL.
J’aime moins:
– La prise en main n’est pas des plus facile et pourtant j’ai de la bouteille, il faudrait repenser la partie (UI/UX)
– L’installation complète drupal 7.39 plante, on passe plusieurs heures à comprendre pourquoi … J’ai dû passer par la version minimale.
– Il y’a un problème de login de drupal 7.39 sous Firefox. J’utilise exclusivement firefox à titre personnel et il m’a fallu un bon moment pour comprendre que cela ne fonctionne pas. J’utilise du coup Edge pour tester drupal 7.x. Je trouve cette problématique assez rédhibitoire,
– Les histoires de dépendances, ca rend compliqué la maintenance,
– les différentes versions (6.x, dev, …) ca ne facilite pas la maintenance et ca limite tout de suite les choix. Par exemple, je n’ai pas pu installer la dernière version de CKeditor manuellement ; elle n’est pas reconnue (pourtant j’ai bien dézipper sitesalllibrariesckeditor). Même en passant par “wysiwyg-7.x-2.2.zip”, cela ne fonctionne pas. J’ai du installer une version dev. Trop de contrainte de dépendance, surtout que c’est une version de dev et donc rédhibitoire en production.
Au moment où j’écris ses lignes, je n’ai passé que quelques heures avec Drupal 7.39 et les versions antérieures citées. Mon point de vue reste donc assez biaisé. Dans mon cas, je n’utiliserais probablement jamais Drupal sur un projet pro ; les plantages et les différents problèmes que j’ai rencontré, que ce soit de compatibilités ou autres ne me donne pas confiance pour déployer ca chez un client, surtout s’il y’a une TMA derrière.
Je suis très surpris qu’il ne soit pas possible de télécharger une autre version que la 7.39 ou la 6.37. Et pourquoi continuer à garder une version 6.x alors que la 7.x existe et que la version 8.x pointe du nez? Ce n’est pas une critique, mais juste une interrogation.
Certes, Drupal c’est un CMS assez modulable. C’est certainement cela qui a fait son succès par rapport à WordPress 2.x et 3.x. Mais la complexité font que parfois, je me demande si ce n’est pas plus rapide de partir de rien, en passant par un framework.
Pour du e-commerce, je partirai d’une solution comme Magento, même si je n’aime pas l’ampleur de la base.
Pour quelques choses plus userfriendly, je préfère Concrete5. Mais qui a des défauts (lenteurs, quelques bugs assez rédhibitoires, …)
Pour des problématiques spécifiques, je préfère passer par un framework. C’est plus long, plus chers, mais c’est le prix à payer pour avoir exactement ce que l’on souhaite.