par Anne-Laure DELPECH | 21 Oct 2017 | arduino
Je veux depuis longtemps détecter le niveau de lumière dans mon garage pour déclencher automatiquement l’éclairage quand quelqu’un passe et qu’il fait trop sombre. Je me suis enfin décidée à réaliser un prototype. Je l’ai fait en deux temps : en simulation, en réel sur breadboard. Dans ce premier article de la série Arduino : détection de lumière et de mouvement, j’explique les étapes de simulation puis de montage en prototype. D’autres articles expliqueront comment communiquer les données à un serveur, et comment actionner une lampe à partir de ce montage.
Ce que je veux obtenir
Je veux un système qui, lorsqu’il détecte une présence exécute les actions suivantes :
- afficher « motion detected » sur l’écran LCD ;
- afficher la luminosité mesurée sur l’écran LCD ;
- émettre un son pour indiquer qu’une présence a été détectée ;
- allumer une LED rouge pour indiquer qu’une présence a été détectée.
Lorsqu’aucune présence n’est détectée, le montage ne fait rien d’autre que d’afficher « Waiting for motion ».
Un montage simulé sur ordinateur !
J’ai longtemps utilisé https://circuits.io/ pour simuler des montages avec Arduino. Mais maintenant il est intégré à Tinkercad (fonction circuits).
Processus d’expérimentation par simulation
J’ai procédé par itérations successives :
- placer un arduino et un détecteur de mouvement
- ajouter un écran LCD ;
- Ajouter une LED rouge ;
- Ajouter une cellule photoélectrique ;
- Ajouter un haut-parleur ;
- Faire défiler le texte d’attente pour économiser l’écran.
A chaque étape, je valide le code avec la fonction « start simulation » inclue dans Tinkercad.
Toutes ces étapes sont finalisées sur Tinkercad, dans le circuit « Arduino with PIR and light sensor, LCD display and speaker«
Le code
Le code complet est téléchargeable :
Dans le code, on notera simplement que :
- le détecteur de lumière répond par une valeur analogique de 0 à 1023 ;
- le détecteur de présence est soit HIGH, soit LOW.
- L’écran LCD est compatible avec le driver Hitachi HD44780 (comme la plupart des écrans avec 16 broches) et utilise la bibliothèque LiquidCrystal.h .
- On utilise lcd.print(photocellReading); et surtout pas lcd.write(photocellReading); pour afficher la valeur de résistance photoélectrique. La deuxième commande aurait affiché le caractère ASCII correspondant à la valeur de photorésistance (par exemple « a » si la photorésistance avait une valeur de 97).
Les composants
J’avais certains composants et j’ai commandé les autres. Je n’indique la source des composants que pour ceux que j’ai commandé récemment (octobre 2017).
La liste des composants
| Nom |
Quté |
Source / commentaire |
Prix |
| Arduino Uno R3 |
1 |
|
|
| Photorésistance |
1 |
Sur Amazon.fr ici |
5.90 € les 10 |
| Capteur de mouvement (PIR Sensor) |
1 |
Sur Amazon.fr ici |
7.99 € les 3 |
| écran LCD 16 x 2 |
1 |
Sur Amazon.fr ici. Attention, les broches ne sont pas fournies avec, il faut en souder. |
5.99 € les 2 |
| Résistance 1 kΩ |
1 |
marron / noir / noir / marron, pour l’écran LCD |
|
| Potentiomètre |
1 |
Remplacé plus tard par une résistance 1.5kΩ |
|
| Résistance 10 kΩ |
1 |
marron / rouge / noir / noir pour la photorésistance |
|
| LED rouge |
1 |
|
|
| Résistance 220 Ω |
1 |
rouge/rouge/marron, pour la LED rouge |
|
| Haut-parleur |
1 |
Je l’avais démonté d’un appareil usagé. |
|
Tous mes composants (ou presque) sont prêts :
Arduino, mouvement et luminosité : Les composants (manque led rouge)
Sur la photo, il manque la led rouge et le haut-parleur. On notera aussi que je me suis trompée pour la résistance de 10KΩ, qui ne faisait que 1kΩ en fait. J’ai corrigé dans le montage.
Choix de la résistance associée à la cellule photoélectrique
J’ai lu attentivement ce tutoriel d’Adafruit. Il explique en anglais comment choisir la valeur de la résistance « pull-down » selon l’environnement lumineux que l’on a. On choisira une valeur faible (1 KΩ) si on veut différencier des niveaux importants de lumière. On préférera une résistance de 10 KΩ si on veut différencier des ambiances sombres, ce qui est mon cas.
Choix de l’alimentation
L’Arduino peut être alimenté en USB en 5V mais il est préférable de l’alimenter en 7-12V par l’intermédiaire de la prise jack. Pour le prototype, j’ai utilisé une alimentation 12V (DC, attention à ne pas choisir une alimentation en courant alternatif) et 500 mA.
Passage à la phase prototype
Il nous faut monter en réel ce schéma (sur Tinkercad ici) :
Le schéma complet du montage Arduino + détecteur de mouvement + détecteur de luminosité + écran LCD + LED rouge + haut-parleur
Préparer le montage
Le schéma est assez complexe à réaliser. J’ai donc préparé trois éléments pour être certaine de ne pas me tromper et j’ai réalisé les cablages dans l’ordre de ces trois documents :
Elément 1 : câblage de l’arduino
| De |
A |
Couleur |
| 5V |
breadboard |
rouge |
| GND |
breadboard |
noir |
| A0 |
Photorésistance |
mauve |
| 2 |
RS LED |
marron |
| 3 |
E LED |
gris |
| 4 |
DB4 LED |
bleu clair |
| 5 |
DB5 LED |
violet |
| 6 |
DB6 LED |
vert |
| 7 |
DB7 LED |
orange |
| 8 |
PIR |
jaune |
| 11 |
LED |
bleu vif |
Elément 2 : câblage de l’écran LCD 16×2 :
| De |
A |
Couleur |
| GND |
breadboard |
noir |
| VCC |
breadboard |
rouge |
| V0 |
Potentiomètre |
orange |
| RS |
Arduino 2 |
marron |
| RW |
GND breadboard |
noir |
| E |
Arduino 3 |
gris |
| DB0 |
/ |
|
| DB1 |
/ |
|
| DB2 |
/ |
|
| DB3 |
/ |
|
| DB4 |
Arduino 4 |
bleu clair |
| DB5 |
Arduino 5 |
violet |
| DB6 |
Arduino 6 |
vert |
| DB7 |
Arduino 7 |
orange |
| LED |
5V breadboard |
rouge |
| LED |
Résistance 1 kohm |
noir |
Elément 3 : cablage du breadboard (plaque de prototypage) :
Arduino, mouvement et luminosité : préparation branchements
Le code
J’ai utilisé ce code Arduino, mouvement, luminosité, LCD et speaker : le code ARDUINO.
Vérifier le fonctionnement
Arduino, mouvement et luminosité : mouvement détecté, luminosité mesurée
Arduino, mouvement et luminosité : en attente de mouvement
Ca fonctionne comme je veux. Et l’affichage défile lorsqu’il est en attente.
Remplacement du potentiomètre
J’ai mesuré avec un ohmmètre la valeur de la résistance du potentiomètre correspondant à un affichage correct sur l’écran LCD (contraste permettant la lecture). J’ai obtenu 1.2 KΩ. J’ai enlevé le potentiomètre et mis une résistance de 1.5 KΩ (pas de 1.2 sous la main), qui fonctionne très bien. J’ai mis une borne de la résistance sur GND, supprimé le fil rouge pour le VCC du potentiomètre et mis l’autre borne de la résistance sur le fil orange qui va à V0 de l’écran LCD.
Le code qui inclut le potentiomètre n’a pas besoin d’être changé puisque le potentiomètre n’était pas lu par l’Arduino.
Et maintenant ?
Il va falloir que je place ce prototype dans un boitier et que je réalise les soudures pour rendre les branchements définitifs. Mais je veux aussi pouvoir envoyer les données mesurées à un serveur externe. Ces projets feront l’objet d’articles à venir, dans cette série Arduino : détection de lumière et de mouvement.
par Anne-Laure DELPECH | 12 Oct 2017 | développement web
J’explique ici la longue liste des actions à réaliser pour déplacer le contenu d’un site de tests (développement) vers le site de production. En écrivant celà, je conserve une trace de tout ce qu’il faut faire et vérifier avant de déclarer que le site a été modifié avec succès.
Ce tutoriel s’applique en totalité dans le cas suivant :
- Votre ancien site utilise WordPress et est hébergé sur Infomaniak et n’utilise pas l’un des thèmes Premium mis gratuitement à disposition par Infomaniak ;
- Votre nouveau site utilise WordPress et sera toujours hébergé sur Infomaniak et utilisera le thème Divi (ou sans doute un autre des thèmes Premium) ;
Si vous utilisez un thème que vous pouvez télécharger via votre tableau de bord WordPress, ou que vous pouvez installer en FTP, le changement sera un peu plus simple puisque vous n’aurez pas à gérer l’installation du thème par le serveur Infomaniak.
Le principe général
J’ai un site de développement, qui s’appelle test.exemple.com. Il est finalisé et je veux que ce soit le site qui sera disponible sur exemple.com. Exemple.com est mon site de « production », le site que les internautes voient. Je souhaite que le transfert génère le moins de perturbation possible.
Pour l’essentiel, c’est simple :
- importer les tables de la base de données de test (corriger le prefixe dans wp-config si nécessaire) dans la base de données du site à transformer ;
- Copier les fichiers contenus dans wp-content du site de test vers le site à transformer ;
- Eventuellement désactiver toutes les extensions puis les réactiver.
La difficulté c’est que le thème employé (DIVI) et certaines extensions (elegant theme (monarch, divi builder et bloom) sont fournies gratuitement par Infomaniak et doivent être installées à partir de l’interface Infomaniak pour que l’on dispose automatiquement des mises à jour ensuite. Si on les installe en FTP, la mise à jour automatique ne fonctionne pas.
La phase 1 : Préparation
Check list récapitulative : Phase 1 Préparation
| « Photos » de l’ancienne version du site |
|
| Exporter les réglages du thème Divi ou son thème enfant |
|
| Dans site test Désactiver le thème DIVI et toutes les extensions, ou au moins les extensions Elegant Theme (Divi builder, bloom et Monarch) |
|
| Dans site test, mettre en mode maintenance |
|
| Sauvegarder la base de données du site de test |
|
| Sauvegarder la base de données du site à modifier |
|
| Faire une copie de wp-config.php du site à modifier |
|
| Faire une copie de wp-config.php du site de test |
|
| Copier les fichiers de wp-content du site à modifier |
|
| Copier les fichiers de wp-content du site de test |
|
| Supprimer les répertoires Divi, divi builder, bloom et monarch de la copie du site de test |
|
Garder des traces de l’ancien site
On peut faire des « photos » des pages intéressantes du site qui va disparaître (exemple.com). J’ai utilisé les captures d’écran des outils de développement Chrome (article en anglais ici) .
Exporter les réglages du thème Divi
Si le site à transformer utilise le thème Divi, ou un thème enfant de Divi, il vaut mieux en exporter tous les réglages également, pour avoir une copie en cas de problème. Tout est expliqué dans cet article : Importer et exporter des paramètres et modèles du thème Divi pour WordPress.
Désactiver les extensions et changer de thème sur le site de test
Dans le tableau de bord WordPress du site test, désactiver le thème Divi et les 3 extensions Elegant Theme (monarch, divi builder et bloom). En effet, c’est Infomaniak qui gérera l’installation et l’activation de ces thèmes et sites.
Mettre le site test en mode maintenance
On devrait mettre le site de test en mode maintenance, de manière à ce que ce mode soit immédiatement appliqué dans le site à transformer. Pour ce faire, on peut se lire cet article, How To Put WordPress Site Into Maintenance Mode, ou utiliser l’extension « Maintenance Mode« , de Lukas Juhas.
Exporter une copie des bases de données
Sur le compte Infomaniak, les bases de données peuvent être exportées dans le menu bases de données d’infomaniak.
Pour les options, on choisit Gzippé, DROP Table et CREATE TABLE IF NOT EXIST
On exporte la base de données du site de test et la base de données du site à modifier.
Copier les fichiers de wp-content et wp-config.php
Avec le FTP en ligne d’infomaniak (en tous cas pour ceux qui ont des connexions lentes et ne veulent pas rapatrier les fichiers dans leur ordinateur), faire une copie des fichiers et répertoires suivants vers un répertoire ald-utils/site-date/ que j’ai mis à la racine de l’hébergement :
- wp-config.php
- fichiers de wp-content/plugins
- fichiers de wp-content/themes
- fichiers de wp-content/uploads
A faire pour le site à transformer au cas où.
A faire pour le site de tests. Pour celui-ci-, dans le répertoire de destination de la copie (je l’ai appelé ald-utils/test-exemple-2017-10-10/, j’ai supprimé les fichiers du thème Divi et des extensions Divi Builder, Bloom et Monarch. Je les réinstallerai via l’interface Infomaniak.
Phase 2 : transformer le site !
A partir de maintenant, toutes les actions concernent exclusivement le site cible.
Durant cette phase, le site de production entre en maintenance pour une durée de l’ordre de 10 à 15 minutes, plus si on veut faire les phases suivantes en maintenance aussi.
Check list récapitulative : Phase 2 transformation !
| Mettre le site à transformer en maintenance |
|
| Copier les fichiers (sauf extension de maintenance) |
|
| Modifier si nécessaire le préfixe de base de données du site à transformer |
|
| Importer la base de données de test dans la base de données cible |
|
| changer les adresses des liens dans cible avec Search-Replace-DB-master |
|
| vérifier que tout fonctionne |
|
| Désactiver les extensions du site |
|
| Dans le tableau de bord Infomaniak, vérifier les réglages |
|
| Installer Divi et les extensions Elegant Theme souhaitées |
|
| Activer les extensions |
|
| Régler le thème enfant de Divi (ou le thème Divi) |
|
Mettre le site à transformer en maintenance
mettre le site en maintenance, comme pour le site de test dans la phase de préparation.
Copier les nouveaux fichiers dans wp-content du site à transformer
copier les fichiers du site de test dans wp-content de la cible : répertoires plugins, themes et uploads. On supprime d’abord ceux qui sont présents (à l’exception de l’extension de maintenance) puis on fait la copie.
wp-config.php : Modifier si nécessaire le préfixe de base de données
Il faut que ce soit le préfixe de la nouvelle base que l’on va importer.
Importer la base de données de test dans la base de données cible
Importer la base de données de test dans la base de donnée de la cible.
changer les adresses des liens dans la cible avec Search-Replace-DB-master
On remplace https://test.exemple.com par https://exemple.com. Dans mon cas, 16 437 valeurs ont été changées !
On n’oublie pas de supprimer le répertoire dans lequel on a placé Search-Replace-DB-master.
vérifier que tout fonctionne
On vérifie pour :
- le mode maintenance si on n’est pas connecté en tant qu’administrateur
- le site si on est connecté en tant qu’administrateur
- le tableau de bord WordPress si on est connecté en tant qu’administrateur
ATTENTION AU CACHE DE CHROME…
pour une raison que j’ignore chrome redirige la cible vers test mais pour autant firefox affiche correctement, et via « voir le site » d’infomaniak ça fonctionne aussi… Dans chrome il faut taper https://exemple.com/?donotcachepage pour que ça fonctionne sans rediriger… aussi https://exemple.com/wp-login.php?donotcachepage
Désactiver les extensions du site
Dans le tableau de bord WordPress, désactiver toutes les extensions, sauf celle de maintenance
Dans le tableau de bord Infomaniak, vérifier les réglages
- vérifier les réglages de l’hébergement :
- version PHP 7.1
- max_execution_time à 300 secondes
- memory_limit à 640 Mo
- Compression des fichiers ON
- Module Google PageSpeed ON
Installer Divi et les extensions Elegant Theme souhaitées
- Dans « mon site WordPress » >> Paramètres, activer le thème DIVI (sans importer le contenu de démonstration du thème)
- installer (sans activer) Monarch et Bloom
L’extension Divi Builder est installée automatiquement lorsqu’on installe le thème Divi.
Activer les extensions
Nota : il vaut mieux ne pas activer WP Super Cache à ce stade.
Nota : le site doit avoir l’extension « Customizer Export/Import » de Beaver builder si on utilise un thème enfant de Divi.
Régler le thème enfant de Divi (ou le thème Divi)
Activer le cas échéant le thème enfant de Divi.
Importer les réglages de thème du site test (ils ont été exportés dans la phase 1 de préparation).
- fichier en .dat si thème enfant pour la personnalisation (via Export/import tout en bas du menu de personnalisation du thème enfant) ou fichier Json si thème Divi utilisé directement
- fichiers Json pour les options et la bibliothèque Divi
A ce stade, le site se présente exactement comme le site test initial. Il est cependant toujours en mode maintenance. On peut le remettre en production si on le souhaite.
| activer et vérifier le réglage de google analytics |
|
| saisir les redirections dans l’extension redirections |
|
| dans réglages / lecture : autoriser la lecture par les robots |
|
| réactiver yoast seo |
|
| Vérifier que les widgets se sont correctement transférés |
|
| Désactiver le mode maintenance |
|
| activer WP Super Cache |
|
Autres vérifications ou ajustements
L’extension Yoast SEO affichait qu’il y avait un problème de chargement de la page d’accueil. J’ai suivi les instructions de cette page d’aide Yoast et vérifié le site avec le test de sites pour mobiles de Google qui confirmait le problème. Ensuite, la page d’aide Yoast recommandait de faire « fetch the current status » dans le tableau de bord WordPress (fenêtre Yoast). Maintenant ça fonctionne correctement mais je n’ai pas du tout compris le problème…
Il y a eu une mise à jour du thème Divi et du Divi Builder dans les heures qui ont suivi la mise en ligne de la nouvelle version du site. Elle a fonctionné correctement. Mon protocole est donc bien adapté.
Et maintenant ?
Nous disposons maintenant d’une check-list précise de ce qu’il faut réaliser pour faire un changement important dans un site. Si vous avez des conseils à partager, vos commentaires seront bienvenus.
par Anne-Laure DELPECH | 12 Oct 2017 | astuces rapides, Plugin (extension) WordPress
Cécile, qui utilise un site mis à jour récemment avec un thème enfant pour Divi m’a envoyé la demande suivante : « Le divi builder ne peut pas prendre en compte mes sauts de paragraphes. Peux-tu me dire quel code html ajouter pour ne pas que tout mes textes se retrouvent à la suite des uns des autres sans mise en page STP ».
Je suis allée regarder de plus près et, effectivement, impossible de conserver les retours à la ligne lors de la publication des contenus qu’elle créait dans des « bascules » (toggle en anglais). J’ai essayé diverses solutions puis fait une recherche Google. Là je suis tombée sur l’article « Divi Text Module loses formatting« .
J’ai appliqué la solution : installer et activer l’extension TinyMCE Advanced d’Andrew Ozz.
Pour les réglages de Tiny MCE Advanced :
- Décocher « Activer le menu de l’éditeur » car je trouve l’éditeur actuel très bien ;
- Cocher « Conserver les balises de paragraphe » car c’est là que se trouve la solution au problème de la perte des retours à la ligne :
- Activer les améliorations pour tous les éditeurs :
Et voilà !
Si je crée des paragraphes séparés dans l’onglet visuel de l’éditeur d’un module Bascule de Divi :
Lorsque je regarde avec l’onglet texte, des balises <p> et </p> sont maintenant présentes !
Et l’affichage se fait maintenant comme je le souhaitais, même après publication de la page dans laquelle se trouvait ce module !
par Anne-Laure DELPECH | 12 Oct 2017 | développement web
Durant la vie d’un site web, on est amené à modifier des adresses (url) web et il faut aider les internautes (et les moteurs de recherche) à s’y retrouver. C’est pour cela que l’on a inventé les redirections 301 (permanentes) voire 302 (temporaires). Nous allons voir ici comment utiliser l’extension Redirection, de John Godley.
Cet article a été mis à jour le 10 novembre 2017.
Pourquoi faire des redirections ?
Les moteurs de recherche passent leur temps à indexer des contenus, des sites font des liens vers des contenus, des internautes copient et collent une adresse web… Si vous supprimez ou modifiez une url (d’un article, d’une page, d’une catégorie, …), tous ces liens archivés par des tiers vont aboutir à une page en « erreur 404 », un code HTTP qui indique que l’adresse recherchée n’existe pas.
Afin de simplifier la vie des internautes, mais aussi de conserver un bon référencement dans les moteurs de recherche, il faut indiquer quelle est l’adresse de remplacement de celle qui ne fonctionne plus. C’est ce qu’on appelle une redirection. Et elle peut être permanente (301), ou temporaire (302).
Comment faire des redirections ?
On peut les écrire directement dans le fichier .htaccess de notre site WordPress mais ça présente des inconvénients :
- il faut connaître la syntaxe précise, ce qui n’est pas toujours simple ;
- La lisibilité n’est pas très bonne et on risque des erreurs ;
- Mais surtout, si on déplace le site, on risque d’oublier de déplacer aussi les redirections dans le .htaccess créé dans le nouvel hébergement.
C’est à cause de la dernière raison que j’ai décidé d’utiliser une extension WordPress pour les redirections. Le gros avantage aussi est qu’un administrateur compétent, mais sans expérience de code, peut aussi définir des redirections.
Utiliser l’extension Redirection, de John Godley
L’extension Redirection a de très bons avis, est mise à jour régulièrement et est utilisée par des centaines de milliers de sites.
Je l’ai donc installée et activée sur un site récemment modifié lourdement.
La notion de module
L’extension peut utiliser 3 « modules » pour réaliser les redirections :
- module « WordPress », qui a l’avantage d’être simple (pas besoin d’un accès à .htaccess) mais sollicite plus les ressources du site ;
- module « Apache », qui est plus rapide. Mais attention, elle ne fonctionne pas toujours (voir plus bas) ;
- module « Nginx » – je n’ai pas cherché à l’utiliser, je ne crois pas que mon serveur utilise Nginx.
La page Redirection, du développeur de l’extension (en anglais) explique plus en détail ce que sont ces modules.
J’ai créé deux groupes de redirection (onglet Groups du menu « outils » >> « Redirections »), l’un, intitulé « redirections WP », est associé au module WordPress, l’autre, « Redirection Apache », est associé au module Apache.
Créer des redirection (quel que soit le groupe)
On peut utiliser un fichier CSV ou entrer chaque redirection à la main. Dans tous les cas, une syntaxe précise est à adopter.
La syntaxe à adopter
Imaginons que vous souhaitez rediriger https://mon-site/test-old vers https://mon-site/test-new .
Le problème, c’est que si l’internaute tape https://mon-site/test-old/ , avec un « / » final, la redirection ne se fera que si vous avez bien défini l’url source.
Il faudra écrire que la source est /test-old/? , avec « /? » à la fin et cocher la case « Regex » (Regular Expression). Cette expression dit qu’il faut rediriger qu’il y ait le / à la fin ou non.
Avec un fichier CSV
Pour créer les redirections, j’ai importé un fichier CSV (créé avec Libre Office Calc, car Microsoft Excel gère très mal l’encodage et les caractères de séparation des CSV). Ce fichier CSV contenait des éléments comme suit (elles fonctionnent mais évidemment je ne les ai créées que pour l’exemple) :
| source |
target |
regex |
type |
code |
match |
hits |
title |
| /test-old/? |
/test-new |
1 |
url |
301 |
url |
0 |
|
| /old-page/? |
https://autre-site.com/new-page |
1 |
url |
301 |
url |
0 |
|
J’ai défini le groupe pour l’ensemble des redirections du fichier CSV durant l’importation.
A la main
La deuxième redirection s’affiche comme ça si on la saisit à la main :
Régler une redirection 301 avec l’extension Redirection
Redirection avec le module WordPress
Ca fonctionne parfaitement. Toutes mes redirections utilisant le module WordPress se font à la perfection.
Redirection avec le module Apache
Dans le menu WordPress « outils » >> « Redirections », on voit un onglet « options ».
Il faut y définir le chemin vers le fichier .htaccess de l’hébergement. Pour le connaître, je suis allée regarder dans Réglages / WP Super Cache, onglet avancé et « Cache Location » est défini comme : /home/clients/2453337d17…073506d/site/wp-content/cache/
Donc dans Outils / redirection, onglet options, je définis Apache Module comme : /home/clients/2453337d17…073506d/site/.htaccess.
J’ai laissé sur « default server » car je préfère que ce soit Infomaniak qui gère l’absence ou la présence de www devant le nom de domaine.
J’ai ensuite créé des redirections exactement comme précédemment. Mon fichier .htaccess est effectivement modifié si je crée une redirection dans le groupe « Redirection Apache » entre /test/ et /cat/bla-bla :
<IfModule mod_rewrite.c>
RewriteRule ^test/$ /cat/bla-bla/ [R=301,L]
</IfModule>
Mais la redirection ne fonctionne pas. L’url monsite/test n’est pas dirigée vers monsite/cat/bla-bla….
J’ai cherché comment régler le module Apache, mais les onglets que je vois sont « Redirects | Groups | Log | 404s | Import/Export | Options | Support ». Je ne peux pas accéder à un onglet « Module » qui me permettrait de régler Apache…
J’ai déposé une demande d’aide sur le support de l’extension et j’ai reçu une réponse 2 jours après ma demande. Voici la solution, en attendant une mise à jour de l’extension.
J’utilise l’extension WP Super Cache pour accélerer mes sites. Elle écrit également des informations dans le fichier .htaccess.
John Godley, l’auteur de l’extension Redirection m’a proposé de corriger à la main le fichier .htaccess et d’y déplacer les éléments relatifs à la redirection avant les éléments liés à WP Super Cache.
Donc dans le fichier .htaccess, il faut déplacer les éléments
# Created by Redirection
CODE
# End of Redirection
avant les éléments
# BEGIN WPSuperCache
Code
# END WPSuperCache
Et maintenant ça fonctionne correctement !
Et maintenant ?
Les redirections fonctionnent correctement.
par Anne-Laure DELPECH | 8 Oct 2017 | développement web, Plugin (extension) WordPress
Le thème Divi est très bien, mais il lui manque quelques fonctionnalités pratiques. J’ai créé précédemment un thème enfant pour Divi afin de générer différemment les pages de catégorie. Mais pour ajouter d’autres fonctionnalités, il était préférable de créer une extension, afin de ne pas mélanger les choses. Je commente ici l’extension créée.
Ce que je voulais obtenir
- le style des méta-données de catégorie dans les pages de catégorie doivent être de la couleur des liens du site. Plutôt que de modifier à la main la feuille de style du thème enfant, je voulais trouver automatiquement la couleur définie dans Divi pour les liens et l’appliquer à ces méta-données par le biais d’un style défini en code (inline style).
- Lorsqu’on écrit un nouvel article, ou n’importe quel autre type de contenu, avec l’éditeur classique, on dispose d’un moyen de changer la couleur du texte. Mais les couleurs proposées ne sont pas celles du site. Je voulais donc trouver automatiquement la palette par défaut du site (définie dans les options Divi, onglet général) et utiliser cette palette comme couleurs possibles pour le texte.
- Je voulais aussi supprimer la possibilité d’insérer manuellement un titre H1 dans un contenu. Les titres H1 sont réservés aux titres de pages web et sont générés automatiquement par le thème. Il ne doit pas y avoir de deuxième titre H1 dans une page car ça « perturbe » les moteurs de recherche.
L’extension finie
L’extension (sur GitHub, ou la version 1.0 – zip – commentée ici, en téléchargement : Extension « Divi Add functions » (zip) ) peut être installée sur un site WordPress par le biais d’ajout d’extension. Il suffit ensuite de l’activer, il n’y a pas de réglage à réaliser.
Je suis partie d’une extension réalisée par Divi Space, ici sur GitHub et je l’ai modifiée de manière extensive.
Trouver la couleur appliquée aux liens
Dans le répertoire /wp-content/plugins/clea-divi-add-functions/includes , deux fichiers (cdaf-enqueues.php et cdaf-editor.php ) contiennent les lignes :
$accent_color = esc_html( et_get_option( 'accent_color', '#2ea3f2' ) );
$link_color = et_get_option( 'link_color', $accent_color );
$link_color prend la valeur définie dans le paramètre « COULEUR DU LIEN DU CORPS » de la personnalisation du thème Divi (ou du thème enfant), onglet « Paramètres Généraux » >> « Typographie ». Je ne suis pas certaine de ce à quoi correspond accent_color…
Définir un style en ligne (inline style)
C’est en regardant le code de l’extension réalisée par Divi Space, ici sur GitHub que j’ai compris comment on fait ça. Le fichier contient :
add_action( 'wp_enqueue_scripts', 'cdaf_divi_enqueue_scripts' );
function cdaf_divi_enqueue_scripts() {
if ( wp_basename( get_bloginfo( 'template_directory' ) ) == 'Divi' ) {
wp_enqueue_style( 'cdaf-stylesheet', CDAF_DIR_URL . 'css/clea-divi-add-functions.css' );
$accent_color = esc_html( et_get_option( 'accent_color', '#2ea3f2' ) );
$link_color = et_get_option( 'link_color', $accent_color );
// there must be an extra } at the end of the custom_css string...
$custom_css = "#left-area .post-meta a[rel='category tag'] {color: {$link_color};}}";
wp_add_inline_style( 'cdaf-stylesheet', $custom_css );
}
}
La fonction exécute les instructions suivantes :
- si (et seulement si) le thème Divi (ou un thème enfant de Divi) est utilisé, alors :
- charge la feuille de style css/clea-divi-add-functions.css (qui ne contient rien actuellement) – cette instruction ne sert à rien en l’état actuel de l’extension.
- Trouve quel est le code de la couleur définie pour les liens
- ajoute un style « inline » qui contient le texte défini dans la variable $custom_css . Il faut bien noter qu’il y a deux } à la fin de ce texte.
Et maintenant, si je regarde dans le <head> d’une page du site (par exemple https://parcours-performance.com), je trouve :
<link rel='stylesheet' id='cdaf-stylesheet-css' href='https://parcours-performance.com/wp-content/plugins/clea-divi-add-functions/css/clea-divi-add-functions.css?ver=4.8.2' type='text/css' media='all'/>
<style id='cdaf-stylesheet-inline-css' type='text/css'>
#left-area .post-meta a[rel='category tag'] {color: #843bbb;}}
</style>
La feuille de style est chargée, et un style « inline » est défini pour #left-area .post-meta a[rel=’category tag’].
Trouver la palette de couleurs définie par l’utilisateur de Divi
Le fichier cdaf-utilities.php contient la fonction suivante :
function cdaf_read_color_palette() {
$cdaf_color_palette = et_get_option( 'divi_color_palette', false ) ;
$return = explode("|", $cdaf_color_palette);
return $return ;
}
Cette fonction va chercher la valeur de ‘divi_color_palette’ et me renvoie une chaîne de caractères (string) avec les codes couleurs séparés par |. Avec explode, je place dans $return un tableau (array) contenant les codes hexadécimaux des couleurs.
Modifier les couleurs proposées dans l’éditeur WordPress
A l’origine l’éditeur WordPress par défaut propose un ensemble de couleurs, plus des cases « personnalisées » que l’on ne peut pas modifier.
Le fichier cdaf-editor.php contient le code correspondant à cette fonctionnalité. Dedans, deux fonctions assurent la modification des couleurs proposées par l’éditeur WordPress.
- La fonction cdaf_editor_colors( $init ) assure le passage de l’état initial (image 1) à l’état 2 (image 2) dans lequel les couleurs par défaut sont remplacées par les couleurs du site.
- La fonction cdaf_tiny_mce_remove_custom_colors( $plugins ) s’occupe d’enlever les cases blanches « personnalisée » qui ne fonctionnent pas. Je l’ai trouvée sur StackExchange. Je n’ai pas cherché à comprendre comment elle marche.
Intéressons nous à la fonction cdaf_editor_colors( $init ) , que j’ai eu bien du mal à créer, même si je suis partie d’une solution initiale qui fonctionnait (disponible ici). Elle contient les éléments suivants (que j’ai divisé en quatre parties) :
function cdaf_editor_colors($init) {
/*********** PARTIE 1 **************************
***********************************************/
$cdaf_colors = cdaf_read_color_palette() ; // an array of hex codes beginning with #
$index = 0 ;
$default_colors = array();
// what is the link color for text ?
$accent_color = esc_html( et_get_option( 'accent_color', '#2ea3f2' ) );
$link_color = et_get_option( 'link_color', $accent_color );
// remove # in color code
$link_color = ltrim( $link_color, "#" ) ;
// met en majuscule le code HEX
$link_color = strtoupper( $link_color );
/*********** PARTIE 2 **************************
***********************************************/
// transformer en array avec code hex sans # et nom sous forme "color n"
foreach ( $cdaf_colors as $color ) {
// remove # in color code
$color = ltrim( $color, "#" ) ;
// met en majuscule le code HEX
$color = strtoupper( $color );
if ( !( $link_color == $color ) ) {
// the text color palette should not include the link color
$default_colors[] = array( $color, 'color ' . $index ) ;
$index++ ;
}
}
// the only way I found to have a string which works....
// the string shoulr be like this : '"423432","color 0","FFFFFF","color 1","4C858D","color 2","ED693B","color 3","F28A2B","color 4","FAC079","color 5","F6DB6B","color 6","A60F65","color 7"'
$custom_colours = wp_json_encode( $default_colors ) ;
$replace = array( "[", "]") ; // we don't want these in the final string
$custom_colours = str_replace($replace, "", $custom_colours );
/*********** PARTIE 3 **************************
***********************************************/
// build colour grid default+custom colors
$init['textcolor_map'] = '['.$custom_colours.']';
// change the number of rows in the grid if the number of colors changes
// 8 swatches per row
$init['textcolor_rows'] = 1;
// debug will echo in the footer of the editor !
//echo "<p>" . $custom_colours . "</p>" ;
return $init;
}
/*********** PARTIE 4 **************************
***********************************************/
add_filter('tiny_mce_before_init', 'cdaf_editor_colors');
Partie 1 : Définir les variables qui vont nous intéresser
Ces variables sont la palette par défaut (celle que l’administrateur a défini dans les options Divi) ainsi que la couleur des liens définie dans la personnalisation du thème. Avec la palette par défaut, j’ai la liste des codes couleur que je voudrais intégrer dans l’éditeur WordPress. Mais on ne veut pas que la couleur des liens soit accessible à un auteur de contenu. L’internaute ne comprendrait pas que certains textes d’une couleur soient cliquables quand d’autres ne le sont pas. Il faut donc que je sache quelle est cette couleur de lien.
J’obtiens deux variables qui contiennent les données définies par l’administrateur du site :
- $link_color , qui contient un code à 6 chiffres ou lettres A à F en majuscules. Le # du code a été enlevé.
- $default_colors , un tableau (array) tel que défini précédemment.
Partie 2 : transformer l’array de couleurs
Je dois obtenir une chaîne de caractère au format suivant :
'"423432","color 0","FFFFFF","color 1","4C858D","color 2","ED693B","color 3","F28A2B","color 4","FAC079","color 5","F6DB6B","color 6","A60F65","color 7"'
Je pars d’un tableau (array) qui contient simplement les codes Hexadécimaux des couleurs sous la forme #AABBCC. Pour aboutir à la chaîne de caractère ci-dessus, il faut :
- lire chaque élément du tableau (array), avec foreach ( $cdaf_colors as $color )
- pour chaque valeur ($color) :
- enlèver le # devant (ltrim( $color, « # » ) ) et le mettre en majuscule (strtoupper( $color ) ) ;
- si elle est égale à la couleur utilisée pour les liens je ne l’utilise pas ;
- sinon, je la place dans un nouveau tableau, sous la forme (code Hex, nom couleur).
A la sortie de cette boucle, $default_colors contient toutes les couleurs à utiliser, avec leur nom (sous la forme « couleur n »). Mais ce n’est toujours pas une chaîne de caractères…
J’ai passé beaucoup, beaucoup de temps à bloquer là dessus. Tout le monde saisit à la main les couleurs à intégrer dans l’éditeur, sans profiter de l’automatisation possible. Mais j’ai trouvé !!!
- avec wp_json_encode( $default_colors ) , on transforme le tableau (array) en une chaîne de caractères ;
- avec str_replace($replace, « », $custom_colours ) , on enlève tous les caractères dont on ne veut pas, définis dans $replace = array( « [« , « ] ») .
Partie 3 indiquer à l’éditeur les nouvelles couleurs de texte
Là je me suis bornée à recopier ce qui était écrit dans le code proposé sur StackExchange.
La seule difficulté (importante) était de fournir une chaîne de caractères au bon format.
Partie 4 dire à WordPress de charger la fonction
Avec add_filter(‘tiny_mce_before_init’, ‘cdaf_editor_colors’); , on dit qu’au moment où l’éditeur s’ouvre, il doit exécuter la fonction cdaf_editor_colors.
A ce stade, lorsqu’on utilise l’éditeur, il nous propose les couleurs définies dans les options de Divi, moins celle qui est dédiée aux liens :
Je n’aime pas du tout les carrés « personnalisée » en dessous. Je n’y faisais pas attention avant, mais là, ça me gène. Alors j’ai ajouté une autre fonction, trouvée dans une autre discussion sur StackExchange :
add_filter( 'tiny_mce_plugins', 'cdaf_tiny_mce_remove_custom_colors' );
function cdaf_tiny_mce_remove_custom_colors( $plugins ) {
foreach ( $plugins as $key => $plugin_name ) {
if ( 'colorpicker' === $plugin_name ) {
unset( $plugins[ $key ] );
return $plugins;
}
}
return $plugins;
}
Et maintenant, les choix de couleur de texte sont présentés de manière « propre » !
Supprimer les titres H1 des styles proposés par l’éditeur WordPress
Je me suis bornée à reprendre le code proposé dans ce gist, sur GitHub.
function cdaf_remove_h1_from_editor( $settings ) {
$settings['block_formats'] = 'Paragraph=p;Heading 2=h2;Heading 3=h3;Heading 4=h4;Heading 5=h5;Heading 6=h6;Preformatted=pre;';
return $settings;
}
add_filter('tiny_mce_before_init', 'cdaf_remove_h1_from_editor');
Avant, l’éditeur proposait aux auteurs des style Titre 1, maintenant il n’est plus possible de commettre l’erreur de donner un tel style à du texte.
Et maintenant ?
Si vous voulez télécharger l’extension complète : Extension « Divi Add functions » (zip). Je la ferai certainement évoluer ultérieurement. Mais pour l’instant elle répond à mes besoins.
Commentaires récents