davidm

A noter depuis le 30 octobre Elgg 1.1 est sorti avec des optimisations au niveau des requêtes sur la BDD et une amélioration du cache...

Effectivement Dadou précision de taille qui je pense est nécessaire En ce qui me concerne je facture un peu différemment de ce que j'ai exposé ci-dessus, même si l'approche sous jacente est identique après deux ans d'expérience supplémentaires (et notamment un suivi au quart d'heure près du temps passé sur les projets réalisés) j'ai appris à border encore mieux les prestations.

Ton besoin me semble trop vaste (comme tu le dis, groupware + CMS) pour être gérable par un seul outil qui corresponde à tes critères ("adaptablomodulable" autrement dit flexible et évolutif), du moins pas sans un développement. Plusieurs options : partir d'un CMS façon Joomla, YACS, XOOPS et autre CMS "tout en un" avec X extensions que tu combineras pour avoir ce que tu veux : problème (tu sembles l'avoir compris, tu en viens) -> tu perd la flexibilité, la simplicité d'utilisation et les mises à jour / la maintenance risquent d'être un cauchemard à moyen/long terme. partir d'un CMS/CMF flexible avec une bonne API et coder la partie "groupware" et/ou customiser les extensions existantes : scénario envisageable avec une bonne connaissance de l'outil utilisé (car sinon il faut ajouter le temps d'apprentissage, à voir si c'est possible pour toi) avec des outils comme modx, expression engine ou typolight. partir de zéro et tout coder avec un framework type CakePHP, CodeIgniter, Symfony.... tout dépend de ta connaissance de ces frameworks et de la précision du cahier des charges fonctionnel dont tu disposes (attention quand on part de zéro il faut avoir bien défini les aspects fonctionnels en amont -> sinon dérive). utiliser un groupware/outil collaboratif avec une API ouverte et mettre en oeuvre une intégration entre celui-ci et un CMS/CMF avec lui aussi une API ouverte : par exemple, je parle de ce que je connais et qui me semble faisable modx + activecollab (je parle du 1.x). Ca demande du travail mais c'est un juste équilibre à mon avis entre flexibilité et base de code existante qui évite de partir de zéro (et l'admin d'activecollab est probablement une des toutes meilleures du marché).

Vu le message d'erreur je pense qu'il s'agit plutôt d'un problème de login / mot de passe que de connections, le message serait différent sinon...

Dans ce cas vérifie que tu n'as pas coché l'option permettant de générer un sitemap.xml automatiquement... je ne vois pas d'autre explication...

