Questions autour des modules

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour, je suis en train d'évaluer divers CMS par rapport à un projet. Evidemment, on ne me laisse pas beaucoup de temps pour faire les tests, et je m'y perd un peu entre les fonctions natives et les modules (fort nombreuses !).

En deux phrases, le projet c'est de monter un annuaire référençant des logiciels (pour chaque logiciel : une description courte et une longue, des mots clés, des champs personnalisés type adresse du support ou licence), avec des fonctionnalitées de communautés associées (au moins un forum par article, possibilité de signaler une erreur à l'auteur, liaisons avec des mailing-lists, etc.).

Bref, quelque chose d'assez proche de http://www.01net.com/telecharger/windows/Bureautique/calculatrice/fiches... (par exemple, même si on ne proposera pas le téléchargement), http://www.download.com/ ou http://www.framasoft.net/

Dans mon cahier des charges j'ai notamment des demandes un peu particulières (mais forcément rencontrées par d'autres) :

1. Drupal permet-il de manipuler simplement des champs supplémentaires personnalisés ? (par exemple je veux ajouter un select avec un liste de licences, ou un textarea "Avis du rédacteur" dans l'interface de rédaction de certaines sections) (Bon, là je sais que la réponse est "oui", mais je n'ai tout simplement pas trouvé d'entrées dans la doc :-/ )

2. Ces données peuvent-elles être enregistrées et manipulées dans une BDD externe ? (en effet, afin de ne pas m'enfermer dans un outil, j'aurais souhaiter pouvoir enregistrer les données ailleurs que dans la BDD Drupal

3. Est-il possible d'avoir une interface de rédaction personnalisée pour un certain type de rédacteur (ce n'est pas critique, mais je trouve frustrant de cliquer sur des liens pour se manger un "Vous n'avez pas les droits suffisants pour effectuer cette action") ?

Merci :)

Bref, connaissez-vous des sites "d'évaluations/comparaisons" (pas forcément de téléchargement, ça pourrait tres bien être des recettes de cuisine) réalisés avec Drupal (et quels modules ?)

Tout ça sachant que j'ai en gros 3 mois pour : apprendre Drupal, le skinner, le configurer, lui développer ce qui manque, et le remplir avec nos contenus existants... Je passe mon chemin ?

  1. Oui, avec le module CCK.

  2. Non. CCK crée ses propres tables dans la BDD Drupal. Cela dit, la structure de ces tables est particulièrement claire, et rien ne t'empêche d'écrire un petit script PHP qui récupère et exporte les données Drupal.

  3. C'est quoi une "interface de rédaction personnalisée" ?

  4. "3 mois pour tout faire". Si tu es à temps plein sur le projet et que tu es développeur web (maîtrise php, html...), c'est possible.

Déjà, merci de la réponse :)

  1. Je regarde CCK et le test aujourd'hui

  2. oui, ce n'est pas un reel probleme à partir du moment ou les tables sont séparées des tables natives

  3. interface de rédaction personnalisée = backend personnalisé (par exemple avec ses propres menus, css, champs de rédaction de contenus, etc.) en fonction des permissions utilisateurs.

  4. oui, je serai à temps plein (enfin, on sait ce que sait ;) ), et je suis développeur web.

Merci encore pour les réponses efficaces et rapides (forcément, ça rassure et motive à retenir Drupal)

Tu veux dire en terme d'outils ?

J'ai fait une (tres) rapide évaluation des outils suivants :
Drupal
e107
eZpublish
Jaws
Joomla
Lodel
MODx
SPIP
Textpattern
Tiki CMS
Typo3
Xaraya
Xoops

Evidemment, l'évaluation s'est faite par rapport à l'analyse de nos besoins et de nos contraintes (notamment des délais tres serrés).

J'ai en gros identifié 4 grandes catégories de CMS ("institutionnels", "communautaires", "éditoriaux" et "framework"). Evidemment la plupart des CMS se retrouvent dans plusieurs, voire chaque catégories.

Aujourd'hui, par rapport à notre besoin, il reste en lice :
Drupal, SPIP, Typo3 et MODx.

L'avantage et l'inconvénient de Drupal, c'est son positionnement à mi-chemin entre CMS et CMF. Ce qui signifie une courbe d'apprentissage relativement élevée.

Je pense éliminer Typo3 car je crains de ne pas avoir le temps de passer un mois à apprendre le typoscript. Mais ça sera peut être un risque à prendre.
MODx est un mon avis (no troll), le CMF avec le plus fort potentiel, mais il est encore un peu jeune et va beaucoup changer cette année (xPDO inside). Pourtant, le systeme chunks/snippets est assez fabuleux.

