C’est quoi une CMS Headless ?

Les CMS Headless sont avant tout des systèmes d’édition de contenu ; ça c’est la partie CMS (Content Management System), mais qui ont une particularité bien spécifique, c’est qu’ils s’affranchissent totalement de la façon dont ils sont affichés : par qui, par quoi ? Ils s’en moquent. En d’autres termes, ils sont totalement indépendants de toute plateforme d’affichage et de canvas. Ce qui signifie qu’ils ne dépendent pas d’une technologie en particulier pour fonctionner. Et c’est là toute leur puissance.

En effet, si un contenu n’est pas dépendant d’une technologie particulière pour exister, cela signifie qu’il peut être bien plus flexible dans la manière dont il va être distribué.

Et dans les faits ça donne quoi ?

Imaginons que l’article que vous êtes en train de lire actuellement soit « Headless », pour moi qui écris cet article, ça signifie plusieurs choses :

Pour commencer, je peux récupérer et utiliser ce contenu dans différentes applications. Pourtant je n’ai pas à faire de réplication car la source du contenu restera inchangée. Si je souhaite que certains de mes articles soient affiché à la fois sur mon site mais aussi dans une application mobile de mon cru (ou de quelqu’un d’autre d’ailleurs), je n’ai qu’à écrire mon contenu et « brancher » les applications concernée avec la plateforme sur laquelle j’édite mon texte. Je ne suis pas forcé non plus d’intégrer mon contenu via des procédés peu pratiques comme c’est encore trop souvent le cas via des iframes. Non, tout ce que j’ai à faire est d’écrire mon contenu sur ma plateforme d’édition et d’accorder les permissions nécessaires aux différentes applications qui vont le consommer.

Quel est l’intérêt ?

Je pense qu’avec les lignes précédentes, l’intérêt devrait vous sauter aux yeux : Pour faire simple, votre contenu peut être distribué vers n’importe quelle application et son affichage ne dépend que de la plateforme sur laquelle il est affiché.

Pour les publicateurs, c’est du temps gagné : Une plateforme de publication unique, pas de « tweak » ni de pris de tête avec des considérations techniques. L’écriture du contenu sera la seule considération.

Pour les développeurs aussi c’est du temps de gagné, car les données avec lesquels ils devront interagir seront toujours de même format : du JSON.

Les avantages en termes de créativité sont conséquents qui plus est, car le choix des technologies de développement ne sera plus un frein lié au canvas d’édition, comme ça peut être le cas avec des CMS Couplés type WordPress ou Liferay pour ne parler que d’eux. En tant que développeur, on peut être tenté d’utiliser une technologie qui n’est pas adaptée dans le but de gagner du temps, parce qu’on connait bien la dite technologie. Imaginons qu’on souhaite créer une application qui délivre du contenu, le souci étant qu’il faut permettre à notre client de pouvoir éditer son contenu avec un outil qui gère bien cette problématique. On peut être tenté d’utiliser une CMS Couplé, puisqu’ils gèrent normalement très bien la gestion de contenus (en même temps c’est pour ça qu’ils sont conçus). Les problèmes de cette solution sont nombreux :

Pour commencer, ces CMS viennent souvent avec un arsenal de fonctionnalités dont on n’a pas besoin. Ils viennent également avec des background techniques qui peuvent être assez lourd. C’est le cas de Liferay par exemple, qui est un puissant outil de gestion de contenu, mais c’est aussi, et avant tout un outil de création de portails qui pèse à lui seul plusieurs centaines de Mo. D’autre part chaque CMS Couplé est tributaire d’un environnement d’exécution : ça peut être Php / Apache, Java etc, qui nécessitent des serveurs qu’il faudra configurer et administrer. Ce sont des coûts supplémentaires non négligeables. Enfin, disons le simplement, c’est souvent « overkill », ou dit plus simplement, ça revient à tuer des mouches avec un fusil.

Alors attention, je ne dis pas que les CMS Headless n’impliquent plus de développement et qu’ils ne nécessitent pas d’environnement d’exécution, ce serait faux. Mais si l’on envisage uniquement les CMS Headless As A Service, la facture finale ne concernera au mieux que la partie frontale de nos applications, et au pire quelques middlewares supplémentaires.

L’intérêt des CMS Headless est donc conséquent, tant pour l’éditeur qui n’aura plus à se soucier des aspects techniques, comme c’est encore malheureusement le cas avec beaucoup de CMS populaires, mais aussi pour les développeurs qui peuvent travailler rapidement, grâce à l’utilisation de langages simples comme json, et de conventions de communication standardisées comme REST. Et si l’on est tout à fait ouvert à l’idée de CaaS (Content As A Service) et que l’on est prêt à embrasser ce que nous offre le cloud computing, les coûts de production seront drastiquement réduits pour les clients et les développeurs.

