Faudrait qu'on s'y colle: la vitrine laisse à désirer.
Donc, discutons de:

• ce qu'il contiendra
  
• et de son apparence

En avant !

Idéalement le site proposerait des articles, références, dossiers, tips, etc aux utilisateurs francophones.

Le forum serait un endroit d'échange hyperactif mais ne serait que le brouillon du site, c'est à dire qu'une fois un prolème résolu, le contenu du thread sera repris et formaté par un membre pour le passer dans une des rubriques du site.

Nous devrons trouver des moyens d'attirer et te nourir l'esprit communautaire.
Gcu est pas mal pour ca si on fait abstraction des comportements. Leurs système d'article est d'ailleurs plutot bien pensé.

Un système de mise en avant des activités personnels des membres peut aussi être un bon ajout, permettant à chacun de montrer sa facon d'utiliser l'os.

Des fonctions utiles pourrait être ajoutés comme par exemple une petite application permettant à tous de partager des informations machines tels que des dmesg, pciconf ou des kernels pour donner quelques astuces sur les supports matériels.
Ou une application permettant de partager des fichiers de configurations fonctionnelles pour des configurations particulières.

etc, etc.

Graphiquement, tout dépends de ce qui sera décidé pour le logo, ce sera un des élément clefs du design, il définira les couleurs, fonts, etc. Forcément nous devons être compatibles w3c et autres. J'apprécierais avoir un site graphiquement cohérent et non un site d'une facon, un forum d'une autre et encore un wiki.

shes wrote on 19. Jun 2006 at 15:45:

Le forum serait un endroit d'échange hyperactif mais ne serait que le brouillon du site, c'est à dire qu'une fois un prolème résolu, le contenu du thread sera repris et formaté par un membre pour le passer dans une des rubriques du site.

Le wiki est né, au départ, du besoin de rénover le site www.freebsd-fr.org: le but était d'y concocter des articles pour les transférer ensuite dans le site. Les choses ayant tourné comme on le sait, ça n'a pas pu être fait. Mais l'idée reste: utiliser le wiki comme un espace de travail en vue d'une publication des éléments "finis" dans le site web statique.
On avait déjà une FAQ-list en projet ("documents à écrire"): le but était de donner une réponse claire et détaillée aux problèmes fréquemment remontés. On peut lui adjoindre des cas pratiques complets (les threads résolus sur les forums) comme tu le suggères.
Je te laisse consulter le wiki pour te faire une idée des docs déjà dispo: ici.

shes wrote on 19. Jun 2006 at 15:45:

Des fonctions utiles pourrait être ajoutés comme par exemple une petite application permettant à tous de partager des informations machines tels que des dmesg, pciconf ou des kernels pour donner quelques astuces sur les supports matériels.

Les posts devraient idéalement comprendre ces infos.

Quote:

J'apprécierais avoir un site graphiquement cohérent et non un site d'une facon, un forum d'une autre et encore un wiki.

je suis complètement d'accord avec ça, je pense qu'il faudrai d'une part vraiment rassembler toutes les ressources Fug-Fr en un seul et unique site, la cohérence graphique entre ces différentes ressources me semble également importante, mais malgré tous optionnel dans un premier temps.

pour cela je pensait qu'utiliser un cms serait intéréssant pour plusieurs raison :

- la première est evidement de tout regrouper sur le même site, forum, wiki...etc
- l'uniformité graphique dont parle Shes entre ces différents éléments
- l'intégration d'origine de toute les élémements nécéssaires, donc pas besoin de créer donc passer du temps que personne n'a.

seul contrainte pour le moment, le trouver ce CMS, je cherche de ce pas

Je ne sais pas si partir sur un cms serait l'idéal, mais si c'est la solution pour laquelle nous optons, je conseil vivement joomla.

PS: je me porte volontaire pour faire la créations de templates (forum & cms) une fois que les objectifs sont définis. Joomla est assez pratique tant dans sa gestion des templates que dans son système de dévelopement dans lequel nous pourrions aisément mettre les doigts.

bah je pensais justement proposer celui la, mais je voulais tester avant d'en parler :p

Si tu peux trouver un truc dispo en Ports, ce serait bien. Et il faut considérer aussi l'existant: autant les forums n'ont pas une mine d'infos extraordinaire, et on peut de toute façon tout récupérer facilement (fichiers plats), autant les docs du wiki sont plus conséquentes et méritent qu'on se creuse la tête pour les exporter/réimporter avec le minimum de magouilles...
Après, j'exprime quand même une réserve: j'ai des doutes quant à trouver un outil qui ferait tout ça tout bien. Do a single thing and do it well...

/usr/ports/www/joomla
http://www.joomla.org/

Si vous avez besoin de démos, sheltem se porte volontaire pour faire une instalation standard sur un de ses serveurs.

Il y a comme une crispation: pas mal de passage cet après-midi, et pas tellement de retour.
Le sujet est assez sensible, je pense. Changer le soft qui supporte ces forums et celui du wiki implique de faire une croix sur l'existant (même si on récupère les données, ça laisse le goût de "défaire pour refaire").
Je voudrais bien savoir ce qu'en pense un peu tout le monde.

Quote:

Il y a comme une crispation: pas mal de passage cet après-midi, et pas tellement de retour.

Une "crispation" ? En ce qui me concerne, j'ai eu peu de temps aujourd'hui jusqu'à 19 heures mais j'ai plus ou moins tout lu en passant très vite dans la journée. Si je n'ai pas réagi sur les différents sujets c'est

- soit parce que c'est trop technique pour moi, et que de toute façon ce n'est pas moi qui supporterai les conséquences d'un choix (comme ce sujet pour lequel je ne suis absolument pas opposé à un changement de "logiciel" si vous le souhaitez) ;

- soit parce que je trouve que je parle déjà beaucoup et souhaite pouvoir laisser les autres s'exprimer sans "toujours" la ramener (comme pour le logo par exemple).

Voilà...

Marc

