Aller au contenu

Quel CMS pour un site de partage de photos ?


captain_torche

Sujets conseillés

Bonjour,

Mon entreprise réfléchit actuellement à la refonte d'un site communautaire développé sous Typo3, qui est actuellement excessivement lourd à modifier (et à exécuter, Typo3 n'étant assurément pas le CMS le plus léger au monde).

Nous aurions besoin de quelques fonctionnalités relativement simples :

- Upload de photos, et géolocalisation de celles-ci (éventuellement via l'API Google maps)

- Rédaction d'articles par les membres (avec ajout des photos précédemment uploadées)

- Rédaction de "bons plans" (articles géolocalisés, sans photo associée)

- Rédaction de commentaires

A votre avis, quel CMS serait le plus à même de proposer ces fonctionnalités, relativement simplement (via des plugins ou un peu d'huile de coude) ?

Lien vers le commentaire
Partager sur d’autres sites

Hello,

Wordpress pourrait sans doute faire l'affaire avec le plugin geo mashup

A modifier / marier avec une extension de gestion de galerie tel que nextGEN en fonction de tes besoins.

Après je ne sais pas ce que tu entends par "communautaire" mais tu peux regarder du côté de buddypress qui transforme un wordpress mu en une plateforme de réseau social

C'est la première soluce qui me vient à l'esprit, mais en creusant un peu je suis sur qu'il est possible de faire ça avec d'autre CMS (modx, typolight voir drupal)

Nico

Lien vers le commentaire
Partager sur d’autres sites

Pour parler de ce que je connais le mieux Drupal permet de le faire.

Modules à utiliser : location (geocodage), gmap (affichage sur Google map), image (a ton avis?), + modules pour les fonctions communautaires.

Tout cela marche out-of-the box sans une ligne de code, maintenant le niveau de customisation dépendra évidemment des détails de ton cahier des charges (ah, les détails...)

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Je ne vais pas dans l'originalité mais Modx me semble approprié.

Petit snippet : http://modxcms.com/GoogleMapMarker-723.html qui te permet de faire un appel à l'API google maps. (&apiKey)

demo ici : http://www.netguru.fi/modx/

sinon plus simple : http://www.modxcms.com/GoogleMap-658.html

Outputs one or multiple Google maps using on-the-fly accurate geocoding of addresses or predefined points

Si tu as un peu d'huile de coude, tu pourras apporter pas mal de personnalisation.

David ? :)

Aour

Lien vers le commentaire
Partager sur d’autres sites

Je n'ai rien à rajouter pour modx tout est là, sauf peut-être le plugin DirectResize qui permet d'assurer le redimensionnement auto des images...

Côté Typolight c'est bien sûr aussi possible via dhl_google_maps, et Typolight est peut-être préférable pour un site communautaire, avec la gestion des membres plus aboutie que modx (webloginPE étant tout aussi complet mais pas toujours parfaitement stable :( ), idem au niveau de la gestion des newsletter ou des droits. Ce sera aussi plus rapide à déployer :P

Pour moi c'est donc plus Typolight ou Drupal, voire CMS Made Simple (qui a un module SimpleGoogleMaps ou CGG Google Maps) pour du communautaire... encore une fois comme le dit Alexandre il faut affiner le besoin pour savoir quel est l'outil le plus adapté (et ça dépend bien sûr aussi de ce qu'on préfère, perso Drupal n'est pas ma tasse de thé je ne "clique" pas comme avec modx ou typolight).

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Je dirais sans hésiter Drupal, il permet en natif, de gérer tout ce dont vous avez besoin a part la géolocalisation, qui existe sous un module tier.

En faite, le plus sera sans doute, le graphisme à réadapter.

Sébastien

Lien vers le commentaire
Partager sur d’autres sites

Concernant le choix entre Modx et drupal :

Si l'aspect communautaire est important , je pencherais clairement plus pour Drupal parmi le peu de CMS que je connais à peu près (modx, spip, joomla, drupal, CMS madesimple, textpattern); ça assure au moins une tranquillité certaine et une facilité de mise en place au niveau de la gestion des droits, des contributions par les membres via formulaires personnalisés front-end en toute simplicité, suivi des contributions, commentaires qui se mettent en place en un clic...

J'ai moins d'expérience en terme de modules que Alex ; surtout pour ce qui est de l'upload des images pour chaque membre qui doivent pouvoir si j'ai bien compris disposer d'un repertoire à eux dans lequel ils peuvent piocher leurs images, mais si il dispose de ce qu'il faut de ce côté comment inéation semble le dire, je ferais ce choix avec mes maigres connaissances...

Je n'ai pas poussé typolight assez loin pour pouvoir le comparer à drupal, c'est vrai que typolight a l'air aussi pas mal pour gérer une communauté; ce serait intéressant de savoir les points forts et faibles de l'un et l'autre sur un projet de ce type. (typolight dispose sans doute de moins de modules disponibles? qui est le plus facile à templater? )

En faite, le plus sera sans doute, le graphisme à réadapter.

En partant sur une création de template basé sur PHPtemplate; cet aspect sera assez vite maitrisé, ça permettra aussi facilement de créer plusieurs templates pour les différents type de page sans trop d'efforts.

Modifié par nyl auster
Lien vers le commentaire
Partager sur d’autres sites

Je pense que CMS Made Simple n'est pas à exclure non plus... depuis la 1.4 il y a eu de gros progrès et il y a pas mal de modules dispo aussi, et le language de template à base de tag est très facile à adopter quand on vient de textpattern ou de modx.

Côté template Drupal ou Typolight à mon avis c'est plus une question de se sentir à l'aise avec l'un ou l'autre qu'un avantage intrinsèque. Drupal on rentre dans la logique ou pas, c'est un peu trop nerd/geek pour moi. Sans être codeur, j'arrive à m'y retrouver dans typolight, c'est clair et la logique me parle... mais bon j'ai toujours été plus sensible à l'OO (ça donne envie de s'y mettre).

