Pour faire suite à la vidéo de présentation de WP Synchro, celle-ci est dédiée à ses réglages avancés. Vous y verrez que les possibilités offertes permettent d'aller très loin dans la personnalisation. Vous saurez tout sur chacune des options afin de pouvoir répondre à tous vos besoins de migration.
Revue de détail de chaque option, commentée et expliquée, des deux grandes catégories d'une migration : les fichiers et les tables de la base de données. La vidéo se termine par une mise en pratique avec le cas d'un site de e-commerce.
Si besoin, activez le sous-titrage en français de la video : il est effectué par nos soins.
Avant d'aller plus loin, sachez que cet article est destiné aux professionels du web : migrer un site, quoiqu'on puisse lire un peu partout, ou voir sur Youtube, nécessite de bien savoir ce que l'on fait…
Cette mise en garde effectuée, je vous présente l'une de mes extensions préférées, qui me simplifie la tâche et me fait gagner beaucoup de temps dès que je dois effectuer une migration entre hébergeurs ou pour rapatrier un site sur mon serveur local afin d'y apporter des modifications.
Bon, ne riez pas : je viens de dénigrer les tutos Youtube qui vous promettent de migrer un site en un tournemain, et qu'est-ce que je fais ?
Ben… je vous propose mon propre tuto Youtube !
Je vous y explique tout : quelle extension, sa politique tarifaire, le site source, le site de destination, toutes les fonctionnalités du plugin et comment les configurer, etc. le tout avec des petites animations qui m'ont demandées pas mal de temps !
Pour vous donner une idée, la vidéo dure plus longtemps (18 minutes) que n'en prend la migration en elle-même 😉
Si besoin, cliquez sur l'icône de sous-titre pour activer le sous-titrage Français effectué par nos soins.
Avec la généralisation du https par les navigateurs, les sites doivent avoir un certificat SSL.
Si vous utilisez MAMP ou MAMP Pro comme serveur local pour développer vos sites, vous pouvez lui demander de générer un “certificat SSL auto-signé” pour chacun d’eux. Toutefois, les navigateurs identifient qu’il s’agit d’un certificat auto-signé et affichent une alerte ou une page d’avertissement plutôt anxiogène.
Heureusement, MacOS X permet de “forcer” l’approbation du certificat auto-signé afin d’accéder au site sans avoir à subir ces avertissements. Ce tutoriel vidéo vous explique en 5 minutes le pourquoi et le comment.
Bonjour,
Ce court tuto pour répondre à une problèmatique qui revient assez souvent lorsqu’on crée un site en local avec Mamp ou Mamp Pro et qui concerne les certificats SSL auto-signés.
Bien qu’ayant généré le certificat SSL, lorsqu’on accède au site via un navigateur, on obtient une alerte ou une page assez anxiogène nous informant que la connexion n’est pas privée et évoquant même des individus malveillants tentant de subtiliser nos précieuses informations personnelles.
Dans le cas présent, s’agissant d’un site en local, c’est-à-dire un site qui est hébergé sur notre propre ordinateur, ce type de message n’est pas justifié. Mais le navigateur n’est pas en mesure de détecter cette configuration, il se fait ‘gruger’ et nous affiche donc cette alerte.
Dans les faits, qui plus est, le navigateur se trompe : la connexion est bien ‘privée’, c'est-à-dire que les flux de données échangés entre notre site local et le navigateur sont bien cryptés, on est en https://.
En revanche, là où il a raison, c’est que le certificat ne peut pas être ‘certifié’ par une autorité de certification. C'est la définition même d’un certificat ‘auto-signé’.
C’est comme si, lors d’un contrôle d’identité, l’agent de police n’avait que votre seule parole pour vous croire lorsque vous lui dites que vous n’avez pas vos papiers sur vous, mais que vous vous appelez Jacques Dupond. Faute d’une pièce d’identité certifiée, l’agent n’est pas en mesure de savoir si vous êtes bien celui que vous déclarez être.
C'est la même chose avec un certificat SSL ‘auto-signé’.
Nous allons donc en venir au réel sujet de cette vidéo et faire en sorte de ne plus afficher ce type de message lorsqu’on accède à notre site en local.
Pour cela, on va utiliser un logiciel fourni en standard avec MacOS X : il s'agit du ‘Trousseau d'accès’, que vous trouverez dans le dossier “Applications”… puis le dossier “Utilitaires”…
Voici le “Trousseau d'accès”… et on le lance.
Là, assurez-vous de cliquer sur ‘Certificats’ dans la rubrique ‘Catégories’ afin de réduire le contenu des éléments listés aux seuls certificats.
Dans la rubrique ‘Trousseaux’, vous pouvez sélectionnez soit “Session”, soit “Système” :
Le but de l’opération maintenant est d’ajouter au Trousseau notre certificat SSL et d’imposer sa validité.
Il nous faut donc le certificat en lui-même. Pour cela, on va le récupérer…
…dans Mamp.
On sélectionne le site concerné… et on accède à l’onglet SSL…
Là, on clique sur l’icône de dossier des fichiers de certificat “.crt”
On sélectionne le certificat du site concerné et on le fait glisser dans la fenêtre du “Trousseau d'accès”.
Dans le Trousseau d‘accès, je peux alors double-cliquer sur le certificat qu‘on vient d‘ajouter afin d‘en réveler le contenu et, surtout, la fonctionnalité qui nous intéresse : “Se fier”… que je déroule en cliquant sur le petit triangle.
Et là, je vais changer la valeur “Réglages par défaut”, que je remplace par “Toujours approuver”.
Je ferme la fenêtre du certificat…
Je valide la modification en saisissant mon mot de passe utilisateur… et je peux fermer le Trousseau d’accès.
Maintenant, si je rafraîchis la fenêtre du navigateur…
Tadaam ! Le site s’affiche désormais sans alerte et avec le petit cadenas tant recherché !
Voilà ! J'espère que ce petit tuto vous a plu et on se retrouve lors d’une prochaine vidéo.
Salut !
WordPress met à la disposition des développeurs toutes les fonctionnalités nécessaires à l’internationalisation (la traduction) des thèmes et des extensions.
Au fil du temps, les règles d'écriture (les “bonnes pratiques”) se solidifient [rigidifient ?].
Si le thème ou le plugin ne suit pas ces “recommandations”, il y a de fortes chances qu’il ne franchisse pas les contrôles lui permettant d’intégrer le Dépôt Officiel de WordPress : le développeur devra revoir son code en conséquence.
En soi, ces recommandations sont parfaitement justifiées. C’est un gage de compatibilité, de “maintenabilité”, de lisibilité, etc. Là n'est pas le problème.
C’est juste que si l’on se conforme à ces recommandations, il me semble que le textdomain devient inutile et qu'on pourrait s'en passer…
Les recommandations de développement WordPress concernant l’internationalisation des extensions, spécifient que toutes les fonctions concernées doivent indiquer, en clair, le textdomain :
$texte = __( 'The text to translate', 'mon-super-plugin' ); echo $texte; _e( 'Another text to translate', 'mon-super-plugin' );
Mais auparavant, on doit déclarer ce textdomain via la fonction dédiée :
load_plugin_textdomain( 'mon-super-plugin', false, plugin_basename( __DIR__ ) .'/languages' );
Puisqu’on déclare ce textdomain, pourquoi ensuite est-il nécessaire de le spécifier pour chaque chaine à traduire ?
D’ailleurs, si on va plus loin, ce textdomain doit correspondre au nom slug de l’extension.
Si le fichier principal de l’extension est “mon-super-plugin.php », le textdomain doit être “mon-super-plugin”.
On en arrive alors à se demander la nécessité de la fonction load_plugin_textdomain().
Tout cela pourrait être pris en charge par le core de WordPress :
Si on ne l’indique pas, WP devrait le déduire à partir du nom de l’extension.
On conserve bien sûr l’aspect optionnel afin de pouvoir spécifier un textdomain différent. Par exemple, dans le cas où l’extension reprend une chaine du cœur de WordPress ou, par exemple, de WooCommerce :
_e( 'This controls the title which you see during checkout.', 'woocommerce' )
Local by Flywheel est un serveur de développement web en local. Gratuit et performant, il constitue une excellente alternative à WAMP (Windows), MAMP (Mac OS X).
La version 3.0 vient tout juste de sortir, immédiatement suivie par la v3.0.1. Je vous propose d’en découvrir les nouveautés.
Retrouvez la liste officielle des nouveautés à la fin de cet article.
La principale nouveauté, du moins celle qui est la plus visible, est l’ajout d’une bibliothèque de modules (Add-ons) directement intégrée à LbF (le petit nom de Local by Flywheel).
Ces modules permettent d’ajouter/compléter les fonctionnalités de base, un peu comme le font les plugins de WordPress.
Les autres nouveautés concernent des améliorations de performances, des corrections de bugs survenants dans de rares situations ainsi que la mise à jour des composants internes, et de la version wordpress fournie (v5.0.1).
Avec cette version 3, la barre latérale se pare d’une nouvelle icône, une pièce de puzzle, permettant d’accéder aux 5 modules (add-ons) disponibles pour l’instant.
Gageons que leur nombre augmentera, d’autant que Flywheel met à disposition une API ainsi que la documentation nécessaire pour le développement d’autres modules.
Ces modules ne sont pas tous nouveaux, mais soit il fallait les installer “à la main” (Xdebug + PhpStorm), soit ils ne fonctionnaient plus avec les précédentes versions (Stats).
Tous ces modules s’appliquent à chaque site déclarés dans LbF.
Volumes
Ce module permet d’ajouter des dossiers à prendre en charge.
Une fois ce module activé, on accède à ses réglages via le menu “More…” de chaque site.
Ports
Ce module permet de déclarer la prise en charge de ports supplémentaires. Le plus souvent, il s’agira du port 22 (SSL) pour déclarer votre site en https.
Une fois ce module activé, on accède à ses réglages via le menu “More…” de chaque site.
Stats
Ce module permet d’afficher en temps réel les “ressources” consommées par un site. Les ressources en question sont la quantités de mémoires consommées et la puissance de calcul sollicitée.
Une fois ce module activé, on accède au visualiseur via le menu “More…” de chaque site.
XDebug + PhpStorm
Ce module, dédié aux développeurs, permet d’installer XDebug et de l’interfacer à PhpStorm* en 1 simple clic. Une bien belle avancée, vous en conviendrez si vous êtes développeur 😉
Une fois ce module activé, on accède à ses options via le menu “More…” de chaque site.
*PhpStorm est un IDE de développement.
Notes
Ce module est un mini pense-bête vous permettant d’ajouter des notes. Il supporte la notation markdown.
Une fois ce module activé, l’écran d’accueil “Overview” comporte une nouvelle section “Notes”, sur la droite.
Je prévois une série d’articles sur les avantages d’un serveur web local et sa configuration autour de Local by Flywheel.
Si vous êtes intéressé, faites-le moi savoir en commentaires.
Rendez-vous sur le site de Local by Flywheel pour télécharger la dernière version.
Un plugin WordPress peut faire appel à de nombreuses class qu’il faudra inclure via autant de require ou include. C’est long, fastidieux et potentiellement source d'erreurs. Pourquoi s’embêter avec ça quand PHP peut le faire pour nous ?
En bon codeur respecteux des standards, on part du principe que toutes nos class sont regroupées dans un même dossier et que les fichiers sont nommés selon ce modèle : class-nomdemaclass.php Si toutes nos class sont regroupées dans un dossier includes, on obtient quelque chose ressemblant à ceci :
Nous allons créer notre autoloader. Et vous savez quoi ? Ce sera lui aussi une… class. Dans le dossier includes de notre plugin, on crée un fichier class-rrphf-myplugin-autoloader.php et on y rédige le code suivant :
<?php defined( 'ABSPATH' ) || exit;
/**
* Project: RRPhF MyPlugin
* File: class-rrphf-myplugin-autoloader.php
* User: reskator
* Author: RR PhF
*
* @Description Class autoloader for RRPhF MyPlugin plugin
* @since 1.0.0
*/
if ( ! class_exists( 'RRPhF_MyPlugin_autoloader' ) ) :
class RRPhF_MyPlugin_autoloader {
/**
* Singleton
*
* @var null Single instance
*/
private static $_instance = null;
/**
* RRPhF_MyPlugin_autoloader constructor.
*
*/
private function __construct() {
spl_autoload_register( [$this, 'load'] );
}
/**
* Singleton method
*
* If it has not already been done, creates and return an instance of the class
*
* @author RR PhF
* @since 1.0.0
*
* @static
* @return \RRPhF_MyPlugin_autoloader
*/
public static function get_instance() {
if ( ! self::$_instance ) {
self::$_instance = new self();
}
return self::$_instance;
}
/**
* Class loader
*
* Converts the name of the class to a file name and includes the class file.
*
* @author RR PhF
* @since 1.0.0
*
* @param string $class_name - class to load
*/
public function load( $class_name ) {
//Converts the class name to a file name
$class_file = str_replace( '_', '-', strtolower( $class_name ) );
$class_file = 'class-' . $class_file;
$class_file = __DIR__ . '/' . $class_file;
// do the autoloading
spl_autoload( $class_file, '.php' );
}
}
/**
* Make sure an instance can't be cloned
*
* @author RR PhF
* @since 1.0.0
*
*/
private function __clone() {
// do nothing
}
}
RRPhF_MyPlugin_autoloader::get_instance();
endif;
Notre class est instanciée à la ligne 81. par l'appel de la méthode… get_intance()
RRPhF_MyPlugin_autoloader::get_instance();
Le fait d'instancier la class fait que PHP cherche si un constructeur est présent dans la class et l'exécute automatiquement. Ça tombe bien notre class en comporte un :
private function __construct() {
spl_autoload_register( [$this, 'load'] );
}
Pour schématiser, spl_autoload_register() permet d'indiquer à PHP la fonction (méthode) qu'il devra utiliser lorsqu'il découvrira une nouvelle class durant l'exécution de notre plugin. En bonus, il se chargera de transmettre à notre méthode le nom de la class concernée. Dans le cas présent, comme vous pouvez le voir, nous lui indiquons d’utiliser la méthode load :
*/
public function load( $class_name ) {
//Converts the class name to a file name
$class_file = str_replace( '_', '-', strtolower( $class_name ) );
$class_file = 'class-'. $class_file;
$class_file = __DIR__ .'/'. $class_file;
// do the autoloading
spl_autoload( $class_file, '.php' );
}
La méthode load dispose de l'argument $class_name. C'est cet argument qui reçoit le nom de la class ayant déclenché l'appel _autoload. Après avoir converti le nom de la class en nom de fichier (mais sans l'extension), on appelle la méthode PHP spl_autoload() avec, en 1er argument, le path du fichier à charger (toujours sans l'extension), et en deuxième argument, l'extension. Notez que notre class est particulièrement ‘verrouillée’ :
$_instance est déclarée private et static ;__constructor est déclaré private ;get_instance() fait sont possible pour ne déclarer qu'une instance.Je dis qu'il fait son possible car il ne peut empêcher que l'instance soit… clonée :/ D'où la dernière méthode de notre class :
private function __clone() {
// do nothing
}
Dans le cas où l'on tenterait de cloner l'instance de cette class, la méthode __clone() sera appelée… mais ne fera rien : plus de clonage possible.
L'autoloader étant en place, il nous faut l'implémenter dans notre plugin :
<?php defined( 'ABSPATH' ) || exit;
/*
Plugin Name: RRPhF MyPlugin
Plugin URI: https://www.reskator.fr
Description: The best plugin in the world that everyone expected
Version: 1.0.0
Author: Reskator
Author URI: https://www.reskator.fr
Text Domain: rrphfmyplugin
Domain Path: /languages
License: GPLv2 or later
*/
if ( ! defined( 'RRPHF_MYPLUGIN_FILE' ) ) {
define( 'RRPHF_MYPLUGIN_FILE', __FILE__ );
}
if ( ! class_exists( 'RRPhFMyPlugin_autoloader' ) ) {
include_once __DIR__ .'/includes/class-rrphfmyplugin-autoloader.php';
}
// Calls plugin's main class
$myplugin = new RRPhF_MyPlugin();
Et voilà ! On n'a désormais qu'un seul et unique include pour charger toutes nos class 🙂 Et on peux voir la 'magie' opérer dès l'instruction suivante qui instancie la class principale du plugin. Sans autoloader, on a tendance à inclure TOUTES les class. Or, il se peut qu'elles ne soient pas toutes requises à chaque fois. Avec un autoloader, PHP ne chargera que les class nécessaires, libérant ainsi des ressources (mémoire, accès disques, etc.).