Ca m'est arrivé aussi, le temps de comprendre la logique qui est derrière... si tu as des soucis n'hésite pas à poster sur typolight.fr avec des questions plus précises Alors, dans typolight l'admin n'est pas forcémment plus intuitive que dans modx, je dirai même qu'elle l'est moins. Par contre on a un total contrôle (au début ça donne mal au crâne avec toutes ces options de permissions) sur ce que le client voit dans l'admin (mais au lieu d'avoir à utiliser un plugin du genre ManagerManager pas forcémment toujours parfait et lourd à utiliser) on a ça nativement dans la gestion des permissions. Ca veut donc dire que le client ne voit que ce dont il a besoin et cela simplifie énormément les choses pour lui. Deuxième élément, l'aide en ligne est très complète bien plus que dans modx. En fait c'est très courant : la plupart des CMS ont un système avec une spécialisation des contenus par type, les articles étant le type de base et les extensions donnant en général des types additionnels (galerie, sondage, news... etc). modx ne fait pas de distinction et l'unité de contenu c'est le document web qui peut ou non contenir d'autres documents (répertoire) : mais modx est une exception ! Avec typolight on retrouve la notion d'article mais avec deux grosses nuances : 1) un article n'est pas un élément de contenu ! : c'est un "conteneur" auquel on peut associer n'importe quel type de contenu, mais qui ne comprend pas de contenu en dehors d'un texte d'accroche qui va servir sur les pages listant les articles. Il défini les propriétés de l'article (date de publication et de fin de publication), certaines propriétés CSS optionnelles liées au framework CSS de TL, l'auteur... 2) un article n'est pas contraint par une structure de contenus rigide : La puissance de typolight est un peu similaire à modx par certains aspect pour cette raison : on est pas contraint par une structure du type titre - intro - texte mais on peut choisir à loisir les éléments de contenus. En quelque sorte les "content elements" de typolight sont un peu comme les TV dans modx. Un élément de contenu peut être : un texte, un titre, une image, un fichier à télécharger, du code HTML, mais aussi un élément de contenu d'un autre article ou un autre article ou encore et c'est très intéressant : un module (les modules sont un peu comme les chunks dans modx, mais dans le sens étendu du chunk c'est à dire qu'ils sont souvent l'équivalent des chunks de templates utilisés par les snippets). La différence c'est aussi que la structure de données peut être différente pour chaque article, alors que dans modx elle est associée à un template (un gros défaut de modx, à quand les DocumentVariables ?). Tu n'est pas obligé de faire comme ça ! Tu peux simplement utiliser une zone de texte dans laquelle tu crée tes contenus exactement comme tu le fais pour "content" dans modx Oui et non. Ca dépend en fait du type de contenu dont on parle. Si c'est une page "statique" alors oui. Le fait que l'arborescence soit "double" : page d'un côté, article de l'autre est à mon sens illogique et la séparation du concept de page et d'article a peut-être des justifications techniques (notamment côté structuration de la DB) mais il serait plus cohérent de les fusionner surtout que le concept d'article est utilisé de manière atypique ici ça peut amener des incompréhensions. Apparemment une future version de typolight (qui ne portera pas le même nom) devrait mettre fin à cette distinction... Si c'est une page dont le contenu est dynamique et géré via un des modules installé (actualités, galerie, sondage, calendrier.... etc) alors là non il suffit de définir des pages comportant soit une présentation custom qui contient elle même des modules pour lister les contenus (là on bosse comme avec Ditto : une page pour lister, une page pour afficher le détail) et pour présenter le détail d'un élément. Le client ne fait qu'ajouter une actualité dans la catégorie souhaitée et le reste est automatique Idem pour les autres types de contenus.

Question bête : tu as un robots.txt qui empêche l'indexation de tes pages / sites en test ? Je pense que non Mais oui pas de raison que Typolight pose problème avec la ré-écriture d'url et un code clean.

Salut Nyl Effectivement je n'ai pas encore testé mais formauto ou EFG doivent pouvoir permettre ce type de chose. Encore que, franchement vu le degré de contrôle sur l'affichage des éléments au sein de l'admin (imagine en terme MODxien que tu as d'office ManagerManager intégré dans la gestion des droits) et la finesse des permissions tu peux tout aussi bien envisager de donner un accès au backend. Ceci dit c'est plus pratique d'avoir un formulaire de création de compte frontend et de développer des formulaires customs qui insèrent des données dans les tables du catalogue. Il faudrait regarder plus en détail les posts de Thyon qui a déjà mis ce genre de chose en place. Donc oui c'est sûrement possible. La facilité avec laquelle on peut lier les formulaire à des tables de la base devrait aussi jouer

Et la notice Typolight est publiée sur Framasoft http://www.framasoft.net/article4791.html

Hein ? Dans ce cas là il faut me tapper sur les doigts ainsi que tout les freelances qui bossent dans le même secteur Je pense qu'il faut faire attention à bien distinguer les agences ou les boîtes avec des équipes ou le principe est la spécialisation et les freelance comme moi qui font plusieurs choses : en ce qui me concerne, intégration + graphisme + installation/paramétrage/administration/extension des CMS et applis web. Alors évidemment, pour du développement spécifique je fais appels à des développeurs mais hormis les zones non couvertes par les extensions existantes, je bosse en solo. Quelque soit le cas, je suis en total désaccord sur le fait qu'un intégrateur n'a pas à connaître un CMS, car pour moi l'intégration va jusqu'à l'étape ou l'on créé les templates au format du CMS avec lequel on travaille. Sinon qui assume la conversion d'un template "pur" XHTML/CSS en un template Drupal, SPIP, MODx... ? Probablement pas le graphiste et le dév peut le faire mais ce n'est pas sa spécialité normalement. Pour la meilleure adéquation possible c'est quand même du resort de l'intégrateur... enfin, c'est mon avis !

Côté référencement, je n'ai pas suffisamment de retours mais il n'y a pas de raison que Typolight démérite avec la ré-écriture d'URLs native mais il faut voir côté gestion des 301 et 302. Je n'ai pas encore balayé toutes les extensions il y a peut-être quelque chose de ce côté là...

Bonne analyse, effectivement business is business néanmoins MODx a réussi à percer et il y aura un livre Packt en février 2009, en fonction du succès de celui-ci peut-être une place dans la catégorie reine ? Wait and see... Pas de raison que Typolight ne puisse pas accéder au même chemin. J'espère bien convaincre Leo et booster aussi la visibilité dans la sphère anglophone... Nous verrons !

Ce n'est pas moi qu'il faut convaincre sur ce coup là, c'était juste une remarque