Pour ce qui est du nombre de modules, franchement c'est un argument qui a ses limites... on a déjà 60 modules pour TYPOlight dont la majorité couvre bien 90% des besoins les plus courants. La question est plus, à mon avis, de savoir si - quand on a besoin des 10% - le développement d'un module sur mesure sera rapide ou non, facilement templatable ou non, avec un modèle de données customisable et facilement évolutif ou non. Evidemment si on a un besoin spécifique dès le départ et que tel CMS dispose déjà de l'extension pour le satisfaire, cela va orienter le choix mais ça ne me semble pas être le cas ici.

Pour prendre un exemple, j'avais besoin de développer l'exportation d'une base de données adhérents construite sous modx avec des TV vers une base de données avec des champs custom sous Excel à destination d'un imprimeur. Avec un CMS traditionnel j'aurai cherché un module qui permette d'exporter mes données et si il n'existe pas il aurait fallu développer un module custom en php. Avec modx, j'ai simplement utilisé Ditto en créant un template formatté en CSV qui permet à l'imprimeur de récupérer le fichier. C'est bête et méchant mais très efficace. Donc on peut aussi dire que modx a moins de modules que certains CMS mais on peut faire beaucoup de choses avec certains snippets (Ditto en premier) sans jamais avoir besoin de modules spécifiques. Je pourrai citer au moins 5 exemples du même genre de logique... modx fait descendre au niveau du designer la logique "légo" qu'on trouve habituellement à un niveau d'abstraction supérieure (l'API) réservé aux codeurs.

TYPOlight ou Drupal sont des CMS avec une API puissante tout comme modx mais par contre faute de coder, il est bien plus difficile de customiser ici et là les choses sans module additionnel...

Pour ce projet ça ne dépend pas seulement de l'adéquation fonctionnelle mais aussi de qui va travailler dessus et de leur attirance vers tel ou tel CMS qui va convenir à leur façon de travailler, à leur compétences / expériences, etc...

Lien vers le commentaire
Partager sur d’autres sites

salut

Effectivement on peut aussi prendre l'exemple de joomla qui dispose de très nombreux modules mais qui demande parfois plusieurs modules là où MOdx, typolight ou Drupal vont pouvoir gérer la situation sans aucun modules additionnels les doigts dans le nez.

C'est un argument qui a donc ses limites comme tu l'as bien démontré mais je ne pense pas qu'il soit forcément à négliger non plus: Quant un CMS a beaucoup de contributeurs et une certaine ancienneté, ça agrandit quand même les chances de trouver une solution toute prête face à des besoins qui se sont déjà posés à d'autres dans le passé ; et qui ont pondu un module pour y répondre. J'aime bien savoir en utilisant Drupal pour un site communautaire qu'il existe tout un tas de modules stables pour développer son côté communautaire/ reseau social.

Concernant le projet de Captain Torche, je ne me permettrais pas de juger quel CMS est le plus adapté, mon expérience étant insuffisante, je ne fais que rapporter mon sentiment sur les outils que je connais.

Modifié par nyl auster
Lien vers le commentaire
Partager sur d’autres sites

Oui c'est ce qu'on disait avec Alexandre, il faut approfondir la définition du besoin pour se prononcer, plus prendre en compte les facteurs d'appropriation et d'affinité vis à vis de la solution puisque plusieurs peuvent convenir...

Je pense que la vitalité et le nombre de contributeur côté modx n'est plus à démontrer... l'absence de certaines fonctionnalités natives par contre (versionning, multi-linguisme...) est un handicap. Pour Typolight le problème est plus du côté du support anglophone trop faible (j'ai mis un point d'honneur à aider les gens sans réponses côté english, quand je peux...) et l'attitude de Léo parfois un carrément autocratique (par exemple, j'ai soumis deux tickets via Trac, zappés sans explication et je suis même interdit de soumission de bug !!! Un peu étonnant quand on sait que j'ai contribué à plusieurs communauté et pas seulement modx et que je ne suis pas un newbie... un échange de mail avec l'intéressé n'a rien changé - et je n'ai pas plus compris pourquoi (aucune réponse)... soit... moi je mets un gros mauvais point là ! Ou alors c'est une incompréhension culturelle entre français et allemand ? J'avoue ne rien y comprendre...). Heureusement la communauté française avec un leader de choc en la personne de Cyril Ponce est gérée totalement différemment !!!