je ne pense pas que casser l'existent pour tout refaire sois quelque chose de négatif, au contraire ça montre un certain dynamisme, et ça permet d'avancer, on se rend compte petit a petit de nos besoins, et donc on construit en conséquence...

pour ce qui est du cms, j'ai mis en place joomla sur mon serveur à http://www.sheltem.com/joomla

j'ai crée un compte administrateur pour francis qui peut donc en disposer comme il veut pour voir.

du peut que j'ai pu en voir ce cms est extremement flexible, et visiblement tout les modules, mods, et autres plugins s'installe depuis l'interface d'administration sans jamais avoir à ce connecté sur la machine elle même.

pas vraiment de crispation, un peu comme marc pas trop de temps j'ai passer le wekk-end en conference sur l'ecohabitat donc aujourd'hui pas trop envie de reflechir a des choses qui paraisse "futile" par rapport a ces 15H fort instruxctive

j'attend aussi le retour de ros vus que c'est lui qui a fait l'effort en premier de recuperer les archive de l'ancien site et qui a creé le wiki je pense que c'est surtout lui qui a son mot a dire sur le quoi du comment et pas a moi qui ni connais pas grand chose

laurent

Je suis passé voir l'exemple de Sheltem ; du point de vue du candide, cela semble bien tentant bien que je ne sois pas sûr de comprendre le fonctionnement à terme.

Par exemple, pour News et Links, chacun pourra y déposer les nouvelles et liens qu'il trouve... ou non ? Je n'ai pas vu de lien "ajouter une news ou un link" ?

Pourquoi retrouve-t-on les News dans Blog ? Quelle différence ?

Où passeraient les articles du Wiki ? Dans Blog, FAQs ? Chacun pourra y écrire ? Là encore je ne vois pas de liens "éditer ou créer"... Mais peut-être ceci ne fonctionnera pas du tout comme un Wiki ou ces liens apparaissent-ils si  l'on s'enregistre ?

Bref comme vous le voyez, du moins "en passant" je ne saisis pas trop comment cela fonctionnera du point de vue du simple utilisateur. Les questions précédentes n'ont d'ailleurs peut-être pas beaucoup de sens aujourd'hui et renverraient plutôt à une organisation ultérieure ?

Marc

Toutes modifications de contenu nécessite un compte utilisateur.

Derrière il y a une grosse gestion des droits et des comptes.
Ce que tu voit la n'est que le template et les contenus d'une instalation par défaut.

Par la suite, tout est modulable. Nous aurons d'un côté une gestion des utilisateurs unique (site, forum, wiki, page perso, etc.) et de l'autre l'accès à tout une multitude de fonctions (forum, wiki, news, edition online, agenda, newsletter, blog, etc.).

C'est un gros boulot au début, mais une fois lancé c'est relativement sans soucis.

En parlant de soucis, sheltem: http://www.milw0rm.com/exploits/1922
Même si c'est une très bonne application, mod_security oblige!

Bonjour à tous,

Avant toute chose, je vous informe que la mise place des backups du wiki est à présent effective et semble bien fonctionner.
Il est donc dés à présent possible de faire une récupération du contenu des 7 dernier jours (ce qui signifie qu'en cas de problème, on à 7 jours pour réagir).

Pour ce qui est du site web, je suis désolé de contredire Sheltem, mais je suis froncièrement contre la destruction, car bien qu'elle puisse être vivifiante, le travail de recontruction peut décourager les contributeurs, et conduire à une mort du projet. Disons plutot une refonte esthètique.

Le wiki, me semble en tout cas être un bon outil pour l'ecriture, car il permet à la fois le travail en groupe, l'historisation des modifs et la possibilité de retour arrière. Ce dernier pourait continuer à être la base de travail. Car aprés tout rien n'empeche de faire des extractions de la base pour generer des pages web statiques ou dynamiques.

Pour ce qui est du CSM je suis juste un petit peu reservé......
1/ Car j'ai un peu peur que si l'on multiplie les lieux de discution et d'expression , on finisse par se perdre
2/ A t'on besoin d'un si gros *MACHIN* ? :o


Je serais plutot partisan d'une petite sulution simple et souple (n'oubliez pas le decoupage forum / web )
qui nous permete de garder le coté artisanal de la gestion.  ::)

concernant le cms, Joomla est entièrement modulable, je n'ai absolument rien configuré sur la version que j'ai mis en place, donc tout est par défaut, à part le forum qui est un module que j'ai rajouté.

Joomla est un gros "machin" comme dit Ros, mais on peut réduire facilement, et supprimer tout modules inutiles sans problème, c'est justement sont intéret face à d'autre CMS.


Quote:

Pour ce qui est du site web, je suis désolé de contredire Sheltem, mais je suis froncièrement contre la destruction, car bien qu'elle puisse être vivifiante, le travail de recontruction peut décourager les contributeurs, et conduire à une mort du projet. Disons plutot une refonte esthètique.

le but n'est pas de détruire mais de migrer...


Quote:

Pour ce qui est du CSM je suis juste un petit peu reservé...... 1/ Car j'ai un peu peur que si l'on multiplie les lieux de discution et d'expression , on finisse par se perdre

c'est justement le contraire que l'on cherche à faire, le but du CMS est de tous rassembler à un seul endroit, wiki, forum, news...

Cela simplifiera les taches de tout le monde.

Pour les utilisateurs:
Un site uniforme ayant les mêmes fonctionnalitées qu'aujourd'hui (forum, wiki) et même plus.

Pour les membres:
Un seul compte pour poster des messages sur le forum, pour ajouter des pages dans le wiki, etc.

Pour les administrateurs:
Une seule application à gérer, une seule base de donnée, des outils de mise à jour facile, etc.

Au risque de paraître un peu vieux jeu, je suis un peu sceptique sur ces outils qui font tout et bien. Ca m'en rappelle d'autres qui étaient au départ intéressants et sont maintenant devenus de véritables usines à gaz. Un indice, il s'écarte un peu du business maintenant pour aller vers l'humanitaire... bon ok, j'arrête,