Donc resterait SPIP et Drupal.
Ne hurlez pas, merci ! :) Il se trouve que je connais assez bien SPIP (en tant qu'admin de framasoft.net) et que je suis donc directement operationnel dessus. Et que la version 1.9 permet, avec les plugins, de contourner énormément des limitations initiales de cet outils (qui dispose du meilleur support francophone que j'ai pu trouver. Ce qui ne remet absolument pas en cause celui de Drupal !)

Drupal, je vais donc me plonger dedans pendant les heures qui viennent. Notamment CCK et workflow.
Il y a plein de "petits détails" qui ne conviennent pas dans Drupal, et qu'il me faut donc mieux identifier afin de savoir si il s'agit de choix de configuration "malheureux" ou de limitations intrinsèques (un exemple ? ma réponse à ce message ne montre que le message précédent - de Dramator - et non tout le thread. C'est probablement modifiable, mais il me faut "tirer la pelote de laine" et voir où et comment).

Par contre, Drupal a tout de même de serieux atouts. Une doc claire (mais assez peu fournie par rapport à l'outil à mon avis). Une communauté francophone active et relativement bien identifiée. Des exemples fournis (snippets), un templating bien foutu, code et execution légères, etc.

A la limite, côté francophone il manquerait qq points d'entrées (que je n'ai pas su trouver) :
- la logique globale de drupal (les concepts, pas les fonctionnalités) qui le différencie des autres : CMF, API, node, etc)
- mise en valeur des 3 ou 4 extensions qui font de Drupal un outil encore plus puissants : CCK, Views, Action, Taxonomy ?
- une traduction du post d'Eaton : http://drupal.org/node/34421 . Dire la vérité crue aux (futurs) utilisateurs permettent de développer la confiance et leur future implication.

Ce n'est pas un reproche, évidemment, juste une opinion d'un oeil exterieur.

Keep up the good work et désolé pour la taille de la réponse (mais c'était ma façon a moi de dire merci)

Merci pour tout ses détailles, il est vrai que SPIP et MODx sont les deux seul en course au coté de Drupal.

J'avoue ne pas aimé SPIP et trouver MODx pas assez fini par rapport à Drupal (ce qui m'a fait choisir Drupal)

Pour les détailles, effectivement, toi visiblement tu as une expérience pour les projets de longues durées (merci pour framasoft), donc évidement, tu te dois d'être assez pointilleux sur tes attentes.

Pourquoi ne pas continué avec SPIP (étant donné que tu as déjà une expérience assez positive avec?),
même si je pense que Drupal est plus simple et est fonctionnel plus rapidement par rapport à SPIP...
(pour une réponse rapide à un des détailles que tu expliques, je pense qu'en mettant le formulaire de réponse en bas des commentaires suffit à palier)

Pourquoi ne pas continué avec SPIP (étant donné que tu as déjà une expérience assez positive avec?)
Parce que je suis payé pour être un minimum objectif ;)
Et parce que mon expérience dans framasoft est bénévole et, comme tu le précise, sur le long terme.

Là, mon employeur (un labo du CNRS), a un besoin relativement précis (et complexe), mais surtout la volonté de ne pas passer 6 mois en pré-prod. Donc à moi de faire le tour de ce qui existe et, par rapport à nos besoins, de lui présenter un tour d'horizon des différents outils avec un maximum d'objectivité et de réalisme.

  1. Désolé, mais je comprends toujours pas la question. Interface personnalisée par rapport à quoi ?

Déjà, sur Drupal, il n'y a pas vraiment de distinction entre back et front office (en gros, les contenus sont éditables depuis le front office).

Pour ce qui est de l'interface d'admin (url commençant par admin/xx), les rubriques qu'on y trouve dépendent des permissions de l'utilisateur connecté. C'est donc bien "personnalisé" en fonction des droits.

(désolé, cross-post avec ma réponse à dramator, j'avais pas vu ta réponse)

Déjà, sur Drupal, il n'y a pas vraiment de distinction entre back et front office (en gros, les contenus sont éditables depuis le front office).

Pour ce qui est de l'interface d'admin (url commençant par admin/xx), les rubriques qu'on y trouve dépendent des permissions de l'utilisateur connecté. C'est donc bien "personnalisé" en fonction des droits.

Ca répond parfaitement à ma question :)