Côté Drupal, je ne sais pas, j'ai toujours eu du mal avec le forum natif qui ne me plaît pas du tout...

Lien vers le commentaire
Partager sur d’autres sites

[HS]

ah, pas très encourageant comme attitude...

Le truc avec Drupal c'est que il est tout sauf sexy; beaucoup de choses rebutent quand on le prend en main, j'ai mis du temps à passer ce cap. Et comme tu disais, il a peu ce côté "nerd" : il perd de sa puissance si on ne bidouille pas le php; du moins disons que la possibilité d'insérer quelques lignes de php dans l'admin pour décider des arguments des views ou de la visibilité d'un bloc est très appréciable si on fait du php. Quand à son codage, y'a ce systeme de "hook" que j'ai toujours pas compris à fond qui est un point central de son fonctionnement; sinon c'est comme une grande librairie de fonctions qu'on peu réutiliser sans peine (une fois qu'on a trouvé la fonction qui nous intéresse :-( ).

Mais je ne parle que de Drupal 5, il manquait trop de modules sur Drupal 6 pour que décide de le choisir sur le projet en cours; peut être est-il codé de tout autre manière.

[/HS]

Modifié par nyl auster
Lien vers le commentaire
Partager sur d’autres sites

Concernant la logique de construction de Drupal et pourquoi la dév team a choisi de ne pas opter pour un passage à la POO (cela a suscité des discussions nombreuses sur le web, exemple ici), cet excellent article (en anglais) qui approfondi pas mal aussi les choix architecturaux derrière Drupal (notamment une partie intéressante sur les hooks).