Excuse-moi par avance shes, je ne souhaite pas te facher mais :


Quote:

les mêmes fonctionnalitées qu'aujourd'hui (forum, wiki) et même plus

Quote:

des outils de mise à jour facile, etc

ça serait pas un peu marketing comme arguments ?...

J'ai essayé joomla et son père mambo, il y a quelques temps, pour des sites perso nécessitant wiki et forum et je dois dire que j'ai du faire marche arrière ayant des problèmes de compréhension de l'ensemble. Je préfère les outils dédiés, rustiques et faciles à entretenir...

Voilà, ce ne sont bien sur que quelques centimes...

Ce qui est positif à mon avis, c'est la notion de "gestionnaire de contenu" (J'en avais parlé dans mes premiers mails, et déjà sur l'ancien forum lors de la création du Wiki(avec Plone, plus abouti), mais personne n'a réagit).
Meme si ca parait gros machin, rien n'empèche d'utiliser juste le nécessaire.
La condition serait aujourd'hui de pouvoir transférer facilement les fichiers existants, condition qui ne me parait pas remplie aujourd'hui.

Donc, pas trop d'accord pour tout chambouler brutalement (inutile dans l'état actuel des choses), et si un choix similaire est fait ultérieurement, on pourra toujours mettre au point "tranquille".

Je pense au contraire que le decoupage fonctionel est un mieux :
- un partage plus grand des charges & responsabilités
- une plus forte disponibilité (2 serveur valent mieux qu'un) ;)
- une maintenance plus facile, car updater un CSM  reviens à *tout* updater
  ce qui à tendance à freiner la bonne volonté des admins.

L'important cerait de reusir à tout regrouper sous le domaine fug-fr
de manière à arborer un seul et même drapeau.

ros wrote on 20. Jun 2006 at 20:18:

L'important cerait de reusir à tout regrouper sous le domaine fug-fr de manière à arborer un seul et même drapeau.

Je fais des efforts, promis :)
Je me tape le BIND operation guide, histoire de faire les choses correctement. Mais vu le flou actuel et le temps qui se partage avec d'autres choses (notamment ma recherche de boulot, peut-être un scoop cette semaine ;) stay tuned), j'avais mis ça en stand-by.

Quote:

ça serait pas un peu marketing comme arguments ?...

Effectivement :) Chassez les habitudes elles reviennent au galop.

Ayant soumis pas mal de correctifs au projet et utilisant ce système tous les jours pour des applications >professionnelles< je ne peut que le soutenir.

Par contre je tiens aussi à souligner mes propos plus réservés tels que:

Quote:

Je ne sais pas si partir sur un cms serait l'idéal, mais si c'est la solution pour laquelle nous optons, je conseil vivement joomla.

Après on peut aussi parler de bricoler des morceaux de pages en perl destinés aux utilisateurs utilisant la command line, j'aurais surement un avis :)

Mon seul soucis est au niveau de la cohérence.

* s'apprete à faire la hola pour le nouveau taff de francis

Bon je tente un argumentaire plus exhaustif histoire de défendre mon steak :

-la stabilité :

Des cms comme joomla ont largement fait leur preuve, ils sont stables est performants, certes pas exempt de bugs ou failles de sécurités mais lesquels n’en on pas.

-la modularité :

joomla est, je pense, le plus modulable qui existe aujourd’hui, on peut pratiquement faire ce qu’on veut de l’interface graphique, des templates… on peut ajouter des tonnes de modules comme des forums, des wikis, des galeries de photos, des languages… je n’ai pas eu le temps de tout parcourir mais c’est indéniablement très vaste.
Concernant l’argument genre « ça fait tout donc ça fait pas bien », je pense d’une part que ce n’est qu’un préjugé un peu facile, j’ai entendu ça pendant 10 ans concernant les imprimantes multifonctions et aujourd’hui elle font tous bien, et d’autre part compte tenu des fonctions très avancés de joomla, je ne vois vraiment pas ce qu’il pourrai mal faire, à partir du moment ou dans un premier tant il intègre un wiki et un forum fonctionnel et au vu de tous ce que l’on peut ajouter je me demande bien ce qu’on peut lui demander de plus, du moins dans notre cas. Il est vrai que dans le cas d’un portail fait à la main tout est modifiable, mais cela implique que pour la moindre modification quelqu’un prenne la peine de démarrer un éditeur html et donne beaucoup de son temps pour parfois ajouter de subtiles modifications.

-gestions des utilisateurs :

la gestion des utilisateurs est largement simplifié, un seul compte permet l’accès ou non à tous le cms, c’est apparemment tellement flexible qu’un admin peut en trois clique attribué un droit de publication, de modération du forum, ou de gestion quelconque à n’importe quel utilisateurs enregistré, ça évite donc d’être obligé de donner plus de droits qu’il n’en faut comme donner un accès au ftp à quelqu’un qui voudrait juste publier des articles dans la section news, ou d’avoir à changer tous les mots de passes parce qu’un admin se serai fâché avec un autre… on peut donc de surcroît et en toute confiance répartir des taches entre utilisateurs qui voudrait participer au projets, on peut avoir un utilisateurs sympa qui s’occupe des news, en prendre d’autre comme modérateurs, sans pour autant qu’ils aient le moindre accès à l’administration ou au fichiers.

-administration :

