Matt Biscay: développeur WordPress et WooCommerce pour SkyMinds
WordPress : rediriger la page d'attachement vers l'article auquel les fichiers médias appartiennent photo

WordPress : rediriger la page d’attachement vers l’article parent

WordPress publie par défaut une page d’attachement pour chaque fichier média que vous publiez sur votre site.

En règle générale, un fichier média (image, vidéo, autre) appartient à un article: on attache souvent ce type de fichier lors de la rédaction des articles, pour les insérer dans le corps des billets.

Le problème est donc que WordPress crée gentiment une page dédiée à chaque média publié. Cette page ne contient aucun contenu, à part afficher le média en question, ce qui n’est pas vraiment idéal au point de vue SEO puisque l’on se retrouve avec énormément de pages mais qui ne seront jamais indexées au vu du contenu inexistant. S’il est donc superflu d’avoir ces pages, autant s’en séparer!

C’est là que nous allons tenter d’être malin : pourquoi ne pas rediriger ces pages d’attachement vers l’article auquel ces fichiers media appartiennent?

Jusqu’à très récemment, j’utilisais le module Origin de The SEO Framework, qui fonctionne très bien si le média a été uploadé sur un article. La page d’attachement est alors automatiquement redirigée vers l’article.

Le hic, c’est que si le fichier média a été uploadé directement depuis la page WP Admin > Média, alors nous sommes redirigé vers /wp-admin, ce qui ne fait aucun sens.

Voici donc la solution que j’utilise sur le site:

<?php
/*
Script Name: Redirect attachment page to parent post.
Script URI: https://www.skyminds.net/?p=32314
Description: Redirects attachment to parent post (if it exists), or redirects to the homepage otherwise.
Version: 2.6.0
Author: Matt Biscay
Author URI: https://mattbiscay.com
*/
add_action( 'template_redirect', 'sky_redirect_attachment_to_post' );
function sky_redirect_attachment_to_post(){
  // if not an attchment, bail out early
  if( !is_attachment() ) {
    return;
  }
  // check if parent post is defined
  if( isset( $post ) && isset( $post->post_parent ) && is_numeric( $post->post_parent ) && ( $post->post_parent != 0 ) ) :
    // redirect to parent post
    wp_redirect( esc_url( get_permalink( $post->post_parent ) ) ); exit;
  else: // media has been uploaded through the Media page or is unattached to a specific post
    // redirect to homepage
    wp_redirect( esc_url( home_url( '/' ) ) ); exit;
    // or redirect to the media itself
    // wp_redirect( esc_url( wp_get_attachment_url() ) ); exit;
  endif;
}

Ce code est à copier-coller dans le fichier functions.php de votre thème enfant. Vous pouvez également l’enregistrer en tant que plugin.

Une fois activé, si vous visionnez l’adresse d’une page d’attachement, vous devriez être redirigé sur l’article parent.

Notez que je vous ai mis 2 possibilités pour la redirection lorsque le media n’a pas été attaché à un article: une redirection vers la page d’accueil ou alors vers le fichier média directement.

A vous de choisir ce qui vous correspond le mieux :)

macos monterey wallpaper

Installer composer et PHP sous MacOS Monterey

Depuis la mise à jour MacOS Monterey (v12+) et pour toutes les versions à venir, Apple ne fournit plus de binaire PHP installé par défaut.

Si vous utilisez composer par exemple pour l’un de vos scripts ou plugin, voici le message d’erreur que vous pouvez obtenir:

composer update --no-plugins --no-scripts
env: php: No such file or directory

J’ai tenté pas mal de solutions, comme installer PHP avec brew mais cela n’a pas résolu le problème.

Error: Permission denied @ apply2files

C’est l’une des erreurs obtenues lors de l’installation de paquets avec brew, directement après la mise à jour vers Monterey:

Error: Permission denied @ apply2files - /usr/local/lib/node_modules/npm/node_modules/.bin/node-gyp

