davidm

Ouaip SMF marche bien, c'est ce qu'on utilise sur les forums de MODx

PunBB est une solution rapide et sûre, et légére. On l'utilise pour le forum de textpattern depuis plus de deux ans, aucun problème sauf au niveau de la recherche passé un certain seuil de messages (bon il faut dire que 13000 post et plus de 90 000 messages, ça commence à faire...). Perso je vais me répéter mais j'aime bien UNB (le seul forum tableless à ma connaissance, avec quelques fonctionnalités originales...)

Denis, je crois qu'au fond on est d'accord... Mais j'avoue que même si j'ai du recul par rapport au choix d'un CMS (qui n'est qu'un outil, pour finir), j'ai un avis assez clair sur les outils avec lesquels je préfère travailler. Autrement dit des outils : * flexibles (pour coller au mieux aux besoins du client) * évolutifs (pour accompagner l'évolution des besoins) * conformes et accessibles (parcequ'une base saine est toujours préférable) * rapide à mettre en oeuvre (parcequ'il est important d'optimiser les coûts de développement pour proposer le meilleur prix au client) * permettant un contrôle total sur le design (pour offrir la meilleure différenciation à mes clients) Ceci dit, ça n'engage que moi

Joomla est un fork de Mambo qui a été créé par les développeurs principaux de Mambo qui ont claqué la porte de chez Miro (qui commercialise Mambo, la version commerciale : rappelons que ce qu'on appelle Mambo, c'est en fait Mambo OS). Donc oui le code de départ Joomla 1.0 était identique à Mambo 4.5.2, et diverge depuis. Pour moi Mambo est une coquille vide (ou le sera bientôt), car tout le talent est parti chez Joomla. Je passerai à Joomla sans hésiter si j'étais sous Mambo... La roadmap est autrement plus ambitieuse et un petit tour sur les forums de l'un et l'autre permet de vite se faire une idée : le momentuum est du côté de Joomla, à mon sens.