l’administration est simplifié également, un seul site, une seule console, et tout les utilisateurs sous la main, un nouveau besoin, on rajoute un module sans faire la moindre démarche sur la machine, sans connaissances en graphisme ou programmation, tous se fait depuis l’interface d’administration, la gestion de tous les modules se fait depuis cette même console donc pas besoin de zapper entre les différentes ressources et les admins eux même n’auront plus a jongler avec leurs différents comptes. Concernant la maintenance, je ne sais pas pour les autres mais pour joomla les mises à jour se font depuis la console d’administration, on télécharge, on upload, et joomla décompresse et installe, ça prend 2mn montre en main et sans interruption de service sauf peut être pour le pékin qui va se connecté dans la minute de la mise à jour. En somme je pense que c’est plutôt un avantage de tous updater en même temps plutôt que d’avoir à s’occuper séparément des différents sites. En cas de changement de serveur, l’installation de joomla seul prend 5mn si on à les bases de données, en admettant qu’il y ai deux ou trois modules à remettre j’estime une réinstallation éventuelle à 45mn environ donc le fait que tout soit regrouper sur la même machine fait tout tomber en cas de panne, mais à l’inverse je ne pense pas que les utilisateurs soit à une heure, et même a un ou deux jours près en cas de pannes sachant que compte tenu de la stabilité des serveurs chez les hébergeurs professionnel je doute que cela puisse arriver.

D’un point de vu purement marketing, parce qu’il en faut quand même un peu, je me mets à la place de l’utilisateur lambda qui se pointe sur un portail qui lui-même pointe sur plusieurs choses, je me dis qu’une bande de copains ont crée deux ou trois communautés sur le sujet et on regroupé les liens sur une page, alors que si je me pointe sur un cms d’aspect très « pro », j’ai l’impression d’être dans un endroit régie par une structure sérieuse un peu à l’instar d’une entreprise même si ceci n’est pas vrai, et j’aurais donc beaucoup plus confiance et serai plus tenter de me créer un compte.


bon c'est mon point de vu, et comme d'habitude, c'est pas moi le tolier ici :p

PS : désolé pour la mise en page c'est un poil difficile a lire mais j'ai un peu la flème

<troll>
<Shes> et l'honneur du plus long post revient a... SHELTEM!
<Sheltem> merci... merci... je voudrais remercier mes parents, mes amis, ma compagne.
<Sheltem> MAIS VOUS ALLEZ COMPRENDRE QUE JOOMLA CA TUE SA MERE?
</troll>

je suis un incompris... pfff :p

Mais non, mais non :) , je ne connais pas joomla, jamais mis le nez dedans.

Mais dans ton "argumentaire", je reconnais la plupart des vertus d'un CMS (pardon SGC puisqu'on est francophones :) ).
De mon coté je citais Plone (parce que je connais un petit peu), intéressant parce que tout est fait pour séparer l'applicatif du contenu, sous forme d'objets manipulables.

Et puis ce que dit ros:

Quote:

- une plus forte disponibilité (2 serveur valent mieux qu'un)

- Mais avec deux serveurs, un SGC, c'est le pied !

Quote:

une maintenance plus facile, car updater un CSM  reviens à *tout* updater ce qui à tendance à freiner la bonne volonté des admins.

- Ben non, parce que justement on update pas tout (relatif aux objets), et un admin prefèrera toujours avoir à en faire le moins possible, là ca fait un au lieu de deux, avec la multiplication potentielle des petits soucis, des sauvegardes différentes, extc..., et l'activité d'administration est plus facilement partageable qu'avec plusieurs applis.

Enfin, "point de vue", ces gestionnaires ont aujourd'hui le vent en poupe, car outre leur capacités de gestion, ils permettent un accès et une interactivité facile aux utilisateurs, je pense donc que le concept du forum sera obsolète d'ici peu, peu etre dès un an ou deux.
On en voit arriver de partout, ils occupent déjà les universités avec leurs forums liés, Wikis, blogs et tutti-quanti :) .

Ceci pour dire, gouverner c'est prévoir, pensons déjà un petit peu à l'avenir, meme si on débute.
 

Plone a le léger handicap de nécessiter le serveur www de zope, mais j'ai pu trouver de la documentation rapidement (Apache front-end pour ZServer, notamment, et c'est la configuration qui m'intéresse, puisque je ne peux pas dégager Apache de la jail: pages d'admin, CGI, etc.)
Ensuite, pour ce qui est de l'import des données du wiki et des forums, je pense que ça va réclamer un bricolage.
Bon, jetez un oeil à la comparaison qu'en fait CMS Matrix (peut pas vous donner l'URL directe) et dites-moi ce que vous en pensez (sinon: attention ! je lance un vote !)

Presque-PS: je vous balance donc mon scoop de la semaine, puisque que je suis embauché au Centre de Ressources Informatiques de Haute-Savoie!!! Ooooooooléééééééééé !!!

Bienheureux pour le scoop  :)

Sans opinion pour le reste.

Marc

cool pour le taf,

d'ailleurs au mag on monte des "pingoo" pour les écoles du chablais, des machines qui servent de routeurs... on monte les machines suivants leurs directives, et eux installe les softs, je crois que c'est une debian préconfiguré pour les écoles.

Quote:

je vous balance donc mon scoop de la semaine, puisque que je suis embauché au Centre de Ressources Informatiques de Haute-Savoie!!!

Félicitations !  :D

champagne!

Je ne suis vraiment pas convaincu par cette histoire de CSM  :-/ :-/ :-/

Sheltem wrote on 21. Jun 2006 at 17:16:

d'ailleurs au mag on monte des "pingoo" pour les écoles du chablais (...) une debian préconfiguré pour les écoles.

Il y a un site dédié (pingoo.org) pour plus d'infos.

francis:
Je me joins au concert de félicitations.
J'espére que tu y trouvera l'expertise convenant à tes attentes. Tu as du pot de trouver un truc comme ca, a priori tu ne devrais pas y vivre l'ostracisme larvé que je rencontre vis à vis du libre :) .
(Pour le champagne, on attendra que tu ais touché la paye :) )

