Corriger l’erreur Gravity Form « Call to a member function can_be_used() on bool »

Cet article est plus là pour mon moi du futur, mais ça peut en aider d’autres.

Suite à la mise à jour vers Gravity Form 2.6.2, je me suis retrouvé sur plusieurs sites dont j’ai la maintenance avec une erreur fatale ressemblant à:

[06-May-2022 20:30:52 UTC] PHP Fatal error:  Uncaught Error: Call to a member function can_be_used() on bool in /var/www/my-great-website/wp-content/plugins/gravityforms/common.php:2813
Stack trace:

Je n’ai pas trop creusé pour en connaitre la cause… je ferais ca un peu plus tard… quand un site client est en rade… on corrige vite 😉

Pour corriger cette erreur il m’a suffit d’ajouter

define( 'GF_CACHE_DEBUG', true );

dans le `wp-config.php` puis d’aller resauver les réglages des formulaires (sans rien changer)

Cette erreur arrive lorsque la vérification de licence échoue. Les développeurs de Gravity Forms sont en train d’étudier la question et vont publier prochainement une nouvelle version.

La constante ajoutée permet de valider la licence sans prendre en compte les données en cache.

Dites-moi en commentaire si vous avez eu cette erreur et que cette astuce vous a aidée!

Déployez votre site Web grâce aux Github Actions

Je vous ai déjà parlé des Github Actions dans un article précédent afin de publier facilement votre extension WordPress sur le dépôt officiel des extensions.

Aujourd’hui, l’idée, c’est de déployer automatiquement vos développements quand vous poussez vos modifications sur GitHub

État des lieux

Actuellement, je publie mes modifications sur les sites WordPress de mes clients grâce au DeployHQ.com. C’est un service très simple à mettre en place:

  • On lie DeployHQ à notre profil Github
  • On sélectionne le dépôt GH à déployer
  • On paramètre la connexion SFTP sur notre hébergement

A ce moment la, DeployHQ ajoute un webhook qui sera déclenché à chaque push sur une branche définie de notre repo Github qui lancera le déploiement.

Quelques secondes plus tard (ou ça se compte en seconde), vos modifications sont en ligne.

DeployHQ fonctionne bien… alors pourquoi changer ?

Ben oui pourquoi ?

Au-delà de cette raison tout à fait louable, il se trouve j’avais envie de tester une alternative !

Principe des Github Actions

En simple, Github Actions permets d’automatiser des taches selon des évènements se produisant sur le dépôt sur lequel il est actif.

Des taches, il peut y en avoir des centaines, voir des milliers et afin d’aider les développeurs, Github a mis en place une place de marché ou chacun peu publier son Action afin de la partager.

Le principe:

  • On crée un fichier de configuration au format yml.
  • Ce fichier est stocké dans votre dépôt GitHub
  • Lorsque l’action définie dans le fichier de configuration est exécutée, GitHub Actions entre en jeu et exécute alors les tâches qu’on lui a demandées.

Passons à la pratique

Dans le paragraphe précédent, je vous ai parlé d’une place de marché. Sur cette place de marché, je suis tombé sur https://github.com/marketplace/actions/ssh-deploy qui selon la description, fait exactement ce dont j’ai envie.

En pratique, il faut créer dans votre projet un dossier .github qui contiendra lui-même un dossier workflows. À l’intérieur de ce dossier vous ajouterez un fichier qui portera le nom que vous voudrez, mais qui sera au format yml. Par exemple deploy.yml.

GitHub actions

Dans ce fichier deploy.yml on ajoutera ce code:

name: Deploy

on:
  push:
    branches:
      - master

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: Install Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '10.x'
      - name: Install npm dependencies
        run: npm install
      - name: npm init
        run: npm init -y
      - name: Run build task
        run: npm run build --if-present
      - name: Deploy to Server
        uses: easingthemes/ssh-deploy@v2.1.7
        env:
          SSH_PRIVATE_KEY: ${{ secrets.SERVER_SSH_KEY }}
          ARGS: "-avz --delete"
          REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
          REMOTE_PORT: ${{ secrets.REMOTE_PORT }}
          REMOTE_USER: ${{ secrets.REMOTE_USER }}
          TARGET: ${{ secrets.REMOTE_TARGET }}
          EXCLUDE: "/.git, /.github, /dist/, /node_modules/"

Et qu’est ce ca veut dire ?

name: Deploy

Est simplement le nom de cette action, car bien sur, vous pouvez avoir autant d’action que vous le désirez.

on:
push:
branches:
- master

Quand est ce qu’on jour cette action ? facile ! « sur » le « push » de la « branche » « master ».

Ainsi on peut imaginer avoir une autre action avec :

on:
  push:
    branches:
      - staging

Le bloc qui nous intéressera ensuite est:

        env:
SSH_PRIVATE_KEY: ${{ secrets.SERVER_SSH_KEY }}
ARGS: "-avz --delete"
REMOTE_HOST: ${{ secrets.REMOTE_HOST }}
REMOTE_PORT: ${{ secrets.REMOTE_PORT }}
REMOTE_USER: ${{ secrets.REMOTE_USER }}
TARGET: ${{ secrets.REMOTE_TARGET }}
EXCLUDE: "/.git, /.github, /dist/, /node_modules/"

Car il définit les informations liées à Rsync

SSH_PRIVATE_KEY

La clé SSH privée servant au déploiement. Selon la doc de l’Action, vous pouvez en créer une avec la commande:

ssh-keygen -m PEM -t rsa -b 4096

Cette commande va créer une clée privée, a garder secrete et une clé publique.

La clé publique est à ajouter dans le fichier /home/user/.ssh/authorized_key de votre serveur / Hébergement. Le chemin sera à adapter selon que vous êtes sur un hébergement mutualisé autorisant SSH ou sur un serveur dédié ou autre cas.

La clé privée doit quant à elle être stockée sur votre compte Github dans les réglages du dépôt que vous voulez déployer. Le principe sera le même pour chacune des instructions qui suivront.

github actions secrets

En cliquant sur « New repository secret » vous aurez 2 champs.

  • Le champ « Name » prendra la partie en majuscule de vos réglages soit par exemple SERVER_SSH_KEY
  • Le champ « Value » prendra quant à lui la valeur à envoyer lors du transfert (ici la valeur de la clé privée)
ARGS: "-avz --delete"