Si cela vous arrive, c’est un problème de permissions sur le répertoire /user/local, la solution est simple, il faut redonner les bonnes permissions à votre utilisateur avec cette commande:

sudo chown -R $(whoami):admin /usr/local/* \
&& sudo chmod -R g+rwx /usr/local/*

Voilà déjà un problème réglé.

Installer composer sous MacOS Monterey

La véritable solution, toute simple finalement, est de réinstaller composer, qui se charge alors d’installer la version idoine de PHP.

On installe composer avec brew:

brew install composer

Résultat:


==> Downloading https://ghcr.io/v2/homebrew/core/php/manifests/8.1.0
Already downloaded: /Users/matt/Library/Caches/Homebrew/downloads/6dba7b955c116a258cc340994e9e9ed7dfdfe3ab7668f0f9adb5dfcdaaf303a2--php-8.1.0.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/php/blobs/sha256:dbbf3f0e595af9a72f6dcf7fef1890c6152bf9fb1be83f166b467393176c4aa5
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:dbbf3f0e595af9a72f6dcf7fef1890c6152bf9fb1be83f166b4
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/composer/manifests/2.1.14
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/composer/blobs/sha256:02f5fed3d67b82fb827078ffcd486a4a455d1f94e94d0701d779238d4e10903e
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:02f5fed3d67b82fb827078ffcd486a4a455d1f94e94d0701d77
######################################################################## 100.0%
==> Installing dependencies for composer: php
==> Installing composer dependency: php
==> Pouring php--8.1.0.monterey.bottle.tar.gz
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_ini /usr/local/etc/php/8.1/php.ini system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_dir /usr/local/share/pear system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set doc_dir /usr/local/share/pear/doc system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set ext_dir /usr/local/lib/php/pecl/20210902 system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set bin_dir /usr/local/opt/php/bin system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set data_dir /usr/local/share/pear/data system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set cfg_dir /usr/local/share/pear/cfg system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set www_dir /usr/local/share/pear/htdocs system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set man_dir /usr/local/share/man system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set test_dir /usr/local/share/pear/test system
==> /usr/local/Cellar/php/8.1.0/bin/pear config-set php_bin /usr/local/opt/php/bin/php system
==> /usr/local/Cellar/php/8.1.0/bin/pear update-channels
🍺  /usr/local/Cellar/php/8.1.0: 512 files, 79.9MB
==> Installing composer
==> Pouring composer--2.1.14.monterey.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/composer
Target /usr/local/bin/composer
already exists. You may want to remove it:
  rm '/usr/local/bin/composer'

To force the link and overwrite all conflicting files:
  brew link --overwrite composer

To list all files that would be deleted:
  brew link --overwrite --dry-run composer

Possible conflicting files are:
/usr/local/bin/composer
==> Summary
🍺  /usr/local/Cellar/composer/2.1.14: 3 files, 2.2MB
==> Running `brew cleanup composer`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

Comme vous pouvez le constater dans les résultats précédents, le lien symbolique n’a pas été créé correctement donc nous allons le corriger à la main.

On teste notre commande avec --dr-run d’abord:

brew link --overwrite --dry-run composer
Would remove:
/usr/local/bin/composer

Tout semble bon, on crée le lien symbolique:

brew link --overwrite composer
Linking /usr/local/Cellar/composer/2.1.14... 1 symlinks created.

On reteste maintenant notre mise à jour de plugin via composer:

composer update --no-plugins --no-scripts

Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
Generating autoload files

Impeccable, composer et php sont de nouveau opérationnels sous Monterey.

PHP: résoudre l'erreur

PHP: résoudre l’erreur “file_get_contents(): SSL operation failed with code 1”

J’ai récemment joué avec l’API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d’ajouter au site les données structurées idoines.

Il se trouve qu’en local, lorsque l’on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n’est pas configuré avec le bundle de certificats OpenSSL:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2

Warning: file_get_contents(): Failed to enable crypto in ...php on line 2

Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2

Si cela vous arrive, plusieurs solutions s’offrent à vous.

Méthode 1: configuration de PHP côté machine/serveur

1. Vérifiez qu’OpenSSL est bien installé sur votre machine (il devrait l’être sur le serveur!).

2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:

openssl.cafile=/usr/local/etc/openssl/cert.pem

3. Redémarrez le service PHP.

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Au lieu de m’embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l’on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.

Voici la fonction en question:

/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
	$c = curl_init();
	curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $c, CURLOPT_URL, $URL );
	$contents = curl_exec( $c );
	curl_close( $c );
	if( $contents ) :
		return $contents;
	else:
		return false;
	endif;
}

La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d’un tableau qui n’existe pas.

On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c’est un sujet à aborder une autre fois).

Gravity Forms : activer l'anti-spam honeypot sur tous les formulaires photo

Gravity Forms : supprimer les entrées mais garder les fichiers uploadés sur le site

Gravity Forms garde en base de données toutes les entrées des formulaires. Sur un site qui génère énormément de demandes (formulaire de contact, demandes d’informations, formulaire de commande ou pré-commande…).

Cela signifie des milliers d’enregistrements dans la base de données, ce qui n’est pas toujours souhaitable, pour des raisons de stockage et de performance.

Supprimer les entrées des formulaires Gravity Forms

Si vous avez besoin de supprimer les entrées créées par Gravity Forms une fois que le message a été envoyé, vous pouvez utiliser cette fonction:

// Delete all entries from form ID  1.
add_action( 'gform_after_submission_1', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
    GFAPI::delete_entry( $entry['id'] );
}

Dans l’exemple ci-dessus, on ne supprime que les entrées du formulaire qui a l’ID 1. Si vous souhaitez supprimer toutes les entrées de tous les formulaires Gravity Forms d’un site, il suffit d’enlever le _1de la cible de l’action gform_after_submission:

// Delete all entries from all forms.
add_action( 'gform_after_submission', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
    GFAPI::delete_entry( $entry['id'] );
}

Garder les fichiers uploadés lors de la suppression des entrées

Attention: supprimer les entrées Gravity Forms revient également à supprimer les fichiers qui auront été uploadés via les formulaires. C’est tout à fait normal puisqu’ils font partie des champs du formulaire.

Pour garder les fichiers uploadés, même si les entrées associées sont supprimées, il faut utiliser le filtre gform_field_types_delete_files:

add_filter( 'gform_field_types_delete_files', '__return_empty_array' );

Supprimer les fichiers associés à un champ upload particulier

Si vous souhaitez supprimer tous les fichiers qui auront été uploadés via un champ upload particulier, il suffit de préciser ce champ dans le tableau $field_types avant de le passer à gform_field_types_delete_files:

add_filter( 'gform_field_types_delete_files', 'sky_delete_custom_upload_field' );
function sky_delete_custom_upload_field( $field_types ) {
    $field_types[] = 'my_custom_upload_field';
    return $field_types;
}

Dans cet exemple, notre champ upload s’appelle my_custom_upload_field.

Gravity Forms : activer l'anti-spam honeypot sur tous les formulaires photo

Gravity Forms : activer l’anti-spam honeypot sur tous les formulaires

Gravity Forms permet de créer rapidement des formulaires avec des logiques conditionnelles sous WordPress.

Dans les options de Gravity Forms, il existe une option qui ajoute un champ caché au formulaire, “honeypot”, qui permet d’éviter le spam mais qui doit être activé manuellement pour chaque formulaire, ce qui peut être rapidement fastidieux selon le nombre de formulaires que vous avez sur le site.

Voici comment activer et ajouter le champ honeypot à tous vos formulaires, automatiquement:

<?php
/**
 * Enforce anti-spam honeypot on all Gravity forms.
 *
 * @param array $form The current form to be filtered.
 * 
 * @return array
 */
