Bonjour,

je trouve le débat intéressant, mais il aurait été d'autant plus intéressant de proposer d'autres schémas pour appuyer ces arguments. Car en effet, quand on parle de hiérarchisation, on s'imagine tout de suite ce que ça implique, mais quels seraient en terme d'exemples, les autres façons d'organiser le contenu ?

Dans ta conclusion, tu finis par poser la question : mais "comment puis-je organiser mon information autrement qu'en hiérarchie ?"
Mais si on a jamais fait autrement, on peut se poser la question longtemps .... Des exemples de réalisations, avec quelques explications autour auraient été les bienvenues je pense !

"Qui annule en bonne partie la dimension modulaire de Drupal (tout en continuant de dépendre de multiples briques dont on ne sais pas très bien dans quel sens elles vont partir)."

Bin ça dépend comment tu conçois le probleme :

- si par exemple un module de boutique en ligne utilise une vue par défaut pour afficher ses produits, ça te donne le pouvoir de la modifier donc de customiser ton site grace à la modularité de Drupal. Mais ça implique que la vue soit dans le code du module (ou dans une features).

- en revanche si ce même module de boutique en ligne n'utilise pas views du code php en dur, tu ne pourras rien faire, aucun customisation possible (sauf si tu es dev et que tu as des hooks bien implémentés à disposition).

Donc à mon sens ça offre une souplesse plus grande. Evidemment si tu veux personnaliser ta solution, tu fais plus ou moins un fork de la distrib mais c'est inévitable si tu veux concevoir un produit unique... Donc y'a un moment où il faudra faire les mises à jour des modules mais plus la mise à jour de la distrib (comme sur un drupal normal), ça constitue juste un super point de départ :-)

merci pour le compte-rendu.
Les problemes que tu évoques me rappelent ceux que j'ai rencontré avec open atrium : ne pas trop savoir ce qu'on peut overrider ou pas, features qui rajoute une couche de plomb par dessus le bouzin qui fait qu'on n'est plus aussi libre de le customiser qu'un drupal classique (ou du moins on hésite à mettre les mains dedans ! ).

En théorie avec features tu peux
- modifier tout ce que tu veux comme normalement. Simplement les éléments apparaitron comme "overridés", c'est à dire différents de la version de la configuration qu'il y a dans le code.
Si tu mets ensuite à jour ta distribution, tes modifications seront toujours prises en compte MAIS les modifications apportés sur la distribution, elles, tu risques de ne pas les voir ! Peut être qu'ils ont modifiés des vues, des champs CCKs, or si tu as tout overridé, tu ne le sauras jamais :-/
(sauf à faire un gros drush features-revert-all -force avec drush pour revenir à LEUR version, ce qui implique évidemment que tu perds alors tes customisations à toi. )

bref, une fois que tu commences à overrider des trucs, c'est tout à fait comme si tu faisais un fork car tu te désolidarises du code initial pour créer ta propre configuration.

C'est à la fois l'avantage et l'inconvénient d'utiliser features (ou autre solution à base d'exportables)
1) tu peux modifier à volonté tout un tas de choses vu que ce sont des vues et des champs CCK, etc... Tu ne pourrais pas faire ça avec un module qui fait tout en php, en interne.
2) mais dès que tu touches ça, tu ne profiteras plus des mises à jours des vues etc... qu'apporteront les prochaines versions pour les éléments que tu auras overridé

Strongarm est un sujet plus épineux : il verrouille carrément certain trucs en t'interdisant de les changer car un module a besoin d'un réglage précis pour fonctionner, il t'interdit donc de le modifier.

Hélas, que ce soit features ou une autre solution le probleme serait le même : si on te donne des vues par défaut, des champs CCK etc..., oui tu peux les customiser mais tout override fais que tu crée un espece de "fork" de la distribution.

Je lis tes billets depuis un certain temps et je les trouve toujours intéressants. Merci pour ton travail...
Pour suivre l'évolution du développement de Drupal 7 depuis 6 mois et avoir vécu celui de Drupal 6, je pense réellement que l'initiative D7CX a fait beaucoup de bien. Beaucoup de modules sont portés sous Drupal et pas des moindres. Si ils sont encore en version de développement, je trouve cela normal étant donné que le coeur de Drupal lui-même est toujours version alpha !
J'aimerais rappeler que 6 mois après sa sortie, Views était lui toujours en alpha, Ubercart aussi, et je passe sur imagecache, filefield, éditeurs de texte, etc.
Je pense qu'il y a une autre différence entre la V6 et la V7 : c'est que Drupal 7 va maintenant être utilisable sans l'ajout quasi-obligatoire de 10 ou 15 modules car il sont maintenant intégrés.
Bon tout ca pour dire que j'ai bon espoir que la sortie de Drupal 7 soit un véritable évènement...
Voilà, c'était mes remarques, bonne continuation !