Les arguments de RSYNC à retrouver dans sa doc

Je vous invite à regarder la doc très simple et claire de l’Action pour les autres paramètres.

Tadam!

Normalement… si tout s’est bien passé, vos modifications sont téléversées automatiquement lorsque vous les poussez sur votre branche principale (ou sur la branche que vous avez choisie)

Conclusion

Vous savez maintenant utiliser les Github Actions pour déployer vos sites, il ne reste plus qu’à faire de jolis site web 😉

Si comme moi vous êtes développeur WordPress mais que vous hébergez vos sites chez WPEngine, sachez qu’il existe une action qui permet de déployer directement chez WPEngine !

Je débute avec cet outil… si vous avez des questions… c’est pas gagné, mais tentez quand même en laissant un commentaire.

Ajouter des icônes personnalisées à vos projets avec ACF et ACF: FontAwesome Field

Si vous avez l’habitude de créer votre propres icônes web, vous devez connaître Icomoon. Pour un projet client utilisant déjà FontAwesome, j’ai eu besoin d’ajouter 2 icônes personnalisées provenant en utilisant le service Icomoon.

Pour cet article, j’ai utilisé Icomoon mais vous devriez pouvoir adapter, vous inspirer de cet article pour insérer n’importe quel icône personnalisé.

Les icônes FontAwesome étaient utilisées sur des éléments de menu grâce à Advanced Custom Fields et Advanced Custom Fields: Font Awesome Field. le but est donc d’ajouter à la liste des icônes FontAwesome, mes 2 ou 3 icônes customs d’icomoon.

Afficher les icones Icomoon dans le champs ACF FontAwesome

Advanced Custom Fields: Font Awesome Field que je nommerai dorénavant ACFFA propose un filtre permettant de venir modifier la liste des icônes:

ACFFA_get_icons
add_filter( 'ACFFA_get_icons', 'cot_test' );
function cot_test( $icons ) {
$icomoon = array(
'cierge' => array(
'name' => 'cierge',
'hex' => '\e90e',
'unicode' => ''
),
'calice' => array(
'name' => 'calice',
'hex' => '\e90f',
'unicode' => ''
),
);
foreach ( $icomoon as $ico ) {
$icons['list']['far'][ 'far ' . $ico['name'] ] = '<i class="icon-' . $ico['name'] . '"></i> ' . ucfirst(
$ico['name'] );
$icons['details']['far']['far ' . $ico['name']]['hex'] = $ico['hex'];
$icons['details']['far']['far ' . $ico['name']]['unicode'] = $ico['unicode'];
}

return $icons;
}

Ici nous filtrons la liste existantes des icônes FA pour y ajouter nos icônes personnalisées. Malheureusement, l’extension de Matt Keys étant développées pour FA, seules les catégories FontAwesome sont disponible à savoir Brand (fab), Regular (far), Style (fas). J’ai décidé d’ajouter mes icônes dans les Regular soit Far. Ceci est purement arbitraire.

Décortiquons le code ci-dessus