add_filter( 'gform_form_post_get_meta', __NAMESPACE__ . '\\sky_enforce_gravity_forms_anti_spam_honeypot' );
function sky_enforce_gravity_forms_anti_spam_honeypot( $form ): array {
	$form['enableHoneypot'] = true;
	return $form;
}

Et voilà, une protection supplémentaire et automatique pour tous vos formulaires !

PHP : solution pour l'erreur

PHP : solution pour l’erreur “preg_match(): Compilation failed: invalid range in character class”

Lors de la mise à jour d’un site vers PHP 7.4, je suis tombé sur cette erreur :

preg_match(): Compilation failed: invalid range in character class at offset 20 session.php on line 278

Depuis PHP 7.3, le moteur PCRE – qui est responsable de la gestion des expressions régulières – a été migré vers PCRE2.

Or, il s’avère que PCRE2 est plus strict dans la validation des pattern et c’est la raison pour laquelle, après la mise à jour de PHP, certaines expressions régulières ne peuvent plus être compilées correctement.

Voici un exemple d’expression régulière qui fonctionnait avant PHP7.3:

preg_match('/[\w-.]+/', ''); // this will not work in PHP7.3

Voici maintenant le même exemple mais qui sera désormais valide sous PHP 7.3 et les versions ultérieures :