ros:
Alors là je m'inquiète.
Je vois ces propositions de gestionnaires de contenus comme une reflexion sur les orientations futures, tenant compte de possibles nouveaux besoins à satisfaire dans un avenir proche, ceci pour rester "up" avec l'évolution des outils de communications/publications.
L'intéret d'y penser maintenant, est d'essayer de choisir une voie, qui plus tard, ne nous obligera pas à de lourdes et douloureuses modifications.
C'est vrai que le concept n'est pas encore totalement grand public, mais ca va vite, j'ai pu en voir en intranet dans des boites, particulièrement créatifs.
Et il n'est pas question pour moi de violer nos "admin" :) , je concois trés bien qu'il y ait une partie digestive et des essais, sans balayer ce que vous avez déjà fait.
la période estivale qui arrive laisse le temps de voir, il faut aussi tenir compte de la disponibilité de chacun (francis aura surement moins le temps :) ), et de mon coté il y a aussi du chamboulement, je serais aussi plus souvent absent.

Quote:

Alors là je m'inquiète.

Oh, il n'y a pas vraiment de quoi. Je suis juste un peu ronchon ces derniers temps. Tu sais ce que c'est, une mauvaise semaine. Et puis je dois avouer que les bidules tout intégrés me font parfois un peu peur, surtout
qu'ils sont souvent gourmands en resources. Bien entendu cela n'est que mon avis   8-)
Le choix sera bien evidament collectif.  ;)

ros wrote on 23. Jun 2006 at 20:48:

Quote: Alors là je m'inquiète. Oh, il n'y a pas vraiment de quoi. Je suis juste un peu ronchon ces derniers temps. Tu sais ce que c'est, une mauvaise semaine. Et puis je dois avouer que les bidules tout intégrés me font parfois un peu peur, surtout qu'ils sont souvent gourmands en resources. Bien entendu cela n'est que mon avis   8-) Le choix sera bien évidemment collectif.  ;)

Il faut bien avancer un peu, alors je donne mon avis et pose des questions:

• sur un plan technique, je préférerais de loin que l'on s'oriente vers Plone. Python vs PHP (c'est un a priori tenace chez moi: je pense à tous les développeurs qui se sont formés à la prog en PHP lorsque la bulle gonflait, gonflait, ...), possibilité d'avoir une répartition sur plusieurs serveurs avec ZOE (même si ce n'est utilisé que pour garder le service dispo durant des travaux, ça peut valoir le coup), autant de fonctionnalités disponibles qu'avec Joomla.
  
• pour ce qui est de la documentation, c'est subjectif, mais je préfére Plone, là aussi. Joomla semble être dans l'ambiance "faites-nous confiance, uploadez le bidule, ouvrez telle URL et suivez les écrans d'install" (on est presque chez m$, là. Au passage, j'ai lu une FAQ parlant d'un éditeur wysiwyg ne fonctionnant que dans IE...).
  
• j'ai trouvé peu d'info côté Plone sur le support d'Unicode, mais ça donne en tout cas plus d'espoir que du côté de Joomla (bidouillage pré-install requis pour la série 1.0x, sinon faudra attendre la 1.5)
  
• mais Plone est gourmand, surtout en occupation mémoire comme l'indique cet extrait de la FAQ:
  
  Quote:

  Plone is much heavier on RAM and CPU usage than your run-off-the-mill web system. It's built to do a lot of different things, and should preferrably be hosted on a dedicated server if possible. The most important consideration when building a Plone server is to have enough RAM. To take plone.org as an example, it uses about 500-700 MB of RAM fully cached. It is a very busy site, though - so you will get by with less, normally. For basic usage, you can get away with about 100-200 MB RAM usage. You should have at least 512MB RAM and a 1GHz processor if you want Plone usage to not be painful when you start getting traffic. plone.org runs on a 3.2GHz Xeon with 4GB of RAM, with Squid in front - using the CacheFu setup.

  
  La jail est hébergée par une machine qui a sans doute quelque-chose comme 2Go de RAM, mais bon, c'est partagé.
  

A part Dumpy, qui a de l'expérience avec Plone ? De façon plus large, qui Pythonise de temps à autre ? Si on part là-dessus, je m'y mettrai, bien sûr, mais avoir un coup de main ne sera pas de refus, bien que vu le nombre d'extensions dispo en standard, je doute qu'il y ait besoin de bricoler...

PS: à propos du boulot -> merci à tous ! Et pour la boisson, ça restera virtuel, sauf pour les lascards du coin qui savent que le génépi les attend ;)

Comme je parlais de temps de "digestion et d'essais", l'idéal serait de pouvoir en mettre un de facon sommaire en ligne, et chacun pourrait bricoler dans son instance comme dans un bac à sable, sans risque pour les autres :) , avec l'avantage de pouvoir discuter dessus en direct. Un vrai outil collaboratif... :)

Ca je peux fournir !  8-)
Dumpy, si tu veux prendre l'installation et la configuration en charge,
je peux te fournir un espace avec les acces nécésaires.

::)

Pour Joomla, il y a le serveur de Sheltem: je peux prêter mon login, ou on peut lui en demander un autre.
De mon côté, j'ai installé Plone sur la jail, mais je n'ai ni créé d'instance, ni intégré ça avec Apache. Mais si ça dit à quelqu'un d'essayer, je démarre ça vite-fait sur un port différent.

plusieurs choses :

concernant le choix, du CMS, je ne trouve pas trés important, voire un tantinet prise de tête de choisir un CMS en fonction du language utilisé, il me parait indispensable de porter son choix vers quelque chose de fiable, de maintenu et "secure" et surtout qui fourni les services qu'on lui demande.
après ça, que le bazar soit codé en python, php, perl, ou je ne sais quoi d'autre, je pense que ce n'est pas d'une importance capitale et que ce qui nous intéresse dans l'histoire c'est le contenu que l'on peut fournir, sans ce prendre la tête avec le contenant, c'est pour ça au départ que j'ai proposer un CMS.

ensuite,

Quote:

Comme je parlais de temps de "digestion et d'essais", l'idéal serait de pouvoir en mettre un de facon sommaire en ligne, et chacun pourrait bricoler dans son instance