Quels service choisir ?

Bon, c’est bien beau, mais alors quels CMS Headless méritent qu’on s’y arrête ? Vaste question à laquelle une réponse nuancée est de mise. Déjà il faut savoir si l’on souhaite une solution auto-hébergée ou une solution As A Service. En ce qui me concerne je n’ai pour le moment utilisé que des solutions Cloud. Le but ici n’est pas non plus de faire un comparatif des offres qui existent sur le marché, d’autres articles en parlent bien mieux que je ne le ferais. Mais les deux solutions qui me semblent aujourd’hui viables, avec chacune une offre gratuite sont Contentful, DatoCms et Prismicio. J’ai une préférence pour Prismicio : Support en français, équipe réactive, et l’interface est vraiment sympa à utiliser. Seul « bémol » à l’heure actuelle, il n’est pas possible d’éditer du contenu en dehors de leur application web. Mais l’équipe y travaille actuellement d’après ce que j’ai appris de mes échanges avec eux.

Et les CMS Couplés dans tout ça ?

Mais du coup, est-ce que les CMS Headless signent l’arrêt de mort des CMS Couplés ? Là aussi une réponse nuancée est de rigueur. D’abord parce que certains acteurs du secteur sont en train de faire bouger les lignes : WordPress en tête, qui a amorcé un virage significatif ces trois dernières années en proposant de manière désormais standard, une api Rest. Drupal lui emboite le pas. La transition est donc marche. Quant à dire si les CMS tels que nous les connaissons vont mourir, j’ai tendance à penser que oui. Je pense aussi que les dinosaures qui n’auront pas su évoluer vers les contenus distribués disparaitront aussi. Quant à savoir quand tout cela se produira, je dirais qu’au vu de la vitesse à laquelle les choses ont évolué ces cinq dernières années, cela va arriver vite. Très vite même.

Conclusion

En ce qui me concerne, je continue d’utiliser les CMS Couplés, car à ce jour, ils bénéficient d’écosystèmes riches en termes fonctionnalités notamment. Ils permettent donc de travailler rapidement sans être forcé de réinventer la roue. Mais je me tourne de plus en plus vers du développement Javascript pure, car le langage propose aujourd’hui à peu près tout ce dont on a besoin pour développer des applications robustes et aux fonctionnalités riches. NodeJS et les framworks Javascripts comme Angular, VusJS et React sont en train de parachever cette transition, et c’est un plaisir de travailler avec ces technologies. Je vous invite par ailleurs à jeter un oeil à mon site personnel que je viens de mettre en ligne et qui embrasse cette philosophie de Headless CMS : http://francklebas.fr/

Si vous souhaitez aller plus loin, je vous recommande les articles suivants :

https://pantheon.io/decoupled-cms

Gestion de contenu : faut-il passer au headless CMS et au Content as a service ?

L’article Les CMS Headless, les CMS du future ? est apparu en premier sur DesireLabs.

Quand on lance un site, il existe différents cas de figures dans lesquels il est nécessaire que ce dernier envoie des emails. Par exemple quand un visiteur utilise le formulaire de contact, ou encore quand vous recevez un commentaire pour votre blog, voire quand un utilisateur s’inscrit.

Avec une application fonctionnant avec php, il est possible de configurer le smtp qui sera utilisé par l’application pour envoyer l’email. Le soucis est qu’il faut que la machine qui exécute l’application, le serveur donc, soit autorisé à le faire d’une part, et que l’adresse d’envoie qu’elle utilise existe.

Celà implique d’emblé de devoir envoyer les mains dans les fichiers de configuration, de devoir configurer le sendmail, d’autoriser l’envoi au niveau de votre registrar… On a déjà mal à la tête et on n’a pas forcément la garanti que ça fonctionnera. Alors que faire ?

La délégation de service

Des sociétés offrent de passer par leurs serveurs pour router les emails émis par vos applications et vous assurer de ne pas atterrir dans les spams. Souvent ces services offrent des formules très intéressantes et gratuites pour les faibles volumes d’envoi. Pour en avoir testé quelques uns, j’ai choisi de vous parler de celui que j’utilise aujourd’hui pour sa fiabilité et sa facilité de prise en mains : J’ai nommé Mailjet !

Alors oui, je fais de la publicité, et je ne suis pas rémunéré pour ça. Mais je pense que quand on découvre des services intéressants, c’est bien de partager

Mailjet c’est quoi ?

