J’ai un nouveau serveur sur lequel je souhaitais passer en SSL pour mes domaines protégés. Comme Let’s Encrypt propose des certificats SSL gratuits et de qualité, je me suis tourné vers cette solution. Pour l’installation, c’est facile et vous trouverez plein de tutoriel sur ce sujet.

Let’s Encrypt propose de valider le nom de domaine en allant vérifier le répertoire .well-known dans votre racine web. Comme chaque certificat émis ne dure que 3 mois, il faut créer une tâche CRON qui va permettre de valider le domaine, émettre un nouveau certificat et l’installer.

Problème, si votre accès au domaine est protégé par un .htaccess couplé à un .htpasswd alors la validation n’a pas lieu correctement puisque l’accès et refusé. Voici une solution très simple. à laquelle j’aurais dû pensé plus tôt … Du fait de son fonctionnement même htaccess fonctionne répertoire par répertoire, il suffit donc d’aller créer un .htaccess dans le répertoire .well-known et y ajouter les instructions suivantes :

Satisfy Any
Order Allow,Deny
Allow from all

Vous pouvez maintenant tester et Let’s Encrypt aura bien accès au répertoire .well-know pour sa validation. Ainsi le certificat pourra être émis de nouveau sans problème.

J’espère que ça vous aidera.

Mon plugin WordPress pour créer un sitemap est Better WordPress Google XML Sitemaps. Mais le problème semble être le même avec Yoast SEO. Vous pourrez surement donc adapter la solution pour Yoast.

En configurant votre Nginx pour WordPress, vous devez avoir créé une ligne qui ressemble à ceci :

location / {
  # include the "?$args" part so non-default permalinks doesn't break when using query string
  try_files $uri $uri/ /index.php?$args;
}

Comme les plugins de WordPress n’écrive pas le fichier sitemap.xml en dure sur le serveur, il génère en dynamique (avec cache) le sitemap. Il faut donc diriger sitemap.xml vers la bonne URL qui va générer le sitemap. Voici pour ma part ce que j’ai utilisé dans mon fichier nginx.conf (dans la racine de mon site, mais vous pouvez le mettre dans votre fichier de config de nginx ou de vhost directement).

## Sitemap XML config
rewrite ^/sitemapindex\.xml$ /index.php?gxs_module=sitemapindex last;
rewrite ^/post\.xml$ /index.php?gxs_module=post last;
rewrite ^/page\.xml$ /index.php?gxs_module=page last;
rewrite ^/post_google_news\.xml$ /index.php?gxs_module=post_google_news last;
rewrite ^/taxonomy_category\.xml$ /index.php?gxs_module=taxonomy_category last;

ATTENTION : À ce stade, si vous souhaitez tester si ça fonctionne il faut REDÉMARRER NGINX

Soit faire la commande suivante :

sudo systemctl restart nginx

Voilà, votre sitemap a retrouvé ces couleurs et est prêt à servir google et autres répertoires …

Si vous avez des questions, n’hésitez pas.

Je vais donc vous présenter rapidement ce qu’il faut savoir pour commencer à utiliser VIM  et j’espère convaincre les débutants de le substituer à nano.

Fonctionnement et bases de l’éditeur VIM 

Premièrement il est important de savoir qu’il existe 2 modes, le mode édition (changer les texte) et le mode lecture (on parcours le fichier). 

Lorsqu’on ouvre un fichier avec VIM (vim monfichier.txt), on ouvre le fichier en mode lecture, si on veut éditer le fichier il faudra alors taper « i » (pour insert). Revenir en mode lecture se fera grâce à touche « ESC ». 

Lorsque vous êtes en mode édition, pour sauver le fichier il faut repasser en mode lecture (appuyer sur la touche ESC) et saisir « :w » et appuyer la touche « Entrer ». Le texte  « :w » s’affichera en bas de la fenêtre de votre terminal. Il est aussi possible de sortir du document au moment de sauver le fichier, saisissez alors « :wq ».

Il est aussi simple de sortir du document en saissant « :q ».

Résumé des commandes de bases de VIM

i = passer en mode edition
esc = Passer en mode lecture
:w = ecrire (en mode lecture)
:wq = ecrire et quitter le fichier (en mode lecture)

Conclusion : 

Comme vous pouvez le voir, VIM est au final très facile à utiliser et se révèle tellement plus pratique que nano. Si vous souhaitez gagner en productivité, je vous le conseil.

Réaliser cette migration se fait en 4 étapes faciles : 

