par Anne-Laure DELPECH | 13 Sep 2016 | Hébergement web
WordPress est habituellement utilisé pour un seul site. C’est plus simple mais ça présente aussi des inconvénients :
- si vous un hébergement mutualisé (Pro OVH par exemple) avec seulement 4 bases de données, vous ne pouvez pas créer plus de 4 sites.
- Si vous gérez 4 sites, il faudra faire autant de fois les installations de WordPress, les mises à jour de WordPress et des extensions.
J’expérimente ici la création d’un site multisite à partir d’un nom de domaine « potentiel-web.com » sur un hébergement Pro mutualisé d’OVH. Ce site a déjà été créé, avec un certificat SSL « Let’s Encrypt » (voir l’article WordPress avec un SSL Let’s encrypt sur OVH mutualisé). Nous allons maintenant le rendre multisites.
Qu’est-ce que WordPress multisite ?
Un réseau WordPress multisite, c’est un ensemble de sites internet distincts qui partagent une seule installation de WordPress. Le site WordPress.org, qui est composé de millions de sites en est un exemple. Chaque site du réseau est en fait un site virtuel, qui dispose cependant de son propre répertoire « upload » pour les médias et de ses propres tables dans la base de données.
Les extensions et thèmes sont installées au niveau de la tête de réseau mais chaque site peut les activer ou les désactiver.
Un réseau de sites peut fonctionner selon deux principes distincts :
- en « sous-domaines » : les sites auront des url du type site1.domaine.com, site2.domaine.com ;
- en « sous-répertoires » : les sites auront des url du type domaine.com/site1, domaine.com/site2.
A quoi ça sert ?
Un seul individu (ou entreprise) peut avoir plusieurs sites ou blogs. Ca devient vite compliqué de les gérer chacun individuellement, de les mettre à jour, d’ajouter la même extension dans chacun. On peut donc utiliser la fonctionnalité multi-sites de WordPress pour n’avoir qu’une seule installation de WordPress, des extensions et des thèmes pour plusieurs sites distincts.
Un développeur, ou une agence web, pourra aussi avoir un réseau de sites de clients installés et administrés d’un seul endroit. Les clients peuvent avoir un accès administrateur à leur propre site s’ils le souhaitent. L’avantage est qu’ils ne pourront pas ajouter des thèmes ou des extensions.
On peut également avoir un réseau dans lequel des gens peuvent ajouter leur propre site, gratuitement ou moyennant paiement.
Dans tous les cas, une extension spécialisée permet le « domain mapping » et autorise l’utilisation de noms de domaines différents pour chaque site du réseau.
étape 1 : régler WordPress
C’est WordPress qui gérera les sous-domaines, pas notre espace client OVH. Je ne crée donc pas de sous-domaine sur OVH.
Pour cette étape, je m’inspire des tutoriels suivants :
Activation du réseau: dans wp-config.php
Ajouter les deux lignes suivantes dans wp-config.php , juste avant la ligne « /* C’est tout, ne touchez pas à ce qui suit ! Bon blogging ! */ » :
/* Multisite */
define('WP_ALLOW_MULTISITE', true);
Créer le réseau, dans WordPress
Dans le menu « outils » du tableau de bord WordPress, il y a maintenant un menu « création du réseau ». Les extensions éventuellement présentes doivent avoir été désactivées avant.
Il faut (1) choisir entre le mode « sous-domaines » et le mode « sous-répertoires ». J’ai choisi « sous-domaines » car j’ai le sentiment que c’est mieux adapté, mais je ne suis pas certaine d’avoir tout compris. J’ai lu que c’était compliqué de transformer un site existant en mode multisite avec sous-répertoires car les anciennes url ne vont plus fonctionner correctement. Comme ces essai est un préalable à la transformation d’un site existant, il m’a semblé plus simple d’essayer tout de suite en sous-domaines.
Il faut également indiquer (2) le titre du réseau et (3) l’adresse email de l’administrateur du réseau (le super administrateur).
Ensuite, on clique sur « installer ». Pour cet essai, je pars d’un site vide, mais évidemment, si on part d’un site existant, il faut impérativement sauvegarder la base de données et les fichiers avant de réaliser cette modification.
Après avoir cliqué sur « installer », nous arrivons à une page assez effrayante…
Dans l’écran qui s’affiche, on voit trois éléments :
- Une alerte « Attention ! L’enregistrement DNS générique (joker) peut ne pas être configuré correctement ! ». Pour l’instant, nous ne nous en préoccupons pas.
- du code qu’il faudra ajouter à wp-config.php
- du code qu’il faudra ajouter au fichier .htaccess
Modifier wp-config.php
Je copie puis colle le contenu indiqué dans l’écran WordPress dans mon fichier wp-config.php , sous la ligne contenant define(‘WP_ALLOW_MULTISITE’, true);
Modifier le fichier .htaccess
Le nouveau contenu de ce fichier est maintenant :
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
Se reconnecter
Une fois les modifications faites, j’ai cliqué sur « reconnecter » en bas de la page WordPress qui contenait les instructions.
Mon tableau de bord WordPress contient maintenant un nouveau menu « mes sites ».
Créer un nouveau site dans le réseau
Attention : si on utilise un certificat SSL pour le site principal, voire pour les sites du réseau, il y a des spécificités. Voir plus bas le chapitre « Spécificités du SSL (https) »
Nous allons créer un sous-domaine test1.potentiel-web.com.
Dans le tableau de bord WordPress
Lorsque je me connecte à potentiel-web.com/wp-admin, j’ai une interface WordPress qui paraît identique à celle d’un site unique classique. Mais il y a des différences :
- sous le menu « tableau de bord », il y a maintenant un menu « mes sites », comme vu précédemment.
- Mais surtout, maintenant si je place ma souris tout en haut sur le titre du site, j’ai un sous-menu « admin du réseau » qui apparaît.
Si je vais dans le sous-menu « Sites », je peux créer, supprimer, modifier des sites du réseau, comme si c’était des articles ou des pages !
Je crée donc le site test1.potentiel-web.com :
Après avoir cliqué sur « ajouter un site », ce nouveau site apparaît dans la liste de mes sites. J’ai reçu aussi plusieurs mail :
- des mails à mon adresse donnée lorsque j’ai créé le multisite, mon adresse de « super admin » !
- des mails à l’adresse que je viens de donner comme administrateur de test1.potentiel-web.com. Ces mails m’informent de la création du site et indiquent où aller pour configurer mon mot de passe.
Mais si je met « test1.potentiel-web.com » dans un navigateur , j’obtiens une page d’erreur « Impossible de trouver l’adresse DNS du serveur test1.potentiel-web.com ». Il faut que je crée le nom de domaine dans OVH.
Création du sous-domaine dans l’espace client OVH
dans l’espace client d’OVH. Je clique sur l’hébergement auquel est rattaché mon site multisite puis sur l’onglet « multisite ». Ensuite je clique sur le bouton « ajouter un domaine ou un sous-domaine ».
Dans l’étape 2, il n’y a aucune raison de créer également le sous-domaine avec le www. Je ne le fais donc pas.
Le répertoire cible doit être celui du domaine principal du réseau de sites (multi-test pour moi – la copie d’écran ci-dessous indique www mais c’est multi-test qu’il faut lire, le répertoire où est installé potentiel-web.com).
Je choisis l’option SSL puisque je veux que tous mes sites soient encryptés.
Je choisis log séparé car c’est plus clair.
OVH affiche « La modification du ou des domaines associé(s) à votre hébergement mutualisé est en cours … » et quelques minutes plus tard, il devient possible d’accéder à http://test1.potentiel-web.com. Il n’est toujours pas possible d’accéder à https://test1.potentiel-web.com (la version encryptée) car je n’ai pas encore régénéré le certificat ssl.
Accéder au nouveau site et le modifier
Si je me connecte au nouveau site test1 (j’ai été créée comme administrateur en tant que « test1 »), je perds ma connexion de super administrateur, ce qui est normal puisque j’ai indiqué un autre email que celui du super administrateur comme administrateur du site test1…
En tant qu’administrateur de test1.potentiel-web.com, je peux faire tout ce que peux faire un administrateur d’un site unique, sauf installer des thèmes ou des extensions. Ces installations, le super administrateur est seul habilité à les réaliser.
Modifier les utilisateurs en tant que super administrateur
Dans le menu « admin du réseau », sous-menu « Sites », je peux modifier les sites du réseau.
Si je clique sur « modifier » pour le site test1, j’ai accès à 4 onglets, dont l’onglet utilisateurs. Je peux ajouter un utilisateur existant ou un nouvel utilisateur.
J’y ajoute l’utilisateur que je suis en tant que super administrateur. Maintenant avec un seul utilisateur, je peux aussi bien agir dans le site test1, que dans le site principal ou administrer le réseau de site.
Installer des thèmes et extensions en tant que super administrateur
En tant que super administrateur, je peux installer un nouveau thème ou une nouvelle extension.
Installer un nouveau thème
soit avec « ajouter », dans le menu « admin du réseau » > « thèmes », pour un thème présent dans les thèmes de wordpress.org ou par ajout de fichiers dans le répertoire /racine/wp-content/themes comme dans un site unique.
Activation d’un nouveau thème
Dans la liste des thèmes, chacun peut être activé ou désactivé pour le réseau dans le menu « admin du réseau » > « thèmes ».
Si je souhaite qu’un thème soit disponible pour tous les sites du réseau : je clique sur « activer pour le réseau ».
Si au contraire je ne souhaite mettre ce thème à disposition que de certains site, je vais dans le menu « admin du réseau » > « sites » et, pour chaque site, je clique sur modifier et je vais dans l’onglet thème.
Ainsi j’ai installé le thème stargazer et je l’ai activé pour tous les sites. Ensuite j’ai installé un thème enfant de stargazer (par transfert de fichiers) et je l’ai activé dans le site « test1 » seulement.
Installer une extension
dans le menu « admin du réseau » > « extensions », je peux ajouter une extension avec le bouton « ajouter » pour pour une extension présente dans les extensions de wordpress.org ou par ajout de fichiers dans le répertoire /racine/wp-content/plugins comme dans un site unique.
Activation d’une extension
Attention, une extension qui ajoute des tables dans WordPress doit être compatible multisite pour fonctionner correctement (voir l’article Make WordPress Plugin compatible with Multisite). Si une extension n’est pas compatible multisite, on pourra l’activer dans chaque site du réseau mais pas pour tout le réseau.
J’installe l’extension « Yoast SEO » qui dit être compatible multisites et « HMS Testimonials » qui est ancienne et n’indique pas de compatibilité multisite, tout en créant des tables.
Lorsque j’active ces deux extensions sur le réseau, dans le menu « admin du réseau » > « extensions », je n’ai aucun message d’erreur.
Et lorsque je vais voir le contenu de la base de données du réseau de site, elle contient autant de tables que de sites, tous avec un préfixe du genre prefixe_nom_table : prefixe tout court pour le site principal, prefixe_1 pour le premier site ajouté, etc… Et HMS Testimonials a ajouté plusieurs tables pour chaque site. Il n’y a donc pas de souci.
Spécificités du SSL (https)
Comme le site principal est crypté, les liens vers les autres sites sont en https. Le certificat SSL doit donc les inclure : J’ai ajouté un deuxième site, test2.potentiel-web.com, j’ai attendu deux heures comme indiqué par OVH puis j’ai régénéré le certificat ssl sur mon espace client OVH.
La régénération est assez longue mais pendant ce temps les sites qui étaient déjà encryptés conservent leurs certificats SSL et fonctionnent donc correctement.
Au bout d’une dizaine de minutes le certificat est régénéré. Au départ, j’ai un problème car le site https://test1.potentiel-web.com est annoncé comme non sécurisé…
La solution : retourner dans le menu « admin du réseau » > « sites » et modifier l’adresse du site de destination. C’était http://test1.potentiel-web.com. J’ajoute un s à la fin de http, et ça y est c’est bon !
Il faut également effectuer des redirections lorsqu’une url est appelée sans rien devant ou en http. Mais on ne doit pas rediriger une url contenant à la fin wp-admin.*, wp-config.* ou wp-includes.*
Donc on modifie .htacess pour que (merci aux auteurs des réponses à cette question sur Stackoverflow) :
- quand le port est 80 (si la connexion était sécurisée elle utiliserait le port 443. Quand elle utilise le port 80, elle est en http)
- ET l’url appelée (%{REQUEST_URI} ) n’est ni wp-content, ni wp-admin, ni wp-includes suivi de n’importe quoi,
- ALORS on redirige vers la version https de l’url.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} !(wp-(content|admin|includes).*)$
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
Noter qu’il faut parfois vider le cache du navigateur pour que la réécriture des url sans http se fasse correctement… J’ai Chrome réglé pour conserver les historiques et Firefox qui ne les conserve pas. Je teste donc dans Firefox puis quand ça fonctionne, j’efface les données de navigation de moins d’une heure dans chrome, en ne sélectionnant que « cookies et autres données » et « images en fichiers en cache ».
et dans wp-config.php , il est préférable d’ajouter une ligne qui force l’usage du SSL pour l’administration :
/* HTTPS only for admin access */
define( 'FORCE_SSL_ADMIN', true );
Et maintenant ?
J’ai donc réussi à créer un réseau de sites avec la fonctionnalité multi sites de WordPress. Ca me semble pratique. Je vais maintenant devoir migrer mes sites existants sur un réseau, apprendre à bien utiliser les réseaux multisite et surtout à les sauvegarder et restaurer si nécessaire…
Je prévois de faire les articles suivants pour compléter mon apprentissage des réseaux multisites WordPress :
- Tester l’ajout de sites dont les noms ne sont pas des sous-domaines du site principal (c’est fait, dans « Associer un nom de domaine à un site d’un réseau WordPress (multisite)« ).
- Transformer un site existant en un site multisite WordPress et y ajouter deux nouveaux sites (créés pour l’occasion) à partir d’un site « standard » (utilisation de l’extension Multisite Cloner) ;
- Explorer les possibilités de sauvegarde et restauration en multisite. J’envisage d’arrêter mon compte ManageWP : ManageWP est compatible avec WordPress multisite comme indiqué dans l’article « WordPress Multisite and ManageWP« , mais « cloning from / to a multisite installation is not supported!« . Peut-être que l’extension (premium) SNAPSHOT PRO de WPmudev le remplacera avantageusement. Voir aussi Moving WordPress Multisite, sur le codex WordPress
- migrer un site solo existant vers un multisite (et inversement)
Ces sujets feront l’objet de plusieurs articles pour cette série WordPress Multisite sur OVH mutualisé.
par Anne-Laure DELPECH | 10 Sep 2016 | Plugin (extension) WordPress
Dans les articles précédents de cette série (Un plugin WordPress avec page de réglage), nousavons construit les fondements d’une extension correcte, avec une page de réglages qui fonctionne correctement. Je veux maintenant modifier trois détails pour que cette extension serve plus facilement de base à d’autres extension :
- si un champs est de type « url » ou « email », il faudra qu’il y ait validation que les valeurs saisies sont bien soit des url soit des adresses mail ;
- Ajouter un champs de type « date » ;
- Les données à modifier pour adapter les bases de l’extension devraient être dans un fichier distinct, avec des commentaires pour faciliter l’adaptation par le développeur.
Nous allons réaliser toutes ces opérations, en commençant par la dernière.
De quoi partons-nous ?
A ce stade notre extension correspond au contenu de ce fichier zip : clea-add-button V0.2 (zip), telle qu’elle a été construite dans le précédent article de la série Un plugin WordPress avec page de réglage.
déplacer les données variables dans un autre fichier
Dans clea-add-button.php , ajouter les lignes suivantes :
// the sections and fields data for the settings page.
require_once CLEA_ADD_BUTTON_DIR_PATH . 'admin/clea-add-button-admin-settings.php';
On dit donc au script principal de notre extension qu’il devra utiliser le script contenu dans /admin/clea-add-button-admin-settings.php . Ce script contient deux fonctions qui retournent respectivement le contenu des arrays de définition des sections et des champs. J’y ai simplement copié les deux fonctions clea_add_button_settings_sections_val() et clea_add_button_settings_fields_val() qui étaient auparavant à la fin du fichier clea-add-button-settings-page.php .
Attention : le fichier doit être encodé en utf-8 avant d’y écrire des caractères accentués en français par exemple. Sinon les texte sont affichés avec des � à la place des caractères « spéciaux ».
Ajouter un champ de type date
Je me suis inspirée de cette question sur stackoverflow.
Dans clea-add-button-admin-settings.php , j’ai ajouté un cinquième champs dans la section 1, avec les éléments suivants :
array(
'field_id' => 'field-1-5',
'label' => __( 'Field 5 : date picker', 'clea-add-button' ),
'field_callbk' => 'clea_add_button_settings_field_callback',
'menu_slug' => 'my-plugin',
'section_name' => 'section-1',
'type' => 'date-picker',
'helper' => __( 'jj/mm/aaaa', 'clea-presentation' ),
'default' => '',
),
Maintenant dans clea-add-button-settings-page.php , il faut que je dise comment traiter les champs de type « date-picker ». Dans la fonction clea_add_button_settings_field_callback( $arguments ) , j’ajoute un cas « date-picker » :
case 'date-picker' :
printf( '<input type="date" id="%3$s" name="%2$s" value="%1$s" class="datepicker" />', sanitize_text_field( $value ), $name, $field, $arguments['default'] ) ;
break ;
A ma grande surprise, je n’ai même pas eu à ajouter quoi que ce soit d’autre. Je m’attendais pourtant à devoir charger jquery-ui-datepicker pour cette page et aussi à devoir créer une fonction…
Si on veut ajouter des options, on pourra s’inspirer des deux articles suivants :
Valider des champs de type « url » ou « email »
On peut avoir à demander une adresse mail ou le lien d’un site internet. Dans ce cas, la validation et la sanitation du contenu du champs ne se font pas de la même manière que pour un simple texte.
La validation des champs est réalisée lorsqu’on affiche les champs. Jusqu’à présent l’utilisateur n’était pas informé s’il entrait une valeur non valide. C’est pourtant indispensable. Nous allons utiliser la fonction
La sanitation et l’affichage sont faits dans clea-add-button-settings-page.php , par le biais de la fonction clea_add_button_settings_field_callback( $arguments ) .
Commençons par ajouter deux nouveaux champs, de type ‘url’ et ’email’ dans la section 1, définis dans clea-add-button-admin-settings.php :
array(
'field_id' => 'field-1-6',
'label' => __( 'Field 6 : email', 'clea-add-button' ),
'field_callbk' => 'clea_add_button_settings_field_callback',
'menu_slug' => 'my-plugin',
'section_name' => 'section-1',
'type' => 'email',
'helper' => __( 'aaaa@rrrr.ddd', 'clea-presentation' ),
'default' => '',
),
array(
'field_id' => 'field-1-7',
'label' => __( 'Field 7 : url', 'clea-add-button' ),
'field_callbk' => 'clea_add_button_settings_field_callback',
'menu_slug' => 'my-plugin',
'section_name' => 'section-1',
'type' => 'url',
'helper' => __( 'http:// ou https://', 'clea-presentation' ),
'default' => '',
),
Il faut maintenant que nous les validions, que les « nettoyons » (sanitation) et que nous les affichions en sécurité. Tout se fait dans une fonction que l’on appelle lors de l’étape « register_setting().
L’article qui m’a mis sur la bonne voie est « The WordPress Settings API« , de Konstantin Kovshenin.
Dans le fichier clea-add-button-settings-page.php , modifier la ligne qui réalise le « register_settings() » pour qu’elle appelle une nouvelle fonction :
register_setting( 'my-settings-group', 'my-plugin-settings', 'clea_add_button_sanitize_validate' ) ;
Et créer ensuite cette fonction :
function clea_add_button_settings_validate_and_sanitize( $input ) {
$output = (array) get_option( 'my-plugin-settings' );
// test the email in 'field-1-6'
if ( is_email( $input['field-1-6'] ) ) {
$output['field-1-6'] = $input['field-1-6'];
} else {
add_settings_error( 'my-plugin-settings', 'invalid-email', 'You have entered an invalid e-mail address.' );
}
// if ( $some_condition == $input['field_1_1'] )
return $output;
}
Cette fonction va vérifier que le contenu du champ ‘field-1-6’ est bien un email. Si ce n’est pas le cas, une erreur s’affichera.
Ensuite, pour afficher le champs email, dans la fonction clea_add_button_settings_field_callback( $arguments ) , on ajoute le cas « email » :
case 'email' :
printf( '<input type="text" id="%3$s" name="%2$s" value="%1$s" />', sanitize_email( $value ), $name, $field );
break ;
Noter que l’affichage se fait en utilisant sanitize_email().
Si je tape une adresse email invalide (par exemple « rgdfghhr »), un message « You have entered an invalid e-mail address. » s’affiche en haut de la page de réglages lorsque je clique sur « enregistrer les modifications ».
Ca fonctionne mais le gros inconvénient est qu’il faudra aller modifier cette fonction à chaque fois qu’on change le nom ou le type d’un champ. Par exemple, si je décide que le champ ‘field-1-6′ s’appellera ’email’, il faudra que j’aille changer le contenu de la fonction clea_add_button_settings_validate_and_sanitize.
Il faut donc que cette sanitation et validation se fasse sans se référer explicitement à un nom de champ. Pour celà, on va utiliser l’array de définition des champs, comme on a fait dans la fonction clea_add_button_admin_init().
function clea_add_button_settings_validate_and_sanitize( $input ) {
$output = (array) get_option( 'my-plugin-settings' );
$set_fields = clea_add_button_settings_fields_val() ;
$types = array() ;
// create an array with field names and field types
foreach ( $set_fields as $fields ) {
foreach( $fields as $field ){
$types[ $field['field_id'] ] = $field['type'] ;
}
}
// now validate and sanitize each field
foreach ( $types as $key => $type ) {
switch( $type ){
case 'wysiwig' :
$output[ $key ] = wp_kses_post( $input[ $key ] ) ;
break ;
case 'email' :
if ( is_email( $input[ $key ] ) ) {
$output[ $key ] = $input[ $key ];
} else {
$message = __( 'You have entered an invalid e-mail address in : ', 'clea-add-button' ) ;
$message .= $key ;
add_settings_error( 'my-plugin-settings', 'invalid-email', $message );
}
break ;
default :
$output[ $key ] = sanitize_text_field( $input[ $key ] ) ;
}
}
return $output;
}
Au départ, je crée un array avec tous les noms de champs et leurs type, tels que définis dans la fonction clea_add_button_settings_fields_val() . Ensuite, pour chaque élément de cet array, nous faisons une sanitation et une validation différente selon son type.
Mettre à jour le numéro de version et le readme
Dans le fichier clea-add-button.php , j’ai modifié @version 0.3.0 . L’extension est maintenant en version 0.3.
Dans le README.md, j’ai ajouté la version 0.3 dans le « changelog » :
== Changelog ==
= 0.3 =
* the definition of sections and fields to display on the settings page is now in /admin/clea-add-button-admin-settings.php
* 3 new types of fields may be processed : date-picker, email and url
* validation and sanitation of user inputs is done and the user gets a notice in case of a bad email
Cette version 0.3 est maintenant sur GitHub et téléchargeable (zip) : clea-add-button V0-3 (Zip).
L’extension de base finale, clea-plugin-boilerplate est passée en version 1 et disponible ici sur github. Elle est identique à clea-add-button sauf que les noms de fichiers, de fonctions et de variables ont été changés et qu’un fichier pot a été généré pour les traductions.
Et maintenant
Notre page de réglages fonctionne, quel que soit le type de champs que l’on souhaite afficher. Nous disposons maintenant d’une extension de base, correctement codée, que l’on peut utiliser comme base (boilerplate) n’importe quelle extension. C’est la fin de cette série, Un plugin WordPress avec page de réglage.
par Anne-Laure DELPECH | 9 Sep 2016 | site web
Les internautes, et les moteurs de recherche, attachent de plus en plus d’importance au petit cadenas vert qui indique qu’un site internet est sécurisé. Lorsque le site est sécurisé, les données bancaires, les données personnelles ou les mots de passe sont cryptés. Les données sont donc mieux protégées.
J’expérimente ici la création d’un site « https://potentiel-web.com » sur un hébergement Pro mutualisé d’OVH. Je vais utiliser un certificat gratuit « Let’s Encrypt », disponible depuis quelques mois sur OVH.
étape 0 : dans l’espace client OVH
Il faut que j’associe le domaine potentiel-web.com à un hébergement. Les éléments qui suivent sont décrits avec plus de détails dans l’article Hébergement Pro OVH avec plusieurs sites.
Dans l’hébergement cible, choisir l’onglet « multisite » et cliquer sur le bouton « Ajouter un domaine ou sous domaine ».
J’ajoute le domaine potentiel-web.com, déjà enregistré chez OVH et dans le second panneau de paramétrages, je choisis « créer également le sous domaine www.potentiel-web.com » et je coche l’option « SSL ». Dans le dernier panneau, je choisis « configuration automatique (recommandé) » et je valide.
Mon espace client affiche successivement « La modification du ou des domaines associé(s) à votre hébergement mutualisé est en cours … » puis « La modification du ou des domaines associé(s) à votre hébergement mutualisé a été effectuée avec succès. ».
Dans la liste des domaines de l’onglet multisites, je vois maintenant apparaître les deux sites (avec et sans www) :
Pour l’instant, je ne m’occupe pas du SSL en orange.
étape 1 : créer un site WordPress classique
Créer la base de données associée
dans l’espace client OVH, partie hébergement, je vais dans l’onglet « base de données » et je clique sur le bouton « créer une base de données ».
Pour le mot de passe, j’utilise le générateur de mot de passe de LastPass, en mode A-Z, a-z et 0-9. La base s’installe.
Une fois que j’ai reçu un mail m’informant de la création de la base, je peux continuer.
Installer le module WordPress
Toujours dans l’espace client OVH, partie hébergement, je vais dans l’onglet « modules en 1 clic » pour installer WordPress.
Je clique sur le bouton « ajouter un module ». Je choisis WordPress et potentiel-web.com comme domaine associé. Je clique sur « installer en mode avancé ».
Je reçois un mail d’OVH, avec le nom d’utilisateur et le mot de passe associé, lorsque le module est installé.
Accéder à WordPress
Je vérifie que j’accède au site http://potentiel-web.com et au tableau de bord WordPress (http://potentiel-web.com/wp-admin, avec le nom d’utilisateur et le mot de passe défini lors de l’installation du module).
J’en profite pour créer un autre utilisateur administrateur, dont le mot de passe n’aura pas été transmis par mail. Evidemment je supprime ensuite le précédent utilisateur.
étape 2 : gestion du certificat SSL
A ce stade, si je tape https://potentiel-web.com/ pour accéder à mon site, mon navigateur (chrome) m’affiche un message d’alerte.
Par contre, http://potentiel-web.com/ s’affiche correctement. C’est normal puisque je n’ai pas « généré de certificat SSL » lors de l’étape 0. Je ne l’ai pas fait car lorsque j’ai essayé, l’espace client d’OVH m’a affiché un message disant que si j’avais crée un nouveau site depuis moins de deux heures, le certificat ne fonctionnerait pas.
Dans mon espace client OVH, je clique sur l’hébergement de potentiel-web.com et j’accède à l’onglet « informations générales ».
Je clique sur « régénérer le certificat SSL ». Selon le guide OVH « Les certificats SSL sur les hébergements web« , il faut maintenant attendre le protocole HTTPS quelques heures, « le temps de le déployer sur l’ensemble de l’infrastructure ».
Nota : pour un site existant, à transformer en https, le processus est légèrement différent, et également décrit dans le guide OVH ci-dessus.
Quelques heures plus tard, le site https://potentiel-web.com/ s’affiche correctement :
Redirection du http vers le https
Maintenant que le site fonctionne en https, il faut que j’élimine toute possibilité d’accéder en http :
- pour éviter les problèmes de « duplicate contents » puisque les robots des moteurs de recherche considèrent les sites en http comme distincts des sites en https.
- pour éviter aussi qu’un internaute se retrouve sur la version non sécurisée.
Pour y arriver, j’ai trois choses à faire :
- régler le nom du site dans le tableau de bord WordPress ;
- Modifier wp-config.php pour interdire l’accès au tableau de bord hors https
- rediriger vers l’url en https avec .htaccess
Modifier le nom du site
Dans le tableau de bord WordPress, menu « Réglages » > « Général », régler « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » pour qu’elles démarrent avec https et pas http.
Modifier wp-config.php
Modifier wp-config.php en y ajoutant :
/* HTTPS only for admin access and login */
define( 'FORCE_SSL_ADMIN', true );
define('FORCE_SSL_LOGIN', true);
Modifier le .htaccess
Ajouter :
# direct everything to https
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R=301,L]
Il n’y a plus qu’à attendre un peu et ce sera bon ! Dans un navigateur, que l’on tape potentiel-web.com ou http://potentiel-web.com, on arrive dans tous les cas à https://potentiel-web.com.
Et maintenant ?
Je pense que la transformation d’un site existant doit être un peu différente, avec des problèmes spécifiques (cf le guide OVH, « Eviter les pièges du SSL avec mon site web« ). Il va donc falloir que je fasses des essais. Ce sera l’objet d’un autre article.
par Anne-Laure DELPECH | 2 Sep 2016 | Illustrations, photos et autres médias
Si, comme moi, vous souhaitez apprendre à mieux dessiner pour illustrer vos contenus, voici quelques pistes. (suite…)
par Anne-Laure DELPECH | 29 Août 2016 | Plugin (extension) WordPress
Nous allons améliorer la page de réglage de notre extension WordPress, en y ajoutant un champ de type « color picker » et en affichant les données complémentaires définies avec les champs. Dans les articles précédents de cette série (Un plugin WordPress avec page de réglage), nous avons progressivement construit l’extension et sa page de réglage. A la fin du précédent article, l’extension correspondait au contenu de ce fichier zip : clea-add-button avec éditeur wp_editor (zip).
Que voulons-nous faire ?
Notre page de réglages est capable d’afficher tous les types de champs sauf les choix de couleur. Nous voulons donc pouvoir choisir une couleur et même définir son opacité. Et pour simplifier la vie de l’administrateur du site, il faut qu’on lui dise quelles sont les couleurs utilisées par son thème, en les intégrant dans une palette sous le color picker.
Par ailleurs, notre page de réglages devra afficher les éléments complémentaires définis pour chaque champs, tels que « helper » qui contient un texte d’aide complémentaire.
Identifier les couleurs utilisées par le site
Les paramètres du thème courant sont stockés par WordPress et récupérables avec la fonction get_theme_mods(). Cette fonction nous donne un array contenant tous les paramètres, dont certains sont des couleurs.
Nous lisons donc l’array et pour chaque valeur, nous regardons s’il s’agit d’une couleur avec la fonction sanitize_hex_color_no_hash(). Cette fonction renvoie « NULL » si elle ne trouve pas un élément en hexadécimal à 3 ou 6 caractères. A chaque fois qu’elle trouve un élément non NULL, on le place dans l’array qui sera retourné pour former notre palette de couleurs.
/**********************************************************************
* find the colors used in the website's theme
**********************************************************************/
function clea_presentation_get_current_colors() {
// to get all the current theme data in an array
$mods = get_theme_mods();
$color = array() ;
foreach ( $mods as $key => $values ) {
if ( !is_array( $values ) ) {
if ( is_string( $values ) && trim( $values ) != '' ) {
$hex = sanitize_hex_color_no_hash( $values ) ;
if ( trim( $hex ) != '' ) {
$color[ $key ] = $hex ;
}
}
}
}
// remove duplicate colors
$current_colors = array_unique( $current_colors ) ;
return $color ;
}
Pour vérifier que c’est une bonne solution, , nous ajoutons le code suivant à la fonction clea_add_button_options_page() :
$colors = clea_add_button_get_current_colors() ;
echo "<hr /><p>Arguments</p><pre>";
print_r( $colors ) ;
echo "</pre><hr />";
Ce code va afficher l’array de couleurs en bas de la page d’options :
Array
(
[background_color] => ffffff
[color_palette_primary] => 4c858d
[color_palette_tertiary] => 423432
[color_palette_dark_font] => ed693b
)
Nous disposons donc des informations pour constituer notre palette par défaut.
Afficher des champs « color picker »
Nous allons utiliser le « Alpha Color Picker for WordPress » développé par Braad Martin. Pour comprendre comment l’intégrer, j’ai utilisé à la fois les explications de Braad Martin et Add an Alpha RGBa Color Picker to a WordPress Plugin Input Field.
Le code pour afficher le color picker
On ajoute le cas ‘color’ comme suit :
case 'color' :
// get the colors used by the theme
$current_colors = clea_presentation_get_current_colors() ;
$data_palette = "";
// the color palette must be a string with colors and | separator
// "#222|#444|#00CC22|rgba(72,168,42,0.4)" would be ok
foreach ( $current_colors as $color ) {
$data_palette .= $color . '|' ;
}
$data_palette = rtrim( $data_palette, '|' ) ;
// uses https://github.com/BraadMartin/components/tree/master/alpha-color-picker
printf( '<input type="text" class="alpha-color-picker" name="%2$s" value="%1$s" data-palette="%5$s" data-default-color="%4$s" data-show-opacity="true" />', sanitize_text_field( $value ), $name, $field, $arguments['default'], $data_palette ) ;
break ;
A ce stade, celà affiche un champs de type ‘text’ avec à l’intérieur la couleur par défaut définie dans le champs. Il nous faut maintenant ajouter la feuille de style et le programme javascript conçus par le créateur de l’Alpha color Picker et un petit script en JQuery.
Les compléments à intégrer dans notre extension
Dans le répertoire « /admin » du plugin, créer les sous-répertoires « /css » et « /js « .
Télécharger le fichier zip du dépôt « components » de Braad Martin ici sur un PC. Décompresser le fichier zip puis dans le sous-répertoire « alpha-color-picker » copier alpha-color-picker.css et alpha-color-picker.js respectivement dans les répertoires /admin/css et /admin/js de l’extension.
Les fichiers à créer
Nous devons créer deux fichiers :
- un fichier (clea-add-button-color-trigger.js par exemple) qui contiendra le JQuery nécessaire à l’affichage
- un fichier (clea-add-button-admin-enqueue.php par exemple) qui sera appelé par le fichier principal de l’extension et qui chargera la feuille de style et les scripts JavaScript nécessaires.
Le fichier /admin/js/clea-add-button-color-trigger.js contient :
// source https://github.com/BraadMartin/components/tree/master/alpha-color-picker
jQuery( document ).ready( function( $ ) {
$( 'input.alpha-color-picker' ).alphaColorPicker();
});
Quant au fichier /admin/js/clea-add-button-admin-enqueue.php , il contient
add_action( 'admin_enqueue_scripts', 'clea_add_button_admin_enqueue_scripts' );
function clea_add_button_admin_enqueue_scripts( $hook ) {
// to find the right name, go to the settings page and inspect it
// the name is somewhere in the <body class="">
// it will always begin with settings_page_
if( 'settings_page_my-plugin' != $hook ) {
// echo "not the right page, this is : " ;
// echo $hook ;
return;
}
// for the alpha color picker
// source : https://github.com/BraadMartin/components/tree/master/alpha-color-picker
wp_enqueue_style(
'alpha-color-picker',
CLEA_ADD_BUTTON_DIR_URL . '/admin/css/alpha-color-picker.css',
array( 'wp-color-picker' ) // You must include these here.
);
wp_enqueue_script(
'alpha-color-picker',
CLEA_ADD_BUTTON_DIR_URL . '/admin/js/alpha-color-picker.js',
array( 'jquery', 'wp-color-picker' ), // You must include these here.
null,
true
);
// This is the JS file that will contain the trigger script.
// Set alpha-color-picker as a dependency here.
wp_enqueue_script(
'clea-add-button-admin-color-js',
CLEA_ADD_BUTTON_DIR_URL . '/admin/js/clea-add-button-color-trigger.js',
array( 'alpha-color-picker' ),
null,
true
);
}
La condition if( ‘settings_page_my-plugin’ != $hook ) permet de ne pas charger le style et le JavaScript si on n’est pas sur la page d’options de notre extension.
Enfin, dans clea-add-button.php , nous ajoutons la ligne qui démarrera clea-add-button-admin-enqueue.php :
// load styles and scripts for the admin
require_once CLEA_ADD_BUTTON_DIR_PATH . 'admin/clea-add-button-admin-enqueue.php';
le résultat
Notre page d’option affiche maintenant la couleur par défaut sous une forme différente :
Le champ « color » affiche bien une couleur maintenant.
Si on clique sur la couleur, un « color picker » s’ouvre. Il affiche la couleur par défaut définie dans le champ 3. On observe qu’il y a une palette de couleur en dessous, qui correspond effectivement aux couleurs du thème sur lequel j’essaie cette extension. Et en dessous, on voit une barre qui permet de gérer la transparence de la couleur choisie.
Le champ « color » affiche un « color picker » complet.
Ici nous sélectionnons la couleur orange du thème et nous demandons à ce que sa transparence soit 71%.
Choix d’une couleur de la palette puis réglage de la transparence
Ca fonctionne parfaitement et la nouvelle couleur s’enregistre correctement.
Afficher les informations complémentaires
Chaque champ affiché dans notre page d’options est défini par un array :
array(
'field_id' => 'field-2-3',
'label' => __( 'Field three : color', 'clea-add-button' ),
'field_callbk' => 'clea_add_button_settings_field_callback',
'menu_slug' => 'my-plugin',
'section_name' => 'section-2',
'type' => 'color',
'helper' => __( 'help 2-3', 'clea-presentation' ),
'default' => 'rgba(0,0,0,0.85)'
)
Nous utilisons toutes les clés de cet array sauf deux (‘label’ et ‘helper’). Ces deux clés contiennent respectivement le texte à afficher systématiquement pour expliciter ce qu’il faut faire et un texte d’aide complémentaire.
Pour l’afficher, avant le champs à remplir, j’ajoute le code suivant dans la fonction clea_add_button_settings_field_callback( $arguments ) :
// If there is a help text and / or description
printf( '<span class="field_desc">' ) ;
if( isset( $arguments['helper'] ) && $helper = $arguments['helper'] ){
printf( '<img src="%1$s/images/question-mark.png" class="alignleft" id="helper" alt="help" title="%2$s" data-pin-nopin="true">',CLEA_ADD_BUTTON_DIR_URL, $helper ) ;
}
// If there is a description
if( isset( $arguments['label'] ) && $description = $arguments['label'] ){
printf( ' %s', $description ); // Show it
}
printf( '</span>' ) ;
La condition if( isset( $arguments[‘helper’] ) && $helper = $arguments[‘helper’] ) vérifie que $arguments[‘helper’] est défini ET qu’il n’est pas vide.
J’ai placé un fichier question-mark.png dans le répertoire /images de l’extension.
Le résultat n’est pas très joli :
Il faut donc que j’ajoute une feuille de style pour améliorer la page d’options.
Créer une feuille de style pour la page d’options
Dans le fichier /admin/js/clea-add-button-admin-enqueue.php , nous ajoutons une ligne pour charger la feuille de style de notre page de réglages :
// options page style
wp_enqueue_style(
'clea-add-button-admin-style',
CLEA_ADD_BUTTON_DIR_URL . '/admin/css/clea-add-button-admin.css'
);
et dans le fichier /admin/css/clea-add-button-admin.css
/**
* Settings page (admin)
*/
span.field_desc {
display: block;
font-style: italic;
margin-bottom: 5px;
}
img#helper {
margin-right: 5px;
}
Le résultat est lisible maintenant :
Et maintenant ?
A ce stade notre extension correspond au contenu de ce fichier zip : clea-add-button V0.2 (zip).
Notre page de réglages fonctionne. Il ne reste plus que quelques améliorations à apporter. Ce sera l’objet du prochain article de cette série, Un plugin WordPress avec page de réglage.
Commentaires récents