city:drupal

  • Drupal c’est bon mangez-en. Ici sur le tout nouveau tout beau site du MOCO, en Drupal 8 tu penses bien… première page que je visite : le point d’interrogation à la ligne (un automatisme présent d’office dans SPIP depuis la version… hum… zéro) :


    ou, ailleurs, les guillemets qui se promènent en fin de ligne :

    Tu as aussi l’illustration qui, sur un téléphone de 320 pixels de large, charge une image de… 2500 pixels de large :

    Une page typique du site charge 3 CSS locales, et 3 fichiers JS (plus une tripotée de cochonneries pour les partages sociaux, dont on pourrait aisément se passer, mais bon).

    Sinon, pas directement lié à Drupal : les FontFace qui n’arrivent pas à gérer l’italique (pas de Plantin italique, remplacé par un Plantin « penché »), et le responsive est codé à la va comme je te pousse, tiens pour le plaisir, sur un écran de 800 pixels de large :

    Ou encore les tailles de texte toutes petites sur petit écran, puis de plus en plus grandes, puis finalement à nouveau plus petites (en passant 1280 pixels de large, on passe d’une taille énorme à une taille toute riquiqui). Et sur iPad, apparemment on a pensé qu’il fallait se débarrasser totalement des blancs tournants autour du texte :

    Ah, et tant qu’à faire, les webfonts du Plantin sont des polices Monotype, que tu peux directement récupérer au format OpenType (.otf) :


    Je ne sais pas quel type de licence ils livrent avec leurs polices, chez Monotype, mais ça me semble un peu olé-olé de diffuser une police propriétaire de cette façon.

    Voilà, c’est assez typique de ce que je vois passer régulièrement : du Drupal parce que Drupal c’est mieux, souvent du Bootstrap parce que sinon comment tu veux faire du responsive de manière professionnelle, des clients à qui on a expliqué que SPIP c’est caca, des budgets qui, pour du Drupal, passent du simple au double, et au final, clairement, l’argent n’est pas passé dans les finitions et les optimisations, dont certaines sont natives dans SPIP, ou accessibles par des plugins faciles à utiliser.

  • DrupalCamp 2017 Lannion
    https://linuxfr.org/news/drupalcamp-2017-lannion

    Après Nantes c’est au tour de Lannion d’accueillir le DrupalCamp 2017.

    Le DrupalCamp est proposé par l’association Drupal France et francophonie. Il se déroulera du 27 au 29 octobre 2017, à l’Espace Ste Anne de Lannion (22).

    Ce sera l’occasion de découvrir ce gestionnaire de contenu (CMS) ou en approfondir ses connaissances au cours de 3 jours de conférences et de rencontres.

    Sprints, conférences et discussions sont accessibles librement, à tous les niveaux techniques et fonctionnels, à tous les profils du développeur à l’utilisateur. Toutes ces rencontres se font dans la bonne humeur, des soirées étant aussi organisées les vendredi et samedi soirs (accessibles avec le pack weekend).lien n°1 : DrupalCamp 2017 Lannionlien n°2 : Drupal.frQu’est que Drupal

    Drupal est un CMS (système de gestion de (...)

    • 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.

  • Info importante apprise en visionnant les vidéos du CMS Day : #Drupal 8 va intégrer plusieurs des modules de base du #framework #symfony !

    Le cœur qui implémente super proprement le standard #HTTP dans #PHP, le module de #route #routing pour faire correspondre masques d’#URL, actions HTTP, et action dans le logiciel, plein de trucs supers... qui vont être intégrés directement dans le noyau de Drupal.

    Le but est de rajeunir un code vieillissant, de le rendre plus maintenable, plus testable et générique, et plus interopérable puisque le code sera partagé avec d’autres applis, ces morceaux ne seront plus propres à Drupal.

    Je trouve cela extrêmement intéressant.
    Le but n’est évidemment pas que tous les logiciels se ressemblent et gommer leur personnalité ou ce qu’ils pourraient apporter d’innovant.
    En effet, ça intégrerait surtout des éléments bas niveaux, qui sont à priori des bonnes pratiques dans un contexte #REST, quelque soit ce qu’on en fait ensuite.

    Voici l’annonce de #Fabien-Potencier, de Symfony :
    Symfony2 meets Drupal 8 - Symfony
    http://symfony.com/blog/symfony2-meets-drupal-8

    Et l’annonce de #Dries-Buytaert, de Drupal :
    The future is a RESTful Drupal
    http://buytaert.net/the-future-is-a-restful-drupal

    Des idées pour #SPIP 4 ?

    • SPIP intègre déjà des bouts de symfony (yaml par ex), mais en effet on a tout intérêt collectivement à avancer vers plus d’interopérabilité et de partage de code.

  • De #Drupal 7 à Drupal Gardens - Philippe Scoffoni
    http://philippe.scoffoni.net/drupal-7-drupal-garden

    Un des arguments mis en avant est l’absence de “#lock-in” ou verrouillage des utilisateurs. (...)
    Drupal Gardens répond à cela en offrant la possibilité de sauvegarder intégralement le site sous la forme d’un fichier compressé. Cette archive contient l’intégralité du répertoire de votre site avec tous les médias que vous avez pu charger , l’intégralité du code source PHP de Drupal, les extensions, le thème et bien sûr une sauvegarde de la base de données.

    #SaaS