SPIP Blog
Drupal et mySQL sont sur un serveur...Je suis tombé un peu par hasard sur un article du blog de la société Adyax, où un des développeurs explique comment il a résolu ses problèmes de charge SQL sur un site Drupal qui venait d’être mis en ligne.
Curieux par nature, et toujours à la recherche de bons conseils, je lis alors l’article en détail, espérant trouver l’une ou l’autre astuce transposable à mon travail.
Je vous donne le lien vers l’article qui n’est plus disponible à l’heure où j’écris ce billet [1], et donc le lien vers le cache de votre moteur de recherche préféré vous permettra de le lire.
J’ai tiqué d’abord sur la difficulté qu’a eu le développeur à trouver la requête fautive, un peu étonné que Drupal n’offre pas un outil comparable à ?var_profile=1&var_mode=calcul qui permet d’un coup d’oeil d’avoir l’ensemble des requêtes SQL lancées au calcul d’une page :
- classées par temps total d’execution (soit la somme des temps de chaque execution si la requête est appelée plusieurs fois)
- avec la requête exacte, ce qui permet de la rejouer à la main
- avec la référence à la boucle qui produit cette requête, ce qui permet de la retrouver dans le code
Puis j’ai vu la requête fautive, que je vous remets ici juste pour le plaisir :
Pourquoi tant de haine ?
Ce que je crois avoir compris de l’article (si un expert Drupal est dans la salle, qu’il n’hésite pas à me corriger sévèrement :p si j’ai tout faux) est que ce genre de requête est générée par le célèbre et très usité module views de Drupal qui sert à construire des listes. Et que cette requête est le résultat d’une concaténation de plusieurs conditions et jointures chacune ajoutée par le(s) dévelopeur(s) à travers le système de hook de Drupal.
De toute évidence ce système conduit à la génération d’une requête qui n’est pas optimisée.
Avec un peu de réflexion, cela se comprend : si la requête est construite à chaque service de la page, il n’est pas raisonnable d’ajouter à ce coût de construction de la requête un coût d’optimisation (qui par nature est toujours important) qui ne sera rentable que sur des grosses requêtes.
D’où le résultat.
Et SPIP alors ?
vous demandez-vous, fort interloqué que le nom de votre outil préféré n’ait pas encore été cité sur ce blog pourtant franchement partial, d’habitude.
La différence fondamentale de SPIP par rapport à autres outils est son système de boucle. J’ai déjà eu l’occasion de vous vanter l’avantage de cette sur-couche que certains développeurs PHP exècrent pourtant méthodiquement.
Profitons de l’occasion pour voir une nouvelle fois d’autres avantages de cette sur-couche.
Des requêtes « préparées »
Un des premiers avantages est que les squelettes de SPIP sont « compilés » à l’avance (le terme de compilation est ici inexact mais a l’avantage de bien faire passer l’idée) : l’ensemble des squelettes est converti en code PHP et en requête SQL une fois pour toute.
Du coup, il est acceptable de payer le coût d’un certain nombre d’optimisations : lorsqu’un champ demandé nécessite une jointure, il est par exemple possible d’analyser la requête déjà construite pour vérifier que la jointure nécessaire n’est pas déjà là. Et de ne l’ajouter que lorsque c’est nécessaire.
Des critères optimisés
Un grand nombre de critères existent nativement dans SPIP qui permettent la sélection des données dans les boucles. Ces critères ont pu être optimisés pour que la requête produite soit optimale en général.
Une optimisation systématique
À un développeur qui me disait dernièrement : je préfère faire mes requêtes à la main car je peux et je sais les optimiser
, j’ai fait remarquer que oui, sûrement : un bon développeur peut optimiser une requête mieux que n’importe quel outil.
Mais un site est le produit de centaines, voire des milliers de requêtes générées.
– combien le bon développeur en optimisera-t-il vraiment ?
– combien de requêtes avez-vous pris le temps d’optimiser sur votre dernier projet web ?
– comment savez-vous que ce sont les requêtes qu’il était le plus intéressant d’optimiser ?
À votre avis, sur un site qui compte un millier de requêtes différentes, qu’est-ce qui est plus intéressant :
– avoir un outil qui gagne gratuitement, et sans effort, 1 % de charge sur chaque requête SQL ?
– avoir un bon développeur qui est capable de gagner 50 % de charge sur 1 % des requêtes après 2 jours de travail ?
Le grand intérêt d’un outil qui optimise les requêtes est qu’il le fait systématiquement.
Des outils d’analyse
Avoir une optimisation de base systématique des requêtes SQL n’empêche pas d’utiliser intelligemment votre développeur. Et pour ça l’outil d’analyse des requêtes d’une page ?var_profile=1 est redoutable [2].
En effet, en listant toutes les requêtes lancées pour le calcul d’une page classées par temps d’execution, il mets en avant les 2 ou 3 requêtes qui vous génèrent 50 % du temps de calcul. Et il devient très confortable de faire travailler vos neurones (ou ceux de votre développeur expert) sur ces quelques requêtes, en mesurant tout de suite les gains obtenus.
Des possibilités d’optimisation
En effet, les requêtes ne sont pas écrites directement, mais sous forme de boucles. Lorsqu’une requête peu performante est trouvée, il est alors possible de modifier l’implémentation de la boucle et/ou du critère qui provoque cette requête.
La surcouche n’exclut donc pas du tout les optimisations manuelles, mais vous permet en plus d’optimiser d’un seul coup toutes les boucles semblables, sans avoir à repasser dans tout le code de votre projet pour appliquer la même optimisation partout.
La cerise sur le gâteau
Last but not least, comme disent nos amis américains. Le système de cache de SPIP.
Une autre grande différence de SPIP avec d’autres CMS, comme l’excellent Drupal, est son système natif de cache. Il s’agit, au demeurant, d’un avantage direct de son système de squelettes. Lorsque le résultat d’une page a été calculé (les requêtes SQL évaluées, le php executé...) pourquoi recommencer la seconde d’après si les données en base n’ont pas changées ?
Avec SPIP 2.0, le système de caché a été simplifié pour plus d’efficacité. Exit toute l’artillerie complexe, et décriée à raison par certains hébergeurs, qui visait à deviner si les données d’une page avaient changées ou non. La règle est simple :
– les données éditoriales n’ont pas changées depuis le dernier calcul de la page ? Hop SPIP la ressert sans plus de formalité, à la vitesse de l’éclair.
– les données ont changées : pas de problème, SPIP évalue le PHP préparé, avec ses requêtes déjà construites. Vous n’avez rien perdu par rapport à d’autres CMS.
Du coup, SPIP est capable de tenir le choc face à un buzz qui voit plein de monde arriver sur une page tout d’un coup. Là où d’autres CMS souffrent. Souffrent. Et tombent.
SPIP, pour un site qui fonctionne à moindre coût
Je crois que vous avez un peu compris où je voulais en venir.
Sérieusement, au delà de l’effet de mode dont certains CMS comme Drupal bénéficient, il ne faut pas perdre de vue les fondamentaux techniques lorsqu’on choisit un outil.
L’utilisation de Drupal comme plateforme est souvent justifiée par les prestataires professionnels par son efficacité supposée en terme de développement et de coûts associés.
Si tant est que cela serait vrai, j’ai quand même envie de rappeler que le coût de fonctionnement d’un site peut très vite devenir beaucoup plus important que le coût initial de développement.
Et de finir en boutade, avec un fond de vérité :
Pour construire un site qui fonctionne à moindre coût, choisissez SPIP.
Pour vendre des jour.homme, choisissez Drupal.
Messages
11 juin 2009, 22:09, par Stanislas
Merci Cédric pour cet article très intéressant.
Est-ce à dire que la révision du cache rend le plugin fastcache de Fil inutile sur spip 2 ? J’attendais de retrouver tous les plugins que j’utilise... et là je me dis que Fastcache pour spip 2 ne viendra jamais... s’il n’a plus lieu d’être... :)
11 juin 2009, 22:37, par cedric
Le plugin Fastcache de Fil (comme le plugin Expresso que j’ai développé en parallèle sur une autre méthode :p), apporte un niveau supplémentaire de cache en pur html.
Très honnêtement, ces outils sont surtout prévus pour être utilisés de manière transitoire pour donner un degré de liberté supplémentaire et faire face à une surcharge temporaire (pic prévisible mais sans avoir la liberté de remettre en cause son infrastrucure, réduction de charge en attendant un changement d’infrastructure).
Ils ne sont pas nécessairement applicables sur toutes les pages, ni dans tous les cas. Il n’est donc pas très sain de faire reposer la performance du site en régime stabilisé sur ces outils qu’il faut plutôt réserver aux urgences.
Je ne sais pas dire si l’un ou l’autre des plugins tourne avec SPIP 2.0, mais le cas échéant le portage n’est pas forcèment très lourd. Et leur intérêt reste complet, y compris avec SPIP 2.0, dans le cadre que je viens de donner.
11 juin 2009, 23:25, par Maxime TOPOLOV
Le système de cache de SPIP est simpliste et ne correspond pas à la complexité des sites actuels. On parle de « contenu éditorial » qui n’aurait pas changé... Mais cela n’a plus de sens pour, ne serait-ce qu’une page d’accueil. Pour peu qu’il y ait un agrégateur de fil RSS, des espaces de mise en avant automatisés et des blocs avec les derniers commentaires / inscrits sur le site : la page sera rechargée trop souvent....
Les bonnes pratiques mettent en place un cache exprimé en durée en fonction de divers critères (URL ou profondeur de la page). C’est le cas chez Akamai, par exemple... On paramètre la page d’accueil à 5 min, les pages du niveau 1 à 20 min, niveau 2 à 3 heures etc....
En suite, le système décrit n’est pas du tout adapté à du contenu généré par les utilisateur en mode connecté. Comment compiler le squelette d’une page constituée de plusieurs blocs affichés de manière dynamique selon tout un tas de critères ?
L’optimisation AUTOMATIQUE de requêtes est une absurdité totale. Aucun intérêt réel pour le serveur, on sait depuis long temps que le seul système qui fonctionne en termes d’optimisation est un bon système de cache intelligent, qui ne soit pas en base (cf. intégration de Drupal avec Memcached, chez Rue89.com par exemple). Pour des applications spécifiques, l’optimisation par un DBA est une obligation. Il faut comprendre la structure des données, analyser le plan d’exécution des requêtes, bref, c’est un travail complexe qui est rarement accompli par les développeurs eux mêmes (sur tout si l’on est plus sur MySQL, mais DB2 ou Oracle par exemple).
Aujourd’hui l’optimisation des requêtes en base pour un site normal est INUTILE (pas une application web, dont l’usage spécifique la rend intéressante pour l’optimisation).
Tout d’abord parce que 80% des pages sont servies depuis le cache du CMS (ici les gagnants sont Typo3 & Drupal avec loin derrière ezPublish dont le système de cache fait souvent planter MySQL ou SPIP trop simple est pas adapté aux besoins de gros sites d’aujourd’hui).
Si le trafic augmente encore, il faudra de toutes manières passer sur un CDN (Akamai, par exemple).
Encore une fois les CMS, dans les appels d’offres, sont choisis sur FONCTIONNALITÉS. Or, je pense, que vous serez d’accord pour dire, que de ce coté SPIP est loin derrière... non ?
PS : Merci pour avoir remarqué que le blog n’est plus accessible (suite à une migration de serveur, petit problème de .htaccess)
12 juin 2009, 00:25, par cy_altern
disons que la seule chose sur laquelle je suis d’accord pour dire que SPIP est loin derrière c’est le nombre d’alerte de sécurité par semaine sur la mailing-list du CERT...
12 juin 2009, 01:21, par cedric
Il est bien évident qu’il ne faut pas attendre des vendeurs de hardware (ou des vendeurs de services associés) qu’ils militent pour que le soft consomme moins de ressources.
Et l’histoire montre que, quel que soit le domaine technologique, c’est toujours lorsqu’on est contraint par les ressources qu’on fait preuve de l’ingéniosité nécessaire pour réduire sa consommation.
A ce titre, SPIP bénéficie d’un contexte favorable : en gardant sa vocation d’outil utilisable par toute structure militante, à faible budget de fonctionnement, il évolue sous la contrainte permanente du coût des ressources systèmes. Et contrairement à ce que vous évoquez, son système de cache interne et de calcul des pages fonctionne parfaitement dans le contexte de sites participatifs, ou de contenus profilés, changeants etc ... J’ai volontairement gardé mon propos simpliste dans les explications de mon article, mais croyez moi (et des applications en production le montrent tous les jours).
Quand aux fonctionnalités, c’est un vaste débat. Il me semble que le module Views indispensable à tout site Drupal ne permet rien d’autre que ce que permet l’écriture d’un squelette dans SPIP, éventuellement modularisé sous forme de modèles. Certes, le niveau d’abstraction n’est pas le même, mais le procédé n’est pas moins propriétaire que les boucles de SPIP dans le sens où il est spécifique à l’outil.
En terme de qualité de code, SPIP à énormément progressé, et je ne suis pas certain que le souvenir que vous en avez soit encore représentatif de l’état de l’art.
De ce fait, il est de plus en plus facile et rapide d’implémenter des fonctionnalités qui parraissaient hier encore impossible à SPIP.
Pour ne prendre qu’un exemple, je citerai la polyhierarchie multi arborescente que ce site http://www.cuisine-libre.fr/ illustre très bien. Un serpent de mer pour l’architecture de l’information de sites complexes, sur lequel SPIP a longtemps été incapable de proposer des solutions satisfaisantes, et qui peut maintenant se traiter simplement et de façon générique.
Sur l’aspect DB, là encore c’est un domaine où SPIP a énormément progressé en assurant le support de SQLite, PostgreSQL et mySQL (et je crois savoir que le portage Oracle n’est pas très loin).
Alors certes, la communauté autour de SPIP ne sera jamais de la même taille que celle autour de Drupal, au niveau mondial au moins.
Mais contrairement au discours ambiant qui tend à proclamer que hors Drupal plus de salut, et que SPIP est mort, ce dernier fait mieux qu’agoniser. En mutant et en évoluant à sa façon il a su proposer des solutions techniques alternatives intéressantes qui permettent d’aller très loin avec moins de technicité apparente.
J’ai la conviction que, comme chez les médecins, il y a les informaticiens qui aiment à déployer force technicité et langage complexe pour marquer leur supériorité présumée, et ceux qui sont capables de se mettre au niveau de leurs interlocuteurs et à la portée de leur public. Ce sont rarement les plus mauvais.
Il me semble qu’on retrouve un peu cette typologie, cette différence entre Drupal et SPIP, et qu’on voudrait nous faire croire que c’est la preuve d’une supériorité certaine du premier, en confondant un peu vite la technicité affichée avec les capacités intrinsèques.
Cela dit, j’ai aussi bien compris que ce discours permettait certainement de vendre plus facilement des jour.homme. C’était le sens de ma conclusion.
12 juin 2009, 09:07, par Maïeul
A bon ?
Oki, donc citez moi un CMS qui permette :
– de citer rapidement la Bible sur son site
– de mettre facilement des jeux types Mot-croisés, QCM
– de mettre des formulaire de calcul élèctoral
bon, oki, je triche, c’est moi qui ai développé c’est trois plugin. Mais les aurai-je développé avec Drupal ? Je doute car le système de squelette de SPIP m’a considérablement simplifié la tâche...
et puis SPIP a à mes yeux un gros avantage : il est d’abord Francophone-> résultat la doc la plus récente est en FR... ce qui a l’époque de l’anglais omniprésent fait un grand bien
12 juin 2009, 09:16, par cedric
@Maieul : Je ne suis pas sûr que les fonctionnalités que tu propose soient très demandées, hein ...
12 juin 2009, 10:23, par cvallois
histoire d’étayer un peu le propos et d’avancer, pourrais tu nous dire quelles sont les fonctionnalités présentes chez drupal et absentes chez spip, il est possible que pour certaines fonctionnalité ce soit plus un défaut de documentation ou de mise en avant plutôt qu’une absence des dites fonctionnalités.
de plus, développant des sites pour des associations ou des écoles, on me pose souvent la question : mais pourquoi spip et pas wordpress ou joomla ou drupal ?
et ma réponse n’est pas technique ( ou ils s’en foutent ou je leur parle chinois) mais philosophique : ce n’est certes pas un hasard si nombre de syndicats, d’associations et de mouvements d’idée ont choisi spip pour leur site.
Il n’y a pas que la technique dans la vie et l’on a droit de faire un choix politique : celui d’un logiciel dont la philosophie s’adapte parfaitement à la philosophie associative : collaboration, entraide, participation...
et sans dénigrer les autres.
« Je ne suis pas d’accord avec ce que vous dites, mais je me battrai jusqu’au bout pour que vous puissiez le dire. » Voltaire
12 juin 2009, 13:59, par Maïeul
@cerdic
je suis convaincu effectivement qu’elles ne sont pas très demandé ... et alors ?
12 juin 2009, 14:26, par Valéry
En effet les fonctionnalités sont importantes mais le choix n’est pas nécessairement quantitatif, ce qui compte c’est surtout les fonctionnalités dont un a besoin pour un projet plus que le total des fonctionnalités disponibles sur une application. SPIP s’avère largement suffisant pour la moitié des projets auxquels je suis confronté (pour les autres nous utilisons Typo3 également très puissant).
Dès lors que le besoin fonctionnel est couvert, ce sont d’autres critères qui sont pris en compte, par exemple l’utilisabilité des interfaces utilisateurs, la disponibilité de la documentation, l’évolutivité de l’outil, etc. SPIP reste très bien positionné sur tout ceci.
Enfin en terme de fonctionnalités il est également de plus en plus simple d’en ajouter par le développement d’un plugin pour prévoir ce qui pourrait manquer sur un projet particulier.
12 juin 2009, 16:41, par totoro
Je tenais à souligner aux lecteurs non-spipeurs que les principaux points techniques « reprochés » à SPIP sont (en partie seulement) valides... pour les anciennes version : <1.8.X> http://fr.wikipedia.org/wiki/Fear,_uncertainty_and_doubt] pour rien.
13 juin 2009, 00:56, par esj
Quand on lit des affirmations non étayées comme celles-ci, on peut être certain que l’auteur défend des intérêts personnels. Le CV de ce monsieur nous apprend qu’il vend du management d’équipes de développement basées dans les pays de l’europe de l’est. On comprend donc pourquoi il attire l’attention par des majuscules sur le mot « automatique » qu’il qualifie d’absurde : il ne faut surtout pas que ses clients viennent à penser qu’un bon système qui marche tout seul est plus intéressant qu’un mauvais qui a besoin de personnel pour l’optimiser.
Depuis que l’informatique existe, il y a toujours eu tout un tas de gens pour expliquer que toute une partie du boulot des informaticiens ne peut être fait par un ordinateur. Ne pas avoir à programmer à la main le processeur était qualifié d’utopie. On sait ce qu’il en est advenu.
Mais Cédric, tu n’aurais pas dû dire que le terme de compilation est inexact, car c’est bien de cela qu’il s’agit.
13 juin 2009, 07:04, par neutral
SPIP est très très sympatoche en tant que CMS des copains mais Drupal a un potentiel beaucoup plus grand.
SPIP est franchement à la traine sur de nombreux points :
– toujours pas de REST ou même de XML-RPC (très très gros handicape pour rester jeune)
– gestion des identités pas franchement reluisante
– système de workflow incomparable avec celui de Drupal
– multi-sites moins efficace que celui de Drupal
– internationalisation très sommaire
– gestion des medias plus que light en natif
– gestion des documents … passéiste ?
– backoffice un poil poussiéreux
– peu de prospective (FOAF, opensocial, taxonomie, …)
– template usine pas très sexy
– pas vraiment de cadre de tests unitaires proposés
– modularité spartiate et pataude
– …
La mécanique de SPIP tourne plutôt bien, le système de templating plutôt bien pensé, et de nombreuses fonctionnalités ornementales autour du text et de l’image sont plutôt bien foutues.
Mais mais, comment envisager monter avec SPIP (sans pulvériser le core à tous les étages) des gros sites avec du trafique en masse (par ex MTV), des réseaux sociaux, des plate-formes médias ou des intranets avec workflow avancé ? Peut-être que certains commerciaux survalorisent les chantiers de certains projets web (en vendant du Drupal mass-costo pour du simple portfolio) mais il faut bien se rendre à l’évidence : SPIP ne sait franchement pas tout faire (malheureusement :-)).
13 juin 2009, 09:05, par Maïeul
et après, tu parle de
Je n’ai rien compris à ces trois termes anglais ... parlez français, non d’un chien
13 juin 2009, 10:20, par esj
C’est un peu moins à l’emporte pièce que le message précédent, mais ce florilège d’adjectifs ne dit rien sur le fond. Ce manque de précision conduit à une contradiction au moins apparente : comment les « templates » peuvent-ils être à la fois « pas très sexy » et « bien pensés » ? Et en quoi SPIP n’est-il pas REST depuis la version 1.9 ? Enfin, le « en natif » dit bien la limite de la critique : Drupal en natif est encore plus petit que SPIP, est-ce que la comparaison se fait bien entre les deux noyaux, ou entre le noyau de l’un et l’ensemble des extensions de l’autre ? Bref, il y a de la matière dans ce message, mais elle est inexploitable en l’état.
13 juin 2009, 13:45, par cedric
Pour le traffic de masse, je me permet de comparer ton exemple avec le site de http://www.france-info.com, réalisé en SPIP (1.9.2 qui plus est). Projet réalisé sans toucher au core, qui montre un beau potentiel en terme de traffic : http://www.alexa.com/siteinfo/www.mtv.fr+www.france-info.com
Je serai curieux de comparer les architectures matérielles qui sont déployées derrière ...
Pour le réseau social, voici un exemple de communauté autour du vin, qui intègre un lien avec facebook via l’api http://www.obiwine.com. Projet réalisé sans modif du core, encore une fois, et qui a été l’occasion de mettre en place des facilités de développement des briques ajax au sein de SPIP.
A ce sujet, je suis prêt à parier que SPIP est la plateforme sur laquelle il est actuellement le plus rapide de mettre en place un formulaire de saisie géré en ajax (vérification de la saisie, traitement des données) qui fonctionne sur tous les navigateurs et se dégrade sans problème sans javascript. En fait, cela tiens en deux lignes à ajouter une fois que le formulaire fonctionne sans ajax :
Ce qui, pour le lot quotidien des développeurs d’application web 2.0, est assez en rupture...
Certaines critiques sont fondées :
– la gestion des identités reste à remettre au gout du jour, avec les facilités que cela suppose en terme de méthode d’identification
– le XML-RPC n’est pas disponible, il reste à implémenter sur les méthodes REST qui elles sont bien là
– la gestion des documents date
Mais d’autres critiques témoignent d’une méconnaissance de l’actualité de SPIP
– la gestion des médias et des documents est en pleine refonte, avec un certain nombre de fonctionnalités déjà utilisables en plugin pour SPIP 2.0 http://www.spip-contrib.net/Mediatheque
– le back office est en pleine réécriture et bénéficie même dans la version en développement d’un système de skins http://trac.rezo.net/trac/spip/chan... et http://zone.spip.org/trac/spip-zone...
– la modularité est déjà très grande via le système de plugins, et va même être exploité pour modulariser le core lui même : SPIP Core : tout change, rien ne change !
Il me semble donc lire dans ces critiques beaucoup de préjugés ou d’avis qui datent un peu par rapport à l’évolution actuelle de SPIP.
Une conclusion prudente de cette discusion pourrait être qui est sans doute temps de (re)découvrir SPIP, non ?
13 juin 2009, 14:36, par Spip
SPIP ou Drupal , j’hésite toujours !
13 juin 2009, 16:24, par Alexandre
Sur les 50 appels d’offres de gros sites (sociétés du CAC40, budget dev > 100 K€, ...) Aucune, je dis bien AUCUNE proposition sous SPIP.
On voit :
1. Drupal
2. ezPublish
3. Typo
Meme Joomla n’est plus proposé alors qu’il y a 1 an c’etait encore le cas.
Je constate simplement le mouvement.
Question fonctionnalités au SPIPiens :
– Comment gérer un workflow complet de publication d’un contenu ?
– Comment gérez vous un site en 3 langues (Menu, taxonomie, contenus...) ?
– Comment construire du contenu avec des champs spécifiques ?
– Comment gérez vous les fonctionnalités : Devenir un ami, activité de ses amis, ?
– Comment gérez vous des boutiques eCommerce avec SPIP ?
– Comment gérez vous la génération automatique d’URL propres dont on peut utiliser des morceaux pour contextualiser les blocs et contenus des pages ?
– Comment gérez vous la construction de pages en agencant des blocs sans code (cf. Panels chez Drupal).
Voila :)
13 juin 2009, 17:34, par cedric
– Pour un site en N langues, SPIP intègre nativement les outils de gestion des traductions des contenus, et tout ce qu’il faut pour contruire un site multilingue. A ce titre http://www.taize.fr est un bon exemple
– Pour du contenu avec des champs spécifiques : le développement et l’intégration d’objets spécifiques (avec tables sql physiques) est devenu très simple, et l’ajout de champs spécifiques au contenu existant l’est encore plus. D’autres outils comme le plugin F&T permettent de créer des objets virtuels et de les configurer directement depuis l’interface...
– Pour avoir des amis, j’utilise personnellement le plugin « Amis » sur http://www.obiwine.com
– Pour faire une boutique eCommerce, il y a un connecteur avec Thelia, un plugin dédié echoppe en cours de développement. Personellement, sur http://www.love-intelligence.fr j’ai utilisé F&T pour créer tous les contenus spécifiques dédiés (catalogue, clients, offres d’abonnements ...), et du dev technique spécifique pour définir les comportements.
– Pour la génération d’URL propres, c’est natif dans SPIP, avec une gestion arborescente également, donc chaque segment contextualise nativement l’ensemble des blocs et contenus de la page
– En ce qui concerne le module Panels, je doute réellement qu’un professionnel appuie sa prestation (ou sa réponse à appel d’offre...) sur un module dont je lis qu’il est selon les versions « more or less unmaintained », « It works sort of, but not very well », ou « currently it is rocky » (http://drupal.org/project/panels). Si l’on parle de quelque chose de ce niveau là, alors il y a des propositions fonctionnelles équivalentes dans http://www.spip-contrib.net/Le-plugin-ACS ou http://www.spip-contrib.net/Le-plugin-Magusine.
Voilà.
13 juin 2009, 19:07, par Valéry
@cedric :
– Contenus et champs spécifiques : mais comme tu aimes à la rappeler F&T n’existe pas pour SPIP 2.0 et il n’y a pas d’équivalent. F&T est du reste imparfait au sens où les interfaces créees sont très différentes des interfaces habituelles de SPIP ce qui pose quelques problèmes d’utilisabilité. Pas de solution mature je dirais. La possibilité d’afficher les nouvelles tables voire les contenus d’autres applications dans SPIP 2.0 reste très impressionante.
– Le plugin Amis ? Je ne le connais pas. Il est disponible ou a été développé spécifiquement pour ce site ?
13 juin 2009, 20:18, par esj
Soit, mais quelles conclusions en tirer ? Pour prendre un seul exemple parmi une quantité d’autres, pendant les années 90 il a été martelé qu’Apple était à l’agonie, qu’il ne pouvait survivre face à la lame de fond de l’OS désormais le plus utilisé etc etc. On sait ce qu’il en est aujourd’hui, et combien cette vieille marque paraît plus moderne que bien d’autres nées après elle (et bien qu’elle ait beaucoup de défauts néanmoins).
SPIP a été pionnier en son genre, et c’est le genre de qualité qui a toujours pour effet de cacher les autres qu’on peut avoir. Libre à chacun de ne pas lever le voile.
14 juin 2009, 06:01, par neutral
@Maïeul
Que diable, francisons PHP, CSS, HTML qui emploient des termes anglophones totalement incompréhensibles. Non, non je ne vais pas que dire que l’une des grosses ‘faiblesses’ de SPIP est justement de ne pas être écrit en anglais (frein à une communauté de développement plus grande).
@esj
Les adjectifs employés étaient relativement mesurés. Mais je vous accorde qu’il n’est pas toujours facile de pouvoir être critique et objectif sur le fruit de son labeur.
Je faisais une distinction entre les templates html (donc les thèmes en français) mis à disposition par la communauté et le pseudo-language de templating (les boucles).
Spip & REST je suis curieux d’avoir des retours d’experiences/d’utilisations de REST dans un cadre tout-Spip. M’enfin, je vois mal comment faire une API publique à la twitter/ delicious/… avec Spip.
@cedric
Franceinfo, l’huma, ecrans, ..certes mais il n’y a pas de tonnes de sites sous Spip à grosse montée en charge. Vois-tu dailymotion (sans entrer dans les détails multi-serveurs) sous Spip ?
Seulement une maigre poignet de tentatives de sites communautaires développés sous SPIP. Monter un site/réseau ‘social’ sous SPIP relève un peu du sport de combat, possible mais assez extrême. Obiwine c’est un peu l’exception : comment montrer qu’il est possible de gravir le Mt Blanc en espadrilles…
Très bon point pour la class ‘ajax’, mais cela ne fait pas pour autant de Spip le meilleur CMS PHP du monde libre.
Pour la gestion des médias / du backoffice et de la modularité je parlais au présent (sur la version stable du moment).
‘Pour un site en N langues, SPIP intègre nativement les outils de gestion des traductions des contenus’
=>possible mais en bricolant. Taize.fr n’est franchement pas l’idéal des solutions multilingues ! Spip ne propose qu’une internationalisation des articles, pour les rubriques et tout le reste cela relève de la bidouille. Mais peut être est-ce du au fait que Spip ne parle que le français ? (mo/po ?)
‘faire une boutique eCommerce, il y a un connecteur avec Thelia’
=> bien et pratique pour des petites boutiques, pour du ‘petit’ commerce. Mais pas très sérieux pour des ‘gros’ projets à forte envergure (Houra en Thelia, yeah).
Spip se retrouve à la croisée des chemins : bon CMS mais qui présente pas mal de retard sur des solutions aux périmètres proches. Pas vraiment framework (zend, symphony, cakephp du coté de PHP, Django ou des solutions en RoR gèrent cela beaucoup mieux), pas franchement moteur de blog (difficile de rivaliser avec WP sur ce secteur), pas hyper cross-généraliste pluriel (typo3, EzP, Drupal,..), pas super tendance flashy-groovy-trendy (Modx, CMS made simple,…). Spip sait bien faire du webzine (il est conçu pour cela) et du site de présentation mais il n’est pas forcement adapté à tous les usages/les demandes/les possibles.
La force de Spip (sa simplicité de mise en bouche) en fait sa faiblesse sur des projets de taille. Pour un chef de projet il est assez difficile de recommander Spip pour des projets qui nécessitent par exemple l’usage d’un workflow avancé (et ne me dites pas que tout cela est possible avec le plugin autorités et beaucoup d’amour). L’une des vraies forces de Drupal est, justement, de proposer un gestionnaire des droits d’accès hyper efficace (plus sexy et plus simple que celui de typo3) ce qui permet de modulariser le backoffice en fonction de profils totalement différents (quasi impossible de reproduire cela avec Spip sans customiser à outrance).
Spip c’est du bonheur, de la confiture, un parfait ‘esprit’ GNU et de la lutte des classes, mais Spip accumule aussi beaucoup de lacunes et de lourdeurs issues d’un autre âge/une autre époque. Spip fait très bien son boulot (pour des particuliers, des assoc, des instances publiques/entreprises à projets petits/moyens …) mais ne crée pas la tendance (pas encore ?), ne révolutionne pas le monde des CMS (pas encore ?), et ne parle pas tellement aux jeunes loups du code (uniquement français) qui voudraient s’impliquer dans un projet opensource innovant (MVC ?, tests unitaires ?, PDO ?, sémantique (RDF,FOAF,SPARQL (http://drupal.org/project/sparql) ?, plan de route/motivation ?, mashup(isation) ?, …). Spip est à l’aise dans ses query sur de la confection de monde-diplo like mais l’est beaucoup beaucoup moins sur (par exemple) de la mise en place de réseau oèèb2.0-(je gère ma tribu) facebook like.
Et de finir en boutade, avec un fond de troll-vérité :
Spip, c’est bien mais Tim Berners-Lee ne l’utilise pas (http://drupal.org/node/41322)
14 juin 2009, 07:50, par esj
Pour le workflow de SPIP, oui ça fait longtemps qu’on a diagnostiqué que son côté figé qui en facilite la prise en main pour un Webzine est un handicap quand on l’utilise pour autre chose. Ca fait partie des chantiers prévus mais toujours différés jusqu’à présent.
Pour ce qui est du MVC, ça a été un des changement de la 1.9. Il y a encore des scories mais l’essentiel y est.
Pour PDO, alors là je rigole. L’interface de PHP avec les serveurs de BD était un sacré foutoir, surtout comparé avec d’autres langages comme Perl. Avec PDO il y a enfin une harmonisation des noms, en passant par de l’Objet. Toujours ça de pris. Mais ce nommage homogène n’apporte pas grand chose sur le fond, toutes les différences entre les serveurs SQL restant à gérer à la main (car le « standard » SQL, est un sous-ensemble réduit de ce qu’on demande à ces serveurs, qui sont incompatibles hors du noyau). Or une des raisons de la sortie tardive de SPIP 2.0 est justement la mise en place du serveur virtuel SQL de SPIP, qui offre un niveau d’abstraction bien supérieur à PDO. Après sa mise au point pour PostGres, le portage sur SQLite2 et SQLite3 se sont faits en un clin d’oeil. Alors l’interface avec SPARQL et le reste, çà ne fait pas peur à SPIP.
Wait and see.
14 juin 2009, 11:04, par cedric
@neutral : je veux bien que l’on parle au présent pour SPIP, mais alors évitons d’argumenter sur la base de fonctionnalités Drupal encore en dev et non utilisable sérieusement en production (SPARQL, Panels ...)
En ce qui concerne la couche d’abstraction de serveur SQL, je ne peux que souscrire à ce que dit esj. A titre d’exemple, j’ai réalisé une implémentation FQL (Facebook Query Language) assez facilement qui permet de requêter directement FaceBook avec le langage de boucle de SPIP.
En ce qui concerne le nombre de gros sites sous SPIP, je suis d’accord avec toi qu’ils ne sont pas légions. Ça n’est que le reflet de la mode actuelle pour d’autres CMS comme Drupal. L’objet de mon billet était justement d’aborder les problèmes de charge sous un point de vue technique et de montrer que SPIP a des armes tangibles qui en font une plateforme robuste et viable sur ce point.
Pourquoi ne pas aller plus loin et ouvrir un index relatif des gros sites en recensant simplement le CMS utilisé, et l’architecture serveur derrière (ou même déjà le nombre de machines avec leur caractéristiques sommaires) ? Pour le trafic relatif des uns par rapport aux autres, référons nous à Alexa, ce qui évite de devoir donner des informations que d’aucuns jugent sensibles. Un tel index serait profitable à tout les acteurs autour des CMS libres, non ?
Pour ce qui est d’un site social avec SPIP, je peux t’assurer que ça n’a rien de la montée du mont blanc en espadrille. En faire toute une histoire me fait un peu rigoler devant le simplicité du code qui est derrière. En témoigne le plugin amis que j’ai publié sur la zone suite à notre discussion, et qui implémente toutes les fonctionnalités nécessaires à la gestion des amis pour écrire les squelettes d’un site social web 2.0 etc ... (et qui va même plus loin que ce que j’ai vu jusqu’ici autre part, car capable d’inclure les relations amicales définies par une plateforme sociale externe telle que FaceBook).
Pour la gestion des droits, l’API autoriser permet de customiser une très grande partie de l’espace privé sans bidouille (et c’est encore plus vrai avec la version en cours de dev ou le plugin bandeau pour SPIP 2.0).
Alors, oui SPIP n’est plus à la mode, et pas encore revenu à la mode (on sait tous la furieuse tendance qu’ont les modes à tourner en rond...).
Mais ce n’est pas une raison pour s’incliner devant la toute puissance présumée des CMS dans le vent, et de se dispenser de mettre le doigt sur les forces de SPIP et de montrer qu’il à des cordes à son arc qui peuvent en faire un outil de choix, avec des arguments techniques valables.
Et oui aussi, tout n’est pas rose (mais quel outil pourrait prétendre le contraire ?). SPIP a une histoire et ne pas repartir d’une feuille blanche est parfois un gros handicap dans la refonte et la reforme des fonctionnalités. Mais c’est aussi une des grosses forces de SPIP que de continuer à évoluer et à muer tout en assurant la compatibilité avec des sites développés 5 ans plus tôt, et d’en assurer la migration des bases de données.
Tous les CMS (ni même moteur de blogs) ne peuvent pas en dire autant quand il s’agit de changer de version majeure.
Alors certes, le code de SPIP (qui n’utilise pas les objets, ce qui n’exclue pas pour autant la programmation objet) n’est pas tendance quand il s’agit de frimer dans les réunions geek.
Mais ses vocations premières sont avant tout de servir les utilisateurs, d’optimiser les performances, et d’être facilement accessible par des développeurs de tout niveau. C’est un autre combat, mais pas moins glorieux.
Comme dit esj, mais en plus proactif, Work and see.
15 juin 2009, 13:44, par raf
petite question, sans doute un peu hors de propos, sans doute avec une réponse sur un des innombrables sites de spip...
Ne serait-il pas profitable d’avoir quelque part (programmer.spip.org ? doc.spip.org ?) une doc sur l’api de spip
– exhaustive
– facilement navigable
– équivalent à api.drupal.org
un telle doc permettrait d’ailleurs d’y voir plus clair et de gagner du temps dans ce type de débat... (ouf, je retombe sur mes pattes)
15 juin 2009, 14:12, par Jacques Pyrat
Dernièrement, j’ai eu à travailler sur un « petit » site gouvernemental qui ne fait que 250 000 visiteurs par jour : le site du rSa.
Et une des exigences du ministère concerné était que le site soit fait sous SPIP...
15 juin 2009, 21:21
« la polyhierarchie multi arborescente » c’est pas un truc de SPIP-Agora :-p
16 juin 2009, 01:28, par MT
@ Jacques Pyrat
Dernièrement j’ai eu à travailler sur un « petit » site du gouvernement : www.gouvernement.fr et l’une des exigences était que le site soit fait sous Drupal :)))
Et si non, dites, sur www.rsa.gouv.fr, cherchez « rsa » dans le moteur de recherche :)))
16 juin 2009, 03:55, par kent1
Pour sortir du combat SPIP / Drupal qui tourne en rond et dont les utilisateurs n’en ont pas grand chose à cirer à vraie dire....
@MT ... Ca tombe bien ... je voulais envoyer un email au webmestre mais comme vous êtes là ...
Pourriez vous avoir l’amabilité d’enlever le mot « strict » du doctype que vous utilisez pour ce site ? J’ai personnellement du mal avec les croix rouges en bas de mon navigateur...
Les gens du RSA qui quand à eux ont développé dira-t-on le « Site du pauvre »... ou « Site du futur pauvre »... ou « Site ultime de la crise » ou ... en tout cas affichent moins de prétention que d’autres...
Bref, messieurs ... laissons les batailles de clochers à Interville s’il vous plait ... ca risque d’être marrant cette année avec Nelson Montfort ...
Sinon Mr Topolov aka MT... on se retrouve l’année prochaine au mois de juin pour un nouveau troll autour de spip... Vous avez un an pour parfaire vos argument...
16 juin 2009, 06:56, par Stanislas
Aïe, oui c’est pas top !
J’ai fait la même recherche sur gouvernement.fr, est ce que le moteur est celui que drupal propose en natif ?
16 juin 2009, 11:41, par Crayon
Sur gouvernement.fr c’est une vue avec des filtres exposés qui est utilisée. Le module de recherche en natif de Drupal n’est pas vraiment très performant il me semble, mais il y a des solutions alternatives. Notamment http://drupal.org/project/apachesolr
16 juin 2009, 18:49, par neutral
@kent1
Au contraire, la comparaison Spip / Drupal doit servir à tirer Spip vers le haut. Sans tomber dans des guérillas de clochers (Drupal fait mieux la vaisselle et sent plus la rose que Spip), il est tout à fait sain de regarder ce qui se fait de mieux dans le voisinage.
Drupal, n’est pas qu’un CMS à la mode, top tendance, il sait faire des choses qui sont (à ce jour) compliquées ou lourdes à développer en Spip.
Quoi qu’en dise @cedric monter un réseau social sur Spip n’est franchement pas chose aisée. Je ne parle pas d’un réseau social avec une gestion minimale de groupes d’amis mais un vrai outil de relations. La nature des projets web (intra/extra) a considérablement évoluée depuis la création de Spip.
Mozilla a récemment choisi Drupal (http://www.slideshare.net/jaypatel/mozilla-universe-the-mozilla-crm-project ) pour développer son CRM/réseau social. Objectivement, Spip ne pouvait pas prétendre répondre à toutes les attentes et les ambitions de ce projet. Spip sait très bien gérer les sites comme celui du RSA ou même de France-info mais ne peut rivaliser avec Drupal sur des solutions comme celles imaginées par Mozilla.
Pourquoi vouloir faire de Spip ce qu’il n’est pas ? Le cœur de Spip tourne autour de l’éditorial (en gros rubriques/ articles), et il est assez difficile de sortir de ce cadre pour étendre à loisir les possibilités de l’animal. Il y a plein de choses pratiques sous Spip mais il faut aussi bien être conscient des réalités (pas possible de gérer des multi-objets à l’infini (‘node’) et des droits aussi bien qu’en Drupal) (pourquoi vouloir manger un flan à la baguette alors qu’il existe des cuillères).
@cedric
Pourquoi ne pas aller plus loin, également, en proposant des ‘patrons de conceptions’. Bien beau de dire et affirmer qu’il est possible de monter les doigts dans le nez un facebook-like en Spip mais montrer/détailler clairement comment s’y prendre c’est encore mieux (structurer une méthode).
Ex :
Cas ‘blog’ (construction possible avec SPIP) .. comment (détail architecture) …avec quoi (addons) limites (oui mais…)
Cas ‘plate-forme médias’ (construction possible avec SPIP) .. comment (détail architecture) …avec quoi (addons) … potentiel (réplication sur 30 serveurs + Akamai) … limites (oui mais…)
Cas ‘réseau social (mon facebook)’ (compliqué en Spip mais faisable par des baroudeurs musclés) …
18 juin 2009, 00:17, par IZO
Très très bonne idée Mr Neutral ... vraiment très chouette.
4 juillet 2009, 00:26
Spip à des qualités, c’est certain. Mais de là à tirer sur Drupal faut pas abuser.
Spip n’est pas si parfait que ça...
– Cherchez Spip la dedans : http://www.packtpub.com/open-source-cms-award-previous-winners
– Coller l’interface d’administration de Joomla par exemple et le truc de Spip devant un client : Qu’est-ce qui fera le plus envie ??? Qui sera le plus vendeur ???
– Spip versus code objet... Grand débat...PHP pas vraiment objet / performance du code objet...
– Communauté French only contre communauté internationnal
Bref il faut savoir faire la part des choses. Spip est sans doute adapté pour certains projets/clients mais pas pour tout, il faut être un peu réaliste.
15 juillet 2009, 11:48, par cedric
Trés bon commentaire, très construit, monsieur anonyme ...
– Pas de SPIP dans un palmarés organisé par une maison d’édition anglaise qui ne comporte aucun ouvrage sur ce sujet ? Qu’est ce que ça nous apprend ? Qu’il faut être comme les moutons de panurge, et suivre la communauté anglaise qui sait bien mieux ce qui est bon pour nous ?
– L’interface d’administration de SPIP ferait pas envie ? La lecture de cette comparaison avec d’autres outils me semble plus constructive que ta question ouverte dont la réponse ne semble évident que pour toi. Contrairement à l’interface des autres outils à tout faire, celle de SPIP a un parti pris. Elle n’est pas parfaite, mais on en est conscient et on y travaille dur. Avec plein de nouveautés à venir dont un système de thèmes.
– AAAhhh. Le code objet. Nous y voilà. Je vais commencer par un bref rappel : les méthodes objets sont tout à fait utilisables dans un langage sans objet, et réciproquement, l’usage d’un langage objet ne présume aucunement de l’utilisation des méthodes objet.
Donc commençons par préciser de quoi on parle. Une étude de Potok et al. a montré qu’il n’y avait pas de différence significative de productivité entre la programmation par méthodes objet et l’approche procédurale. Un article de Lucas Cardelli dénonce aussi les défauts des méthodes objets.
Mais les méthodes objet peuvent surtout être vues comme un outil méthodologique qui fait office de garde fou dans les grosses entreprises, en empêchant les mauvais programmeurs débutants de faire trop de dégâts. Au prix d’un ralentissement des bons programmeurs. C’est l’essence même du fonctionnement des grosses organisations : avoir des outils et des méthodes qui garantissent que la qualité du résultat sera à peu près constante, quelles que soient les équipes internes qui travaillent dessus.
Tout le contraire du développement Open Source, où c’est avant tout la qualité du contributeur qui garantit le résultat. L’utilisation intensive des objets sert beaucoup plus les sociétés qui vendent du service autour de l’Open Source en les protégeant par un écran de fumée technologique que le logiciel Open Source lui même.
En créant une barrière à l’entrée dans la compréhension du code, l’utilisation intensive des objets filtre les contributeurs possibles et tend à homogénéiser les profils de ceux-ci, laissant sur le bord des profils atypiques qui peuvent apporter une vision différente souvent à la source de l’innovation.
Ce manque de diversité est un problème récurent dans la gestion des ressources humaines des grosses structures. Cette diversité est a contrario une richesse dans le monde de l’Open Source. Calquer les méthodes sur celles de l’industrie, c’est à coup sûr accepter de s’enrichir d’une part de ses défauts...
– La communauté trop francophone ? Sûrement oui. Comme on le lit dans ce comparatif
Mais SPIP doit-il sacrifier toute son âme sur l’autel de la domination anglo-saxonne ? Encore une fois, le choix de conserver un langage francophone, qui est ici le vrai problème, est un choix délibéré de rester accessible au plus grand nombre des utilisateurs, y compris non anglophones. A abandonner cette spécificité, SPIP perdrait beaucoup, mais y gagnerait-il vraiment quelque chose ?
Maintenant, de quoi parle-t-on quand on parle de la communauté ?
Bref, comme tu disais, il faut savoir faire la part des choses. Ce billet prenait un exemple concret, et s’appuyait sur une analyse technique etayée et argumentée pour montrer que les CMS à la mode, anglo-saxons et tout objet ne sont pas forcèment la panacée.
Tu peux ne pas être d’accord, mais il faudrait tout de même argumenter un peu plus sérieusement.
Ou alors, tu ne fait que contribuer à propager un phénomène de mode sans fondemant rationnel, ce que je dénonçais à travers ce billet, justement. CQFD
9 août 2009, 05:21, par Manao
Bravo pour tous ces commentaires ! Passionnant, réellement et pas mal de courtoisie, malgré la passion de certains. Ceci dit certaines remarques font quand même hurler de rire, surtout quand je pense à l’interface d’administration de Joomla !… Un total fiasco devant les clients. Alors non… pas vendeur du tout. Au début ils aiment les boutons, puis, après avoir quitté la salle de formation ils pleurent leur mère de ne pas avoir pris suffisamment de notes ;)
Pour Spip les formations des utilisateurs ont le mérite de se terminer avec une heure d’avance et de ne plus avoir à faire avec le client pendant des mois… Enfin, si, il y en a toujours qui rempilent ;))
Sinon merci à Cédric pour le texte et les commentaires. Je dois migrer un site depuis Drupal vers Spip et je suis tombé ici par hasard pour glaner quelques informations. La raison de ce « retour arrière » est le coût d’exploitation sous Drupal. Les modifications post-prod sont prohibitives alors on va se regarder la migration sous un bon CMS bien solide comme Spip. C’est pas gagné mais comme il s’agit d’un site d’information ça devrait pouvoir le faire !
Bonnes vacances à tous.
9 août 2009, 12:07, par cedric
Merci Manao pour ton retour, c’est très instructif, et ça correspond vraiment à ce que je ressens et crois comprendre de Drupal. Mais je ne l’avais encore jamais lu aussi explicitement.
Il serait vraiment très intéressant de pouvoir comparer les performances de ton site en version Drupal et en version SPIP sur un même serveur. Si le projet t’intéresse, je suis prêt à te donner un coup de main dans ta migration, pour pouvoir faire ensuite un joli article sur ce blog !
9 août 2009, 13:28, par esj
Non seulement ce qu’on ressent, mais aussi ce que Drupal affiche lui-même dans sa présentation comme ressources nécessaires à son fonctionnement.
Je reviens d’ailleurs sur le commentaire disant que l’optimisation des requêtes SQL aurait un intérêt négligeable du fait de la présence d’un cache. C’est une affirmation bien superficielle, car il y a quantité de situations où le cache n’est pas utilisable. Les jugements sur les performances qui ne reposent pas sur des jeux de tests libre d’accès n’ont aucune valeur chaque utilisation va tomber sur certaines forces et faiblesses du système utilisé, qui peuvent se revéler déterminante dans un sens ou dans l’autre.
9 août 2009, 15:27, par BoOz
@MT
Il suffirait d’ajouter le plugin "recherche fulltext" au site du RSA et ca fonctionnerait comme on pourrait souhaiter. En travaillant plus sérieusement tes dossiers, tu l’aurais su.
Concernant les "exigences" du gouvernement, elles sont souvent dictée par des lobbies industriels (SSII etc). A l’époque précédente l’exigence c’était "spip-agora", c’est à dire au moment ou les SSII avaient investi la dedans, maintenant c’est Drupal, bon.
Je crois qu’il y a une chance avec SPIP de produire un CMS francais d’envergure, certains acteurs économiques et départements du gouvernement l’ont compris, et pendant ce temps là, nos SSII font du Drupal parce que Drupal permet de "faire des réseaux sociaux avancés" : de qui se moque t’on ?
Comme le dit Cerdic, si vraiment il fallait réaliser autant de sites de réseaux sociaux à la Mozilla que ca (je demande à voir), et bien un dev motivé produirait les plugins spip qui vont bien assez rapidement.
Idem pour la gestion des droits avancés (feature in-dis-pen-sable à toute bonne usine à gaz) ; depuis le temps que les SSII nous bassinent avec ca, que n’ont elles proposé un plan de travail en vue d’un plugin qui permettrait de gérer des droits à l’infini.
Qui sont les devs des SSII françaises qui participent aux projets open source francais ? Combien de temps par semaine ? Ou est leur livre blanc sérieux sur SPIP ? Ou sont leurs powerpoint (lol) analytiques sur les faiblesses de SPIP et les pistes d’amélioration, ou est - rêvons tout haut - leur code informatique ?
Nulle part. Les SSII aujourd’hui en France, ne sont pas là pour produire du logiciel libre de qualité avec les communautés d’utilisateurs, mais pour vendre des services le plus cher possibles, le plus souvent possible, pragmatisme décomplexé j’imagine.
Drupal de son coté permet aux SSII de réaliser une meilleure marge commerciale à court terme en vendant un projet technique bien touffu, plein de nouveautés in-dis-pen-sables, et qui bouffe énormément de ressources, c’est un peu triste, mais c’est la vie des affaires. Alors ces temps-ci on installe du Drupal.
Ensuite je prédis qu’il faudra bientôt migrer vers un nième nouveau système qui gère cette fois-ci le web 3.0, in-dis-pen-sable, et on repartira pour un tour.
Ce jour là, si le « décideur » est toujours en place, il se dira peut-être : « j’aurais du le faire moi même en SPIP dès le début ce site »
9 août 2009, 20:00, par phil93
j’ai personnellement l’exemple d’un super projet d’intranet/internet basé sur un super produit STELLENT a l’époque, Oracle UCM maintenant, qui a été choisi a la place de SPIP-agora (on ne pouvait même pas évoquer SPIP ce logiciel libre pas cher ). du DRUPAL en J2EE si on veut.
Oracle UCM est très très puissant avec des réglages d’autorisation (une des raisons du choix ) qui n’ont jamais servi a rien car les autorisations fines il faut aussi les gérer et ce n’est pas forcément facile. On s’en sert aujourd’hui après 5 ans d’efforts comme d’un vulgaire SPIP avec des pièces jointes.
Et même pour avoir des flux RSS on nous dit que cela fait parti d’un développement spécifique. bonjour la pompe a finances. Mais notre prestataire est bien sur a notre écoute.....
9 août 2009, 20:10
@ Manao et @cedric : ce qui pourra faire l’objet d’un super plugin « drupal2spip » comme l’avait fait Booz pour « joomla2spip » !
Et on ne comptera plus tous les sites Drupal qui pourront enfin se libérer facilement ensuite ! Hahahahahaha.
9 août 2009, 22:08
@BoOz : bien dit, l’ami
11 août 2009, 18:26, par AeM
tant qu’on parle de sites de type « editorial » ou « generaliste », ça va,
chacun peut amener son cms...
après chacun a ses forces et ses faiblesses, et ses façons de faire,
qu’ils s’appellent drupal, spip,typo3, ezpublish, wordpress, xoops ou autres...
maintenant, qu’on me propose des faire un site de vente en ligne de vidéos,
imposer une seule possibilité de cms au client parce que c’est le seul
qu’on souhaite proposer, c’est pas forcément une solution
suivant le cahier des charges précis :
pour certaines (ssii ou clients), la maintenance sera facilitée sous spip,
pour d’autres, sous wordpress, pour d’autres encore sous drupal
ou typo3...
il faut aussi étudier la capacité du client (et/ou son personnel) en amont,
sinon on risque parfois de grosses surprises au moment de la prise en charge
(cf. joomla et son panneau d’administration : pour les admins c’est touffu,
mais un admin peut régler pour que ceux qui vont publier ne voient
que les 2 ou 3 options qui les concernent : tiens d’un coup y’en a beaucoup moins !
ah, oui, c’est vrai : beaucoup de « petites » ssii oublient de faire ce genre de détail
et préfèrent larguer le client en admin... dommage le client !
des ssii de tous niveaux, on en trouve partout et pour tous les cms
[@manao, 9 aout] )
l’essentiel, c’est pas les guéguerres à la con, c’est le respect
du client, de son cahier des charges initial, de sa modularité éventuelle
à venir, et de la prise en compte de ses capacités propres non ?
comme dit plusieurs fois plus haut, il vaut mieux privilégier
l’ergonomie et la facilité de la maintenance, même si on « galère » un peu au développement initial
(éventuellement !) que ce soit sous spip, drupal, ezpublish, xoops ou autres...
chaque projet a ses spécificités après tout, il n’existe pas de
« une même taille pour tous » sinon ça se saurait depuis le projet
de « modules de programmation universel » prévu dès les années 40 :
après c’est sûr que la plupart des choses sont réalisables dans
tous ces cms, qui sont tous autant les uns que les autres des usines à gaz
(d’un point de vue développeur en particulier - hem :) )
mais tellement indispensables pour gérer nos données préférées !
wordpress conviendra peut-être mieux
que spip ou drupal pour un débutant absolu en particulier,
qui veut juste faire un petit blog « bête et méchant »...
ezpublish/typo3/drupal pour une gestion de franchises de véhicules à louer
et gestion bancaire associé (tant qu’on ne parle que de php bien entendu),
à moins que symfony/cakephp/autre framework ne passent ici,
ça commence à faire limite suivant le besoin :)
après entre les deux, il existe tellement de besoins et de façons
de résoudre qu’il vaut mieux voir les impressions du client
et comment lui, ressent ça (infogérance ? allez-y avec ce que vous souhaitez !
que lui ou son équipe se chargent de la gestion du contenu ?
attention à l’interface, mieux vaut proposer un panel de maquettes/cms si vous pouvez...
avec accès restreint, cf joomla mal configuré plus haut mais c’est valable
pour tous les cms)
26 août 2009, 14:48, par marc
Salut à tous,
J’ai lu presque en entier (si si je le jure) ce long, très long jeu de ping pong entre les pro et anti.
Et franchement, j’ai maintenant compris pourquoi ce monde avait encore tant de guerre.
Les mêmes personnes qui ici se font les ayatollah d’un CMS où de l’autre font sûrement partie de ceux qui s’offusquent de voir des gens faire de l’extrémisme religieux.
Je suis un total newbe dans le monde des CMS, mais voilà plus de 10 ans que je travail dans le monde des systèmes d’information et je suis encore et toujours accablé par ces discours sans fondements réels.
Le monde du libre était « un jour » un monde où les différents contributeurs se sentaient comme complémentaire.
Chaque nouveau venu était un contributeur qui amenait sa sensibilité, son expérience et ses envies, et chacun l’acceuillait comme quelqu’un qui faisait grandir une communauté mondial des « GPListes ».
Aujourd’hui la communauté n’est plus « mondiale », mais chacun s’identifie à l’un ou l’autre logiciel et adopte alors presque immédiatement une attitude guerrière contre le membre de la communauté d’un autre logiciel.
REVEILLEZ-VOUS !!! Sommes nous tous devenus des futurs développeurs de « propriétaires » ??? NON
La présence et l’émergence de multitude d’approches différentes d’une même problématique, que ce soit pour un CMS, un ERP, un eCommerce ou autre, est bénéfique à l’ensemble de la communauté !!!
Allez... je vous laisse à vos combats d’Ayatollah et je retourne à ma vie de bohême.
Bonne route à tous
Marc
P.S. : newbe total du CMS, j’ai installé Joomla, SPIP et Drupal... ben le seul que j’ai réussi à prendre en mains c’est Drupal :-)
26 août 2009, 19:36, par cedric
Ton jugement me parait bien sévère : je vois dans ce forum une discussion plutôt construite et argumentée sur des points techniques, ce qui est suffisament rare pour être souligné, et non des .
30 août 2009, 13:33, par serge
Une petite mise au point pour la discussion : Drupal a un système de cache, qui s’est amélioré en drupal 6. En 5, c’était géré page par page, et désactivé pour les utilisateurs connectés, mais à partir de 6, le cache est géré « bloc » (grande division d’une page, quoi) par bloc, et ça fonctionne mieux du coup.
Autre mise au point : du point de vue du langage, Drupal n’utilise pas les fonctionnalités objet de PHP ! Il est donc dans le même lot que Spip à ce niveau.
Sinon, rien n’oblige un administrateur drupal à créer une view. Il a parfaitement le droit d’écrire sa requête et tout. Simplement, le mécanisme des views, et surtout celui de CCK (création de nouveaux types de contenus avec les champs qu’on veut), permettent d’ajouter à la volée et sans programmation de nouvelles fonctionnalités à un site.
12 novembre 2009, 19:33, par filnug
Bonjour,
Je ne veux pas rajouter de l’huile sur le feu sur ce long débat (commentaires de juin à août) et enflammé, mais j’ai eu l’occasion de travailler sur SPIP et Drupal. Le choix du CMS n’est pas des plus simple et les critères qui font son choix varient d’une personne à l’autre.
Dans mon cas, mes objectifs dans le choix du cms étaient les suivants :
– Facilité à créer un site internet selon une maquette graphique claire. Pas de template ou theming préfabriqué,
– Interface d’administration claire et intuitive à utiliser pour le (les) administrateur (s)
et c’est tout.
J’ai constaté plusieurs choses :
– L’utilisation d’un cms demande bcp d’énergie pour s’habituer à l’utiliser et à créer un site internet. Personnellement, je trouve la courbe d’apprentissage de Drupal très complexe.
– Les personnes qui se déchirent dans des comparaisons de cms sont souvent des programmeurs. Et Drupal de ce côté en est le parfait exemple. Pourtant, contrairement à spip, il y a souvent très peu de code à écrire du fait des plugins views, panel, cck, etc. Et au final, l’utilisateur se fiche de savoir quel cms est utilisé pourvu que le site tourne et soit clair.
– Si l’on créée un site internet en partant d’une maquette visuelle, la démarche entre spip et drupal est complètement différente. Spip permet de travailler les css et le code en même temps (bien que cela ne soit pas une obligation). Avec Drupal on génére le code, puis on habille le site (cela m’a rappelé joomla).
– Pour avoir participer à des réunions de geeks drupalien en Allemagne, j’ai constaté que les programmeurs ont réalisés de gros projets, mais qu’ils ont passé plus temps sur le theming que sur le code ! Cela prouve bien un handicap majeur de Drupal. Les tutorials sur le theming sont très compliqués et peu nombreux par rapport à des tutorials techniques.
– Et finalement, spip est très français et cela est son frein principal. Drupal est internationalement reconnu et s’en vante, mais je connais personnellement qu’une personne qui écrit des modules Drupal. A mon avis, si le langage de boucles SPIP existeraient en anglais, Spip gagnerait en popularité.
En conclusion, les 2 cms se valent. Tout dépend du projet. Drupal plaît bcp aux programmeurs (avec tous ces modules à installer et à configurer sans fin) et SPIP est tout prêt pour se concentrer sur le Design.
Selon mes critères, mon choix se fait sur SPIP, mais Drupal s’imposera certainement à l’avenir du fait de sa popularité (ce qui est un très mauvais critère dans le choix d’un cms).
12 novembre 2009, 19:42, par cedric
Merci de ce retour éclairé à la fois d’un côté et de l’autre. J’ai lu il y a peu, sur un blog anglo-saxon, que SPIP était un très bon outil, dont le seul défaut était d’être français.
Sans aller jusque là, mais en abondant dans ton sens, il est certain que la francophonie de SPIP et de son langage de squelette bloque la croissance de sa communauté dans toute la partie anglo-saxone du monde.
Néanmoins, il faut aussi reconnaitre que c’est cette qualité qui lui vaut d’être utilisé par nombre de personnes qui ne veulent pas céder (pour tout un tas de raisons, bonnes ou mauvaises) à la culture dominante anglo-saxone.
Donc oui, si la collectivité de SPIP était une société chargée de pénètrer un marché et de gagner des PDM, nul doute que l’anglicisation du produit serait un incontournable.
Mais on est plutôt des passionés, qui avons envie de faire durer un projet humain, et de ne pas abandonner ce qui en constitue une partie essentielle. Alors dans ce cas, garder son côté francophone est important, voire vital.
Peut-être arriverons nous un jour à conjuguer les deux pour le bonheur de tous ? ...
13 novembre 2009, 00:02, par filnug
@cedric
Je comprends la démarche de Spip et je m’étonne tjs (à part sur le coup des 20h ;-) de la disponilibité des spipiens sur le canal irc. En plus en français, c’est un vrai luxe.
Mais peut-être que les 2 langues pourraient coexister avec un leadership francophone. Il suffirait de proposer une traduction anglaise du langage Spip et complet du site internet pour voir déjà quelle serait l’évolution. Si en plus les plugins les plus utilisés (couteau suisse etc,) et les nouveaux plugins seraient traduits automatiquement, cela pourrait donner une belle perspective d’avenir et d’aventure au projet Spip.
Ce point de vue est certainement utopique et naïf de ma part, mais je pense que Spip est un bon choix de CMS sur certains projets et que cela devrait être partagé avec le plus grand nombre. La solution dans ce sens est l’anglais.
9 janvier 2010, 19:48, par ed
histoire de faire mon cheveux sur la soupe (froide, à l’heure qu’il est...)
J’ai fait développer 8 sites cette année pour des clients souhaitant quelque chose de plus « simple à gérer » que ce qu’ils avaient déjà.... Leur point commun ? Ils étaient tous sous drupal.
Donc, moi je pense que Drupal, c’est génial. Ça me permet de vivre. :P
Mais tous les nouveaux sites n’étaient pas sous SPIP... Parfois, Wordpress suffisait à la tâche. Si je me fie aux retours des clients sur l’utilisation de SPIP, le seul point vraiment à améliorer, c’est l’interface privé. Pas dans le sens qu’elle est désuète, mais plus dans le sens qu’elle ne répond plus à la logique standard de bien des outils de publications de contenu. Les gens s’attendent à un panneau admin de style wordpress en un peu plus compliqué, ils s’attendent à cette « logique ». Pour pallier à cela, on doit créer des panneaux déroulant dans la partie public pour proposer des liens pour « écrire un nouvel article ect » et, bien sûr, les crayons aident énormément ! Sans les crayons, plusieurs clients pleureraient. L’interface pour traduire les articles mériterait d’être plus poussée, mais on y pallie avec quelques heures de formations vidéos.
Finalement, le point final, c’est que si on pouvais ’squelettiser’ la partie admin, avec des noisettes et des inclusions de blocs d’éditions, beaucoup de gens seraient plus heureux.
10 janvier 2010, 11:44, par b_b
Salut ed,
Elles sont où tes vidéos ? Si elle peuvent permettre à des utilisateurs de comprendre facilement des notions de SPIP elles auraient peut être leur place sur videos.spip.org non ? Partageons, partageons...
++
10 janvier 2010, 16:24, par Têtue
@ed : merci pour cet intéressant retour utilisateur !
@b_b : huhu, il me semble plus futé d’améliorer l’interface pour éviter d’avoir à palier, plutôt que de se refiler les rustines et perdre NxN temps en formation :-P
10 janvier 2010, 21:25, par b_b
Oui bien sûr tetue mais, si ed a fait une belle vidéo de tutoriel autant la partager en attendant que quelqu’un ai le temps d’améliorer la dite interface, non ? D’autant plus qu’on sait tous les deux que l’interface est un sujet sensible chez SPIP :p
13 février 2010, 13:12, par Gilles
Sinon pour rester dans la comparaison Drupal / SPIP, j’ai trouvé cet article assez complet qui parle plus de l’aspect fonctionnel :
La facilité avec SPIP versus la souffrance avec Drupal (le point de vue de PoolSPIP)
18 avril 2010, 00:49, par cedric
Un article intéressant de retour d’expérience d’un déploiement de Drupal, où l’on apprend que pour gérer 200 000visiteurs/jour il faut 8 serveurs frontaux+3 serveurs de BDD+un filer NFS (et que un ou deux frontaux de plus ne seraient pas de trop) : http://www.media-business.biz/content/bilan-technique-drupal
A comparer avec certains gros sites sous SPIP qui absorbent un trafic comparable avec 2 frontaux web+1 SQL+1filer.
Et d’après mon retour d’expérience, un site SPIP codé proprement et bien optimisé peut absorber un trafic de cet ordre sur un unique serveur HTTP+SQL.
Alors, à votre avis, quand on prend en compte la durée de vie d’un projet et les coûts de maintenance et d’hébergment en production, de quel côté aura-t-on un TCO le plus bas ?
5 juin 2010, 13:53, par Cédric
La discussion sur http://didier.misson.net/blog/2010/06/05/france-televisions-un-drupal-multisite-avec-1000-sites/ confirme un ordre de grandeur d’une capacité de service par Drupal de 125 000 pages/jour/frontal et 335 000 pages/jour/sql.
21 juin 2010, 17:43, par Xavier « PHP Killer »
La facilité avec SPIP versus la souffrance avec Drupal ....
entièrement d’accord !!!
voilà 4 ans que je dev tous mes sites sous SPIP, très vite et très rentable pour ma boite :-) et voilà t’y pas que ma boss à décider de me faire faire le plus gros site que l’agence ai eu à faire avec ... drupal :(
3 jours de formation « sur le pouce » et me voilà lancer dans le dev de ce projet ... à mon avis, à Noël j’y suis encore.
Il est vrai que les possibilités de Drupal sont impressionnantes, mais que c’est compliqué de mettre tout ca en oeuvre.
en plus, comme l’a si bien dit Manao plus haut, pour la formation client au back office ... je redoute pour drupal, il faudrait presque créer une surcouche du BO faite pour l’administrateur (ou les administrateurs) final, un truc simple et intuitif ... comme celui de SPIP !!!
19 juillet 2010, 16:55, par Jean-Baptiste Bourgoin
Pour avoir fait quelques formations à SPIP, et écouté mes proches au sujet de son interface privé, le seul truc qui ennuie vraiment le rédacteur « lambda » (selon l’expression désormais consacrée), c’est l’absence d’un éditeur WYSIWYG, et le positionnement
Soyons franc, l’interface d’administration de Joomla et de Drupal est excessivement complexe. Trop de boutons pour l’un, trop de texte pour l’autre.
En matière de « ouèb 2.0 », la gestion d’AJAX par SPIP est merveilleuse. En revanche, j’attends toujours un moyen simple d’intégrer quelques composants « sociaux » (plugin « Amis » ?) facilement. Un tutoriel à conseiller ?
J’ai été étonné d’entendre que la gestion du multilinguisme est mauvaise en SPIP. Elle me semble très bonne au contraire ! Je suis actuellement sur un projet de site en français/breton, et il n’y a bien que SPIP pour proposer une traduction intégrale en breton (interface privé comme publique) ;)
La communauté de SPIP est extraordinaire, et ses nombreux sites amusants. Très loin du très ennuyeux site tout bleu tout propre de Drupal, ou des sites au look bien commerciaux de Joomla.
J’aime que SPIP soit en français. Pour moi, c’est une force. Je sais lire l’anglais, parfaitement bien. Mais j’en ai un peu marre de passer mon temps à coder en anglais. Quel plaisir de pouvoir parler de « boucles » !
26 août 2010, 09:48, par François Daniel Giezendanner
Bonjour Jean-Baptiste,
Concernant ton attente :
« j’attends toujours un moyen simple d’intégrer quelques composants "sociaux" (plugin "Amis" ?) facilement »
As-tu essayé le plugin :
http://www.spip-contrib.net/Social-tags
Il fonctionne à la perfection. La version 0.9 que j’utilise propose de choisir parmi 64 sites sociaux.
Mais peut-être fais-tu allusion à autre chose !
Cordialement
FDG
21 octobre 2010, 15:07, par Jean-Baptiste Bourgoin
Bonjour François,
Non, je ne le connaissais pas ! Merci !
Mais je ne pensais pas vraiment à cela. Je pensais à des plugins qui permettent de créer un site de réseau social (un facebook quoi !) avec SPIP.
Cela dit, ce plugin va m’être utile.
7 novembre 2021, 10:25, par Rhoda
Upadłość Konsumencka Sanok Upadłość konsumencka w Sanoku.
Niezabezpieczone długi osób fizycznych lub małych przedsiębiorców nie więdną na gałęziach wierzycieli.
Rocznie setki tysięcy dłużników decyduje się na to rozwiązanie,
a my pomagamy im w przygotowaniu dokumentów.
Outsourcing oznacza dla Państwa : my zajmujemy się wszystkim, a po kilku miesiącach przedstawiamy
ostateczną decyzję sądu. - Upadłość Konsumencka Sanok