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.

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.

Je trouvais que ce qui manquait réellement à Jetpack Portfolio, c’était la possibilité de filtrer ses projets en fonction du type par exemple. Et comme je trouvais dommage d’installer un autre plugin de portfolio juste pour cette featurette, j’ai opté pour un plugin maison qui fait appel aux portfolio Jetpack. Donc vous ne pouvez pas utiliser ce plugin sans Jetpack.

Pour l’heure, il utilise un template spécifique pour l’affichage des portfolios, qu’il faut choisir sur la page d’affichage lors de l’édition, en remplacement de l’utilisation du shortcode fourni par automattic. Cela implique que l’on n’a plus la main sur les portfolios qu’on affiche. Mais une version est en cours de développement afin de rendre à César ce qui est à César, et offrir à nouveau cette possibilité.

Télécharger le plugin sur :

Ou sur :

Je vous laisse découvrir et me faire vos retours

L’article Filtrer ses portfolios Jetpack grâce à Isotope est apparu en premier sur DesireLabs.

1. Pouvoir ajouter des widgets dans un contenu (page ou article par exemple) via un simple shortcode
2. Pouvoir afficher une page dans un widget (pratique si l’on souhaite faire un design one page)

C’est la version 1.0, ce qui signifie qu’elle est stable bien sûr, mais aussi que pour l’instant, il n’y a aucune autre fonctionnalité que celles décrites plus haut. J’ai déjà une petite liste d’améliorations et d’évolutions dans les cartons, so wait (try) and see

Je ne vous décris pas son fonctionnement, je vous laisse découvrir ça par vous-même, car vous verrez c’est très simple.

Quelques captures d’écran viendront bientôt, donc en attendant, si vous souhaitez tester l’application, rendez-vous sur mon compte GitHub :

Ou sur wordpress.org :

N’hésitez pas à me faire vos retours sur mon compte GitHub ou dans les commentaires. Merci

L’article Intégrer des widgets dans ses contenus WordPress est apparu en premier sur DesireLabs.

Ensuite vient la question de l’organisation du travail à effectuer : si tous vos sites se ressemblent en termes de structure et de contenu, autant ne pas se fouler et utiliser un outil qui va industrialiser tout ça pour vous : MultiSite Clone Duplicator. L’idée de base est simple, on fait son site « maître », on active le multi, et on duplique.

Etape 1 : la création du site maître et l’activation de WordPress MultiSite

On commence par créer sa première instance de site, et on active le multi en ajoutant à wp-config.php la ligne

define( 'WP_ALLOW_MULTISITE', true );

juste au dessus du commentaire

/* C'est tout, ne touchez pas à ce qui suit ! Bon blogging ! */

A partir de là, on se connecte à l’administration, et sous le menu « Outils », une nouvelle entrée « Création du réseau » apparaît.

Avant de cliquer, désactivez tous les plugins, ceci est impératif, sans quoi, vous ne pourrez pas poursuivre la configuration. A noter au passage que toute action sur un site au sein du réseau, nécessite que les plugins soient désactivés sous peine de voir apparaître des bugs.

Vous arrivez ensuite sur la page de configuration où l’on vous demande de choisir entre sous-domaines ou sous-dossiers. C’est à vous de voir. Pour mes besoins, ce sera en sous-domaines. Vous n’avez qu’à suivre à la lettre les indications de cette page et de la suivante pour procéder en bonne et due forme à l’activation de votre réseau.

Avant de modifier vos fichiers .htaccess et wp-config.php comme demandé à l’étape suivante, je vous recommande de vous en faire une sauvegarde, just in case Une fois que les modifications sont faites, il vous suffit de vous reconnecter et d’admirer votre nouveau menu d’administration de réseau.

Voilà ! Vous n’avez plus rien à configurer, si ce n’est votre site maître. Car votre installation est encore toute fraîche, il vous faut l’alimenter, la paramétrer, créer vos users ainsi que vos pages principales.

Etape 2 : Cloner son site maître et créer un site enfant en sous-domaine