Mailjet est un « copilotes pour l’emailing ». C’est ainsi qu’ils se définissent en offrant une plateforme facile à utiliser pour faire des newsletter, envoyer des mails, offrir des statistiques détaillées de vos campagnes, et même la création from scratch de vos templates d’email.

Un des gros avantages de cette plateforme est qu’elle permet de configurer l’envoi d’emails à partir de votre domaine ou de votre adresse email, et ce gratuitement jusqu’à 200 emails par jour.

Comment ça marche ?

Premièrement il faut se créer un compte. Une fois que c’est fait, il faut se rendre dans la rubrique « Mon compte » pour atterrir sur votre tableau de bord.

Rendez-vous dans la section « Ajout d’un domaine ou d’une adresse d’expéditeur ».

La première chose à faire est de configurer le domaine à partir duquel les mails seront envoyés. Cliquez sur le bouton « + Ajouter un domaine » et remplissez les champs (nom du site et domaine) puis, validez.

Mailjet vous génère un fichier texte qu’il faudra mettre à la racine de votre site afin de vérifier que vous êtes bien le propriétaire du domaine. Procédez comme demandé, ceci permet de lier votre compte Mailjet à votre domaine.

Vient ensuite la configuration de l’email d’envoi. Oui parce que bon on n’a pas forcément envie que ce soit un email différent de notre domaine qui envoie tout nos mail hein

De retour sur la page des paramètres d’envoi, ajoutez l’adresse email qui est censée envoyer les emails à partir de votre domaine en cliquant sur le bouton « + ajouter une adresse email ».

Remplissez les champs demandés et renseignez le « type d’email ». Dans mon cas c’est pour les emails transactionnels, donc j’ai coché l’option  » E-mails de votre site ».

Voilà pour la configuration côté Mailjet. Passons à la configuration de votre application.

Configurer le smtp de Mailjet sur votre application

Je ne passerai pas en revue les différents moyen de configurer votre smtp, ceux ci étant relatif à votre serveur et / ou application. Ce qui est important c’est que vous sachiez où vous devez configurer tout ça.

Retournez sur votre tableau de bord, puis dans « paramètres SMTP et Send API ».

Sur la page suivante se trouve tout ce dont vous avez besoin pour configurer votre application : l’adresse du serveur smtp, le port (préférez le 587 vu comme précisé que certains hébergeurs bloquent le port 25 désormais), ainsi que vos identifiants de connexion Mailjet si besoin.

une fois que vous avez tout bien configuré, effectuez un petit test pour vous assurer que tout fonctionne Une fois terminé, vous pouvez supprimer le fichier texte qui se trouve à la racine de votre site et profiter de la vie sans prise de tête avec le mails B)

J’espère que cet article vous a plus, sachez que Mailjet propose aussi de l’emailing de masse pour les newsletter par exemple, mais n’ayant pas essayé pour le moment, je vous en reparlerai quand ce sera fait

A bientôt !

L’article Configurez facilement l’envoi de mail sur vos sites est apparu en premier sur DesireLabs.

See the Pen Pure css off-canvas menu by Franck (@neovea) on CodePen.

Cette solution m’a été inspirée par csswizardry et ses filtres de contenu en full css grâce au sélecteur « :target ». Je pense que les possibilités offertes par ce sélecteur sont nombreuses, et je me suis dit que j’en testerais bien une.

Pour commencer, que propose ce sélecteur au juste ? D’après Mozilla Developer Network :

La pseudo-classe:target permet de cibler l’unique élément (s’il existe) dont l’attribut id correspond au fragment d’identifiant de l’URI du document.