je pense que la on est effectivement en train de perdre du temps en discution un peu futile, et comme le dit Dumpy, il est temps d'agir, et donc d'en mettre un en ligne, et surtout de déléguer un peu, comme nous l'avons tous souligné, nous avons tous une vie et des disponibilités différentes, et si l'on peut tous donner notre avis, seul francis et ros peuvent agir, la conclusion est que lorsque il ne sont pas disponible, plus rien ne se fait.
je propose donc que l'on ouvre un topic qui permettrait de savoir ce que chacun peut apporter à la communauté, que que se soit d'un point de vu matériel (hebergement, bande passante...), au niveau comptétence (installation, maintenance...), ou concernant le contenu (création de tutoriel, documentations...). histoire que tous cela avance.
comme je l'ai déja dit, sur un CMS on peut avoir des admins pour la maintenance, des modérateurs pour le forum, des gestionnaires pour le wiki, et de "simples" publicateurs pour les news, articles et autres.


Quote:

Pour Joomla, il y a le serveur de Sheltem: je peux prêter mon login, ou on peut lui en demander un autre.

j'ai mis joomla a ton entière disposition, je peux donc volontier créer d'autre compte, mais si tu souhaite créer des accès cela ne me pose aucun problème qu'elle qu'en soit leur niveau.

Dans l'ordre:

• je pense justement que le langage implémentant le CMS sera déterminant pour sa stabilité (en termes de fiabilité et de pérennité): python a le mérite d'être 10 fois plus lisible que PHP (à mes yeux, au moins), et l'approche OO de Zope garantit une architecture que sa communauté saura faire évoluer.
  
• discuter des mérites des différentes possibilités n'est pas une perte de temps: j'en connais deux qui devront se taper quelques heures de boulot pour "recopier" (croisons les doigts) les données du wiki et des forums vers le machin. Et pour ma part, je ne ferai pas deux fois dans l'année la corvée.
  Si l'on est pressé à ce point, il suffit d'arrêter de se casser la tête sur le logo, de faire une homepage moins moche et de nous annoncer via les canaux appropriés. On court après quoi, au juste ?
  
• pour Joomla: si quelqu'un veut son accès, qu'il me PM' et je lui fais.
  

Quant à Plone, de mon côté: j'essaye de faire fonctionner Zope (maintenant que j'ai ajouté un Python 2.4 pour avoir le multithread, indispensable, il n'arrive pas à ouvrir une p.... de socket locale) mais, merci France Telecom, j'ai des déconnexions toutes les quelques minutes. Je laisse tomber pour aujourd'hui.

Mes excuses à FT: il faut juste que j'apprenne à lire un log (LCP != LQR). Enfin, à décharge: le type de BAS a dû changer, car LQR fonctionnait auparavant, j'en suis certain. M'enfin...

Donc, petite update au passage: je peux démarrer mon instance Zope maintenant (un os.link ne pouvait pas fonctionner, vu que le /tmp est un MFS, d'où une erreur "cross-device link": s/os.link/os.symlink/) mais seulement par 'runzope'. La version plus mieux 'zopectl' ne fonctionne pas: le process qui ouvre la socket de contrôle meurt tout de suite après. Pas pratique... Je continue à chercher.
Si une bonne âme pratiquante du rite python avait une piste pour tracer ça: j'ai pas le temps de trusser le process en question.

Peut etre question de droits. Tu n'aurais pas runné mkzopeinstance en root, par hasard ?.
Sinon il y a une déclaration user pour le suid à faire dans le /etc/zope.conf.

Bon, je va me coucher.  

Non, tout est fait sous le user dédié à Zope, et j'ai déjà rajouté "effective-user" au cas où, mais niet... La vérité est ailleurs.

ros:

Quote:

Dumpy, si tu veux prendre l'installation et la configuration en charge, je peux te fournir un espace avec les acces nécésaires.

Merci, ros :) , mais comme francis s'est déjà lancé...

De mon coté, j'ai essayé hier soir une install de Plone sur une Freebie 6.0 via les ports pour voir ce que ca donne.
On obtient un Zope 2.8 et un Plone 2.1.
Pour Plone, on peut upgrader facile à 2.5, mais pour Zope, il y a 2.9 ou le grand saut sur la branche 3-Release, "no convenient" pour tout. :)
Sachant que Zeo est aujourd'hui considéré comme obsolète, francis ?.



 

Je capitule sur Plone: toujours le même pb et pas le temps d'apprendre à utiliser pdb, avec plusieurs processes a forciori.