preg_match('/[\w\-.]+/', ''); // the hyphen needs to be escaped

Comme vous pouvez le constater dans le deuxième exemple, il faut maintenant échapper le tiret (hyphen) avec un backslash.

Une fois la modification faite, plus d’erreur à ce niveau.

Serveur dédié: passage à PHP 7.4 photo

Serveur dédié: passage à PHP 7.4

C’est Noël avant l’heure : PHP version 7.4 est désormais disponible! Ni une ni deux, elle est déjà installée sur le serveur.

Je vous conseille de jeter un petit coup d’oeil aux nouveautés de PHP 7.4, cela se modernise!

Si vous souhaitez sauter le pas, voici un petit tuto pour l’installation.

Étape 1 : installer le dépôt d’Ondrej

Dans le terminal, installez le dépôt d’Ondrej. Il est très souvent mis à jour et permet de bénéficier de pas mal de paquets à jour, même sur des distributions anciennes:

add-apt-repository ppa:ondrej/php

Étape 2 : installation de PHP 7.4

J’ai juste repris la liste des paquets PHP7.3 déjà installés puis changé le numéro de version.

Cela nous donne donc:

apt install php-igbinary php-imagick php-redis php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip

Note: il vous reste ensuite à modifier php.iniainsi que votre pool PHP selon vos besoins.

Étape 3: modification du server block

L’étape finale est la modification de votre server block. Sous NginX, éditez le fichier de configuration de votre site pour pointer vers le socket de PHP7.4:

#fastcgi_pass unix:/run/php/php7.3-fpm.sock;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;

Il suffit ensuite de relancer NginX et PHP:

service php7.4-fpm start && service nginx restart

Et voilà! Bonnes mises à jour !

NginX : résoudre

NginX : résoudre “upstream sent too big header while reading response header from upstream”

Nginx: des entêtes trop larges

Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:

upstream sent too big header while reading response header from upstream

Solution: augmenter la taille des entêtes

Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:

fastcgi_buffers 16 16k; 
fastcgi_buffer_size 32k;

L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.

Il ne reste plus ensuite qu’à relancer le serveur NginX:

service nginx restart

Hop, problème réglé.

PHP : ajouter les directives

PHP : ajouter les directives “HttpOnly” et “Secure” aux cookies de session

Les directives “HttpOnly” et “Secure”

A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives “HttpOnly” et “Secure”.

Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.

Edition de php.ini

On édite donc notre fichier php.ini:

nano /etc/php/7.2/fpm/php.ini

Et on modifie ces valeurs :

session.cookie_httponly 1
session.cookie_secure 1
session.use_only_cookies 1

Enregistrez le fichier et relancez PHP:

service php7.2-fpm restart

Testez votre site de nouveau : les cookies de session contiennent maintenant les deux nouvelles directives :

