davidm

Je pense que Kent (ainsi que 95% des lecteurs de ce forum) sont au courant de l'existence de Joomla, qui est un CMS open source des plus ancien (enfin, si on considère que Joomla c'est la continuité de Mambo). Evidemment il est possible de construire un réseau social avec Joomla, tout comme c'est possible avec un bon nombre de CMS (Typolight, CMS Made Simple, Drupal pour ne citer qu'eux...). En effet tout dépend ce qu'on entend par réseau social, le concept est vaste et peut recouvrir de nombreuses réalités. Mais alors allez vous me dire qu'est-ce qui distingue une "banale" communauté d'un réseau social, un CMS type portail (Joomla, Drupal...) et un outil de réseau social (Elgg, AroundMe) ? A mon avis, deux choses : 1) la gestion des relations entre les membres : C'est en ce sens qu'un CMS comme Elgg apporte un plus à un CMS type portail : il est conçu pour gérer les relations entre membres, permettre l'affichage de contenus d'autres membres de son propre réseau, de gérer les invitations, les autorisations d'une manière un peu spécifique (i.e qui dépend des relations avec d'autres membres).... chose qui sont possibles avec un CMS traditionnel mais au prix d'un temps de développement supplémentaire et/ou d'une administration plus lourde. 2) L'approche minimaliste : C'est très "web 2.0", les outils de réseaux sociaux ont une approche minimaliste dans le sens où on évite le syndrôme de l'usine à gaz. Ca ne veut pas dire qu'il y a peu de fonctionnalités simplement que leur implémentation va à l'essentiel pour éviter d'alourdir les interfaces que ce soit côté admin ou utilisateur. C'est la tendance et je suis certain qu'elle va se confirmer de plus en plus. A mon sens les outils de réseau sociaux ne sont ni plus ni moins qu'un degré qualitatif additionnel par rapport à la communauté "traditionnelle" animée par un portail : une interface plus simple et une gestion des relations entre utilisateurs. Les fonctionnalités restent les mêmes (forum, blog, galeries, fil rss...) mais mises en oeuvre différemment. On se cherche, car ces outils ne sont pas parfaits, mais ils ont le mérite de mettre un terme à la "course aux armement" en terme de fonctionnalités toujours plus poussées sans être forcémment pensée en rapport à un besoin. On a subi le même phénomène à l'époque de la folie du Flash ou le site qui en jette le plus est le "meilleur" alors qu'il n'y a pas de meilleur dans l'absolu un site internet n'est pas un seulement showcase mais un lien avec un utilisateur, un client, un adhérent... la vague des standards du web a offert une alternative à cette conception des sites web en montrant que simple peut être à la fois beau et efficace - et c'était pour le mieux à mon avis ! La vague web 2.0 si elle est critiquée, à le mérite de remettre l'utilisateur au centre de la conception : il n'est plus spectateur passif qui fait "wouah" quand il voit des choses animées, mais il est utilisateur d'un outil qui facilite la recherche d'information, la mise en relation. Désolé pour cette dérive mais je pense qu'aujourd'hui si on veut vraiment construire un réseau social et non une communauté, il faut choisir l'outil le plus adapté et ce n'est peut-être pas Joomla, Drupal, MODx, CMS Made Simple et j'en oublie car on ne peut pas tous les citer...

Ellg n'est pas une solution si jeune que ça, dans le sens où ça fait bien 2/3 ans qu'elle est développée... personnellement je m'intéresserai plus à la possibilité d'étendre l'application (qualité de la documentation de l'API, de l'API elle-même et vitalité de la communauté) qu'à l'existence d'une foule de plugins en général rigides (Dolphin est un bon exemple). Evidemment Elgg 1.0 est une ré-écriture de l'appli donc les plugins vont mettre quelques mois à s'étoffer mais l'essentiel est là... Donc oui je me lancerai avec Elgg, ou alors j'embaucherai un dév pour coder ça à partir d'un framework type Django, CodeIgniter, CakePHP... Pour le test en local, vérifie ta config car si ton environnement de test est bien configuré, tu dois pouvoir recevoir les emails de confirmation ! Si tu as un problème j'imagine que tu es sous Windows car sous Mac ça fonctionne et sous Linux pourvu que tu ai php avec sendmail ça devrait marcher aussi... Pour ODD voir le site officiel : http://www.opendd.net/ L'import export est possible si les plateformes concernées ont adopté ce standard ouvert... pour Dolphin à vérifier !

Aucune idée mais s'il y a un copyright, c'est que la licence doit t'obliger à le conserver, non ? Sinon une simple recherche dans les fichiers devrait te permettre de savoir où il est... de toute évidence soit tu contactes les auteurs pour obtenir la permission, soit tu t'assures que tu as le droit de le faire.

Oui c'est le moins qu'on puisse dire ! Dolphin est un paquebot, bien marketé mais un paquebot quand même... Si je devais créer un réseau social, je m'appuierai sur Elgg surtout qu'avec la version 1.0 c'est vraiment pas mal du tout ! Par contre l'approche est très "web 2.0" : l'essentiel est assuré par un core light et les plugins sont là pour mettre en oeuvre les fonctionnalités, en plus on a le support d'ODD pour l'import export des données en provenance d'autres plateformes.

A chacun sa solution effectivement je suis le premier à dire qu'il faut partir du besoin inutile de prendre une bombe atomtique pour tuer un moustique Par contre, je ne suis pas très favorable au wiki pour gérer un site corporate... le gros bénéfice du CMS c'est quand même de séparer contenu et présentation (évolutivité du design et maintenance des contenus facilitées) et d'automatiser l'affichage des contenus en fonction d'une structure définie avec le client, via les templates. Par exemple, le client ne saisi que les données concernant un produit (dont les champs sont défini au départ avec lui, tout en restant évolutifs), et c'est le template qui va assurer la cohérence de mise en forme des fiches produits, les données étant stockées séparémment des aspects de présentation. Sinon on retombe dans la problématique du site statique ou contenu et présentation sont mélangés et là on risque : - des incohérences dans la mise en forme - des style "en ligne" au lieu d'être dans des CSS - un gros boulot lors des changements de designs. - etc... Enfin pour ce qui est d'adapter l'outil au besoin, c'est tout à fait pertinent mais cela suppose aussi qu'on détecte les besoins implicites du client (qui ne sont pas forcémment évident à identifier, même lorsqu'on est compétent). Sans compter que la structure du client elle-même peut évoluer dans le temps et ses besoins avec ! Plus qu'un outil qui fait tout je priviligerai plus la flexibilité de l'outil pour laisser les portes ouvertes... "qui peut plus, peut le moins"