Cette étape consiste à dupliquer son site maître ainsi que tous ses réglages, contenus, utilisateurs vers une instance MultiSite. Ceci peut être assez pratique quand on a des sites dont la configuration est les contenus sont similaires, ou qu’on utilise des shortcodes pour structurer ses pages. Il suffit d’installer le plugin MultiSite Clone Duplicator qui, comme son nom l’indique, va créer pour vous vos instances avec les sous domaines qui vont bien, tout en dupliquant vos données d’un site vers l’autre. Son utilisation et sa fiabilité font de ce plugin un must have quand on fait du MultiSite.

Pour installer le plugin, vous ne passez plus par le menu habituel, mais par le menu de « Mes sites » > « Admin du réseau » > « Extensions ». En effet les plugins et les thèmes sont des ressources partagées entre tous vos sites, que vous installez de manière globale. Mais rassurez vous, leur activation sur vos différents sites sont tout à fait libres. Installez donc ce plugin et cliquez sur « Activer sur le réseau », ce qui le rendra disponible pour tous vos sites. Une fois activé, une nouvelle entrée fait son apparition dans le menu d’admin du réseau.

La page d’option est très simple et vous demandera le sous-domaine souhaité (si c’est l’option que vous avez choisie), le titre du nouveau site ainsi que le mail du nouvel administrateur. Vous pourrez également choisir si vous souhaitez conserver les utilisateurs et rôles du site dupliqué, copier les fichiers du répertoire d’upload, voire sauvegarder les logs dans un répertoire du plugin.

Et c’est tout ! Reste qu’à appuyer sur le bouton

Nota Bene : Le Multi ne nous dispense pas de la création de nos vhosts pour rendre nos instances accessibles, mais ça c’est une autre histoire !

C’est à peu près tout, je ne suis pas trop rentré dans les détails car je souhaitais que ce petit tuto reste simple et accessible, mais je posterai d’autres articles connexes au sujet de WordPress MultiSite. N’hésitez pas à venir discuter si le sujet vous intéresse ou que certaines choses ne sont pas claires.

L’article Tutoriel – Installer WordPress MultiSite et cloner son instance de site maître est apparu en premier sur DesireLabs.

Il s’agit de WpScan. Tout en ruby, il s’installe sur une machine Linux. Tout site WP peut être scanner. Ce qui fait de cet outil un joujou de choix pour les hackers potentiels. Je l’ai installé sur mon serveur pour tester, et c’est plutôt efficace. De plus toutes les failles qu’il remonte sont documentées avec plusieurs sources. Bravo aux développeurs de cette perle !

Je vous encourage à le tester. Voici le site ainsi que leur GitHub :

http://wpscan.org/

https://github.com/wpscanteam/wpscan

Si vous aussi connaissez des outils similaires, n’hésitez surtout pas à les partager !

A+

L’article Outil – Scanner de vulnérabilités WordPress est apparu en premier sur DesireLabs.

Il est de notoriété publique qu’un site qui met du temps à s’afficher pose 2 problèmes majeurs :

*Les visiteurs fuient
*Les moteurs de recherche pénalisent le site

Les deux combinés contribuent à une dégradation notable du nombre de visites, une explosion du taux de rebond, et une mauvaise réputation.

Petit état des lieux

Un site c’est avant tout un ensemble de ressources qui sont servies aux visiteurs. Ca comprend des données bien sûr, des feuilles de style CSS pour rendre le tout visuellement agréable à lire, et du javascript très souvent qui permet d’apporter des fonctionnalités souvent discutables. Toutes ces ressources demandent de la bande passante et de la mémoire. La maîtrise de ces deux facteurs est la clé vers l’optimisation d »un site de manière général, et tout particulièrement avec WordPress.

Première étape : Faire du ménage

La question qu’il faut toujours se poser et garder à l’esprit est la suivante :

*est-ce que cette fonctionnalité sert le contenu (et par extension, les visiteurs) ?*