En clair, cela signifie que je peux cibler un élément identifié comme c’est le cas avec une ancre. Je clique sur un lien qui pointe vers une ancre (exemple href= »#mon-id »), je serai à même d’appliquer à l’élément ciblé par cette ancre un style… ou un comportement dans notre cas

Je tiens à préciser que j’utilise massivement sass dans cet article. Je met le code complet à la fin de l’article, avec la feuille de style css compilée

Démonstration

Considérons le code qui suit pour la partie html :

<!DOCTYPE html>
<html lang="fr">
<head>
	<meta charset="UTF-8">
	<title>Pure off canvas css menu</title>
	<link href="https://fonts.googleapis.com/css?family=Cutive+Mono" rel="stylesheet">
	<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" rel="stylesheet">
	<link rel="stylesheet" href="stylesheets/main.css">
</head>
<body>
	
  <div id="menu">
    <ul>
      <li><a href="">Lorem.</a></li>
      <li><a href="">Suscipit!</a></li>
      <li><a href="">Sapiente.</a></li>
    </ul>
  </div>

  <div class="button-group">  
    <a class="menu-button" href="#menu">
      <span>
      	<i class="fa fa-bars" aria-hidden="true"></i>
      	<i class="fa fa-times" aria-hidden="true"></i>
      </span>
    </a>
    <a class="menu-button off" href="#off-menu"></a>
  </div>

</body>
</html>

J’ai créé un menu portant l’id « menu » ainsi qu’un double bouton permettant de l’ouvrir et le fermer.

Remarquez au passage ce qui suit : Dans la balise portant la classe « button-group » nous avons en réalité 2 liens. Cet artifice permettra par la suite d’avoir un bouton pour fermer le menu. Je vous donne plus de détails dans la partie consacrée à css.
autre chose, le menu porte un id, car pour designer son comportement, nous allons faire appel au pseudo élément :target, ce qui en simplifiant, revient à créer une ancre.

A présent que notre structure html est prête, passons à la partie amusante : la css

Voici comment on va procéder : lorsque le bouton sera cliqué, l’élément ciblé via son attribut href sera sélectionné. A ce moment, le menu s’ouvrira, et par la même occasion, le second bouton passera en premier plan de manière à nous permettre de le rendre cliquable et de refermer le menu.

Commençons par opérer un « reset » sur notre page :

* {
  box-sizing: border-box;
}

html, body {
  margin: 0;
}

Ainsi nous aurons bien un menu bord à bord avec notre fenêtre. Ajoutons à cela le design de notre menu :

#menu {
  position: absolute;
  height: 100vh;
  width: 300px;
  margin: 0;
  background-color: #000;
  transform: translateX(-100%); /* Rend le menu invisible */
  a {
    color:#fff;
    font-family: Cutive Mono;
    text-decoration: none;
  }
}

Rien d’exotique ici, nous avons seulement placé le tout en position absolue, stipulé une translation négative de 100% de la largeur de l’élément afin de masquer le menu.

Passons aux boutons :

.button-group{
  position: absolute;
  width: 65px;
  height: 65px;
  top: 0;
  left: 0;
  margin: 8px; /* histoire de ne pas avoir le bouton collé */
}

.menu-button {
  width: 100%;
  height: 100%;
  position: absolute;
  display: flex;
  justify-content: center;
  align-items: center;
  background-color: #000;
  text-align: center;
  color: #fff; 
  border-radius: 50%;
  left: 0;
  top: 0;
  span {
    display: block;
    width: 100%;
    height: 20px;
    position: absolute;

    .fa-times {
      display: none;
    }
  }
  
  &.off {
    z-index: -1;
  }
}

Ce qui est important ici est le positionnement absolu de notre groupe de boutons, mais aussi et surtout ce dont je parlais plus tôt : le second bouton est placé derrière le premier grâce à un z-index négatif. Ainsi, lorsque nous cliquerons la première fois, nous ne risquerons pas de cibler le mauvais bouton.

Désormais, tout est près pour accueillir notre comportement. Il suffit d’utiliser le sélecteur css :target sur le menu pour jouer notre astuce.

#menu:target {
  transform: translateX(0);
  +.button-group {
    left: 300px;
    
    .menu-button:first-child {
      span {
        .fa-times {
          display: block;
        }
        .fa-bars {
          display: none;
        }
      }
    }
    
    .off {
      z-index: 0;
      background-color: transparent;
    }
  }
}

On a donc ajouté notre sélecteur qui dit que s’il est ciblé, notre menu opérera une translation vers la droite. On en profite au passage pour faire passer notre second bouton – celui qui ferme – au premier plan, en redéfinissant sont z-index à 0. Pour le cibler, rien de plus simple : notre groupe de boutons se trouve exactement après le menu dans le DOM. Du coup, on peut agir sur ses enfants simplement en utilisant le sélecteur +. On re-style aussi ce dernier pour se positionner à 300px du bord gauche du document.

Pas encore satisfait ? Allons un peu plus loin en tirant parti des facultés de css en termes d’animation et rendons tout cela un peu plus touchy’

Et puisque nous faisons du scss, créons une petite @mixin qui se chargera de créer nos transitions :

* {
  box-sizing: border-box;
}

html, body {
  margin: 0;
}

@mixin animation() {  
  transition-duration: 0.5s;
  transition-timing-function: cubic-bezier(0.65, 0.05, 0.36, 1);
}

.button-group{
  position: absolute;
  width: 65px;
  height: 65px;
  top: 0;
  left: 0;
  margin: 8px; /* just to give some space*/
  @include animation();
}

