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.

L’astuce est très simple en fait

Dans le script de mon plugin j’ai rajouté ce petit bout de code :

function fp_add_custom_post_class($classes) {
    $classes[] = 'test-class';
    return $classes;
}
add_filter('post_class','fp_add_custom_post_class');

Et le tour est joué, tous mes articles hériteront de ma nouvelle classe perso.
C’est propre, efficace et léger

Par extension, on peut appliquer ça au body avec le hook body_class.

L’article Ajouter une classe css personnalisée aux articles WordPress est apparu en premier sur DesireLabs.

This page contains the following errors:

error on line 11 at column 67: EntityRef: expecting ‘;’

Below is a rendering of the page up to the first error.

Cette erreur est dûe au « & » interprété comme un caractère html spécial auquel il manque le « ; » de fin.

La solution

Pour corriger ce souci, il suffit d’éditer le code source de Google XML Sitemap, de repérer la dernière condition if et la modifier comme suit :

if ( ! empty( $post->post_title ) && ( get_post_type( $post->ID ) != "wpcf7_contact_form" ) ) {
    $xml .= "\t\n";
    $xml .= "\t\t" . get_permalink( $post->ID ) . "\n";
    $xml .= "\t\t" . mysql2date( 'Y-m-d\TH:i:s+00:00', $post->post_modified_gmt, false ) . "\n";
    $xml .= "\t\t" . 'weekly' . "\n";
    $xml .= "\t\t" . '0.8' . "\n";
    $xml .= "\t\n";
}

Cela supprimera tout bonnement la référence inutile
Solution trouvée sur http://wordpress.org/support/topic/google-xml-sitemap-erroring-due-to-contact-form-7

EDIT : Depuis je suis passé à WordPress SEO by Yoast, il s’agit d’un plugin qui comme son nom l’indique apporte toutes les fonctionnalités SEO qu’on peut attendre, dont la gestion de sitemap. Du coup plus de bug.
Je pense rédiger un article au sujet de ce plugin très bientôt, so stay plugged !

L’article Résoudre le conflit entre Google XML Sitemap et Contact Form est apparu en premier sur DesireLabs.