On a pas souhaité présenter MODx cette année... l'année prochaine on aura bien plus de chance avec un nouveau site, Evolution 1.0 et Revolution 2.0 a présenter, cette année est un peu transitoire pour MODx. Et l'année prochaine, on compte bien si ce n'est détrôner les vieux de la vieille au moins les faire bouger sur leurs fondations Par contre, autant je trouve que Drupal mérite d'être considéré comme un des meilleurs CMS actuels, autant je trouve que le jury fait preuve de conservatisme dans les catégories reines en élisant à chaque fois les mêmes... Typolight, à défaut de gagner, méritait largement au moins une 2ème ou 3ème place dans les catégories où il était nommé... Je pense que son seul défaut est la promo de l'outil, et je compte bien y remédier si Leo accepte que je donne un coup de renfort au marketing de TL. Wait and see... Je suis content de voir CMS Made Simple émerger, c'est une bonne chose... mais qui prouve aussi que l'on monte à l'ancienneté chez packt Pour Silverstripe belle victoire méritée, maintenant j'ai envie de dire que l'enjeux pour eux c'est d'amener des développeurs à SS, pour que les extensions dispos s'étoffent car pour l'instant c'est très limité.

Ceci dit, Typolight est entièrement écrit en PHP orienté objet, il me semble Avec MODx on peut faire des catalogues avec les TVs sans toucher à du code aussi, mais c'est moins rapide il faut l'admettre et pour tout ce qui est recherche avancée, filtres, etc... là sous MODx il faut rajouter tvExplorer un peu comme a fait Perrine pour deco-in typiquement le type de site qui est BEAUCOUP plus rapide à mettre en oeuvre avec TL...

Tant mieux si cela t'a permis de lui donner une seconde chance. On attend le site "live" ! Pour rendre à César ce qui est à César si Aour et aussi Perrine ne m'avaient pas poussés à approfondir , je n'aurai pas été aussi loin avec Typolight... Si je n'avais eu un projet pile adapté à TL à mettre en oeuvre rapidement, je n'aurai pas forcémment été aussi loin. Ce CMS mérite d'être plus connu, car il a pas mal de similitude d'un point de vue fonctionnel avec Drupal (multi-lingue, multi-site, versionning...) tout en ayant une conception récente (backend accessible 100% même sans JS ! php5 OO) et un accès moins "geek" à mon sens (doublé d'un meilleur templating). Je vais faire en sorte de réparer ce manque de promo car c'est un excellent outil stable, sûr et flexible ! La notice framasoft que j'ai concocté risque d'amener un peu plus de monde vers TL et sa communauté A une époque j'avais titré un de mes posts "MODx, le SPIP Killer ?" là je pourrai écrire "Typolight, le Drupal killer ?"

Franchement je ne vois pas ce qui sera plus rapide à déployer et plus adapté que Typolight + Catalog + CatalogExt + Taxonomy. modx peut convenir mais avec beaucoup plus de travail en terme d'apprentissage... A mon avis il en sera de même pour SPIP. Après, tu as les classiques (Drupal, Joomla) qui ont peut-être des extensions pour faire ça mais je doute fortement que ce soit aussi flexible qu'avec la formidable combinaison Typolight + Catalog + CatalogExt + Taxonomy. Cette combinaison permet de créer des variables custom avec une interface visuelle super bien faite, stocker les données dans des tables custom crées à la volée, mettre en place des listes templatables côté frontend, un moteur de recherche avancé multi-critères... etc. Exemples de sites qui utilisent cette combinaison de modules : TeamAA National Auto Glass English Sofa Si tu comprend l'anglais lis moi ça et dis moi ce que tu en penses (même si tu ne le lis pas, les captures devraient parler d'elles-même)... http://dev.typolight.org/wiki/ExtensionsCatalog

Perso côté blog je m'intéresse à Habari... plus de news à ce sujet bientôt

Attention je n'ai jamais dit que les gens de WordPress était des copieurs ! Simplement que les grands esprits se rencontrent ou au pire que l'équipe WordPress sait reconnaître les bonnes idées et les reprendre quand c'est pertinent... A moins que vous n'ayez des infos factuelles à ce sujet, mieux vaut éviter d'affirmer ce genre de chose...