Pour l'attitude de Léo et le faible niveau d'activité sur les forums anglophones, ce sont aujourd'hui les 2 gros points faibles de Typolight... pourtant le produit lui-même est vraiment impressionnant ! J'avoue que j'ai des doutes car c'est un aspect clé pour un CMS open source, une des raisons qui m'a conduit à quitter la communauté de Textpattern et à ne plus l'utiliser alors que c'est (était) un excellent CMS. Je suis en train de ré-approfondir CMS Made Simple qui a beaucoup évolué et la logique textpatternienne de son système de tag combiné à une dynamique communautaire forte et une aptitude à couvrir des zones où modx est plus long en déploiement est assez intéressante. Silverstripe reste sur mon radar aussi avec un langage très puissant et un code OO dans la tendance. TypePublish est à surveiller aussi... autre Outsider, TangoCMS, encore jeune mais à surveiller.

Lien vers le commentaire
Partager sur d’autres sites

[HS]

ah, pas très encourageant comme attitude...

Le truc avec Drupal c'est que il est tout sauf sexy; beaucoup de choses rebutent quand on le prend en main, j'ai mis du temps à passer ce cap. Et comme tu disais, il a peu ce côté "nerd" : il perd de sa puissance si on ne bidouille pas le php; du moins disons que la possibilité d'insérer quelques lignes de php dans l'admin pour décider des arguments des views ou de la visibilité d'un bloc est très appréciable si on fait du php. Quand à son codage, y'a ce systeme de "hook" que j'ai toujours pas compris à fond qui est un point central de son fonctionnement; sinon c'est comme une grande librairie de fonctions qu'on peu réutiliser sans peine (une fois qu'on a trouvé la fonction qui nous intéresse :-( ).

Mais je ne parle que de Drupal 5, il manquait trop de modules sur Drupal 6 pour que décide de le choisir sur le projet en cours; peut être est-il codé de tout autre manière.

[/HS]

Je vois qu'on parle de Drupal ;-)

* Avec Drupal 6, le module Views a énormément évolué. Aujourd'hui il permet de faire des requêtes très puissantes sans écrire une ligne de php.

* Pour gérer la visibilité d'un bloc, en plus des options std, il existe un tas de modules supplémentaires permettant de gérer des options de visibilité plus complexes. Sinon, il y a le module Panel qui a été concu pour assembler sur une même page des contenus reliés entre eux par des relations complexes.

* Les hooks, ne sont pas le privilège de Drupal, on trouve cela aussi dans wordpress. C'est un système qui a fait ses preuves et qui permet ainsi aux modules d'agir sur les processus standards de Drupal sans avoir à modifier le code.

* Drupal 6 est une évolution de D5, pas une révolution. Il améliore significativement certaines choses comme le thèming mais le principe de fond est le même (heureusement).

Lien vers le commentaire
Partager sur d’autres sites

  • 5 semaines plus tard...

Passionnante discussion. Pour ma part, j'ai travaillé un peu (tout petit peu) sur Typo et Modx (et un grand merci à David et Aours pour leur aide !), un chouya sur Drupal et je me pose un peu une question similaire aux besoins du Captaine :

En l'occurrence, il s'agirait d'organiser pour un intranet une basse de données d'environ 20 mille photos, idéalement capable d'exploiter les champs IPTC existants, mais aussi de disposer de champs complémentaires très spécifiques (liste des collaborateurs, designeurs, éclairagistes.., lieu, condition météo, matériel, contexte historique, semantiques...) bref des champs à développer sur mesure et naturellement capable d'offrir ensuite des recherches croisées sophistiquées sur cette masse de visuel.

Le tout, naturellement, avec création de miniatures en différents formats, options de téléchargements coté intranautes autorisés mais variables suivant différents types de profils de droits, extension à terme via un petit module d'e-commerce pour l'achat des visuels, et en intra, remplissage de la base front-end via des champs d'uploads idoines, voir avec workflows eventuels.

