Un framework ou cms pour de la presse en ligne

[spinoza]

Bien sûr, le périmètre fonctionnel devrait être précisé. Mais je m'interrogeais sur les outils qui font tourner aujourd'hui des sites comme le figaro, Libé, que choisir.org, etc....

Bref, existe-t-il ds cms orientés "presse" si l'on peut dire (et si ça n'est pas un pléonasme) et si ça existe....

J'imagine que Typo3 saurait largement répondre aux contraintes de ce type de site, notamment pour la saisie backend des différentes rubiques par les journalistes avec le cas échéant le workflow de validation qui va bien auprès des chefs de rubrique..gestion des bandeaux de pub, intégration de système de petites annonces, abonnement en ligne à l'article ou au journal...verrouillage de la consultation de certains articles aux seuls abonnés, etc....

Des frameworks plus simples et moins lourds comme Modx ou d'autres pourraient-ils faire l'affaire ?

Enfin, comme ce type de site a aussi - puisqu'on parle de presse - une source "print", ie publication papier, existe-il aujourd'hui des solutions, fussent-elles propriétaires, qui mutualisent (sous forme de flux xml par exemple), les contenus en provenance de xpress ou Indesign, l'objectif étant évidemment de centraliser les contenus, leur gestion, leur saisie et validation, bref d'éviter de doublonner l'ensemble des tâches rédactionnelles.

Des idées ? Ah, si Modx (ou un autre) pouvait faire tout ça ? Le peut-il ?

Désolé de n'être pas encore plus précis, mais vos pistes sont bienvenues. Merci.

Modifié 2 Août 2008 par spinoza

[davidm]

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

[spinoza]

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..!) ?

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

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 !

Modifié 2 Août 2008 par spinoza

[spinoza]

Donc en clair c'est spip ou drupal ?

[dragondz]

Salut Spinoza

Je te conseil de jeter un coup d'il à textpattern, il pourrait convenir, car je fais tourner les sites de 2 magazines papier avec: viesdevilles.net et dzautos.com et cela marche plutôt bien!

Pour la saisie c'est simple après la mise en place, il y a un système simple de workflow mais pas de versionning (sauf ajout d'un plugin).

A+

[spinoza]

Merci dragonz pour ta réponse et bravo pour ces deux sites. Et côté xml, connaissez-vous une façon simple d'interfacer Indesign et un cms ?

[davidm]

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

[pluriels]

Bonjour,

de mon côté, j'ai utilisé ... du javascript pour importer mes données dans Indesign.

Au lieu de générer un fichier XML (ce que je voulais au départ), je me suis orienté vers un générateur de Javascript.

Au final, on obtient un fichier Javascript à lancer dans Indesign.

[nicoo]

Sans vouloir trop détourner le topic original, Pluriels, pourrais tu m'expliquer comment fonctionne ce générateur js ? et quels avantages tu en tire par rapport un fichier xml ? as tu des exemples de pdf qui auraient été généré par cette méthode ?

Dans tous les cas je pense que, technique mis à part, il sera de toute façon délicat de porter un contenu mot pour mot du web au print et vis versa. Les règles de rédaction et de présentation diffèrent lorsque l'on rédige pour le web ou pour la rédaction papier.

Et puis il faut penser justement à la plus value d'un support par rapport à l'autre et ainsi en tirer les bénéfices pour que ces 2 éditions (web et print) soient complémentaires.

[Anonymus]

Pour ma part, j'ai utilisé Drupal sur un site à largement plus de 5000. Mais il m'a fallut refaire toute l'architecture des menus (le code, quoi..).

C'est (dsl, David) ce qui me fait.. attendre un peu avant d'utiliser vraiment Modx.

Je ne peux me permettre de dire au client que son site est 'limité' à 5000 articles.

Sinon, un bel exemple d'intégration SPIP /> Studyrama. Des milliers de pages, des millions de visiteurs, et.. Cariboo (l'admin du Hub) qui a presque tout développé

( même la boutique en ligne tournait sous SPIP !! )

[KetA]

Spir fait aussi tourner www.sportvox.fr par exemple, footmercato.net ...

[spinoza]

Merci à tous de vos réponses, et à toi David pour ce long post que je n'avais pas vu.

Côté Print et Web, l'idée était simplement qu'il n'y ait qu'une saisie unique des contenus par les rédacteurs - même si bien entendu les gabarits ne sauraient être les mêmes - et que ces contenus soient en effet automatiquement portés, pour tout ou partie, sur l'un et l'autre des supports, voir un troisième comme un tel mobile (ce qui, Nicoo, ne remet pas en cause ta remarque évidemment très pertinente sur la complémentarité Print/web et leur différence rédactionnelle).

Bref, je saisie un article pour une rubrique X, lequel a une structure englobant des conteneurs web et Print (qui peuvent être communs pour partie et différents pour d'autres), et chacun des contenus idoines de l'article se placent automatiquement au bon endroit, l'un dans la rubrique qui va bien du site Web, l'autre dans la maquette Indesign correspondante.

Au vu de ce que vous me dites, il s'agirait donc plutôt de passer non d'une page Indesign à une page Web, mais d'utiliser un système de saisie front-end de type SPIP (ou autre) pour l'ensemble des contenus (y compris des contenus Print non visibles sur le site), bref d'alimenter une base de données dans laquelle Indesign irait piocher tout seul ce qui lui revient (comme l'indique et l'a précisément réalisé Pluriels !)

Je vois donc que ma question semble plutôt relever d'Indesign (auquel je connais rien) que d'un système éditorial web.

Concernant SPIP, c'est le côté CMS éditorial pur et non frameworks qui m'inquiétait, étant donné que certaines fonctionnalités (de type achat d'articles en ligne par exemple, petites annonces, gestion des bandeaux de pub) me semblaient plus complexes à mettre en œuvre dans SPIP que dans un outil comme Modx ou Typo3 (certes trop lourd ici) qui disposent de nombreux modules idoines.

Me tromp'che ?

Enfin, la réputation des terribles boucles spipiennes n'étant plus à faire, n'est-ce donc pas le risque de développements potentiellement plus lourds ?

Bien sur, seul un inventaire précis et exhaustif des services attendus permettrait, sans nul doute, de répondre à ma question.

Merci en tout cas de vos contributions !

Modifié 7 Août 2008 par spinoza

[Ayolia]

Bonjour, ma réponse ne sera peut etre pas original mais as tu éssayer de te renseigner du coté de wordpresse et de ses thèmes magazines, histoires de voir si il pourrait répondre a tes attentes ? Avec une bonne mise en page ( thème magazine ) ca ferait une bonne base, peut etre a développé par la suite mais c'est un bon point de départ je pense.

Julien

[spinoza]

Merci Julien, mais en terme de fonctionnalités (boutique en ligne par exemple), cela ne sera-t-il pas un peu compliqué ?

[Enrico]

Je découvre sur ce site ijoomla magazine (V3) pour la version 1.5 de joomla.

Peut-être une piste ? Perso, pas d'expérience sur le sujet.