Il y a une petite semaine, Jane Wells a publié les screenshots de la nouvelle interface pour WordPress 2.7 qui doit sortir le 10 novembre prochain (on ne chôme pas chez Automattic)... ( http://wordpress.org/development/2008/10/t...l-design-of-27/ ). Si vous voulez en savoir plus sur la démarche de construction de cette nouvelle admin, il y a un autre article à lire (http://wordpress.org/development/2008/10/wordpress-27-wireframes/). Si vous voulez faire un tour dans une démo : http://demo-trunk.wordpress-fr.net/ (Vous remarquerez que la démo n'est pas encore au niveau des screenshots d'un point de vue graphique). Je dois dire que le choix d'une sidebar à gauche au lieu des onglets me fait penser à ... DotClear2 ! Bon OK WordPress a le côté web2.0-isée qui est plus prononcé mais il y a un choix similaire. Quant au Dashboard il me fait penser à Google Analytics ce qui n'est pas une si mauvaise chose Et vous (notamment utilisateurs de WordPress), vous en pensez quoi ?

Si j'étais obligé de bosser avec un environnement .NET en opensource, je n'irai sûrement pas vers dotnetnuke (pas à cause du .NET mais du Nuke-like) mais certainement vers Umbraco ! (le CMS qui anime le site peugeot.com entre autre) Maintenant pour en revenir à la question des coûts, même en admettant que les coûts de développement soient identiques (je ne suis pas assez au courant pour en parler) mon problème avec les solutions Microsoft c'est le coût des licences (je ne parle même pas de la qualité des applications de la suite Office, ou du rapport qualité prix ) et la captivité vis à vis de formats propriétaires de plus en plus complexes (les nouveaux formats .docx et companie). Evidemment on en revient aux arguments en faveur de l'open source je n'invente rien...

Ok je comprend mieux... merci pour les explications. Mais cela veut quand même dire pour un intranet qu'il faut un serveur avec Windows 2003 Server au sein de l'entreprise, on est bien d'accord ? Donc on a une licence serveur OK, et on a pas de licence pour chaque client excepté une licence Windows "normale" et une licence office "normale" ? Par ailleurs quand tu dis tu ne vois pas ce qu'il manque, est-ce que la configuration minimale permet par exemple à des "éditeurs" de valider un contenu, un fichier publié au sein de l'intranet ? Sharepoint est-il "uniquement" en mode "logiciel client" ou alors est-ce qu'on a aussi un accès via une interface web au sein de l'intranet ? Par contre dès qu'on veut proposer des contenus ou des services web à des clients à l'extérieur de l'entreprise (extranet), on est bien obligé de passer à SharePoint Server non ? Quelque soit le cas, on reste dans des optiques qui à mon sens sont coûteuses et rendent prisonnier d'un modèle de données basé sur des formats de fichiers propriétaires et fermés mais bon c'est peut-être un point de vue à réviser mais oui je suis allergiques aux modèles de licence qui cherchent à transformer le client en client captif (typiquement le fait d'inclure IE dans le système d'exploitation et qui malgré le procès fait pour concurrence déloyale n'a jamais été appliqué... on sait quelles sont les conséquences sur le boulot des professionnels du web aujourd'hui... mais c'est un autre débat !).

Le rewriting n'est pas intégré mais il y a un mod : http://mods.mybboard.net/view/mybb-seo Depuis la version 1.4 MyBB a normalement mis en place un système de plugins, et en théorie il n'est pas nécessaire de modifier manuellement les fichiers. Idem pour les templates qui sont actualisé directement par le plugin. C'est vrai que c'est une limitation avec phpBB3 (mais beaucoup d'autres) qui est ennuyeuse Maintenant, je n'ai pas encore eu le temps de vérifier ça je m'étais arrêté à la dernière version 1.2.x ...

Je suis super étonné... de ce que j'ai compris : tu dois disposez d'une licence serveur (là on est OK) Pour activer les fonctionnalités d'entreprise d'Office SharePoint Server 2007,tu dois acheter une licence d'accès client Entreprise en plus de la licence d'accès client Standard. Chaque client doit disposer d'une "licence d'accès client standard" ce qui veut dire que plus tu as de personnes qui accèdent à Sharepoint, plus tu payes cher. Je me base sur http://office.microsoft.com/fr-fr/sharepoi...1655351036.aspx Il faut dire que les termes de licences sont toujours un peu complexes chez MS... Et si on veut rentrer dans des solutions plus "lourdes" alors pourquoi pas Zimbra ?

Effectivement vu les précisions apportées (on n'est plus dans un projet perso là ?) la suggestion de Dadou me semble plus pertinente... Typolight - outre sa flexiblité qui m'impressionne de plus en plus - est aussi un candidat intéressant vu le nombre de type de base de données supportées et son architecture où il est possible d'ajouter facilement de nouveaux drivers... Pour un intranet, je dirai même qu'il est plus adapté que MODx du fait du versionning mais surtout de la gestion des droits (hyper fine) et du fait qu'on peu nativement (sans extension) définir des répertoires de fichier perso par utilisateur ce qui est très pratique. Et pour certains projets, le multi-linguisme et le multi-site sont aussi natifs (donc rapidité de mise en oeuvre et maintenance facilitée). Je ne parle même pas du service de LiveUpdate ou du fait que Typolight propose un moteur de forum écrit sous Typolight en tant qu'extension d'où intégration ultra-simple et gestion unique des utilisateurs Perso, vu la courbe d'apprentissage je laisserai de côté eZpublish (qui n'a pas de fonctionnalités supplémentaires par rapport à Typolight), et vu la lourdeur et l'interface qui date de mathusalem, je laisserai de côté Typo3 (les dizaines de milliers d'euros de développement tu peux les mettre ailleurs )