Marie-Hélène, tu as tous mes encouragements pour poursuivre ton site qui a le mérite d'exister.
C'est vrai qu'au vue du nombre de modules existants, il va être compliqué de tous les répertorier et les classer, mais comme on dit "Paris ne s'est pas construit en 1 jour". J'essaierais de contribuer un peu plus car tu es toujours là pour aider les autres sur le forum, il n'y a pas de raisons qu'on ne te retourne pas l'ascenseur.

A mon avis, le site drupalfr.org est mal conçu c'est pourquoi il y a tant de blogs à côté, d'ailleurs je devrais sortir le mien dans quelques temps, ce serait plus, un retour d'expérience, une sorte de trucs & astuces faces aux différents problèmes que j'ai rencontré depuis que j'ai découvert Drupal il y a presque 1 an.

Côté modules, là aussi drupal.org pêche par son moteur de recherche peut efficace. Mais comme je le disais plus haut, il faut du temps au temps pour que les choses se fassent.

En ce qui concerne Drupal 7, la transition des modules risque effectivement d'être longue, si en plus il faut totalement réécrire les modules, ça risque d'être compliqué car pour maîtriser l'API il faut beaucoup de temps.

Quoi qu'il en soit, Drupal est génial et mérite vraiment de poursuivre son ascension malgré les obstacles qui se dressent.

Penser aussi la communauté et des cycle d'investissement.

Je pense qu'il faut nous mettre en réseau.

Je vais proposer quelque chose par rapport à ça.

Nous en avions déjà parlé, mais ça a progressé. On en reparle mardi soir ?

Sur ton interrogation de positionnement de blog. Ensuite il faudrait que je réfléchisse un peu plus précisément pour te donner un point de vue personnel. A propos as tu Google Analytic ?

Jean-Baptiste

PS En fait tu nous l'a pas annoncé, mais tu avait été promue en début d'année :)

merci !

A LA UNE
Suite à ta révélation (fracassante !) : sache que le Diocèse de Grenoble-Vienne choisit la voie du CMS pour permettre à son personnel, prêtres et bénévoles d'échanger des documents religieux. Ainsi le Diocèse grenoblois a refondu ses sites Web et mis en place un outil ECM. Coût du projet : 115 000 euros. Ambitieux !
Lu sur Le JournalduNet (06 mai).
http://www.journaldunet.com/solutions/intranet-extranet/diocese-de-greno...

Merci pour ce bon résumé de la situation à J - 2 month.
En ce qui me concerne, grosse impatience au sujet de RDF, je commence tout juste à comprendre le concept ^^

Je plussoie le relativement simple, pas de souci, pas taper :) Effectivement le pb du mot de passe peut être épineux, je ne me suis carrément pas posé la question.

J'en ai parlé sur le forum Drupalfr, sur un post où quelqu'un posait la question qui fâche (comment migrer de SPIP à Drupal).

Et aussi sur le site, mais je n'ai pas (encore) fini de tout reclasser : http://www.missmopi.net/migration-du-monde-de-miss-mopi-vers-drupal-ca-c...

En fait j'ai fait un squelette SPIP pour chacun de mes "types" de contenus dont le résultat était... un tableur retravaillé pour générer des requêtes SQL permettant de renseigner directement la base de données de Drupal.

Par contre c'est tellement tordu, que je ne sais pas donner plus d'informations. Ça a tellement dépendu de mes contenus de bases, de mes contenus de destination, de tout plein de bidouille au milieu et d'une sacrément bonne connaissance des mécanismes de base de données de Drupal (que j'ai décortiqué dans tous les sens pour en comprendre la logique) que je n'ai pas réussi à écrire une explication qui me paraisse claire ou exhaustive.

Le plus dur pour moi qui suis plus bidouilleuse que développeuse (mais chut faut pas le répéter) était de trouver comment recréer des contenus Drupal sans passer par les API, car si je connais suffisamment de SQL pour être capable de jouer avec une base de données, je ne connais pas (encore?) suffisamment de PHP pour programmer directement Drupal par ses API. D'où l'analyse de la base de données pour recréer exactement les contenus comme si je les avais saisi.

Après sous SPIP tout le paramétrage se fait dans le squelette en fonction des rubriques, alors que dans Drupal j'ai créé des types de contenus ou pris les contenus de base. Donc une moulinette différente en fonction des sections du site, de si c'était une rubrique ou un article, etc...

Et au final une fois les contenus créés j'ai recréé tous les liens entre eux.

Par contre les commentaires, c'est pratiquement à la main que je les ai repris (un comm reprenant tous les comms de l'ancienne version par article).

Je n'ai pas pour moi fini la migration. La logique de classement dépend encore trop de ce que j'avais fait sous SPIP (ou sous Dotclear, mais là j'ai récupéré un module qui le faisais la migration fut moins douloureuse). D'où la difficulté pour retrouver certains éléments encore...

J'avance, je corrige, je peaufine...

Merci pour l'accueil!