Guerre de religion, n'exagérons pas Même si on défend une opinion bec et ongle (ce qui est souvent mon cas ), il n'existe pas de solution idéale dans l'absolu, juste un compromis entre : - l'adéquation fonctionnelle d'une application avec les besoins identifiés - la rapidité de mise en oeuvre lié à l'outil - le choix de respecter ou non les standards (après tout, chacun a le choix même s'il existe des arguments non seulement d'efficience, d'ergonomie mais aussi économique et de maintenance) - la qualité du support offert par la communauté derrière l'outil - le dynamisme de l'équipe de développement - la perrenité de l'outil et son parc installé - et bien sûr... la connaissance que l'on a d'une application donnée En gros voilà les critères que je metterai en avant. Personnellement, je vais encore parler de MODx mais pour ce type de projet c'est ce que je choisirai. Ou alors Drupal. Mais ça n'engage que moi, et en ce qui me concerne je maîtrise mieux ces deux derniers que SPIP par exemple. Ceci dit, SPIP a l'avantage d'être archi-connu dans le secteur public puisqu'on utilise presque que ça dans les collectivités locales. Typo3 est aussi bien implanté... Et Xoops a aussi le vent en poupe côté français (grâce à une communauté hyper dynamique il faut dire). Pour en revenir aux "guerres de religion" si je critique aussi souvent ces deux solutions c'est qu'on a souvent tendance à ne jurer que par elles alors qu'elles ne sont pas parfaite et qu'il y a peut-être mieux dans certains contexte et pour certains projets... Il faut savoir évoluer, se remettre en question voilà tout ce que je dis

Ouaip surtout que la 0.9.1 a apporté pas mal de plus Mais bon au moins tu vas y gagner côté doc in french

Perso j'ai remarqué des incohérences dans la définition du content-type... peut-être regarder de ce côté là... En tout cas ça n'est pas un problème de cache normalement, cf le header http : Response Headers - http://www.expat-blog.com/fr/ressources/ Date: Wed, 11 Jan 2006 22:29:26 GMT Server: Apache Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Pragma: no-cache X-Powered-By: PHP/4.4.1 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Content-Length: 3327 200 OK

Ca fait plaisir de voir que Plume revient sur la scène, merci du tuyau Je vais m'amuser à le tester pour voir ce qu'il y a de neuf, du moins quand j'aurai le temps !

Nous disposons désormais de sous forum pour la section francophone de MODx qui s'étend considérablement : > Support >> FAQ >> Installation >> Modules, plugins, snippets >> Design/Templates > Documentation, tutoriels et Traduction >> Documentation >> Traduction >> Tutoriels > Communauté >> Annonces >> Présentez vous >> Vos sites >> Le bistrot français Vous pourrez noter que la traduction avance à grand pas, notamment grâce à Skopos, merci à lui !

DotClear, lourd ? Non tout le contraire c'est light, rapide et sûr... Bon test !

Juste pour info, modxcms.com vient de se doter d'un nouveau thème en lieu en place de Green Marinée qui était un peu trop commun... http://modxcms.com/

MODx offre un snippet de génération automatique de menu qui est assez flexible et qui ne cesse dévoluer. Tu as la possibilité d'encapsuler ton menu dans un div, et d'imbriquer des menus. Tous les éléments se voient affectés une classe CSS (div, ul, li...), avec bien sûr une classe spécifique pour la page en cours de visualisation (i.e pour la page active). Tu as aussi une class différente pour le premier et le dernier élément du menu. Les paramètre dispo pour la config du menu : siteMapRoot => pour définir à quel niveau le menu doit débuter (tu n'est donc pas limité à la racine. Ca permet de créer des menus spécifiques dans des rubriques section) maxLevels => la profondeur maximum que doit comporter le menu par rapport à ton arborescence (en partant de siteMapRoot). titleOfLinks => Quel champ de la base de donnée doit servir de base pour le nommage des liens (par défaut, c'est pagetitle mais ça peut être menutitle, id, pagetitle, description, parent, alias, longtitle, introtext i.e tout les champs existant d'un document) pre => le contenu que tu souhaites ajouter en préfixe à tes "li" selfAsLink => Définir si la page en cours doit comporter un lien ou pas hereClass => Classe CSS pour li et a pour la page active showDescription => Définir si tu veux que la description du document soit incluse dans la balise title du lien descriptionField => Choisir quel champs de la base doit être utilisée pour la description (par défaut, description mais on peut choisir introtext) topdiv => Définir si la balise ul de premier niveau doit être encapsulée par un div topdivClass => Définir la classe du div contenant le menu (si encapsulation) topnavClass => Définir la classe de l'ul de premier niveau useCategoryFolders => Si tu veux que les dossiers sans contenu comporte un lien vers une page de rubrique categoryClass => Définir la classe CSS du dossier subdiv => indique si les ul imbriquées doivent être encapsulée dans un div subdivClass => Class du div en question orderBy => Quel champ de la base doit définir l'ordre de classement du menu orderDesc => Ordre descendant ou ascendant Comme tu vois, cela donne une flexibilité assez poussée Plus d'infos sur l'utilisation du snippets ici : http://modxcms.com/snippet-dropmenu.html La traduction est en cours sur le wiki, bientôt tout ça en français

Encore des nouvelles de Textpattern. Suite à l'idée que j'avais avancé, thame a pris l'initiative de reprendre le flambeau et d'organiser un concours de création de templates pour Textpattern : voir http://www.textplates.com/ Pour ceux que ça intéresse, le premier prix est un iPod Video 30Go... a vos bloc notes ;p !

Ni xoops ni Joomla ne permettent de créer des champs customs en choisissant le type de champs à la volée depuis l'admin (du moins pas à ma connaissance...). Il existe peut être des modules pour faire ce que Dragondz veut faire, mais quoi de mieux que de pouvoir définir des variables qui correspondent parfaitement au besoin. Et que dire de QuickEdit le module d'édition frontend qui est le meilleur du genre (pour moi...). Si tu as besoin d'aide pour utiliser MODx sur ce projet, fait moi signe je te filerai des tuyaux

Salut dragondz Je viens de concevoir un site pour une agence de voyages qui nécessitait l'utilisation de champs customs : j'ai choisi MODx car il permet non seulement de créer un nombre illimité de champs custom, mais en plus il permet de choisir le type de champ (contraitement à textpattern). En plus, il permet d'éditer ces champs directement sans passer par l'admin avec une interface clean et simple

Y aura t-il une nouvelle version ? Je commence à en douter... quelqu'un connaît le développeur ?

Merci Bigornot effectivement ItsEasy est un excellent CMS "flatfile" i.e sans base de donnée. Il a par contre été cité plusieurs fois (notamment par ton serviteur), mais aussi bien avant que j'en parle : http://www.webmaster-hub.com/index.php?sho...180&mode=linear http://www.webmaster-hub.com/index.php?sho...aded&show=&st=& http://www.webmaster-hub.com/lofiversion/i...php/t14170.html http://www.webmaster-hub.com/index.php?act...er&f=17&t=15013 etc... Ce qui est dommage c'est que le développement ne semble pas très actif...

Elle tournait déjà parfaitement bien chez moi... Il tourne en safe_mode on ?

A la base, cette discussion concernait Vtiger et non SugarCRM... même s'il est vrai qu'à ma connaissance Vtiger nécessite aussi de désactiver safe_mode. Est-ce forcémment un signe de développement baclé ? La plupart des hébergeurs ont activé safe_mode pour ne pas se prendre la tête (c'est plus simple pour eux mais plus contraignant pour le développement). Un certain nombre d'hébergeurs plus pointus (dont TextDrive) font tourner php en tant que cgi, avec SuExec, et installé mod_security avec safe_mode désactivé. Apparemment, ça marche Voir cet excellent article sur Linux.com (en anglais) : Securing PHP

Pourquoi pas ? Un peu plus difficile d'accès ceci dit, pour ça que je ne l'ai pas cité...

Ca n'est pas forcémment une question de compétences techniques, les contributions peuvent être diverses et variées Remonter les bugs, poster des feature request, écrire des tutos, traduire... etc. Perso je ne suis pas développeur non plus Quant au temps, oui ça je peux comprendre !

Tableau assez complet que je partage, ma conclusion étant qu'en ce qui me concerne la meilleure façon d'avoir l'application qu'on souhaite est de contribuer à la faire évoluer C'est la beauté de l'opensource !

Essaye : http://www.wordpress-fr.net/ ;p

OK merci pour les précisions, ma pratique de SPIP est un peu rouillée pas utilisé depuis presque 3 ans... Ceci dit il y a d'autres moyens d'éviter les conflits d'url, la plupart des CMS utilisent d'autres logiques plus... logique (comme l'impossibilité de créer des doublons)

Complètement en désaccord, ça n'est pas une solution valide : un site statique n'a aucun sens à l'heure actuelle... Même un site de quelques pages a besoin de mises à jour, et de toute façon c'est une attente client pour des sites pro. Apprendre à concevoir des sites avec un CMS, ça demande du temps mais on peut faire exactement la même chose qu'un site codé "à la mano". Pour moi, la question ne se pose même pas...