Drupal est un système de gestion de contenu (CMS) vanté entre autres pour sa souplesse, sa modularité et sa gestion fine des utilisateurs. Dernièrement ce sont ainsi les sites de l'APRIL, d'Ubuntu-fr et bientôt de Framasoft qui ont migré vers Drupal.
Dries Buytaert nous raconte l'origine du projet, son nom et ses évolutions successives qui l'ont amené à être aujourd'hui l'un des CMS les plus utilisés. Il nous explique également pourquoi il a récemment créé la société Acquia qui voudrait être pour Drupal ce que Red Hat ou Canonical sont pour GNU/Linux.
Aller plus loin
- Drupal’s Creator Envisions Web Publishing’s Plug-and-Play Future (3 clics)
- La traduction de l'entretien sur le Framablog (10 clics)
- Le site officiel de Drupal (0 clic)
- DLFP : Drupal 6 est sorti (0 clic)
# Rien ne l'arrête
Posté par Nerdiland de Fesseps . Évalué à 3.
J'y vois tout de même 2 principaux défauts, qui sont le manque de gestion et d'intégration des éditeurs WYSIWYG (que beaucoup d'autres CMS font très bien), et quelques faiblesses dans la gestion de contenu fortement structuré et hiérarchisé (le prix à payer pour la flexibilité.)
Pour avoir tâté du SPIP, du Joomla, du eZ Publish ou encore du SilverStripe, aucun n'arrive au même niveau de qualité. Donc merci au Framablog et vivement Drupal 7 :-)
[^] # Re: Rien ne l'arrête
Posté par mosfet . Évalué à 3.
Est ce que l'on sait si Drupal a plus d'utilisateurs que Joomla, en ce qui concerne la sécurité quel est le plus sur ...
[^] # Re: Rien ne l'arrête
Posté par Cyprien (site web personnel) . Évalué à 4.
- Drupal a moins d'utilisateurs que Joomla
- Au niveau de la sécurité, les failles sont corrigées lorsqu'elles sont découvertes. Il est assez facile de mettre à jour un site Drupal si on l'a bien développé (cad, sans toucher à d'autres fichiers que ceux de sites)
Je te conseille d'essayer : http://www.atelierdrupal.net/demarrage
http://drupalfr.org/documentation
[^] # Re: Rien ne l'arrête
Posté par mosfet . Évalué à 2.
En particulier j'ai plein de projets en attente autour de tout ce qui est plateforme mobile et j'ai vu récemment sur linuxfr que la plateforme de gestion de projet Coding Team etait sorti et par conséquent j'aimerais l'integrer.
En plus il me faudrait un webmail avec si possible une intégration dans le CMS.
Enfin j'aime bien écrire des articles dans lequel il y a du code source et donc il me faut un formateur de code source.
Pour le moment ma première tentative avec joomla a donné ca :
www.smartmobili.com mais je ne suis pas satisfait et je me demande si je passe à Joomla 1.5 ou Drupal 6.8.
[^] # Re: Rien ne l'arrête
Posté par Nerdiland de Fesseps . Évalué à 2.
Drupal et Joomla ont tout deux des communautés importantes et des modules en pagaille, mais Drupal a tendance à être plus populaire chez ceux qui aiment bien bidouiller. On peut l'utiliser comme framework, qui a la réputation d'être l'un des plus plaisants.
[^] # Re: Rien ne l'arrête
Posté par Ludo . Évalué à 1.
De ce que j'avais testé de Drupal, la base sentait plus le "propre".
[^] # Re: Rien ne l'arrête
Posté par Nicolas Deveaud . Évalué à 1.
Dans l'optique de créer un site techniquement de bonne qualité, respectant donc les formats utilisés, et principalement le HTML, il est impossible d'intégrer un système d'édition WYSIWYG, qui par essence ne colle pas avec l'édition HTML :
le HTML n'a pas vocation à faire de la mise en page, mais surtout de la sémantique (donner un sens au document). Le CSS appliqué dessus, lui, se charge de la mise en page. Le WYSIWYG oublie cet aspect sémantique du HTML, et abouti donc automatiquement à une dégradation de la qualité des documents obtenu.
Il existerait une solution, qui serait d'opter non pas pour un éditeur WYSIWYG mais pour un éditeur WYSIWYM.
Malheureusement il n'existe actuellement à ma connaissance qu'un seul éditeur WYSIWYM, WymEditor, qui n'est pas encore sorti en version stable (actuellement en beta).
Il est donc tout à fait compréhensible que le projet Drupal n'intègre pas d'éditeur jusqu'à présent. Il me semble que SPIP à fait un choix équivalent, en ne proposant qu'une interface simpliste basé sur une syntaxe wiki (non WYSIWYG donc).
Espérons que lorsque WymEditor aura atteint une maturité suffisante Drupal proposera cet éditeur très prometteur (sous forme d'un module, autant laisser la base simple sans éditeur).
Et espérons que le WYSIWYM va se développer, et qu'on verra un jour des logiciel d'édition HTML exploitant ce concept apparaître.
[^] # Re: Rien ne l'arrête
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Étrangement, c'est ce que je me disais aussi avant de toucher (sous la pression d'un client) à eZ Publish (4.0). Depuis, je n'ai plus aucune envie de revenir à Drupal. Je m'explique.
J'avais choisi Drupal car (1) il me semblait le plus proche de mes propres choix techniques — traduc' avec gettext, AJAX avec jQuery, gabarits en pur PHP, et (2) car il avait une communauté impressionnante et un nombre de modules tout aussi impressionnant. Cela me semblait le mieux pour me permettre de réaliser les demandes de mes clients au plus vite. Hélas, le passage de la théorie à la pratique fut plutôt difficile.
Tout d'abord, les modules : oui, il y en a beaucoup, mais une bonne partie ne fonctionnent pas avec la dernière version (je ne voulais pas de la 5.x). Je me suis donc trouvé limité dans mes choix. Il y a aussi beaucoup de modules qui procurent des fonctionnalités équivalentes (gestion d'images, par exemple) sans qu'un module-phare se démarque. On se retrouve donc à tester (ça prend du temps) et à faire un choix entre des modules qui ont des avantages et des défauts (pour reprendre l'exemple des images, certains modules les gèrent comme des nœuds Drupal, mais ne permettent pas de les positionner comme on veut dans le document, d'autres le permettent, mais elles sont alors considérées comme des simples fichiers dissociés de la gestion de contenu. Aucune de ces solutions n'est satisfaisante). L'intégration entre modules pèche un peu aussi (par exemple l'intégration entre les gestionnaires d'images et les éditeurs WYSIWYG). C'est un joyeux bordel, et même avec des sites comme [http://drupalmodules.com/] on ne s' y retrouve pas des masses.
L'autre gros point noir à mon sens est la personnalisation. Vous allez me dire : comment ça ? Il y a des CSS, des gabarits, des /callbacks/ pour chaque thème, c'est très personnalisable ! Eh ben, pas vraiment. Tout d'abord, le choix a été fait d'envoyer aux gabarits des variables contenant du code HTML préalablement généré. Il aurait été à mon sens beaucoup plus efficace d'envoyer aux gabarits des tableaux associatifs PHP avec les contenus bruts, et laisser la génération du HTML dans ces derniers. Faute de cela, on se retrouve à aller bidouiller son fichier template.php et rajouter /callback/ sur /callback/ pour faire correspondre l'affichage à ce que l'on souhaite. C'est compliqué, et peu intuitif.
Il y a aussi le cas où les informations que l'on veut ne sont tout simplement pas fournies. Un exemple simple : je voulais un bloc affichant les autres pages ayant le même terme de taxonomie. Il a fallu pour cela utiliser le module Views, et fabriquer une vue compliquée avec du code PHP (et je n'ai toujours pas trouvé comment éliminer de la liste la page courante !), modifier les paramètres du bloc lié à la vue pour définir où il s'affichait, etc. De la même manière, avoir un ordre d'affichage personnalisé des contenus dans une catégorie nécessite un module spécial (nodeorder) qui remplace les pages de taxonomie (j'ai mis un bout de temps à comprendre que les liens créés via Pathauto pointaient toujours vers le module standard). Certains modules, aussi, n'ont pas de /callbacks/ pour appliquer un thème. J'ai souvenir d'avoir dû créer une copie du module Blog pour lui rajouter les /callbacks/ dont j'avais besoin. Au final, cela demande beaucoup de travail et l'utilisation de systèmes disparates pour arriver à ses fins.
Et j'en viens donc à eZ Publish. Au départ, je n'en voulais pas parce que (1) c'était moins communautaire, et (2) cela semblait être une grosse usine à gaz. Ayant dû m'y mettre, je constate que, si c'est *bien* une usine à gaz (avec un particulier un langage de gabarit à la Smarty absolument inutile et énervant, ainsi qu'un nombre incalculable de fichiers de configuration), il a des atouts importants pour un intégrateur de sites.
La souplesse de modification, d'abord. Tout (ou presque) se passe dans les gabarits. Les données brutes sont accessibles au langage de gabarit, et on peut récupérer (via l'opérateur fetch) du contenu supplémentaire à peu près sans limites. Certes, cela enlève un peu à mon sens la séparation nette entre la logique métier et la logique de présentation, mais je préfère cent fois cela à devoir /forker/ un module Drupal pour arriver au même résultat (en particulier lorsque le client veut la modif' pour avant-hier :-) L'architecture globale est par ailleurs bien plus propre à mon sens, avec une orientation objet très prononcée, et cela rend l'écriture d'extensions (si le besoin s'en fait sentir) plus agréable.
Le principe de classes de documents dynamiques est aussi très bon. La classe d'article standard ne vous plaît pas parce qu'il vous faut un « châpo » et une note pour les tests ? Quelques clics plus tard vous avez les attributs nécessaires dedans, et ils sont accessibles dans les gabarits pour être affichés comme on le souhaite. Vous avez besoin de rajouter des encadrés ? Déclarez la classe comme conteneur, et créez des éléments fils avec une classe spécifique, puis faites le fetch qui va bien dans le gabarit. Les formulaires sont pareillement plutôt aisés à créer (il faut néanmoins modifier des fichiers ini, hélas) et les images, fichiers, vidéos, etc. sont gérés comme des documents standard, avec gestion des versions, liens dynamiques, etc. à la clé.
Enfin, j'ai apprécié l'idée de stocker les textes dans du XML. Ceci permet d'empêcher l'utilisateur de faire n'importe quoi avec la charte graphique (je vous dis pas le plaisir que ça fait de voir l'esthétique de votre site flanquée en l'air par un ahuri amateur de Comic Sans MS) tout en lui laissant une certaine flexibilité par le biais de balises personnalisées dont vous pouvez décider l'apparence par un gabarit /ad hoc/. Depuis quelque temps, l'éditeur XML utilisé est basé sur TinyMCE ; l'ergonomie est donc tout à fait acceptable (personnellement, j'aurais bien sûr préferé un WYMeditor, mais pour l'avoir testé, je pense pouvoir dire qu'il est loin d'être mûr pour une utilisation en production).
En conclusion, le choix du CMS dépend bien entendu de l'approche de chacun (certains préfèreront peut-être même un SPIP pour sa simplicité) mais si votre but est d'avoir la plus grande flexibilité pour vos développements, je vous suggère de jeter un œil à eZ Publish. En revanche, n'espérez pas pouvoir l'appréhender en quelques instants : à l'instar de Drupal, sa courbe d'apprentissage est plutôt rude, et la documentation ne donne pas toutes les infos utiles, loin s'en faut. Google vous sera un ami *très* précieux dans cette aventure...
Quelques liens rapides pour terminer (pardonnez-moi au passage pour la longueur inconsidérée de ce message et ses passages très « 3615 MAVIE ») :
- La doc officielle [http://ez.no/doc/]
- L'ancienne doc, plus maintenue, mais parfois plus explicite que le /Technical Manual/ : [http://ez.no/ezpublish/documentation/toc]
- Un wiki avec des infos intéressantes : [http://ezpedia.org/wiki/en/ez]
- Le blog de Pwet : [http://pwet.fr/tags/keywords/weblog/ez_publish]
- Un autre blog qui m'a été utile : [http://serwatka.net/blog/]
Bonne découverte.
Envoyé depuis mon PDP 11/70
[^] # Re: Rien ne l'arrête
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Erratum : je m'aperçois que je n'ai pas été très clair. En fait, depuis quelques temps , il est possible de remplacer l'éditeur intégré par un autre basé sur TinyMCE. La version 4.1 devrait intégrer par défaut ce nouvel éditeur. Désolé pour la confusion.
Envoyé depuis mon PDP 11/70
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.