set-cookie: PHPSESSID=7d5h81tfiuna3p2p00o1v7b13q; path=/; secure; HttpOnly

Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site.

Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.

WordPress : corriger l'erreur

WordPress : corriger l’erreur “Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given”

Je travaille actuellement sur un projet Codeable qui nécessite de passer de PHP5.6 à PHP7.2. Le site en question est une boutique WooCommerce avec un thème custom qui est hébergé chez WPEngine. Jusque là, tout va bien.

Lors de la migration sur un serveur PHP 7.4, le site de developpement (Staging) affiche alors un message d’avertissement sur toutes les pages :

Parameter 1 to wp_default_styles() expected to be a reference, value given
Parameter 1 to wp_default_scripts() expected to be a reference, value given

Après avoir passé un bon moment à éliminer les causes (plugins et thème), il se trouve que c’est un bug de WordPress 4.9.8 (la dernière version en date) dont il est question dans le ticket #44979.

Voici la solution temporaire à ce problème :

  1. éditez /wp-includes/script-loader.php
  2. retirez le caractère & de l’argument des fonctions wp_default_scripts() et wp_default_styles()
  3. sauvegardez le fichier
  4. rechargez le site, les deux messages d’avertissement ont disparu.

Voilà, ce n’est qu’un hotfix mais ce bug devrait être corrigé dans la prochaine version de WordPress – version 4.9.9 – qui sortira prochainement.

PHP : configurer un pool PHP pour chaque site photo

PHP : configurer un pool PHP pour chaque site

Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.

Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.

Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.

Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.

Mise en place du nouveau pool PHP

Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :

cp /etc/php/7.2/fpm/pool.d/www.conf /etc/php/7.2/fpm/pool.d/skyminds.conf

Editons ensuite notre pool :

nano /etc/php/7.2/fpm/pool.d/skyminds.conf

1. Nom du pool : remplacez [www] par le nom de votre site, ici [skyminds] de manière à pouvoir l’identifier plus aisément.

2. Vérifiez l’utilisateur et le groupe dans les directives user et group.

3. On modifie le nom du site dans la directive listen en utilisant le nom du pool que vous avez choisi dans l’étape 1:

listen = /run/php/skyminds.sock

Mise à jour de la configuration NginX

Il nous reste maintenant à mettre à jour la configuration du site :

nano /etc/nginx/sites-available/skyminds.net

Mettez à jour cette ligne (même chemin que la directive listen dans la configuration PHP):

fastcgi_pass unix:/run/php/skyminds.sock;

Relancez les services PHP et NginX:

service php7.4-fpm restart && service nginx restart

Lire la suite

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur “fatal: www-data(33): message file too big”
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. Récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  43. Serveur dédié : activer l’IP canonique du serveur sous Apache
  44. Serveur dédié : mise à jour vers PHP 5.6
  45. MySQL : convertir les tables MyISAM au format InnoDB
  46. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  47. Serveur dédié : migration de MySQL vers MariaDB
  48. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  49. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  50. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  51. Serveur dédié : mise en place du protocole DANE
  52. 8 règles d’or pour bien déployer DNSSEC et DANE
  53. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  54. Serveur dédié : optimiser la couche TCP
  55. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  56. Serveur dédié : mettre à jour Apache pour HTTP/2
  57. Serveur dédié : ajouter le domaine à la liste HSTS preload
  58. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  59. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème “no space left on device”
  60. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
Nouveau logo pour SkyMinds (version 2018) photo

Nouveau logo pour SkyMinds (version 2018)

Aujourd’hui, le logo de SkyMinds fait peau neuve ! Plus discret, plus moderne aussi. J’en ai profité pour mettre en place toute une liste de modifications cosmétiques que j’ai trop longtemps repoussées.

Nouveau logo pour SkyMinds (version 2018) photo
Nouveau logo !

Mise à jour des templates du thème enfant

L’avantage d’un thème enfant sous WordPress, c’est que l’on ne perd pas ses modifications lorsque le thème parent se met à jour. Le thème enfant, c’est tout simplement la base, l’étape qui vient juste après l’installation d’un nouveau thème.