Ca peut paraître bête dit comme ça, mais on a trop souvent tendance à rajouter des fonctionnalités pas toujours utiles à WordPress par l’intermédiaire des extensions. Et c’est compréhensible, avec plus de 32 000 plugins dispos sur le dépôt officiel, c’est tentant. Alors on arrête les frais et on ne garde/installe que ce dont on a besoin. Une extension doit être pertinente et apporter une vraie plu-value à votre contenu. A titre d’exemple, sur / j’ai en tout et pour tout 6 extensions installées :

Akismet
Contact Form 7
Crayon Syntax Highlighter
WP-SEO
Jetpack par WordPress.com
WP Rocket

Et honnêtement je n’ai pas besoin de plus. Ces 6 extensions répondent à l’ensemble de mes besoins. Pareil pour les bibliothèques javascript, souvent activées par défaut dans votre thème. Sachez que même si vous ne les utilisez pas, elles se chargent en même temps que votre page. A défaut de les supprimer, mettez les au moins en commentaire dans votre code afin de pouvoir y revenir si besoin.

Externaliser les ressources

Les CDN (content delivery network), ça vous parle ? Ce sont des serveurs tiers qui hébergent tout type de ressource comme du javascript, vos images ou vos vidéos. Pourquoi faire appel à un CDN ? Pour économiser votre bande passante, tout simplement. Exemple, un fichier javascript qui pèse 40ko et qui se charge sur chaque page et pour chaque visiteur, ça peut vite chiffrer quand on en a une bonne dizaine. Alors pourquoi ne pas libérer cette bande passante pour vos contenus et laisser d’autres faire le sale boulot à la place de votre site ?

Quelques exemples de CDN :

www.jsdelivr.com
developers.google.com
www.maxcdn.com

Il en existe des centaines, voire des milliers. Même les bibliothèques javascript les plus populaires possèdent leur propre CDN. Si vous utilisez un framewwork comme Bootstrap ou les icônes de fontawesome, vous y avez droit. Pourquoi se priver ?

Alléger vos pages de leurs gadgets widgets

Un petit encart pour le partage ici, les derniers articles par là, les archives par ci… Stop ! Les visiteurs s’en tapent. S’ils veulent trouver quelque chose, ils utiliseront la fonction recherche et la taxonomie présente sur votre site. Et s’ils veulent partager vos contenus, ils le feront sans l’aide de vos boutons. Au passage ça évite de nuire à la lecture de vos contenus.

Jouer à cache cache

WordPress permet d’utiliser la mise en cache de vos contenus. Concrètement, un contenu qui a déjà été visite est servi directement de manière statique aux autres visiteurs. On évite les requêtes en base de donnée, ce qui n’est pas un mal avec WordPress quand on sait qu’il n’utilise pas encore PDO MySql. Je crois pouvoir dire sans me tromper de beaucoup que c’est la fonctionnalité la plus intéressante à votre disposition. Le hic, c’est que pour en profiter, il faut un plugin. Et là, on a l’embarras du choix. En ce qui me concerne, j’en ai testé plusieurs, et mon choix s’est arrêté sur WP-Rocket. A ce jour, c’est à mon avis la solution la plus aboutie, légère et complète en plus d’être extrêmement simple à mettre en place. Parmi les options que cette extension propose : lazy loading, minification des css, html et javascripts, et bien d’autres fonctionnalités bien sympa. A 29,00€ le plugin, c’est du pain béni et une véritable cure de jouvence pour WordPress. Un vrai investissement quoi ! Sinon, parmi les gratuits, je recommanderais W3 Total Cache.

Minification

La minification c’est le fait de mettre tous ses fichiers de ressources css, js, html bout à bout et au kilomètre afin de se charger plus vite. Ce n’est pas un gadget mais un véritable outil. Ajouté à la mise en cache, ce sont des performances accrues pour votre site et une meilleure disponibilité de vos contenus. Wp-Rocket inclut cette fonctionnalité, mais si vous recherchez un plugin gratuit : Better WordPress Minify.

Compression des données