Je vais bientôt foutre Joomla à la benne, aussi. La petite histoire: je me dis "aller, je l'installe vite fait ce soir..."
Me voila donc à installer le package, créer la DB, et passer la 'web install'. A ce dernier stade, quelques soucis de permissions (bien que la fin de l'install du package fasse tourner un mtree, donc a priori, les perms devaient être correctes, mais bon. Profil bas, le programme a raison et je corrige: tout est vert). Je passe tout guilleret (ambiance "ouais ! ça a l'air cool, quand même") à l'étape "language pack french". Et là, c'est le drame:
/media en vert, /language en vert aussi (genre "tout bon" ou j'ai l'esprit tordu ?). Je browse sur le pack downloadé localement et je clique "upload & install". Une ou deux minutes plus tard, le verdict: 'can't move uploaded file to /media'. Un peu dans le genre: le blaireau n'a de toute façon pas lu l'écran précédent, donc enfilons-lui une raison qui a l'air logique. Donc, questions qui en découlent: où est posé 'temporairement' ce fichier, et surtout, pourquoi, bordel, ne lui est-il pas possible de le bouger pour une destination où il a les droits ?
Bon, je me calme, et je cherche: où qui n'est le journal ? Réponse: pas l'air d'en avoir.
Je jette un oeil au configuration.php (au passage, ambiance sécurité: ce fichier, qui contient le nom de la BDD et les login/passwd à employer et en mode 644... grand bravo !) et niet trace de répertoire d'upload ou qqch d'approchant.
En attendant vos conseils, je vais tenter d'uploader par scp puis d'installer depuis un chemin local au serveur (c'est l'autre option de "component manager").

Donc, pour installer depuis un emplacement du serveur, il faut encore comprendre comment s'est censé fonctionner: le truc attend un répertoire en guise de paramètre, et le pack downloadé est un zip (de l'arborescence modifiée par le pack, à ce que j'en comprend).

J'ai quand même eu une minute d'espoir en trouvant deux paramètres ('debug' et 'error reporting', respectivement passés à 'enabled' et à 'maximum'), jusqu'à ce que j'en vois l'effet époustouflant: j'ai donc la liste des requêtes SQL exécutées pour produire chaque page, et toujours pas plus d'info concernant mon 'can't move blablabla...'. Magnifique.

Fini, au moins pour ce soir.

Ca sent la fatigue, le stress et pas mal d'autres choses.


Quote:

Donc, pour installer depuis un emplacement du serveur, il faut encore comprendre comment s'est censé fonctionner: le truc attend un répertoire en guise de paramètre, et le pack downloadé est un zip (de l'arborescence modifiée par le pack, à ce que j'en comprend).

Si tu as le support gzip tu n'as besoin d'uploader le dossier complet mais seulement l'archive. Je n'ai jamais eut de soucis avec celà.


Quote:

'can't move uploaded file to /media'

Forcément une question de droits. Que dit ls -l et sous quel utilisateur tourne ton serveur web?


Quote:

(au passage, ambiance sécurité: ce fichier, qui contient le nom de la BDD et les login/passwd à employer et en mode 644... grand bravo !)

Tu noteras qu'a l'install tu as une étape File creations/File Permissions qui te permet de changer les droits des fichiers. Option que tu retrouve plus tard dans Global Configuration > Server.


Quote:

Me voila donc à installer le package

Bon et finalement peut être le seul conseil qui puisse être utile aux autres: n'utilisez pas les ports/packages pour des applications web, particulièrement dans ce cas ou c'est du php, c'est du plug&play.

PS: je ne défends aucunement joomla.

shes wrote on 29. Jun 2006 at 19:07:

Ca sent la fatigue, le stress et pas mal d'autres choses.

Oui, j'avoue que je suis un peu découragé: j'ai passé une ou deux journées à essayer de porter gnash dans pkgsrc, et ça m'a rappellé pourquoi je déteste les gnuseries, les gnomeries et toute ces m... d'automachins qui vont bien avec. Et deux jours de plus à essayer de faire fonctionner Plone pour l'abandonner au final, faute de connaitre un minimum de Python.

(Au passage, piqûre de rappel sur ma question dans 'flash': quelqu'un a-t-il un glibgl.h sur sa machine ? si oui, de quel port provient-il, svp ? (pkg_info -W abs_filename ou peut-être -F sur FBSD, je sais plus))

shes wrote on 29. Jun 2006 at 19:07:

Si tu as le support gzip tu n'as besoin d'uploader le dossier complet mais seulement l'archive. Je n'ai jamais eut de soucis avec celà.

C'est activé chez moi, mais ça ne change rien. La bulle d'aide précise par ailleurs que ça ne concerne que le flux servi. Côté PHP (via System Info), zlib est activée aussi.

shes wrote on 29. Jun 2006 at 19:07:

Forcément une question de droits. Que dit ls -l et sous quel utilisateur tourne ton serveur web?

Peut-être une question de droits: et si un fichier de log pouvait le préciser, ce serait bien. Je ne comprends pas qu'un soft de cette envergure ne logge rien. C'est aberrant.
D'ailleurs, s'il s'agissait d'un pb de permissions, pourquoi tant les vérifications initiales durant le setup, que celles effectuées à l'entrée du module d'installation affirment que tout va bien ? Tout est vert: c'est juste pour faire joli ?
Pour répondre à ta question: l'utilisateur 'www' a bien les droits qu'il lui faut, où il faut (toujours en me fiant aux vérifs initiales). Ce n'est pas la première install d'un machin PHP que je fais, et je crois avoir pigé les permissions unix relativement bien. Je n'ai pas l'intention de tout passer en 777 pour masquer le pb.

shes wrote on 29. Jun 2006 at 19:07:

Tu noteras qu'a l'install tu as une étape File creations/File Permissions qui te permet de changer les droits des fichiers. Option que tu retrouve plus tard dans Global Configuration > Server.

Je vais regarder ces options, mais je persiste à penser que le port devrait installer les répertoires avec des users/groups/permissions correctes pour fonctionner 'out of the box' (il y a un +MTREE_DIRS, après tout).
Pour ce qui est de configuration.php, il n'y a pas à proposer d'alternative: pas d'accès pour 'others', point. Le programme devrait forcer ça sans demander l'avis de l'utilisateur.

shes wrote on 29. Jun 2006 at 19:07:

Bon et finalement peut être le seul conseil qui puisse être utile aux autres: n'utilisez pas les ports/packages pour des applications web, particulièrement dans ce cas ou c'est du php, c'est du plug&play.

Pas tout à fait d'accord. Il y a quand même des avantages indéniables à utiliser un système de paquets: les mises à jour et security/portaudit notamment.
Après, que le port ait besoin de correctifs, c'est possible. Si c'est le cas (on verra si je trouve la solution à mes petits problèmes), je le ferai remonter au mainteneur concerné.

shes wrote on 29. Jun 2006 at 19:07:

PS: je ne défends aucunement joomla.

Moi non plus ;D
Merci en tout cas pour tes indications. Je vais continuer à chercher.

fgudin wrote on 30. Jun 2006 at 12:22:

Oui, j'avoue que je suis un peu découragé: j'ai passé une ou deux journées à essayer de porter gnash dans pkgsrc, et ça m'a rappellé pourquoi je déteste les gnuseries, les gnomeries et toute ces m... d'automachins qui vont bien avec.

Mmm, je confirme l'état de fatigue  ;) sans les automachins comme tu dis, on serait mal...

C'est un point de vue biaisé n'étant pas programmeur, et ayant subi ces derniers temps les effets de bord de la portabilité façon GNU, mais:

• je ne suis pas sûr qu'un shell de 5000 lignes soit nécessaire pour 'configurer' un package aussi simple que dtach. Et les 15000-20000 lignes sont monnaie courante.
  
• je ne suis pas non plus certain de l'efficacité ni de la rationalité qu'il peut y avoir à tester la présence d'un compilo fortran 77 presqu'à tous les coups
  
• je trouve bizarre que cette 'auto'configuration nécessite souvent de petits coups de pouce de la part du porteur d'un logiciel vers un environnement non-GNU

Bref, question portabilité, j'avais l'idée naïve que c'était les standards qui devaient le permettre (ANSI pour le C, SUS pour les OS, etc.) Je sais bien que personne ne prend la peine de les respecter, mais quitte à utiliser une couche supplémentaire, pourquoi ne pas essayer de faire mieux. J'y connais pas grand'chose, mais il y a des alternatives (cmake par exemple). Quelqu'un a-t-il déjà utilisé autre chose que la suite autotools et nous ferait partager son expérience ? Ca m'intéresse, et puis ça animerait un peu les forums qui semblent bien morts ces derniers jours.

Sinon, j'avais l'impression d'avoir trouvé la réponse à mon problème mais 'choux blanc'. Néanmoins, ça soulève une question sur PHP: lorsque upload_tmp_dir n'est pas spécifié dans php.ini, quelle valeur par défaut prend-il ? Le commentaire dans le fichier n'aide pas trop:
[code]; Temporary directory for HTTP uploaded files (will use system default if not specified).[/code]Le truc rigolo, c'est que je pensais que le 'system default' était justement donné par ce fichier de config (/usr/local/etc/php.ini). Je deviens cinglé ? Je mange du bois ?

Quote:

Sinon, j'avais l'impression d'avoir trouvé la réponse à mon problème mais 'choux blanc'. Néanmoins, ça soulève une question sur PHP: lorsque upload_tmp_dir n'est pas spécifié dans php.ini, quelle valeur par défaut prend-il ? Le commentaire dans le fichier n'aide pas trop:

D'après le manuel PHP (http://fr.php.net/manual/fr/ini.core.php#ini.upload-tmp-dir), il prend la valeur par défaut du système ... /tmp donc vraisemblablement.

Oui, c'est bien ça. Le language pack étant assez gros (2.5Mo), ça m'a laissé le temps d'apercevoir un /tmp/phpZP..., ce qui confirme que l'upload en tant que tel fonctionne.
Dans le même temps, en trussant les httpd, j'ai pu voir que les permissions sur le répertoire de destination (/www/joomla/media) sont OK (access(2) avec modes 0 puis 2, succès les deux fois).
Maintenant, il faudrait que j'arrive à tracer ce qu'il se passe du côté de PHP... Et là, je suis dans les choux :(

A part ça, j'ai testé les deux paramètres évoqués plus haut (chmod'er les nouveaux fichiers/répertoires), sans succès.

Bon ! Après une légère modif du php.ini visant à avoir un loggage des erreurs, j'ai la joie de découvrir la vraie raison de l'échec de l'opération:

Code (]
Warning: upload_max_filesize of 2097152 bytes exceeded - file [userfile=Joomla_1.0.10-Stable-fr.zip):

not saved in Unknown on line 0 (...)

On est assez loin de:

Code (]Failed to move uploaded file to /media[/code):

Je suppose que PHP doit retourner une cause d'erreur relativement explicite dans le script, puisque c'est un paramètre qui lui est propre (upload_max_filesize) qui détermine ce comportement: pourquoi Joomla la masque-t-il avec un charabia sans rapport ? Enfin... on s'en fout. L'important, c'est que ce soit corrigé maintenant.. Tiens, je me réjouissais trop vite. J'en ai une nouvelle maintenant: [code]XML setup file is not for a "language".

Aller, je m'en retourne à la guerre.

En attendant de revenir avec de bonnes nouvelles, j'espère, une petite lecture amusante chez les fans de plan 9 à propos d'autohell: Message-IDs: 43F0EF9E.4010301@orthanc.ca, 69296165-14FA-4F30-8923-F49C151B5778@orthanc.ca et ce dernier, moins "pourrissement" que pédagogique: 13740.1147211763@piper.nectar.cs.cmu.edu

fgudin wrote on 30. Jun 2006 at 16:41:

Quelqu'un a-t-il déjà utilisé autre chose que la suite autotools et nous ferait partager son expérience ?

Oui, scons fait bien son boulot aussi. Mais les autotools possèdent un tas d'outils, de macros bien pratiques, car largement utilisés.

Voilà, ça a fini par s'installer. Pour les annales: le pack de traduction était bizarrement foutu. Passe encore qu'il inclue une version 'patch' et une version 'from scratch' (sous le même nom, juste pour la rigolade: )
[code]> unzip -l ../downloads/Joomla_1.0.10-Stable-fr.zip
Archive:  ../downloads/Joomla_1.0.10-Stable-fr.zip
 Length     Date   Time    Name
--------    ----   ----    ----
 1506472  06-28-06 10:36   patch_1.0.x_vers_1.0.10-Stable-fr.zip
 2808541  06-28-06 10:36   Joomla_1.0.10-Stable-fr.zip
--------                   -------
 4315013                   2 files[/code]
mais le plus drôle, c'est que sur les 9Mo dépackés, 30Ko suffisaient. J'ai simplement refait un joomla_fr.zip contenant language/french.{php,xml}.

Quelle prise de tête pour pas grand'chose. Bon, eh bien vous êtes maintenant les bienvenus sur notre Joomla.

PS: pensez à utiliser un username qui ne soit pas le même que votre nom affiché pour plus de sécurité, svp.
Re-PS: la traduction est loin d'être parfaite, mais l'équipe de traduction FR de Joomla a un wiki qui permettra aux courageux de leur prêter main forte :)