/blog

    • Sur les plugins listés, une petite mise à jour des plugins SPIP à utiliser de préférence maintenant :
      – Forms & Tables => Formidable
      – Spip-Listes => Newsletters / Mailsubscribers / Mailshot

      Éventuellement aussi
      – Article PDF => PDF Version

    • SPIP inclut une médiathèque de base. Cela dit, il semble que les images ajoutées en « logo » des articles ne soient pas directement liées à cette médiathèque, contrairement aux images ajoutées en « portfolio ». Drupal fonctionnant uniquement avec des « champs » image, toute image est donc nativement centralisée dans la médiathèque, ce qui semble un peu plus intuitif.

      Hihi…

    • Bonjour, je suis l’auteur de l’article. Pour les plugins, j’ai pris le Top 30 sur https://plugins.spip.net, je suis preneur de suggestions alternatives, et je mettrai à jour l’article avec leurs équivalents Drupal si ils existent.

      Pour la médiathèque, c’est quelque chose que je n’ai pas compris : la médiathèque fonctionne très bien, mais ça m’a interpellé que le « logo » de l’article n’y figure pas. C’est quelque chose que j’ai raté ?

      Plus globalement, je suis preneur de vos retours ou corrections à apporter !

    • Super, merci pour ce retour de retours @simongeorges :)

      Tu as très bien compris pour les logos, et c’est un des chantiers pour la 3.3 (dont le chantier principal sera à priori « tous ce qui concerne les médias »).

      Pour les suggestions il y avait :
      – tu parles de la dernière version stable à priori, hors Forms&Tables n’existe plus, maintenant c’est plutôt Formidable
      – pareil pour les Newsletters, maintenant c’est le trio Newsletters (composition) + Mailsubscribers (gestion de listes) + Mailshot (gestion d’envois en masse)
      – il y a un passage où tu parles du « Plan interne » dans l’admin, en disant que Drupal 8 a un truc plus complet qui est Menus et qui permet de gérer plusieurs menus différents : mais alors là il doit y avoir une incompréhension sur la fonctionnalité car ça n’a à priori aucun rapport du tout. Le plan interne à l’admin est une vue globale du site, qui permet d’avoir une vue d’ensemble, et qui permet de déplacer des branches entières par glisser-déposer pour faire du rangement. Ça n’a pas de rapport avec le fait de créer des Menus à insérer dans le site publique : ça c’est le plugin Menus justement, qui te permet de créer autant de Menus que tu veux, et de les remplir manuellement dans une interface.
      – (et donc commentaire pour un autre endroit : bah c’est pas un manque de SPIP ces menus, puisqu’il existe un plugin pour ça :D … il y a plein de petits sites/blogs où il n’y aucun besoin de gérer des menus manuellement car ça suffit d’afficher l’arborescence des classements dans les templates du site)

      Voilà pour l’instant ce qui me vient :)

    • En fait, pour le plan interne du site, j’ai eu l’impression qu’on ne pouvait gérer que l’arborescence du menu principal, et pas, par exemple, le menu de pied de page. C’est pour ça que je trouvais que le module « Menu » du cœur de Drupal était mieux (et semblait correspondre en partie au plugin « Menus » de SPIP).

      C’est juste ça qui me gênait. Après, au niveau de la fonctionnalité de déplacement elle-même, Drupal et SPIP sont vraiment similaires.

      Je mets à jour les plugins dans l’article !

    • Mmmh, je réfléchis à ce que tu dis, et je me dis peut-être qu’il y a encore une confusion (peut-être hein… si je comprends bien) : un « menu » n’est pas une arborescence, en tout cas pour ce qui est de SPIP, un « menu » c’est quelque chose qui n’est qu’une vue, une présentation qu’on va montrer aux gens.

      Là le plan du site interne, c’est le plan réel du rangement des articles dans les rubriques. Ce n’est pas un menu : c’est, très concrètement, comment sont rangés les articles et les rubriques dans d’autres rubriques. C’est le rangement, la catégorisation, le classement (insérer ici un autre synonyme :p) principal.

    • En fait, les rubriques n’existant pas en tant que tel dans Drupal, sans menu, on n’a que des pages orphelines. Donc, c’est la modification du « menu » qui correspond à ce rangement « réel » des articles dans les rubriques.
      Le « Menu » Drupal regroupe les deux concepts : le rangement et la vue qu’on va montrer aux gens.

      Je vais éventuellement reformuler ou refaire des captures pour mieux illustrer la différence, merci pour les précisions !

    • Effectivement, c’est une grande différence dans la conception, et je trouve bien utile que tu expliques ça à tes lecteurs, pour arriver à comprendre le passage de l’un à l’autre !

      SPIP, pour ce qui est des contenus par défaut (rubriques et articles) a une conception éditoriale, issu du monde journalistique/magazine, avec un classement « principal » des contenus dans une arborescence de rubriques.

      Ce qui me fait penser au passage qu’il faudrait peut-être que tu parles de Polyhiérarchie aussi, par rapport à ce classement et à la taxinomie.

      En effet, dans SPIP, comme dit précédemment, il y a bien une séparation :
      – Les « menus », qu’on les fasse « en dur » dans les templates, ou manuellement avec le plugin Menus, ce ne sont QUE des listes quelconques que l’on présente publiquement aux gens. On peut très bien faire un menu basé sur les rubriques… mais on peut parfaitement faire un menu basé sur les mots-clés, ou des entrées arbitraires quelconques, enfin bref, tout et n’importe quoi !
      – D’un autre côté, il y a le classement des contenus. Et pour ça, il y a plusieurs concepts possibles, certains fournis par défaut, d’autres en plugins, et qui se complètent suivant les besoins simples ou complexes du site. Il y a donc la notion de « rubriques principales », qui est la manière de classer par défaut. Il y a les « mots-clés » (plugin mais fourni en dist) qui propose un autre concept qui est multiple, mais pas hiérarchique (enfin si, un niveau de hiérarchie uniquement, avec les groupes de mots). Et il y a aussi « Polyhiérarchie » qui étend les rubriques principales de SPIP, et qui te permet d’assigner plusieurs rubriques à un même contenu (dont une est toujours la « principale » !).

      Du coup, quand tu parles de Taxonomy, il faut peut-être dire que la correspondance dans SPIP n’est pas juste le plugin Mots, mais tout ce qui concerne le classement des contenus.

    • Salut @simongeorges, merci d’être venu causer de ton article ici, et pour les mises à jour suite aux remarques de @rastapopoulos

      Seenthis est plutôt bien référencé, du coup, ça va te faire un bon boost :D

      Bon, en tout cas ça fait plaisir de lire un article objectif sur SPIP, sans troll, même si c’est pour faire la promotion d’un changement de CMS...

    • En fait, je pense vraiment que tout le monde gagnerait à ce que les clients aient une meilleure vision des « bons » cas d’utilisation de chaque CMS : Drupal la flexibilité (et plutôt des gros sites), SPIP le côté éditorial / multi-rédacteur / simple à mettre en place et à utiliser…

      Au-delà de ça, je pense que chaque CMS peut « apprendre » de ce qui marche bien chez les autres, et tester SPIP je pense (j’espère) me permet de mieux comprendre certains besoins de mes clients.

      Le troll n’est pas constructif. Merci à vous pour l’accueil et les retours sur l’article. Si jamais j’ai besoin d’experts SPIP pour des clients, je saurai à qui m’adresser ;-) !

    • Bah, SPIP ne cherche pas vraiment des clients mais plutôt des contributeurs :p

      Pour préciser, SPIP a une particularité assez unique par son système de squelettes (i.e. templates), à base de boucles.
      Thelia, dans sa V1, s’en est complètement inspiré et poursuit dans sa V2 sur le même principe (avec des extensions de smarty).
      On peut créer des boucles sur les articles, les rubriques ou n’importe quel objet éditorial, en filtrant par mots clés, en triant par date, etc etc.
      On peut aussi créer de nouveaux objets éditoriaux avec La Fabrique, le plugin qui sert à créer des plugins.
      https://contrib.spip.net/La-Fabrique

      Ça donne un CMS très facile à prendre en main pour des bidouilleurs / amateurs / intégrateurs etc. On peut créer un site complet, sur mesure, même un site complexe avec toute sa logique éditoriale (arborescence, taxonomie etc.), sans une ligne de PHP ni configs XML ou autres.