Encore une véritable optimisation. Probablement l’une des plus importantes avec la mise en cache. Il s’agit de servir à vos visiteurs des contenus compressés. Cette manipulation n’est pas triviale et s’effectue côté serveur, à condition d’avoir les bons modules apache activés et les bonnes directives dans votre fichier .htaccess. Je ne m’étalerai pas sur ce sujet, car d’autres sites bien plus spécialisés sauront le faire mieux que moi. Je vous donne tout de même un lien : www.alsacreations.com. Ceci est également proposé en standard par WP-Rocket (je vous l’ai dit c’est une petite bombe :p)

Maîtriser son image

Aujourd’hui WordPress propose un outil pour la gestion des médias qui a bien évolué avec le temps. Beaucoup de tâches sont désormais possibles au travers de l’interface offerte. Mais n’oubliez pas qu’une image destinée au web n’est par défaut pas destinée à être imprimée. Donc on reste dans les standards du web et on optimise le poids des images en ajustant leur taille et leur résolution avant de les importer de préférence. Une image trop grande et de trop grande résolution ne sert à rien sur le net. 72dpi pour la résolution et 1024px de large maximum me semblent être un bon début. Au passage, pensez à bien nommer vos images avant import, pour le SEO, ça compte !

Mais que fait la police ?

Avant on n’avait pas le choix pour les typos de son site : Arial, Times New Roman etc étaient les standards tristement incontournables. Aujourd’hui ce n’est plus le cas et on peut vraiment se lâcher. Du coup on fait un peu n’importe quoi en servant des polices pas du tout optimisées pour le net. Là aussi il y a des services qui vous proposent des typos et ce sans trop alourdir votre site. Vous n’avez plus besoin de choisir entre rapidité et esthétique. Mon préféré est www.fontsquirrel.com avec une pléthore de fonts disponibles et gratuites, des packs webfont prêt à l’emploi, et même un webfont generator. Sinon il y a www.google.com/fonts. Pas mon préféré, mais il fait le job. Alors on arrête d’importer des fonts qui pèsent un âne mort comme des bourrins

Conclusion

J’ai volontairement été succinct en vous donnant toutes les pistes exploitables pour optimiser votre WordPress, car je n’ai pas la prétention d’être expert dans ce domaine. Mais ces pistes doivent être à mon avis un point de départ vers l’optimisation. Et ne jamais perdre de vue que ce qui prime sur un site c’est son contenu. Et que ces optimisations doivent être à son service. Je vous donne encore quelques liens utiles avant de vous quitter ainsi que ceux dont je vous ai parlé dans cet article, histoire de pas vous laisser sur votre faim

Si vous avez des remarques ou des idées et astuces pour améliorer les performances de votre site WordPress, ou que vous pensez qu’il manque quelque chose dans la liste, venez en discuter via les commentaires

Tester les performances de votre site et savoir ce qui cloche :

https://developer.yahoo.com/yslow/ (extension pour navigateur)

https://developers.google.com/speed/pagespeed/

http://tools.pingdom.com/fpt/

http://gtmetrix.com/

Les plugins qui passent bien :

http://wp-rocket.me/fr/

https://wordpress.org/plugins/w3-total-cache/

https://wordpress.org/plugins/bwp-minify/

https://wordpress.org/plugins/p3-profiler/ (pas mal pour voir quels sont les plugins qui mangent vos performances)

Les CDN

www.jsdelivr.com

developers.google.com

www.maxcdn.com

L’article Tutoriel – Optimiser WordPress pour les performances est apparu en premier sur DesireLabs.

sudo find wordpress/ -type d -exec chmod 755 {} \;
sudo find wordpress/ -type f -exec chmod 644 {} \;
sudo find wordpress/wp-config.php -type f -exec chmod 444 {} \;

Explications :