Faire une copie de vos fichiers WordPress

Rien de plus simple, avec votre logiciel FTP, vous envoyez les fichiers sur votre serveur de production. (Généralement à la racine du serveur).

Faire un export de votre base de données

Allez dans PhpMyAdmin de votre serveur de développement et exportez la base de données. (SQL ou ZIP au choix). Allez ensuite sur PhpMyAdmin de votre serveur de production et importez les données via le fichier que vous venez de créer.

Modification sur la base de données 

La base de données WordPress contient dans certaines tables le nom de domaine de votre blog. Pour changer ces informations vous pouvez exécuter votre ces requête SQL suivante dans PphpMyAdmin : 

UPDATE wp_options
SET option_value = replace(option_value, 'http://www.dev-site.com', 'http://www.production-site.com')
WHERE option_name = 'home'
OR option_name = 'siteurl';

UPDATE wp_posts
SET guid = replace(guid, 'http://www.dev-site.com','http://www.production-site.com');

UPDATE wp_posts
SET post_content = replace(post_content, 'http://www.dev-site.com', 'http://www.production-site.com');

UPDATE wp_postmeta
SET meta_value = REPLACE (meta_value, 'http://www.ancien-site.com','http://www.nouveau-site.com');

Changez « http://www.dev-site.com » par l’url de votre environnement de développement et « http://www.production-site.com » par votre nom de domaine de production. Attention le préfixe des tables « wp_ » pourrait être différent pour vous. Attention aux « www » aussi. Si la première requête ne donne aucun résultat, essayez sans les www.

Modifier la config de WordPress

Dans votre logiciel FTP éditez le fichier wp_config.php et remplacez les informations de bases de données par celles de production :

/** Nom de la base de données de WordPress. */
define('DB_NAME', 'votre_nom_de_bdd');

/** Utilisateur de la base de données MySQL. */
define('DB_USER', 'votre_utilisateur_de_bdd');

/** Mot de passe de la base de données MySQL. */
define('DB_PASSWORD', 'votre_mdp_de_bdd');

/** Adresse de l'hébergement MySQL. */
define('DB_HOST', 'localhost');

Conclusion

J’ai crée cette procédure pour mes besoins personnels, j’espère qu’elle vous sera utile à vous aussi, c’est pour ça que je la partage ici. Pour une migration réussie pensez à :

• avoir au moins 1 heure devant (en cas de problème)
• être concentré (couper le téléphone et les distractions).
• Tester une fois la migration finie (toutes les pages, les posts si possibles, les formulaires …)

Pour se protéger, il existe 2 façons de faire : 

Faire un svn export de votre projet

C’est interessant car en faisant cela on enlève radicalement le problème puisqu’on supprime les .svn de chaque répertoire. Cependant, ce n’est pas forcément la meilleure solution car vous ne pourrez plus interagir avec votre serveur SVN, plus de « svn up » possible. Solution efficace donc, mais pas très pratique.

Faire un fichier .htaccess qui va bloqué l’accés aux .svn

L’autre solution est donc de mettre en place un fichier .htaccess à la racine de votre projet avec les lignes suivantes : 

RewriteEngine on
# Hide .SVN Folders
RewriteRule ^(.*/)*\.svn/ / [F,L]

Cette solution vous permet de garder les avantages du svn mais empêche l’accés au .svn. J’utilise personnellement cette 2ème solution.

Conclusion

Juste faites le ! C’est toujours mieux de prévenir que de guérir en sécurité.

Exemple :

subdomain1.domain.com affiche des données différentes de subdomain2.domain.com

Les 2 sous-domaines pointent vers le même répertoire (grâce à un vhost). Il m’a donc fallu trouver un moyen de faire un htaccess conditionnel en fonction de l’url saisie et plus précisément en fonction de la variable  HOST d’apache.

Voici le htaccess conditionnel en question :

#allows everything if its on a certain host
SetEnvIf HOST "^subdomain1.domain.com" subdomain1
Order Deny,Allow

AuthName "Restricted area"
AuthType Basic
AuthUserFile /path/to/your/file/.htpasswd
AuthGroupFile /
Require valid-user

#Allow everyone to enter with no passord but not for people coming from subdomain1
Deny from env=macdonald
Satisfy any

Pour la suite le mode opératoire est le même que dans le cas d’une protection par mot de passe par htaccess. Il suffit de créer un login et un mot de passe dans le fichier /path/to/your/file/.htpasswd.

Ressources

• Générer l’encryption du mot de passe pour le fichier .htpasswd