L'aspect champs extensibles me fait pencher vers les modules CCK et Views de Drupal6, tout comme l'aspect gestion des droits et mini-workflow native contrairement semble-t-il à Modx (en attendant la 1.0 si je ne dis pas de bétise.

Mais peut-être Modx ou typolight sont-ils tout aussi doué pour celà ?

Reste enfin la masse d'info. Les 20 milles pourrait croître à terme à 60 milles Et là, faut que ls système tienne la charge.

Je n'ai pas songé à Joomla..A tord peut-être ?

Vous retours sont vraiment bienvenus.

Un grand merci !

Lien vers le commentaire
Partager sur d’autres sites

Pour le workflow, attention en natif il n'y a pas vraiment de workflow par contre la gestion des droits permet de contrôler effectivement l'approbation par un éditeur. Un workflow ça va au delà... pour ça le module WorkFlow de drupal est un modèle du genre. Totalement flexible : tu peux définir les status possible pour un document, associer un workflow différent par type de contenu, lier des changements de status à des "actions" (par exemple, publier le document lorsqu'il passe de brouillon -> approuvé). C'est très puissant.

Pour un intranet, je pense que Drupal est sans conteste un outil de choix... c'est d'autant plus vrai qu'avec Organic Groups et ses modules satellites, on a vraiment un outil communautaire ultra performant.

Lien vers le commentaire
Partager sur d’autres sites

salut :

Pour la difficulté de gérer un tel nombre de photos avec un CMS (c'est quand même très gourmand en requetes sur la base de données...), je n'en sais hélas rien, il faudrait se renseigner.

Je n'ai pas grand chose à ajouter à ce que vient de dire david, drupal ferait un très bon candidat.

Pour la miniateur d'image, il assure aussi grâce à image cache qui permet de créer autant de presets que tu veux : par exemple tu upload une image et tu peux créer deux miniatures de tailles différentes. (en plus de l'image originale).

Pour le classement ce serait du gateau avec les views (filtres exposés) et la taxonomie; surtout que la taxonomie peut s'utiliser comme un systeme de tags à la volée également; ce qui peut être très adapté à la gestion de photos.

Pour la soumission en front-end, drupal gére ça de façon native, très simple et naturelle.

oublie Joomla pour ce projet. ^^

Modifié par nyl auster
Lien vers le commentaire
Partager sur d’autres sites

Hello

Mais alors, j'arrive pas à avoir mon avis concernant la question suivante : De typolight ou de Modx, lequel est le meilleur en termes de composants/modules externes ("3rd party"), en terme d'efficacité, de rendu, etc...

Car un CMS peut être un excellent outil mais moi je considère que l'efficacité est probablement mon critère n°1.

C'est pour ça que je suis sous Joomla : il y a pléthores de templates, de composants, de modules et de plugins pour que le développement d'un site soit rapide, propre, efficace.

Evidemment, Joomla ne fait pas tout. Dans le cas où on a besoin d'un site bien précis, lequel choisir entre typolight et modx (ou un autre ?)

Je pose cette question car j'ai besoin de développer un site pour lequel il n'existe pas de composant existant ... donc autant partir d'un CMS efficace qui me le permettra.

lolo

ps : je vais encore revenir à Joomla, mais il y a une collection impressionnante de composants pour gérer le partage de photos :) et si besoin, il y a des bridges pour les logiciels tels que Gallery, Copermine, etc... :) ... efficacité, direct, rapide. Ne l'oubliez pas :)

Lien vers le commentaire
Partager sur d’autres sites

Salut

Le code des Modx et Typolight sont très propres.

Tous deux te permettent de faire ce que tu veux et définir pour tes modules des templates persos pour le rendu.

Aujourd'hui, je balancerais plus sur typolight grâce à son module "catalog"

Si tu l'étudie un peu tu pourras facilement créer ton propre module.

Regarde sur le forum francophone de Typolight les posts de oelmekki

Sinon sur son blog, un tutos sur la Création de module backend pour gérer des ressources.

http://blog.olivier-elmekki.com/2009/01/06...des-ressources/

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...