array(
'cierge' => array(
'name' => 'cierge',
'hex' => '\e90e',
'unicode' => '&#xe90e;'
),

Ici je déclare les icônes Icomoon que je vais vouloir utiliser:

  • name: le nom de l’icône dans la liste
  • hex: le code hexadécimal fourni par Icomoon
  • unicode: l’unicode de l’icône Icomoon

Ensuite, avec une boucle foreach, je vais alimenter le tableau $icons contenant les icônes FontAwesome

Afficher les icônes en back-office

Pour afficher les icônes en back-office, il va falloir que la feuille CSS Icomoon avec toutes les icônes soient chargées coté back-end.

Pour ça, nous allons ajouter ce code:

add_action( 'admin_print_styles', 'cot_load_icomoon_css' );

Si vous êtes habitués a développer vos thèmes vous connaissez le hook d’action WordPress wp_enqueue_scripts qui permet de charger des feuilles de styles et des scripts en front-end. Sachez qu’il existe aussi un équivalent pour le back-office et il se nomme admin_print_styles.

add_action( 'admin_print_styles', 'cot_load_icomoon_css' );
add_action( 'wp_enqueue_scripts', 'cot_load_icomoon_css', 9, 1 );
function cot_load_icomoon_css(){
wp_enqueue_style( 'font-icomoon', get_template_directory_uri() . '/css/iconmoon.css');
}

Ici je charge donc la feuille CSS en front et en back-office.

J’ai mis une priorité 9 au chargement front afin de passer juste avant le chargement de la feuille de style du thème et de pouvoir par la suite les utiliser dans mon thème. Par défaut un add_action() à une priorité de 10.

Afficher les icônes en front office

En front-office, l’extension ACF FontAwesome retourne un balisage HTML formaté pour FA (normal!). Nous, on veut que dans certains cas, celui de notre icône personnalisée on aille charger une autre police (celle générée par Icomoon).

Icomoon m’a fourni 4 fichiers de polices de caractères ( .eot, .svg, .ttf et .woff) que j’ai placé dans mon projet. Le fichier icomoon.css fait un @font-face afin que les polices soient chargées

Le problème réside dans le fait que l’extension de Matt Keys génère un markup HTML FA et qu’il va falloir « ruser » pour détourner le fonctionnement seulement pour les icônes Icomoon. Et oui, on veut pouvoir continuer à utiliser normalement FontAwesome!

<i class="far cierge" aria-hidden="true"></i>

On retrouve la class far de FA qui va charger la police FontAwesome puis la class cierge générée à partir du nom données dans la liste des extension a insérer.

Pour que le site charge ma police au lieu de celle de FontAwesome, j’ai créé une feuille CSS modifiant le style des ces classes:

.far.cierge:before {
font-family: "ma-police-icomoon";
content: "\e90e";
}

Pour chaque icône personnalisée je demande à WordPress de charger ma-police-icomoon et d’utiliser le contenu ayant le code hex corespondant à mon icône.

WP Grid Builder pour créer facilement un système de recherche à facettes avec WordPress

Aujourd’hui je vais vous présenter une solution française pour créer une système de recherche à facette !

Qu’est ce qu’une recherche à facette ?

Une recherche à facette est une technique permettant de resserrer les résultats au fur et à mesure que l’on sélectionne des critères de recherches.

Mais si vous savez, vous arrivez sur une page avec 200 T-shirt. Vous sélectionnez votre taille, il reste 128 choix, puis la couleur il reste 50 possibilité, puis le prix et vous obtenez le seul modèle que vous pouvez vous offrir!

Jusqu’il n’y a pas si longtemps, il fallait, sur WordPress, utiliser l’extension FacetWP mais depuis peu, une nouvelle extension développée dans le sud de la France à fait son apparition : WP Grid Builder

Si FacetWP se limite à proposer un outils orienté développeurs pour créer des facettes, WP Grid Builder est lui orienté grand public et ne se content pas de proposer des facettes.

Des facettes et des grilles de contenus

En effet, il propose aussi l’affichage de grille (Grid) et de templates, le tout facilement administrable dans le backoffice de votre WordPress.
Ainsi les non développeurs pourront sans une ligne de code créer une page comportant une zone de recherche a facettes et afficher la résultats sous forme de grille.

WP Grid Builder pour les développeurs.

Vous êtes développeur alors bénéficiez de toute la puissance de WP Grid Builder en créant vos facettes et vos templates directement dans vos projets.

WP Grid Builder a été pensé pour que les développeurs de site web WordPress puissent aisément réaliser toutes sorte de projets. Ainsi ils retrouveront des fonctions et hooks PHP et JS.

Bien sur, une documentation détaillée des fonctions est disponible sur son site internet

WP Grid Builder pour les nons développeurs.

Vous n’êtes pas développeurs ?

Rien de grave, Loïc a pensé a tout. Ainsi vous pourrez créer vos facettes, vos grilles et vos cartes directement dans le back-office et afficher vos créations via des codes courts ou bien des blocks Gutenberg pour le nouvel éditeur.

Allo Docteur? J’ai un problème!

Qui ne s’est jamais retrouvé devant son site internet ou celui d’un client équi ne fait pas ce qu’on veut » ? C’est à ce moment là que le support des extensions payante entre en jeu… et avec WP Grid Builder, en tant que francophone nous sommes gâté puisque Loïc vit dans le sud de la France.

Il réponds donc en français sur notre fuseau horaire… ce qui apporte une réactivité qui est toujours appréciée!

Rien ne vaut des exemples!

Comme on dit: Une image vaut 1000 mots. je viens de remplacer FacetWP sur Thivinfo.com par WP Grid Builder.

Voyez plutôt le résultat:

Amusez-vous bien 🙂

Créer vos blocs Gutenberg facilement avec Carbon Fields

Présentation de Carbon Fields

Carbon Fields est une solution concurrente du célèbre Advanced Custom Field (ACF) mais qui a la particularité de pouvoir être embarqué dans vos thèmes et extensions maison.

En effet, vous ne pouvez pas utiliser ACF Pro dans vos extensions gratuites a destination par exemple du dépôt WordPress.

Comme ACF, Carbon Fields propose une solution entièrement en PHP pour créer des blocs compatibles avec le nouvel éditeur de WordPress: Gutenberg!

Les blocs Gutenberg ont fait leur apparition dans Carbon Fields 3.0.

Installer Carbon Fields

Attention, la version disponible sur le dépôt WordPress est loin d’être à jour.

Installer Carbon Fields avec Composer

Cette méthode a une approche plus orientée « développeur », c’est celle qui est mise en avant dans la documentation de Carbon Fields.

Bien sur, votre système doit disposer de Composer mais si vous suivez cette section, je suppose que vous connaissez, l’avez déjà installé sinon je vous invite à suivre la seconde méthode, sans Composer ou bien à installer Composer.

Rendez vous dans le répertoire de l’extension ou du thème dans lequel vous voulez ajouter votre bloc Gutenberg.

Pour la suite du tutoriel, je partirais du principe que nous sommes dans une extension mais dans le cas d’un thème, vous initialiserez Carbon Fields dans votre functions.php.

La commande :

composer require htmlburger/carbon-fields

va installer carbon-fields dans le dossier vendor de votre projet. Si celui-ci n’existe pas, alors il sera créé.

Ensuite dans le fichier principal de votre extension, ajoutez le code suivant:

Installer Carbon Fields sans Composer

Sans Composer, vous devrez télécharger Carbon Fields, le décompresser et l’ajouter a votre projet.

Ensuite il conviendra d’adapter la fonction de chargement:

Création d’un Bloc Gutenberg en PHP

Comme je le disais en introduction, Carbon Fields est un produit similaire à ACF à ceci près qu’il ne dispose pas d’une interface graphique pour la création des champs personnalisé.

C’est un paragraphe dédié à la création de bloc Gutenberg et il nous cause de champs personnalisé… il a craqué!

mes gentils lecteurs 🙂

Effectivement, si je vous parle de champs personnalisé ici c’est que, comme ACF, ils vont être la matière première pour créer notre bloc.

Tous les types de champs que vous retrouverez dans la documentation sont utilisable pour ajouter des réglages a notre bloc Gutenberg.

En route pour la création!

Première étape, créer un fichier PHP qui accueillera vos déclarations de fonctions qui créeront le bloc.

Ici c’est selon vos habitudes, en procédural ou en POO, un simple fichier PHP ou bien une classe.

Je vais pour ce tutoriel l’écrire en PHP procédural afin qu’il soit le plus accessible possible. Ceux ayant l’habitude de développer en Orienté Objet, n’auront aucun mal à adapter leur code.Créer un fichier mon-block.php

Une fois créé, nous allons déclarer le bloc:

Expliquons ce que fais ce code:

use Carbon_Fields\Block;

va simplement dire a notre fichier PHP qu’il faut utiliser Carbon_Fields et notament la sections dédié aux Blocks.

Block::make( __( 'My Shiny Gutenberg Block' ) )

va déclarer le bloc auprès de WordPress. Il aura ici le nom de « My Shiny Gutenberg Block ». Notez que le nom du block est déclaré dans une function d’internationalisation (i18n) qui va permettre de traduire votre bloc.

Il serait d’ailleurs judicieux d’y ajouter votre text-domain ce qui donnerait:

Block::make( __( 'My Shiny Gutenberg Block', 'mon-text-domain ) )

Ensuite vient la déclaration des paramètres de votre bloc Gutenberg qui se fait via la méthode add_fields( )

Ici nous ajoutons 3 réglages:

  • un champ de texte simple
  • un champ de sélection d’image
  • un champs de texte riche.

Les champs sont tous créé sur le même modèle:

Field::make( 'type de champs', 'identifiant unique', 'libellé du champs')

Enfin, la méthode set_render_callback() va elle générer l’affichage front ainsi que la prévisualisation de votre bloc Gutenberg.

Dans les faits, écrivez une fonction qui va retourner un html valide et appelez-la dans set_render_callback( )

Dans cette fonction, vous passerez en paramètre $block qui sera un array regroupant les paramètres de votre block. Les clés de ce tableau étant les identifiants unique de votre bloc Gutenberg.

https://youtu.be/_sp4uIwvRKg
Votre Block en action!

Aller plus loin avec Carbon Fields

Je ne peux pas terminer ce tutoriel sans vous présenter un peu mieux Carbon Fields car tant qu’a l’embarquer dans vos projets pour créer facilement des blocs Gutenberg, autant en tirer tout son potentiel.

Vous pourrez donc avec Carbon Fields créer des champs personnalisés pour tout les types de publications présents sur votre site mais également créer des pages d’options pour votre thème ou vos extensions.

Si vous voulez voir ce que ca donne en live, je vous invite a installer et regarder mon extension WP GestSup Connector qui embarque Carbon Fields et avec lequel j’ai créé un block Gutenberg mais également la page d’option de l’extension.

Installer WordPress en 3 minutes !

On lit partout qu’il faut 5 minutes pour installer WordPress… et c’est FAUX ! On nous a menti! On peut l’installer beaucoup plus rapidement que ca…

La preuve en vidéo!

https://youtu.be/aEQY9mwhGrg
Installer WordPress multisite en 3 minutes

Ceux d’entre vous ayant déjà installé un multisite savent qu’après avoir installé WordPress, il faut rentrer des constantes dans le wp-config.php pour activer ce mode, se rendre dans le Back-Office, paramétrer le reseau et revenir dans le wp-config.php pour y coller un pavé de constantes ainsi que dans le .htaccess… bref largement plus qu’avec le script que je vous ai concocté!

Comment ca marche?

J’ai créé un script bash qui, lorsque vous le lancer vous pose quelques questions.

Rien de méchant, ce sont les informations que vous rentreriez lors de la routine d’installation d’un WordPress via votre navigateur préféré.

Une fois que les réponses sont enregistrées, le script lance l’installation et le multisite est prêt … en 3 minutes!

Bien sur ce script, pour fonctionner aura besoin de wp-cli.

https://wp-cli.org

Je veux le super script de Séb!

Oui ben il est dispo sur Github 😉

Géocoder une adresse sans utiliser Google Maps

On a été longtemps habitué a utiliser les outils et services de Google pour faire tout un tas de chose… seulement les bonne choses ont une fin et certains de ces services ferment ou deviennent payant.

Dans le cadre du développement de mon extension OpenAgenda pour WordPress, j’ai besoin de trouver la longitude et la latitude d’une adresse d’un évènement.

OpenStreetMap à la rescousse

Il existe heureusement beaucoup de services permettant de remplacer ceux de Google. Parmi eux OpenStreetMap (OSM) pour tout ce qui tourne autour des cartes et la géolocalisation.

Nominatim pour la conversion d’adresse en donnée de localisation.

J’ai donc découvert le service Nominatim.

C’est bien gentils, mais je veux du code!

Si comme moi, vous avez besoin de récupérer la latitude et la longitude d’un point géographique en PHP… pour WordPress, voici ce que je fais:

function get_lat_lng( $address ) {
	$address = rawurlencode( $address );
	$coord   = get_transient( 'geocode_' . $address );
	if ( empty( $coord ) ) {
		$url = 'http://nominatim.openstreetmap.org/?format=json&addressdetails=1&q=' . $address . '&format=json&limit=1';
		$json = wp_remote_get( $url );
        if( 200 === (int) wp_remote_retrieve_response_code( $json ) ){
            $body = wp_remote_retrieve_body( $json );
            $json = json_decode( $body, true );
        }
        $coord['lat'] = $json[0]['lat'];
        $coord['long'] = $json[0]['lon'];
        set_transient( 'geocode_' . $address, $coord, DAY_IN_SECONDS * 90 );
    }

	return $coord;
}

Un peu d’explications:

Ligne 1: on déclare une fonction dans laquelle je passe en parametre une adresse (rue code postal ville).

Ligne 2: j’encode cette adresse pour qu’elle soit intégrable dans une URL.

Ligne 3: je vérifie si un transient avec les coordonnées existe. Nominatim limite l’accès a son PAI… le transient permets donc de stocker les infos en locale et de ne pas faire une requete a chaque affichage… surtout que les coordonnées géographique d’un point ne devrait pas changer trop souvent…

Ligne 14: je crée le transient qui sera valable 90 jours. En gros, votre WordPress ne demandera la géolocalisation qu’une fois tous les 90 jours pour une même adresse.

Entre 2 : si l’adresse n’a jamais été géocodée alors je fais la demande a l’API de Nominatim

Des idées ou amélioration a apporter ? Laissez moi un commentaire!

Installer les WordPress Coding Standards sur PHPStorm facilement

WordPress, comme tous les framework de développement dispose de ses propres règles à suivre pour que chacun des développeurs puissent lire et comprendre facilement le code d’un confrère.

C’est ce qu’on appelle les « Codings Standards » soit en français les standards de codage. Pour WordPress, nous avons les WordPress Codings Standards plus connu sous le joli nom de WPCS!

Ces règles de développement sont lisible ici: Découvrir les WordPress Codings Standards

OK, on a ouate mille page de docs… mais je vais pas lire toutes ces docs tout en développant… t’as pas plus simple?

Et ben vous avez de la chance puisque nous pouvons intégrer ces règles directement dans nos IDE ou éditeurs de texte! Ainsi votre code sera vérifié automatiquement lors de vos développement.

J’utilise quotidiennement PHPStorm de Jetbrains mais sachez que ces règles sont utilisable sur quasiment tous les éditeurs de codes.

Ou trouver les WPCS?

Les WPCS sont disponible sur Github. Je vais vous détailler comment moi je fais, mais vous pouvez lire en anglais qu’il y a plusieurs méthodes. Faites votre choix!

La méthode de Séb pour installer les WPCS

Alors ce n’est pas à proprement dit ma méthode… dans le sens ce n’est pas moi qui l’est mis au point… mais c’est celle que j’utilise et que je vais détailler!

Avant d’installer les WPCS, il faut un installer les PHPCS… et oui, WordPress est développé en PHP et pour faire simple, WPCS rajoute des règles ou modifie un peu les règles des PHP Codings Standards.

Retenez que, comme dans tous l’écosystème WordPress, le but est de rendre accessible et faciliter l’accès au développement.

Installer les PHPCS

 

Personnellement, j’ai une partition sur mon Ubuntu Linux dédiée à mes projets et a coté des projets, j’ai un dossier avec les WPCS et un avec les PHPCS

Les PHPCS sont également disponible sur Github

Cloner le dépôt Github des PHPCS

Rendez vous a l’endroit où vous voulez télécharger les règles puis:

ou

Si vous n’avez pas renseigné de clé SSH sur votre compte GitHub.

Vous devriez normalement avoir maintenant un dossier nommé phpcs.

Cloner le dépôt Github des WPCS

On va réaliser quasiment la meme commande pour cloner le dépot des WPCS cette fois ci:

ou

Je vous rassure, le plus dur est fait…

Paramétrer PHPStorm

Rendez vous dans « File | Settings | Languages & Frameworks | PHP | Quality Tools »

Panneau de réglages PHPStorm

En cliquant sur les 3 point à droite de Configuration vous pourrez spécifier le chemin vers les PHPCS. Il faudra naviguer et sélectionner le fichier « phpcs » présent dans le répertoire « phpcs/bin » obtenu grace au clonage précédant.

Si tout est OK, en bas de la fenêtre affichera la version de Code Sniffer installée.

Passons à WPCS, car après tout… ce sont pour eux qu’on en est là !

Le chemin vers les réglages est File | Settings | Editor | Inspections

J’aime les flèches!

le but ici est d’arriver au menu « PHP Code Sniffer Validation » afin de cocher « Installed Standard Paths » et de chercher après avoir cliqué sur le dossier à droite le répertoire récédement cloner avec les WPCS.

Si tout se passe bien…en cliquant sur les 2 flèches circulaires, vous devriez avoir le choix de plusieurs WPCS… personnellement, je choisis WordPress-Extra. puis on valide en cliquant sur OK…

Migrer un site d’un multisite vers une installation classique

Présentation du multisite WordPress.

La technique du Multisite permet de faire fonctionner plusieurs site WordPress ensemble au sein d’une seule et même installation.

Cette technique permet de mutualiser le Coeur de WordPress, les thèmes ainsi que les extensions.

En résulte un gain de temps non négligeable lors de la maintenance de vos sites puisque vous ne mettez à jour qu’une seule fois.

En savoir plus:

Extraire un site d’un multisite étape par étape.

Tout d’abord, ce tutoriel ne se veut pas LA méthode mais une méthode qui fonctionne et que j’ai mis en action aujourd’hui dans le cadre de mon poste de développeur WordPress.

Étape -1 – Sauvegarde

Saaaaauuuuuvvvvvveeeeegggggaaaaaarrrrrrdddddeeeeee

Sauvegardez vos fichiers (WP, extensions, thèmes, mu-plugins et base de données Mysql)

Étape 0 – Installation en local

Avoir le multisite en local, ce sera bien plus simple à gérer et en cas d’accident, ca ne génera que vous!

Étape 1 – Mises à jour

La première étape va consister a mettre votre multisite à jour:

  • WordPress
  • Thèmes
  • Extensions
  • Langues

Si cette étape n’est pas fondamentale, je me dis que:

  1. ça ne peut pas faire de mal
  2. ça peut éviter les conflits et les soucis par la suite quand vous importerez thèmes et extension dans votre site WordPress « Classique ».

Étape 2 – Installer WordPress

Installer un WordPress tout beau tout neuf… Pour cela je vous propose de le faire en 3 minutes grâce au script wp-cli que j’ai créé pour vous…

OK j’avoue, je l’ai créé pour moi… et je me suis dit que ça pourrait vous intéresser!

Étape 3 – Transférer les fichiers

Alors maintenant, va commencer un transfert de fichiers. Voilà pourquoi je vous ai demandé en étape 0 de travailler en local. e sera bien plus facile de déplacer des fichiers dans l’explorateur de votre machine qu’à distance via un sFTP ou autre.

Pensez à transférer:

  • Les thèmes (parent et enfants)
  • Les extensions
  • Les « mu-plugins »
  • le dossier « uploads »… mais lui je lui réserve l’étape 4!

Bien sur, sur le multisite peut être que toutes les extensions ou tous les thèmes n’étaient pas utiles pour le site que vous êtes en train d’extraire.

Ne transférez que ce dont vous avez besoin et n’activez rien

Étape 4 – le dossier « Uploads »

Le dossier Upload situé dans `wp-content` contient tous les médias téléversés sur votre site et disponible dans la médiathèque.

Avouez que ce serait ballot de ne pas les retrouver dans votre nouvelle installation.

Le dossier Upload est un peu différent à transférer puisque son architecture de dossiers et de sous-dossier est différent d’une installation classique.

Architecture du dossier Uploads en Multitisite
Architecture du dossier Uploads en Multitisite

Remarquez la différence avec une architecture classique. Dans « uploads », nous avons un dossier « sites » qui n’existe pas dans une installation classique de WordPress.

A l’intérieur de ce dossier « sites » nous avons un dossier nommé par l’id du site dans l’infrastructure multisite.

Ensuite, nous retrouvons le classement classique des médias par WordPress avec un dossier année et un dossier mois.

Retrouvez l’ID du site a extraire du multisite

J’estime que si vous faites cette manipulation alors vous avez les privilèges de super-administrateur.

Cette étape est assez simple, il faut se rendre dans l’administration réseau de votre multisite puis dans le sous-menu « Sites » au bout de la ligne concernant le site à migrer vous trouverez l’ID de celui-ci.

Trouvez l'ID du site à migrer
Trouvez l’ID du site à migrer

L’identifiant récupéré vous pouvez déplacer tout le contenu du dossier ayant l’id comme nom dans wp-content/uploads afin de retrouver l’arborescence classique d’un WP.

Étape 5 – exporter puis importer la base de données

C’est bien beau mais pour le moment, vous avez tout sauf votre contenu…. et dans un site, c’est bien le plus important la base de données.

Pour ce tutoriel, je vais estimer que vous avez le préfixe par défaut « wp_ ».

A l’image des médias, WordPress multisite ajoute l’id du site sur certaines tables.

Il va donc falloir exporter toutes les tables ayant l’ID ainsi que les tables wp_user et wp_usermeta qui elles n’ont pas d’id car dans un multisite, les utilisateurs sont commun à tous les sites.

Personnellement je le fais avec PHPmyAdmin si les tables ne sont pas trop volumineuses… on sélectionne les tables voulues (exemple: celle du site « 4 » wp_4_ ainsi que les 2 tables d’utilisateurs).

Avant d’importer, supprimez les tables wp_user et `wp_usermeta` de l’installation classique afin d’éviter les conflits avec les tables que vous allez importer.

Pour l’import dans le WP classique, utilisez également l’outils dont vous avez l’habitude.

Vous allez vous retrouver avec des tables en doublons: Celles de votre installation classique et celle que vous venez d’importer qui ont le préfixe `wp_4_`. Supprimez les tables en doublons de l’installation classique.

Importez vos tables « multisites »

A cette étape, si vous regardez votre base de données dans PHPmyadmin ou autres, vous devez remarquer des tables en wp_ et d’autres en wp_4_

Dans PhpMyadmin, cochez toutes les tables en `wp_4_` puis en bas de la page dans le menu déroulant sélectionnez « Remplacez le préfixe de table »

Si vous décidez de modifier le préfixe de table, n’oubliez pas de corriger le `wp-config.php` en conséquence.

On y est presque!

Étape 6 – Remplacer les URLs des médias en Base de données.

Pour cela j’utilise le script SRDB d’Interconnectit. Vous trouverez un guide de ce script chez mon ami Grégoire Noyelle.

Ici nous allons modifier les urls vers les medias et donc faire un recherche et remplace qui ressemblerait à ça:

Search: https://example.com/wp-content/uploads/site/4/2019/02/mon-image.jpg

Replace: https://example.com/wp-content/uploads/2019/02/mon-image.jpg

Étape 7 – la base utilisateur

Lors de l’import de la base de données, nous avons importé tous les utilisateurs du multisite… or, il y en a qui n’ont aucun rapport avec le site que vous venez d’extraire.

Je n’ai malheureusement pas encore trouvé une requête sql qui va bien … si vous avez une idée, soumettez la moi en commentaire, c’est avec joie que j’améliorerais ce tutoriel.

Étape 8 – Vérifications

Normalement, votre site classique est une copie exacte de votre site lorsqu’il était dans le multisite.

Selon vos installations, il peut y avoir 2/3 choses à régulariser. Exemple, remplacer des urls vers des images écrites en dur dans des fichiers css créé parle constructeur de page Elementor…

Vous avez peut être transférer des extensions qui n’ont un intérêt que dans le cadre d’un multisite…

Étape 10 – Se reposer!

Ouais y’a pas d’étape 9 car ça fait bien de s’arrêter sur un chiffre rond! une dizaine tout ça!

Normalement vous venez d’extraire sans encombre un site d’un multisite vers un site classique WordPress… vous avez bien mérité une petite mousse, un café ou n’importe qu’elle autre chose qui vous fera plaisir!

Et sinon, il y a la méthode simple! (ajout du 20 avril 2019)

Si comme moi vous êtes adepte de WP-CLI alors ce script vous permettra d’extraire un site du multisite en quelques secondes…

trepmal/blog-extractor

WP-CLI command. Extract single blog from multisite – trepmal/blog-extractor

https://github.com/trepmal/blog-extractor

Présentation de WP GestSup Connector, l’extension qui lie votre site WordPress au helpdesk GestSup

GestSup, qu’est ce que c’est?

Site web de GestSup.

GestSup est une solution de gestion de support auto-hébergée que j’utilise avec certains de mes clients pour prioriser les interventions et les développements réalisés par Thivinfo.

Jusque là j’avais, comme beaucoup, un formulaire de contact qui m’envoyait par mail le contenu saisi dans le formulaire en ligne. Ce mail, je le retranscrivais dans GestSup pour créer un ticket… faire et défaire c’est toujours travailler mais pendant ce temps là je n’étais pas productif pour développer les demandes de mes clients.

J’ai donc décidé de créer une extension WordPress qui génèrerait un formulaire via un code-court à placer sur le site et qui irait créer automatiquement un ticket dans GestSup. J’ai donc créé WP GestSup Connector qui fait exactement ce que je décris plus haut… sauf que…

Sauf que si la personne me contactant via le formulaire n’existe pas dans la base de données GestSup et bien le ticket n’est pas créé, je reçois la demande par mail, je la retranscris dans GestSup… hey mais… je l’ai déjà dit ça ! Ça ne pouvait plus durer et je me suis replongé dans le développement de l’extension.

Elle vérifie si l’adresse de la personne envoyant le formulaire existe dans la base de données GestSup. Si c’est le cas, le ticket est créé… si ce n’est pas le cas, un utilisateur est créé avant de créer le ticket.

Afin d’éviter le spam, WP GestSup Connector intègre Google Recaptcha. C’est optionnel, activable par une case à cocher dans les paramètres de l’extension.

Créer son dépot Composer pour gérer ses extensions premiums

Avouez le, si vous avez plusieurs sites a maintenir et que vous ne voulez pas passer par le bouton « mettre a jour »pour des raisons pratiques et de rapidité, les extensions premiums sont assez chia… casse-pieds à gérer.

Quelles solutions pour mettre ses extensions premiums WordPress à jour?

Vous avez plusieurs solutions:

  • Se rendre sur le site de l’éditeur de l’extension, sur son profil, récupérer le .zip de la mise a jour et la transférer via FTP ou via Git selon les habitudes de chacun. Cette opération sera a réitérer  sur chacun de vos sites…
  • Avoir une copie de « dev » de ses sites en local avec les clés API renseignées et cliquer sur le bouton qui va bien…
  • Avoir un dépôt Composer avec les dernières version de ses extensions premiums WordPress disponible.

Et c’est bien cette dernière solution que je compte vous présenter dans ces quelques lignes!

Composer est un gestionnaire de dépendance pour PHP mais ce tutoriel n’a pas pour but de vous expliquer le fonctionnement de ce logiciel. Etant très répandu, d’autres vous expliquerons tout ca bien mieux que moi.

L’idée est donc de créer son propre dépôt Composer sur lequel nous pourrons téléverser les différentes extensions dans leurs dernières versions ensuite il suffira de lancer une mise a jour via Composer sur nos différents projets! Et c’est justement ce que propose Release Belt de Rarst.

Découvrons Release belt

Release Belt est un projet de logiciel libre développé par Andrey Savchenko.

L’installation est assez simple puisqu’il vous suffit de cloner un dépot Git sur votre hébergement Web. Personnellement j’ai créé un sous domaine composer.thivinfo.com sur lequel j’ai installé Release Belt.

Le Readme est assez clair et en 3 commandes votre dépôt composer sera créé:

  • git clone https://github.com/Rarst/release-belt
  • cd release-belt
  • composer belt-update

A ce stade, votre dépot composer privé est installé, il ne reste plus qu’a téléverser les zip de vos extensions sur ce dépôt.

Pour cela il faut créer dans le répertoire releases un dossier « type » puis dans ce dossier type, créer un dossier avec le nom de l’extension et a l’intérieur de celui téléverser le zip… quoi c’est pas clair ?!

Le dossier « Type » peut être un dossier nommé par un nom natif de composer ou dans le cas qui nous interesse: « wordpress-plugin » mais ces possibilités existent:

  • wordpress-plugin
  • wordpress-theme
  • wordpress-muplugin
  • wordpress-dropin

Potentiellement, vous pourriez gérer tout autres projets autre que WordPress en utilisant ces types.

Chez moi le chemin vers les versions de SeoPress Pro ressemblera donc à /public_html/prod/composer/release-belt/releases/wordpress-plugin/wp-seopress-pro

  •  /public_html/prod/composer/ corresponds à la racine de mon installation Release Belt
  • /releases/wordpress-plugin/ le répertoire contenant la liste de mes extensions hébergées

Afin que seul vous ou les utilisateurs autorisés puissent accéder à votre dépôt Composer, je vous conseille fortement de le protéger via un système d’authentification. Les développeurs d’extensions ou de thème premium pourraient ne pas aimer que vous partagiez gratuitement leur travail.

Utiliser son dépôt Composer personnalisé dans un projet WordPress. 

Toutes les informations utiles se trouve sur la page d’accueil de votre dépot Composer. Chez moi c’est donc composer.thivinfo.com.

Si vous êtes un habitué de composer, vous saurez analyser les informations fournies par cette page auto-générée par Release-Belt.

Sinon il faut déclarer le dépôt dans votre composer.json:

"repositories": {
        "composer.thivinfo.com": {
            "type": "composer",
            "url": "https://composer.thivinfo.com/"
        }
    }

Puis dans la partie listant les extensions WordPress du projet vous copierez / collerez les lignes concernant l’extension voulue. 

Par exemple pour ajouter  à mon projet, j’ajouterai les lignes suivantes à mon composer.json à la racine de celui-ci:

"wp-rocket/wp-rocket": "^3.2.2"

Facile!

Comment je suis passé à Lando pour développer en utilisant Docker !

Il y a quelques mois j’avais testé Docker pour gérer mes environnements de développement. L’avantage majeur de Docker est de pouvoir développer en local sur les meme bases techniques  du serveur. Avouez que c’est tentant quand on a des sites hébergés chez des prestataires différents ( Même si la plupart pour mon cas sont chez O2Switch ) avec des versions logicielle des PHP, Mysql, Mariadb différentes. L’inconvénient majeur de Docker, a mon humble avis, réside dans la complexité de configuration! Je n’avais jamais réussi a faire fonctionner plusieurs vhost  en meme temps!

Avec Lando, c’est simple!

En discutant avec un collègue sur le Slack WordPress francophone, j’ai découvert Lando. Pour utiliser Lando, il vous faut tout d’abord installer Docker, puis Lando  vient en surcouche. Il va vous faciliter grandement la configuration des différentes images Docker à utiliser pour faire tourner votre environnement.

Des Recettes WordPress!

Lando propose des « Recipe », littéralement des recettes pour les principaux CMS et Frameworks du marché dont bien sur WordPress. Avec la recette WordPress, Lando va créer un envirronement comprenant PHP, et Mariadb pour faire tourner votre site mais également wp-cli ! Bref, en quelques secondes de lancement, vous voilà pret a développer sur votre CMS préféré.

Une configuration simplifiée pour Docker!

Voici un exemple du fichier de configuration .lando.yml que vous devrez avoir a la racine de votre projet pour lancer votre instance Lando!
name: test
recipe: wordpress
config:
  webroot: .
  php: '7.0'
  xdebug: true
  database: mariadb
services:
  pma:
    type: phpmyadmin
    hosts:
      - database
      - old-test
  mailhog:
    type: mailhog
    hogfrom:
    - appserver
  old-test:
    type: mariadb
    portforward: true
    creds:
      user: wordpress
      password: wordpress
      database: old-test
tooling:
  composer:
    service: appserver
Il s’agit d’un simple fichier texte au format .yml qui sera lu par Lando pour qu’il puisse créer votre environnement. Noter un « name », celui ci sera utilisé pour créer vos url locales de développement! ainsi que les services que vous désirez créer et dans quelle version! Ici j’ai choisi un PHP en version 7.0, Mariadb dans sa version stable courante, Phpmyadmin, Mailhog pour « attraper les mails » sortant sans avoir de serveur mail à configurer. On trouve aussi la configuration d’un second serveur de base de données ‘old-test’, l’activation de Xdebug et de Composer! Lando sur Github

GestSup: le logiciel de support made in France

Il y a quelque temps, je cherchais pour mon activité de développeur Freelance WordPress un gestionnaire de ticket simple et efficace. J’en ai essayé plusieurs: des solutions externes, des extensions WordPress, rien ne me convenait complètement. En discutant avec une amie également Freelance, j’ai découvert GestSup.

GestSup pour Gestion de Support

Avec GestSup comme avec beaucoup d’autres système de ce genre, le support va se faire via un système de ticket. Chaque ticket peut être catégorisé et sous-catégorisé.

Vos clients peuvent ouvrir des tickets, les attribuer à un technicien manuellement ou automatiquement, leur attribuer un degrès d’urgence, de criticité.

L’avantage de ce genre d’outils est que toutes vos demandes de support sont  centralisée au même endroit. Vous avez un historique de chaque problème et surtout leur solution. La solution d’un jour peut resservir dans le futur.

Je pourrais bien entendu vous faire un tour complet de GestSup mais il existe un espace Demo qui vous permettra bien plus facilement de vous rendre compte du potentiel de la solution.

Intégrer GestSup avec votre site WordPress

Mes clients avaient l’habitude de me contacter en utilisant le formulaire disponible sur ma page contact, je l’ai remplacé par une page support qui leur permets d’ouvrir un ticket directement depuis mon site web.

Pour réaliser cette page, j’ai développé l’extension WordPress qui est désormais disponible sur le dépôt officiel WordPress.

Intégrer une Google Map sans extension dans WordPress

Il existe beaucoup de solutions pour intégrer une carte Google dans vos contenus WordPress. Aujourd’hui nous allons voir une solution basée sur un champs Gmap d’Advanced Custom Field (ACF). Cet article est une traduction du tutoriel d’Alicia Ramirez.

Ce tutoriel est basé sur l’utilisation de l’excellentissime extension Advanced Custom Field car elle est utilisée sur la totalité de mes développement et très simple à mettre en oeuvre.

Étape 0: Obtenir une clé API Google Map.

Avant de pouvoir utiliser Google Maps, il va falloir obtenir une clé API Google Map. Vous pouvez  utiliser l’API Standard qui autorise 25000 affichage de carte par jour) ou si vous avez beaucoup de trafic, vous devrez opter pour un plan Premium.

Étape 1: Ajouter du CSS

Coller ce code dans votre feuille de style (style.css) ou ailleurs si vous le pensez plus approprié.

Étape 2: Création d’un script Javascript initialisant la carte.

Copiez / collez ce code dans un fichier gmap.js que vous pourrez stocker dans un dossier de votre thème. Pour l’exemple nous prendrons library/js.

Étape 3: Chargement des scripts par WordPress

Maintenant, il vous faut charger les scripts précédemment créé lors du chargement de WordPress. Vous pourriez coller les liens dans le header.php de votre thème… mais ce n’est vraiment pas une bonne pratique WordPress. Nous allons utiliser la fonction dédiée de WordPress : wp_enqueue_script()

Dans votre functions.php de votre thème, ajoutez le code suivant:

Aux lignes 2 et 10, remplacez « XXXX » par votre clé API Google Map.

À la ligne 3, assurez vous d’avoir saisi le chemin vers le script JS  créé à l’étape 2.

Étape 3 – Bonus

Si vous ne voulez charger votre carte que sur certaines page, par exemple la page « Contact », vous pouvez modifier le code comme ceci:

Étape 4: Affichage de la carte

Dans votre template de page, là ou vous désirez voir la carte, insérez ce code dans la Boucle:

Assurez vous de bien modifier le nom du champs ACF Google Map. Ici on a utilisé « location » dans get_field('location');.

Conclusion:

Vous venez d’ajouter une carte Gmap dans votre thème WordPress sans utiliser aucune extension. Notez que vous pouvez vous passer d’ACF si vous désirez saisir « en dur » les coordonnées GPS d’un lieu. Il vous suffira d’adapter les valeurs de data-lat et data-lng

Pré-remplir un formulaire Gravity Form avec des paramètres d’URL

Gravity Form est une extension WordPress Premium (entendre payante) offrant la possibilité de construire des formulaires de toutes sortes assez poussés.

Sur un projet, j’ai récemment eu besoin d’alimenter de façon automatique des champs d’un formulaire et je me suis dis que j’e pouvais aussi vous en faire profiter…

Récupérer des informations via les paramètres d’une URL

Si vous êtes développeur, ceci ne devrait pas éveiller de questions, si ce n’est pas le cas vous vous demandez sûrement ce que sont ces paramètres d’URL… vous en avez pourtant déjà tous croisé!

Imaginons une URL du type: https://thivinfo.com/blog/tutoriels/pre-remplir-un-formulaire-gravity-form-avec-des-parametres-durl/ … rien de transcendant hein … maintenant en ajoutant les paramètres:

?checkbox=1&texte=mon%20test

on va se retrouver se retrouver avec cette URL https://thivinfo.com/formulaire-pour-tutoriel-gf-et-parametre/?checkbox=1&texte=mon%20test

Et là avouez que le résultat est sympa et que dans bien des cas, ca pourrait être très pratique!

Comment faire ?

Tout d’abord, il va vous falloir acheter Gravity Form puis créer un formulaire.

Pour un champs simple type « texte »

Prenons exemple de mon champ texte, en back-office vous devrez obtenir ceci:

Dans l’onglet « Avancé », cochez « Remplir dynamiquement les champs ». Ceci fera apparaître un champs ou vous pourrez nommez votre paramètre. Ici dans un élan d’inspiration je l’ai nommé « Texte » ce qui me permettra d’avoir le paramètre

texte=

Pour un champs avancés de type « checkbox »

Pour ce type de champs, c’est un peu plus compliqué car il ne s’agit pas de simplement remplir un champs de type Input, il faut définir quelle choix cocher…

Pour ce faire, nous allons dans l’onglet « Général » cocher la case « afficher les valeurs » ce qui aura pour effet d’ajouter un champs par choix afin de pouvoir sélectionner facilement l’une ou l’autre des possibilités du champs « Checkbox ».

Il faut bien entendu définir un paramètre « checkbox » dans l’onglet avancé de la boite de Dialogue Gravity Form pour réaliser l’exemple d’URL cité en début d’article.

Précision pour les non-développeu⋅r⋅se⋅s

Il n’y a pas d’ordre à respecter dans les paramètres à mettre dans l’URL. Le 1er paramètre est toujours un ? et les suivants sont séparés par des esperluettes (&).

Et sinon?

Et sinon… vous n’êtes pas obligé de passer les paramètres dans un lien… vous pouvez aussi les placer dans le code-court (shortcode) de Gravity Form à la manière de


                

Précision pour les développeu⋅r⋅se⋅s

Cette technique est très pratique si vous la couplez à la fonction WordPress add_query_arg() qui vous permettra de construire dynamiquement des URL contenant des paramètres. Si vous désirez en savoir plus sur cette fonction, je vous invite à lire l’article très complet de Maxime Culea