.menu-button {
  width: 100%;
  height: 100%;
  position: absolute;
  display: flex;
  justify-content: center;
  align-items: center;
  background-color: #000;
  text-align: center;
  color: #fff; 
  border-radius: 50%;
  left: 0;
  top: 0;
  span {
    display: block;
    width: 100%;
    height: 20px;
    position: absolute;

    .fa-times {
      display: none;
    }
  }
  
  &.off {
    z-index: -1;
  }
}

#menu {
  position: absolute;
  height: 100vh;
  width: 300px;
  margin: 0;
  background-color: #000;
  transform: translateX(-100%);
  a {
    color:#fff;
    font-family: Cutive Mono;
    text-decoration: none;
  }
  @include animation();
  
  &:target {
    transform: translateX(0);
    +.button-group {
      left: 300px;
      
      .menu-button:first-child {
        span {
          .fa-times {
            display: block;
          }
          .fa-bars {
            display: none;
          }
        }
      }
      
      .off {
        z-index: 0;
        background-color: transparent;
      }
    }
  }
}

Je trouve cette expérimentation – à défaut d’être respectueuse des règles d’accessibilité – très intéressante dans la mesure où elle remet en question l’usage de javascript pour des usages d’ordre fonctionnel ou esthétique. Ceci tend à rendre la frontière entre css et javascript un peu plus floue en rendant css auto suffisant lors de traitements fonctionnels un tantinet complexes.

En revanche, attention ! rechargez votre page et l’état du menu ne sera pas réinitialisé. En effet étant donné que nous utilisons une ancre, celle ci reste dans la barre d’adresse. De plus, l’état de votre menu est de fait enregistré dans votre historique.

Télécharger les sources

L’article Créer un menu off-canvas entièrement en css est apparu en premier sur DesireLabs.

C’est pourquoi je vous propose une approche de création de grille reposant sur SASS. Il est entendu que c’est faisable en CSS, mais c’est beaucoup plus rapide en SASS, c’est la beauté de la chose 

Le découpage du travail sera comme suit : D’abord on définira les différentes variables nécessaires ainsi que les points de rupture de notre grille responsive. Ensuite, on s’attardera sur la mécanique standard pour la génération de la grille “desktop”. Enfin on fera de même pour nos media-queries.

Définition de notre grille : Elle sera responsive bien sûr, on pourra choisir combien de colonnes on souhaite, la taille des gouttières, la largeur globale du conteneur, et les comportements des colonnes sur les différents appareils.

Voici les variables que je définis en premier lieu :

/* 1. valeurs de grille par défaut */

$cols: 12 !default;
$gutter-width: 1.2rem !default;
$max-width: 1180px !default;

On aura donc 12 colonnes, avec une gouttière de 1.2rem et une largeur maximum de 1200px. Ces valeurs sont suffisantes pour jeter les bases de la création de notre grille desktop. Ce que vous allons donc faire de ce pas :

/* 2. Définition de la grille */
.container {
  margin: 0 auto;
  width: 90%;
  max-width: $max-width;
}
.row {
  margin-left: 0;
  margin-right: 0;
  .row {
  	margin-left: -$gutter-width / 2;
  	margin-right: -$gutter-width / 2;
  }
  &:after {
    content: "";
    display: table;
    clear: both;
  }
  /* on divise la gouttière par 2 car on en retire une partie de chaque côté de la colonne */
  .col {
    float: left;
    box-sizing: border-box;
    padding: 0 $gutter-width / 2;
    margin-left: auto;
    left: auto;
    right: auto;

    /* On va boucler sur les colonnes et calculer automatiquement leur taille en pourcentage
     * un peu comme on pourrait le faire en javascript par exemple */
    $i: 1;
    @while $i <= $cols {
      $perc: unquote((100 / ($cols / $i)) + "%");
      &.small-#{$i} {
        width: $perc;
      }
      $i: $i + 1;
    }
  }
}

Dans ce système, ce sont les paddings qui définissent la taille de la gouttière. Ce qui fait que l’on n’a pas à se casser la tête avec le calcul de marges, d’autant que ces dernières ne sont pas prises en compte par box-sizing: border-box. Et ça c’est c’est déjà un pas vers plus de flexibilité : on peut ajouter autant de colonnes que l’on souhaite à notre ligne. Par ailleurs, plus de row ou row-fluid à la Bootstrap 2 : désormais toutes nos lignes sont fluides. Point. Seul le conteneur définira la largeur maximale de rendu. Et étant donné que nos tailles sont calculées en % on est tranquilles 

A présent il ne reste plus qu’à générer cette grille pour les tailles d’écran choisies :