Or, au fil des mois ans, il se trouve que le thème parent évolue et que les fichiers du thème enfant (modifiés) ne sont plus exactement à jour. J’en ai donc profité pour reprendre les nouveaux fichiers et y apporter mes modifications.

Concaténation des appels des fichiers de police

En analysant les fichiers du thème, je me suis rendu compte qu’on pouvait gagner pas mal de temps de chargement grâce à une épuration du nombre de polices utilisées sur le site. Au lieu d’en avoir deux (Open Sans et Droid Sans), il n’y en aura plus qu’une : Open Sans. Elle est légère, classique et facile à lire.

Le problème, c’est que Divi charge pas mal de versions de cette police par défaut : 300, 400, 700… en normal, italic et gras et avec des subsets exotiques comme le cyrillique, le grec ou le vietnamien. Clairement, on doit pouvoir mieux faire !

Divi : suppression des subsets Google Fonts

On commence par virer les subsets exotiques. Rendez-vous dans Divi > Theme options > General > désactivez Google Fonts subsets. Vous venez d’économisez 400KB.

Divi : suppression de toutes les Google Fonts et chargement de l’unique nécessaire

C’est pénible d’avoir tous les grammages d’une police chargés pour rien. Voici ce que j’utilise pour tout virer dans un premier temps, puis ajouter uniquement ce dont j’ai réellement besoin:

/*
|-----------------------------------------------------------------------
| Plugin Name: Sky Remove DIVI Google Fonts and add what we need
| Plugin URI:  https://www.skyminds.net/?p=29578
| Author:  Matt Biscay
| Author URI:  https://www.skyminds.net/
|-----------------------------------------------------------------------
*/

// remove all Divi fonts, we'll just load what we need
// @return: array
function et_builder_get_google_fonts() { return array(); }
function et_get_google_fonts() { return array(); }

// add fonts : logo (Comfortaa:700) and site (Open+Sans:400,700). No subsets.
add_action( 'wp_enqueue_scripts', 'sky_logo_add_google_fonts' );
function sky_logo_add_google_fonts() {
	wp_enqueue_style( 'sky-logo-google-fonts', 'https://fonts.googleapis.com/css?family=Comfortaa:700|Open+Sans:400,700', false ); 
}

Kaboom! On vient de se retirer une sacrée épine du pied. Il faudra juste relire la feuille de style pour être sûr que l’on utilise bien soit du font-weight 400 (regular), soit du 700 (bold). Pensez également à vérifier votre critical CSS.

Amélioration de la section Auteur

A la fin de chaque article se trouve la section de l’auteur, qui comprend une courte description ainsi que des liens vers ses profils sociaux. J’ai profité de la police du thème pour remplacer les noms des réseaux par des icônes. C’est purement cosmétique mais je trouve cela plus joli.

Cela m’a permis de me rendre compte que le site n’utilise absolument pas Font Awesome – ce que je trouve totalement fou. J’aime tellement cette police que j’ai acheté la version professionnelle pour mes développements… et ne l’utilise pas moi-même !

J’ai troqué le bleu clair pour un beige. A voir sur la durée.

Nouveau logo

Et enfin, last but not least, j’ai troqué mon logo image contre un logo font. Cela faisait pas mal de temps qu’il me trottait dans la tête l’idée de le changer. J’ai d’abord commencé, comme d’habitude, par tenter de créer des logos images avant de changer mon fusil d’épaule et considérer la possibilité d’utiliser une Google Font pour le générer à la volée.

Après quelques recherches, j’ai finalement opté pour la police Comfortaa en 700. C’est plutôt moderne par rapport au logo précédent qui avait la particularité d’être un dégradé de plusieurs couleurs (rose, violet, bleu, vert), avec des ligatures à certaines lettres.

Celui-ci sera donc beaucoup plus clean et professionnel. Je pense d’ailleurs le réutiliser sur d’autres supports de personal branding.

Lire la suite