Effectivement on est sur des questions très pointues là et en général, mieux vaut poster sur les forums des CMS concernés...

Smile est en effet un expert reconnu dans le monde des CMS open source et le livre blanc est intéressant même s'il ne suffit pas pour choisir - rien ne vaut quelqu'un qui a l'expérience en face de soi pour discuter d'un projet La modif de l'admin est rarement prévue effectivement, ceci dit concrètement cela va avoir un intérêt réel que dans quelques cas : - branding : tu veux que le CMS soit aux couleurs de ta société en tant que prestataire - personnalisation : aux couleurs de l'entreprise, une demande souvent limitée aux grandes boîtes - accessibilité : tu veux une version accessible, une version mobile, etc... Pour vraiment modifier le backend librement le mieux c'est d'avoir à la fois le contrôle des templates (ça MODx Evolution le fait déjà par exemple) mais mieux accès à une bibliothèque de fonctions bien documentée qui permet de construire une interface réellement personnalisée (pas seulement au niveau du look mais du comportement de l'interface : MODx Revolution offre ce type de possiblité). Je ne sais pas où en est Drupal sur ce sujet depuis la version 6... Côté Joomla, CMSMS et autres je n'ai pas encore regardé...

Vu les besoins affichés, je me tournerai plutôt vers un CMS "pré-packagé" type "portail"... chacun connaît mon aversion pour Joomla! et autres Nuke-like donc je ne le conseillerai pas mais Drupal, CMS Made Simple ou (c'est mon choix du moment) Typolight semblent de très bon candidats

La nouvelle version est très supérieure à mon avis... tu me diras !

Cela faisait quelques temps que l'équipe de dév faisait du teasing sur la version 1.0 de Elgg, notamment de manière hyper active sur Twitter, mais ça y est depuis quelques jours la fameuse version 1.0 est sortie ! (Screenshots ici : http://elgg.org/screenshots.php ) Il faut dire que les plateformes opensource permettant de construire des réseaux sociaux ne sont pas nombreuses et souffrent souvent soit d'une certaine lourdeur à tout vouloir faire (Dolphin) soit d'une communauté trop faible et d'un développement eratique (AroundMe). Elgg a su progresser au fil des années, mais là on part sur une nouvel base de code fondée sur MVC avec un core light, une API qui semble bien pensée (avec notamment prise en compte de ODD, qui permet d'importer les données d'autres réseaux sociaux ou l'export au sein d'autres réseaux) et un système de plugin simple et efficace. Après un petit tour du propriétaire et pour avoir suivi les version depuis la 0.7 je dois dire que la première impressions est très bonne : les fonctionnalités principales sont là et gérées chacune par un plugin, et l'implémentation est simple et efficace. Reste à voir dans un environnement de production comment la bête tient la charge, quelle est la sécurité de l'appli, la fiabilité des plugins... etc. Côté templating petite déception ça reste fragmenté, un système d'includes avec un grand nombre de fichier... ça risque d'être moyen au niveau créa / maintenance, à voir...

Merci pour toutes ces précisions Jean-Pierre, c'est vraiment très détaillé et ça donne une bonne idée sur la manière dont on peut bosser avec Typolight. Je suis persuadé que celui-ci va faire de nombreux adeptes ! Chaque outil a ses spécificités, comme tu le dis bien, et son utilité auprès de tel ou tel public pour tel ou tel projet... on ne peut jamais parler dans l'absolu même si dans le cas de typolight on peut déjà dire qu'au niveau de la mise en oeuvre de formulaires ou de contenus liés à des champs custom ça a l'air d'être le système le plus simple qui existe. Il me reste à approfondir le templating et vraiment m'y plonger plus avant mais dans une logique différente de MODx, Typolight est une option intéressante...

La plupart des scripts d'annonces (à vérifier car ça fait plusieurs mois que je n'ai pas analysé ce segment) même open source sont payants mais certain éditeurs proposent une version lite gratuite comme Geo : http://geodesicsolutions.com/products/clas...ifieds_lite.htm mais à voir ce que cela vaut en terme de templating, de code... La vaste majorité des scripts sont payants. Maintenant, tout dépend de ce que tu as besoin de faire mais tu peux aussi opter pour un CMS généraliste et installer une extension qui gère cet aspect (j'imagine que Drupal, Joomla ou même CMS Made Simple ont ce type d'extension), ou alors développer la fonctionnalités grâce au CMS (avec MODx c'est faisable mais il faut bien connaître et ça demandera du boulot). Dernière solution, pour les codeurs en herbe, utiliser un framework et développer soi-même une appli...

J'ai jeté un coup d'oeil plus approfondi, et par exemple la gestion des formulaires est vraiment un modèle du genre, le détail en plus c'est la possibilité de lier le formulaire à une DB dans aucune connaissance particulière ! Excellent... Le module catalogue est dans la même veine, ça semble flexible tout en restant facile à mettre en place... à confirmer mais c'est un peu le Ditto + TV de MODx en beaucoup plus "simple". Définitivement un CMS à suivre, même si il faut s'habituer à la logique des blocs en ce qui me concerne...

Merci pour les précisions... j'ai bien saisi le concept, et même si on peut faire la même chose avec MODx of course pour certaines choses plus axées communautés Typolight peut être une option intéressante... je vais m'y plonger dès que j'ai un peu de temps, entre deux sites...

Plus ça va plus je me dis qu'il faut que je teste de manière plus approfondie Typolight... catalog a l'air intéressant comme module !

Merci Jean-Pierre tout ça indique une progression constante de Typolight, qui me semble décidémment avoir sa place sur le marché... On dirait que tu passes pas mal de temps avec ces derniers temps

Textpattern est moins vieux que Drupal... il a un peu la même logique que MODx (certains trouve cette logique complexe, moi je la trouve simple), mais en moins puissant et surtout (désolé Dragon) - je parle en connaissance de cause pour m'y être impliqué pendant plus de 2 ans - c'est une application (innovante en son temps ! j'étais parmis les premiers fans) qui est sur le déclin (aucune avancée réelle depuis la 4.0) depuis le départ de Dean Allen. La communauté n'est plus non plus ce qu'elle était malheureusement... faute à un dév principal autocratique et autiste (et pourtant talentueux développeur de plugin, Zem). Les choses ont peut-être changé, mais j'en doute... les "textpattern elements" et "banister" de même que txp pro semblent aux oubliettes...

En 16x16 même monochrome dans le lien du footer ça passe bien En tout cas c'est encourageant le feedback est bon pour l'instant.

Pour MODx ce n'est pas la première fois que je le dis mais ce n'est pas adapté pour tous les projets notamment du fait de l'absence de revisionning, de workflow au sein du manager ou encore de prise en charge multilingue native... Ceci dit, pour moi les meilleurs sites de comparaison d'appli web sont http://www.wikimatrix.org/, http://www.forummatrix.org/ et http://www.weblogmatrix.org/ (même éditeur). Les gens de Cosmocode ont développé un outil custom pour ça, comme ils l'expliquent sur la page "About" il n'est pas dispo publiquement... Pour ce genre de site, j'irai plus vers un framework type CodeIgniter, CakePHP ou autre mais je pense que la réponse ne va pas forcémment être celle que tu attendais... Maintenant, il existe peut-être un addon pour Typolight, va savoir...

Merci pour le feedback Pour l'identité, en fait cela va suivre, on bosse sur l'éditorial du nouveau site en ce moment même... mais motus et bouche cousu je suis tenu au secret !

Comme expliqué par Ryan sur le blog MODx il y a quelques jours, nous avons un nouveau logo ! Pour ceux qui ne parlent pas anglais, voici la traduction de l'esprit du post de Ryan, version courte : Nous avons bossé avec les créatifs de signalfeuer Nous étions parti sur le concept de la boîte vide car il reflète bien ce que MODx représente - une boîte vide où l'on peut mettre ce que l'on veut, de la manière qui vous plaît. Aucune contrainte, une liberté totale peut importe ce que vous voulez faire. (...) Le seul problème c'est que la boîte est un concept utilisé des millions de fois... (...) SignalFeuer fait partie de notre base utilisateur allemande, dont la créativité a été primée de nombreuses fois et que nous avons toujours admiré. Ils ont tenu leur promesse, avec un concept original d'une "boîte dépliée" qui rend encore mieux l'idée de liberté associée à MODx. (...) Le nouveau logo : Impressions ?

Tu n'es pas obligée de l'abandonner mais il faudra composer, et notamment faire passer les rédacteurs par le frontend avec le snippet FDM (FrontEndDocumentManager) - cf ce post ou alors jongler avec ManagerManager comme je l'ai suggéré ici (en fait un peu plus haut dans la même discussion que précédemment). Ceci dit, personnellement je choisirai plutôt un CMS axé éditorial comme SPIP. Il faut désormais appeler la 0.9.7 MODX Revolution 2.0.0 et nous sommes en alpha2 donc elle est déjà utilisable, à savoir elle fait tourner des sites "live" en expérimental (notamment http://www.corganics.com). La question du renommage de MODx 0.9.7 est largement traitée ici, avec aussi quelques indices sur le re-nommage de la branche "historique" qui s'appellera Evolution 1.0.0 : MODx 0.9.7 devient MODx Revolution 2.0.0 Si je comprend bien ce que tu cherches c'est un workflow continu entre les outils print et web ? La seule fonction d'export que j'ai vu sur les pages d'Adobe c'est l'import dans GoLive de fichier Indesign convertis en HTML, mais le seul souci dans ce type de procédure c'est que le HTML généré est souvent du "garbage" HTML. En plus, une présentation pour papier est rarement adaptée au web. Maintenant, on peut imaginer un script d'import des données XML provenant de InDesign vers une base de données MODx (ou autre CMS) mais cela nécessitera de bien connaître : - la structure du XML généré par InDesign car il va falloir convertir en HTML - la structure de la base MODx (ou du CMS choisi) pour ventiler les contenus dans les champs et documents qui vont bien. A mon avis tout ça suppose un peu de développement....

Pour une fois, je vais surprendre en disant que MODx (en tout cas pas aujourd'hui, la nouvelle branche sera mieux équipée pour ça) n'est probablement pas l'outil de prédilection pour mettre en place un workflow de publication. D'une part parcequ'il n'y a pas réellement de workflow (même si on peut mettre en place des solutions de contournement, je déconseille pour des sites à forte densité éditoriale), d'autre part parcequ'un workflow sans gestion des versions est handicapant et MODx n'en dispose pas. Enfin, au jour d'aujourd'hui on sait que MODx est "limité" (du fait de l'architecture et du fonctionnement du cache) à 5000 documents. Encore une fois, ce ne sera pas du tout le cas de MODx Revolution (ex 0.9.7) dont le code est totalement ré-écrit. Mais celui-ci n'est qu'en alpha... Quand aux CMS orienté "presse", en France SPIP est un bel exemple avec le site du Monde Diplomatique (belle référence) et probablement des dizaines d'autres. Autre possibilité, mais je ne suis pas sûr de la continuité ou de l'activité du développement, Lodel aurait pu être une solution. Sinon Drupal peut être un choix tout à fait pertinent si l'équipe qui développe le site "accroche" avec ce dernier (souvent on accroche ou pas avec celui-là ! c'est un peu tu aimes ou tu déteste). Il y a un article (en anglais) sur la mise en place d'un site de journal avec Drupal. Personnellement, je laisserai de côté Typo3 - trop lourd - et il y a aussi le facteur clé qui est l'appropriation des utilisateurs et Typo3 n'est pas ce qui se fait de plus fluide...

On ne peut pas dire de SPIP qu'il est lourd, c'est assez léger comme CMS et il gère très bien le workflow éditorial (plus la gestion des versions) donc pour moi d'après tes critères ça me paraît la meilleure adéquation. Si tu vas vers des CMS plus "light" tu n'auras ni workflow ni versionning....

Pour une fois - sous réserve d'approfondir la définition de besoin - j'irai un peu dans le sens inverse du courant en disant que le projet étant ce qu'il est (fonctionnalités spécifiques) et les délais étant ce qu'ils sont (courts - ce qui n'est jamais bon si on vise réellement plus court que possible - il y a une limite temps incompressible) je pense qu'il vaut mieux partir sur une solution spécifique. Il existe des solutions open source pour ce type de site, par exemple JobberBase que je n'ai jamais testé mais qui sert au site roumain http://www.jobber.ro. La communauté semble embryonaire et surtout anglophone. Côté personnalisation graphique c'est le moteur de template Smarty, et les templates sont clean et facile à comprendre. L'API reste simple en revanche et je n'ai pas vu de plugins donc cette solution semblerait limitée si l'on souhaite mettre en place des fonctionnalités avancées. Malheureusement je doute qu'elle puisse convenir à votre projet "en l'état", mais je le mentionne car cela pourrait intéresser d'autres membres du Hub et après tout pourquoi pas non plus étendre les fonctionnalités en partant de la base de code si celle-ci est solide ? Après il y a deux solutions : soit partir de CMS avec une API qui facilite le développement des fonctionnalités "Job board" (Drupal, MODx....), soit si l'application est réellement spécifique opter carrémment pour un framework applicatif type CakePHP, Symfony, Django... Tout dépend de la spécificité des fonctionnalités que vous souhaitez mais aussi du trafic, du nombre d'utilisateurs envisagés... Donc difficile de répondre sans plus de détail mais de ce point de vue choisir un framework applicatif sera probablement un choix plus adapté si vous souhaitez une meilleure scalabilité et une customisation plus élevée.