@media screen and (min-width:721px) {

      $i: 1;
      @while $i <= $cols {
        $perc: unquote((100 / ($cols / $i)) + "%");
        &.medium-#{$i} {
          width: $perc;
        }
        $i: $i + 1
      }
    }

    @media screen and (min-width:1025px) {

      $i: 1;
      @while $i <= $cols {
        $perc: unquote((100 / ($cols / $i)) + "%");
        &.large-#{$i} {
          width: $perc;
        }
        $i: $i + 1;
      }
    }

Et c’est tout ! Bon on pourrait aller beaucoup plus loin en définissant des comportements plus spécifiques, mais la base est là. Voici le résultat final :

/* 1. valeurs de grille par défaut */

$cols: 12 !default;
$gutter-width: 1.2rem !default;
$max-width: 1200px !default;

/* 2. Définition de la grille */
.container {
  margin: 0 auto;
  width: 90%;
  max-width: $max-width;
}
.row {
  margin-left: 0;
  margin-right: 0;
  .row {
  	margin-left: -$gutter-width / 2;
  	margin-right: -$gutter-width / 2;
  }
  &:after {
    content: "";
    display: table;
    clear: both;
  }
  /* on divise la gouttière par 2 car on en retire une partie de chaque côté de la */
  .col {
    float: left;
    box-sizing: border-box;
    padding: 0 $gutter-width / 2;
    margin-left: auto;
    left: auto;
    right: auto;

    /* On va boucler sur les colonnes et calculer automatiquement leur taille en pourcentage
     * un peu comme on pourrait le faire en javascript par exemple */
    $i: 1;
    @while $i <= $cols {
      $perc: unquote((100 / ($cols / $i)) + "%");
      &.small-#{$i} {
        width: $perc;
      }
      $i: $i + 1;
    }

/* 3. Media Queries */
    @media screen and (min-width:721px) {

      $i: 1;
      @while $i <= $cols {
        $perc: unquote((100 / ($cols / $i)) + "%");
        &.medium-#{$i} {
          width: $perc;
        }
        $i: $i + 1
      }
    }

    @media screen and (min-width:1025px) {

      $i: 1;
      @while $i <= $cols {
        $perc: unquote((100 / ($cols / $i)) + "%");
        &.large-#{$i} {
          width: $perc;
        }
        $i: $i + 1;
      }
    }
  }
}

Il est entendu que la propriété flexbox tend à s’imposer pour ce qui est de la création de systèmes destinés à structurer le contenu. Je pense d’ailleurs qu’elle pourrait à terme remplacer nos systèmes de grille traditionnels. En revanche je pense que les systèmes comme celui que nous avons là on encore de beaux jours devant eux car ils restent à ce jour l’approche la plus stable car compatible avec n’importe quel navigateur / appareil.

Mais je me penche depuis quelques temps déjà sur flexbox, il n’est donc pas impossible que je fasse un article sur le sujet dans les semaines à venir 

L’article Créer son propre système de grille flexible avec SASS est apparu en premier sur DesireLabs.

<?php
function add_featured_image_in_rss() {
    if ( function_exists( 'get_the_image' ) && ( $featured_image = get_the_image('format=array&echo=0') ) ) {
        $featured_image[0] = $featured_image['url'];
    } elseif ( function_exists( 'has_post_thumbnail' ) and has_post_thumbnail() ) {
        $featured_image = wp_get_attachment_image_src( get_post_thumbnail_id(), 'post-thumbnail' );
    } elseif ( function_exists( 'get_post_thumbnail_src' ) ) {
        $featured_image = get_post_thumbnail_src();
        if ( preg_match( '|^<img src="([^"]+)"|', $featured_image[0], $m ) )
            $featured_image[0] = $m[1];
    } else {
        $featured_image = false;
    }
    if ( ! empty( $featured_image ) ) {
        echo "\t" . '<enclosure url="' . $featured_image[0] . '" />' . "\n";
    }
    
}
add_action( 'rss2_item', 'add_featured_image_in_rss' );

Merci à Sushi l’auteur du script

L’article Ajouter enclosure dans le flux RSS de WordPress pour les newsletters MailChimp est apparu en premier sur DesireLabs.

Design is a critical skillset for operating in the business world, but it’s up to you as the designer to show and tell this to your stakeholders.

Source : Designers: earn your seat at the table – InVision Blog

L’article Designers: earn your seat at the table – InVision Blog est apparu en premier sur DesireLabs.