find : c’est la fonction de recherche
wordpress/ : c’est le répertoire à partir duquel chercher
-type : le type avec en argument  « f » pour « folder » et « d » pour « document »-exec : précise qu’on va exécuter quelque chose pour les fichiers ou dossiers rencontrés
chmod : la commande pour changer les droits
755 : permission pour les dossiers
644 : permission pour les fichiers
444 : permission pour les fichiers de configuration sensibles (qui contiennent vos identifiants mysql par exemple)

Il va de soit que vous appliquez les permissions que vous voulez

L’article Astuce – Appliquer des permissions à un ensemble de fichiers et dossiers de manière récursive dans WordPress est apparu en premier sur DesireLabs.

Les prérequis :

Avoir déjà installé le module Wysiwyg et l’éditeur de texte de votre choix. Je ne traiterai pas cette partie, d’autres sites le font déjà très bien. Ici, j’ai choisi TinyMce 3.5.

La suite de module suivante :

• Chaos Tool Suite
• Media
• File Entity

L’installation :

Une fois ces modules installés, activez-lez et rendez-vous dans :

Administration » Configuration » Rédaction de contenu » Formats de texte

Éditez la configuration du format de texte souhaité, et cochez la case Convert Media tags to markup.

Sur la même page, tout en bas, dans Balises HTML autorisées , ajoutez la balise <img>.

Rendez-vous enfin dans Administration » Configuration » Rédaction de contenu » WYSIWYG Profile et modifié le format de texte précédemment sélectionné. Dans la partie Afficher Buttons and plugins, ajoutez à votre éditeur la fonction Media browser.

Pensez également à cocher l’option image afin de pouvoir par la suite éditer votre fichier dans l’éditeur de texte.

Vous voilà paré ! Testez l’édition d’un contenu pour voir apparaître la nouvelle icône.

Les fonctions sont assez sommaires, vous pouvez uploader du contenu ou parcourir le contenu précédemment uploadé et l’insérer dans tout type de contenu pour lequel votre format de texte est activé.

Voilà, vous pouvez à présent uploader des fichiers dans drupal. Enjoy !

L’article Intégrer un uploader des fichiers dans Drupal avec le module wysiwyg est apparu en premier sur DesireLabs.

Quand on créé des pages avec Views, on est forcé de traduire le chemin de page dans views. Or quand on bosse sur un site multilingue, on se retrouve avec le même alias quelque soit la langue. C’est mal foutu, oui.

Exemple, on créé une page actualités/toutes-les-actualités en fr, on se tape le même alias en anglais et consors. Alors pour avoir notre news/all-news, voici comment faire :

Pour commencer on se rend sur la page de gestion des alias d’url dans le panneau de configuration et on dégage et notre alias français et notre aalias anglais si ils sont déjà créés.

Ensuite on créé sa page dans views en version anglais du site, soit « news/all-news ».
On retourne dans la page de gestion des alias, toujours en anglais, et on filtre pour retrouver l’alias fraîchement généré par views, puis on l’édite. Dans le champs « Existing system path » on retape notre alias anglais, et en dessous, dans « Path alias » on tape notre alias traduit en français par exemple. Dans le menu déroulant « Language » on sélectionne la langue de destination, français donc pour l’exemple, et on valide. Et paf ! pastèque !

Testez par vous même : vous avez à présent votre alias en anglais et en français

Si vous devez gérer d’autres langues, vous procédez de la même façon en retrournant modifier l’alias d’url anglais en en spécifiant le bon alias dans « Path alias » et en sélectionnant la langue dans la liste déroulante.

Si jamais ça n’a pas fonctionné, vérifiez que vous n’avez pas déjà une page créée possède déjà l’alias, recommencez toutes la procédure en vous assurant d’avoir bien dégagé les alias dans la page dédiée à la gestion des alias pour toutes les langues et recommencez.

Voilà, c’est tout

Au passage, de manière générale, quand vous construisez un site multilingue, prenez la bonne habitude de construire votre site en partant de la version anglaise, puis traduisez les contenus dans les autres langues enssuite afin de bien définir la langue maîtresse de votre site et ne pas vous emmêler les pinceau.

L’article Traduire le chemin de page dans views est apparu en premier sur DesireLabs.