davidm

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...

Elgg supports

* User, object, file and site management

* Social graph functionality (relationships between users and other users, objects and sites)

* Multiple sites (or applications) per installation

* Easy internationalisation support

* System-wide, tag-based searching across all content and users

* Fine-grained access controls

* Multiple views, allowing for mobile applications and embeddable widgets as well as the traditional web browser view

* Event, plugin and widget APIs

Technical, back-end features

* RSS, FOAF, XFN for content syndication

* OpenID, OpenSocial, OAuth for integration with other web services

* Open Data Definition and an increasing number of data portability formats for import / export

* An extensible RESTful API, with results in JSON, serialised PHP or XML

* AJAX through jQuery and user-definable callbacks

* Easy extension for use with caching systems such as memcached, for increased system performance

* Use of multiple database connections for scalability

End-user features

* Profile

* Dashboard

* Activity feed

* User preferences

* Comprehensive administration tools

* OpenSocial applications

* Blogging

* File repository

* Forums

* Social bookmarking

* And more..

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...

The comparison engine powering WeblogMatrix was developed by CosmoCode and is not publically available.

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 ?

Merci bp David de cette réponse si rapide. Si j'abandonne l'idée du workflow (rédacteur/valideur) et du versionning, et si j'imagine avoir moins de 5000 pages à mettre en cache, l'objection tient-elle toujours (moi aussi, j'aime Modx..!) ?

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.

Au fait, cette 9.7, en attendant la 1, c'est pour bientôt ?

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

Autre question, la versio "print" du journal est générée par Indesign...y a t-il de ce point de vue un outil plus adapté qu'un autre pour automatiser la publication web des versions "print" des articles (c'est-à-dire éviter des re-saisies ou copier-coller) via des ponts xml idoines automatisés ? Euh..suis-je claire ? Merci en tout cas pour ces lumières !

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.

OK bon puisque tu demandes MODx + eForm / eForm2db, mais je crois que j'ai déjà répondu sur les forums de MODx