Un thème WordPress nécessite normalement 1 seul et unique fichier CSS, à la racine : style.css. Mais tout mettre au kilomètre dans ce fichier c’est la garantie de rendre le projet difficile à maintenir et à faire évoluer. C’est pourquoi on préfèrera découper son design en modules. Plusieurs méthodologies existent, mais celle qui fait sens à mes yeux se rapproche de SMACSS. Je vous invite à aller faire un tour sur leur site, on y apprend des choses très intéressantes sur les manières possibles de découper son design CSS.

La puissance des préprocesseurs CSS n’est plus à démontrer : ils nous permettent de s’affranchir des préfixes vendeurs, d’apporter de la logique dans nos feuilles de styles, de séparer proprement notre architecture, bref, de tout calibrer au plus juste sans se répéter. C’est la méthode DRY (Don’t repeat yourself). Globalement, on gagne en productivité, en stabilité, on limite les régressions et en plus on s’éclate. Que demander de plus ?

Sass embrasse parfaitement cette philosophie du DRY et de la scalabilité. Mais pour l’installer sur WordPress comment ça se passe ?

Premièrement, il faut avoir déjà installé et configuré les outils sur sa machine. Dans mon cas, j’utilise le framework COMPASS. Il est réputé pour être l’un des plus complets avec une palette de mixins très étendue, et même si pas mal lui reprochent d’être assez lourd / lent à la compilation, de mon point de vue c’est à la marge. Car si vous n’avez jamais utilisé SASS / COMPASS, il faut savoir que le code que vous générez est compilé à la volée en fichier css standards.

Je pars du principe que les personnes qui lisent cet articles ont déjà COMPASS d’installé et sont prêts à se lancer.

Pour démarrer le projet (thème ou plugin) en mode SASS, il suffit d’initialiser un projet COMPASS à la racine. Si je construit un thème, j’ouvrirai le terminal à la racine de mon thème et je taperai :

compass init

A la suite de quoi, je me retrouve avec un fichier config.rb, ainsi que 2 nouveaux dossiers : sass et stylesheets. Le dossier sass est celui dans lequel on va travailler à l’avenir, mais avant, il faut aller un peu plus loin :

Les fichiers scss contenu dans le dossier sass vont entrainer la création / modification de leur alter égo css contenu dans le dossier stylesheets, à chaque fois que j’ajouterai / modifierai un fichier scss. Je vais donc devoir demander à compass de se mettre en « écoute », de manière à catcher les modifications au fur et à mesure. Je tape donc dans mon terminal, toujours à la racine de mon thème :

compass watch

Le watcher est à présent en mode « écoute », et toutes les modifications effectuées dans le dossier sass seront automatiquement compilées dans le dossier stylesheets. Mais cela ne suffit pas. Il faut dès maintenant indiquer à WordPress comment récupérer / lire les fichiers css créés.

Voici la logique que j’applique :

Mon fichier style.css à la racine de mon thème va dès à présent me servir de passerelle, en appelant un seul et unique fichier contenu dans le dossier stylesheets. Bien sûr, la création de ce fichier se passe d’abord dans le dossier sass : je créé un fichier nommé « main.scss », et automatiquement, son copain « main.css » est créé. Il me suffit alors d’importer ce fichier css dans mon « style.css » :

@import url(stylesheets/main.css);

Mais alors, et les autres fichiers aussi il va falloir  les importer ? Oui et non. En fait ce qu’on va faire c’est créer uniquement des fichiers scss qui ne seront pas compilés en fichiers css. Le but n’est pas de remplir le dossier stylesheets, mais de le maintenir avec un seul fichier : notre fameux main.css, et de dire à ce dernier de faire tous les imports des fichiers qu’on va créer par la suite.

Du coup on va préfixer tous nos nouveux fichiers scss avec un underscore « _ ». Par exemple, si je veux un fichier scss dédié à la navigation et un autre à mes modules, je vais les nommer respectivement « _navigation.scss » et « _modules.scss ». De cette manière je suis tranquille, je sais qu’ils ne seront pas compilés en css. Il ne reste plus qu’à les importer dans l’ordre qui nous convient, dans le fichier main.scss (qui lui ne possède pas d’underscore, et est donc compiler en main.css).

Voici ce que j’écris dans mon main.scss :

@import "compass";
@import "navigation";
@import "modules";

Première chose à noter, j’importe les fichiers en les appelant par leur nom, sans l’underscore et sans leur extension. C’est tout à fait normal. De plus je n’utilise pas « url(nom du fichier) », je met directement le nom de mon fichier entre guillemets, et c’est tout ! L’import de « compass » est nécessaire mais non obligatoire : le fait d’utiliser le compilateur de COMPASS ne vous oblige nullement à utiliser les mixins fournies, mais bon, ce serait dommage de se priver Pour ma part je recommande de ne pas importer COMPASS entièrement, mais de sélectionner les outils qui vous intéressent. Je vous laisse jeter un oeil à la documentation de compass à ce sujet.

Si on récapitule :

j’ai un fichier style.css qui importe le fichier main.css, qui lui même est issu de la compilation de main.scss, et c’est dans main.scss qu’on importe autres feuilles de style scss. C’est aussi simple que ça ! Les modules importés sont préfixés d’un underscore, de manière à ne pas générer un fichier css pour rien, mais de tout centraliser grâce à un seul et unique fichier : main.scss

C’est ainsi que je procède dans mes projets, une fois que tout est en place, il ne me reste qu’à lancer mon watcher et tout se fait dans le dossier sass à la racine du thème. On ne peut faire plus simple, enfin pas tant que les navigateurs ne parleront pas autre chose que du css

L’article Utiliser SASS dans ses projets WordPress est apparu en premier sur DesireLabs.

Petite parenthèse pour les utilisateurs Apple : Je vous présente mes excuses, car certains ont visiblement rencontré des soucis avec le calendrier. N’ayant pas d’appareil Apple pour déboguer, je ne m’y suis pas attelé.

Merci cependant à tous pour vos retours, ils vont m’être précieux afin de proposer des contenus plus adaptés, ainsi qu’un future « cadeau » de fin d’année en 2016, promis

Quant au blog, j’avais déjà par le passé exprimé ma volonté de migrer vers un autre outil de publication. Mais je n’ai malheureusement pas eu le temps de me pencher dessus. Entre le travail à l’agence et les projets freelance, vraiment pas évident, donc relégué plus loin dans la liste des priorités. Par ailleurs, WordPress reste un outil finalement suffisamment puissant et flexible pour décider de continuer avec.

Quant à la publication d’un thème, sachez qu’il est en cours et qu’il arrivera d’ici ce printemps. J’ai pris du retard, car les ambitions étaient assez importantes : proposer un thème qui soit à la fois léger, et modulaire via la création d’options spécifiques qu’on aura le choix d’activer ou pas. Car j’ai toujours regretté ces thèmes ultra complets, lourds et difficiles à maintenir. Ainsi on n’active que ce dont on a besoin et puis c’est tout. Ainsi on n’alourdit pas inutilement sont site. Je travaille à l’intégration d’outils et librairies open source dont la communauté et les auteurs sont actifs, ce qui, je l’espère permettra à ce thème d’offrir à d’autres développeurs les clés pour profiter d’un thème puissant et facilement maintenable.

Comme certains l’ont vu, j’ai également offert à la communauté WordPress 2 plugins, dont le développement est toujours actif :

Desire Portfolio Filter – qui ajoute les fonctions de filtres par type aux portfolio JetPack
Desire Page Widget – qui permet l’ajout d’une sidebar de Widget dans le contenu via shortcode, ainsi que l’inclusion de page via un widget dédié

Ces deux plugins en sont à leurs débuts et ne proposent pour l’instant que des fonctionnalités assez simples. Mais grâce aux retours des utilisateurs, ils devraient bientôt offrir plus. Donc si vous même vous les utilisez, n’hésitez pas à faire un feedback, si possible dans les commentaires de leurs pages respectives, sur GitHub et WordPress.org. Les retours sont très important et permettent d’améliorer et d’offrir des outils pertinents. Deux autres plugins sont en cours de développement. Mais ça, je vous en reparlerai en temps et en heure

Dernière chose, l’activité sur le blog risque de ralentir ces prochains mois. Elle n’était déjà pas énorme, d’autant que je le tiens pour le plaisir d’une part, et participer à la communauté d’autre part, mais je vais opérer une migration de moi-même vers Toulouse ! Ceci arrivera fin juin (à priori). Je suis déjà en recherche active de rencontres, d’agences et de confrères dans la ville rose. Une nouvelle aventure qui se prépare donc, et qui occupe pas mal de mon temps D’ailleurs si vous êtes de là bas, n’hésitez pas à me contacter histoire qu’on se rencontre ou échange une fois sur place, voire avant

Je vous souhaite encore une bonne et heureuse année 2016, pleine de projets, de joie et de vie !

Ciao !

L’article Edito – Calendrier de l’avent 2015 et nouvelle année est apparu en premier sur DesireLabs.

Cliquez ici pour accéder au calendrier.

Joyeuses fêtes

L’article En attendant Noël, je vous offre un calendier de l’Avent 2.0 est apparu en premier sur DesireLabs.

L’article Pourquoi trouver un bon développeur frontend est si difficile ? [en] est apparu en premier sur DesireLabs.