Ajouter une favicon à un blog WordPress

Je voulais ajouter une favicon à mon blog WordPress pour rendre le stockage en favoris plus attractif que les icônes de base des différents navigateurs.

Je connaissais la manière classique d’ajouter une favicon en mettant dans le <head> d’un page la ligne :

<link rel="icon" type="<MIME_DE_LA_FAVICON>" href="<ADRESSE_DE_LA_FAVICON>" />

J’aurais ainsi pu appliquer cette méthode en modifiant le fichier header.php et en ajoutant cette ligne mais je me suis dis : « Je suis sous WordPress, il existe des plugins pour tout, choisissons en un qui va bien ». J’ai donc choisi le plugin All in one Favicon.

Ce plugin permet beaucoup plus de configuration qu’en ligne par ligne et simplifie réellement la mise en place d’une favicon. Me voilà à présent avec un magnifique logo !

Déplacer un WordPress sur un autre serveur

L’autre jour, j’ai essayer d’aider un copain (http://www.lebuffetplaylist.fr/) à s’occuper de son WordPress qui avait été installé en un clic avec l’option application de 1&1. Cette option s’avère être un vrai calvaire pour toutes les opérations de maintenance pour plusieurs raisons.

La première est que les droits accordés à l’application ne permettent pas d’ajouter ou de modifier quoi que ce soit à la main. Toutes les opérations ne peuvent être faites que depuis WordPress. De plus les permaliens ne peuvent pas fonctionner puisque sur 1&1, le module pour l’url rewriting ne s’active qu’en modifiant le .htaccess.

La deuxième est l’impossibilité d’accéder à la base de données créée pour l’occasion. On ne peut même pas la dumper sans passer par un plugin WordPress.

Après avoir cherché des solutions pendant un bon moment, et vu la faible marge de manœuvre qu’autorise l’application pré installée 1&1, nous avons finis par faire une exportation depuis l’onglet « Outils« , copier le thème directement dans le dossier wp-content/themes/ et noté pour réinstallation le nom des plugins qui l’intéressaient. Ceci  a aussi permis de faire du trie vu la quantité prodigieuse de plugins qui s’entremêlaient. Il fallut cependant refaire quelques configurations comme l’agencement de certains modules/liens.

Cette solution était un peu particulière vu la nature du problème mais il existe un plugin incroyablement efficace et qui a l’avantage d’être simple à utiliser.

L’offre iKoula que je possède actuellement n’ayant qu’une durée d’un an, je me retrouverais avec cette nécessité de transfert donc j’ai préféré prendre les devant. En plus de me fournir un transfert immédiat le jour où j’en aurais besoin, le plugin que j’ai choisis me permet de faire des sauvegardes régulières pour le cas où un problème survienne.

Le plugin que j’ai choisis est WordPress Move. Il suffit de recréer une installation basique standard sur le nouvel emplacement et d’y installer le plugin pour faire le transfert et réinstaller plugins/thèmes/posts/commentaires comme si ils avaient étés fait sur ce nouveau serveur et pas sur l’ancien. Redoutable !

Installation d’un serveur web sous Debian

J’avais lors d’un précédent post, expliqué comment installer WordPress sur son serveur Web mais je n’avais pas expliqué comment installer ce serveur.

On partira donc du principe que l’on a besoin de mettre en place un serveur HTTP, un interpréteur PHP, un SGBD (Système de Gestion de Base de Données) et un serveur FTP. De plus pour le contrôler facilement à distance on utilisera le protocole SSH.

Tout d’abord le choix de la distribution. Ayant toujours utilisé des distributions basées sur Debian et Debian étant réputé pour sa stabilité, il m’a semblé évident de prendre cette distribution comme base. De plus les installations sont facilitées grâce à des dépôts bien remplis (pas toujours à jour, mais fournis).

Ainsi, après une installation standard de cette distribution, enfin, en tout cas sans gestionnaire de fenêtre vu que c’est pour un serveur, nous allons passer à la phase d’installation.

Les logiciels que j’ai choisis d’utiliser pour combler tous nos besoins sont :

  • Serveur HTTP : Apache
  • Serveur FTP : vsFTPd
  • Serveur SSH : openSSH
  • interpréteur PHP : PHP5
  • SGBD : MySQL

Nous allons commencer par installer openSSH afin de pouvoir administrer le serveur à distance par la suite à l’aide de la commande :

apt-get install ssh

Nous verrons les configurations à apporter à chaque logiciel par la suite. Installons maintenant le serveur Apache à l’aide de la commande :

apt-get install apache2

Puis PHP et son module pour apache en tapant :

apt-get install php5 libapache2-mod-php5

Pour MySQL, Debian se charge normalement tout seul de récupérer les paquets qui permettent les interactions avec PHP. Dans le cas contraire il faudra les rajouter en plus (paquet php5-mysql). On tapera donc :

apt-get install mysql-server

Un mot de passe root est demandé à ce moment là. Bien penser à en mettre un fort.

Nous allons enfin installer vsFTPd en tapant :

apt-get install vsftpd

Maintenant que tous les logiciels dont nous avons besoin sont installés, il va nous falloir les configurer. Toujours garder en tête cependant que les configurations sont la partie la plus personnelle de ce genre de mise en place car elles dépendent principalement de ce que l’on désire faire. Je ne détaillerais pas les configurations d’SSH car j’ai déjà mis un exemple détaillé dans ce post ci.

Commençons donc avec la configuration d’Apache. Un fichier de configuration extrêmement important est le fichier /etc/apache2/conf.d/security. C’est ce fichier qui déterminera le niveau de détail des messages d’erreur. Pour un serveur en production, afin d’éviter toute fuite d’information sensible en cas de faille, on mettra les lignes :

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Pour un serveur de développement, le but étant d’obtenir un maximum d’informations, on mettra :

ServerTokens Full
ServerSignature On
TraceEnable Extended

La configuration de base d’Apache donne le dossier /var/www/ comme dossier du site principal. On peut héberger plusieurs sites sur un seul serveur en rajoutant des fichiers de configuration dans le dossier /etc/apache2/sites-available/ (De manière globale, tout fichier présent dans ce dossier est inclus dans le fichier de configuration au lancement d’Apache). Une configuration minimale de site possible est :

<VirtualHost <ADRESSE_DU_SERVEUR>:<PORT_DE_CONNEXION>>
ServerName <NOM_DU_SERVEUR>
ServerAdmin <ADRESSE_DU_WEBMASTER>

DocumentRoot <DOSSIER_DU_SITE>
<Directory <DOSSIER_DU_SITE>>
Options -Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

CustomLog <URI_DU_FICHIER_DE_LOG> combined
LogLevel warn
</VirtualHost>

Pour plus de détail on peut aller sur la documentation officielle d’Apache sans oublier les conseils sur la sécurité. On pourra, selon la distinction que l’on voudra faire entre les différents sites web (différentes adresses IP, différents ports de connexion), utiliser cette page de documentation ou celle ci pour choisir ses options.
Vous remarquerez le -Indexes qui permet de ne pas lister le contenu d’un dossier lorsque le fichier index.html ou index.php n’existe pas. Pour d’autres options de sécurités on peut aller voir par là.

Il ne reste alors plus qu’à activer le site nouvellement configuré à l’aide de la commande

a2ensite <NOM_DU_FICHIER_DE_CONFIGURATION>

et à redémarrer apache (nous ferons ceci à la fin).

En ce qui concerne PHP, je ne rentrerais pas dans les détails de la configuration car ils sont beaucoup trop dépendants de ce que l’on souhaite mettre en place. De plus, ceux de base conviendront la plupart du temps.

La configuration de MySQL étant plus une configuration par base de données que dans sa globalité, les paramètres originaux feront largement l’affaire. Cependant, il ne faudra pas oublier de créer un nouvel utilisateur pour chaque base afin d’améliorer la sécurité et de ne pas laisser traîner le mot de passe root quelque part. J’avais détaillé le script de création dans mon post sur la mise en place de mon blog.

Il nous reste enfin à configurer vsFTPd. Mon choix s’est porté sur ce logiciel plutôt que sur ProFTP, qui est le plus souvent cité lorsque l’on cherche un serveur FTP, car, notamment, il a été conçu en étant orienté sécurité. Le fichier de configuration est /etc/vsftpd.conf. Il est bien détaillé et facile à paramétrer. On peut choisir de chrooter les utilisateurs, utiliser le serveur en IPv4/IPv6, autoriser l’accès anonyme, etc … J’ai détaillé une des configuration que j’utilise sur l’un de mes serveurs dans ce post.

Il suffit ensuite soit de redémarrer la machine (le plus simple), soit de redémarrer tous les services, après configuration. On peut les relancer un par un à l’aide des commandes :

/etc/init.d/apache restart
/etc/init.d/ssh restart
/etc/init.d/vsftpd restart

On a alors un serveur HTTP/FTP/MySQL/SSH prêt à être utilisé.

Plugin de statistiques identique à celui de WordPress.com

J’avais mis en place il y a un certain temps le script pour avoir mes statistiques de Google Analytics sur mon Blog. Cependant, j’aimais bien les statistiques disponibles sur la plateforme de blog WordPress.

Google Analytics faisait parfaitement l’affaire mais l’option « statistiques » disponible sur l’application WordPress sur Android ne fonctionne qu’avec le plugin Jetpack. Pour le faire fonctionner, il faut obligatoirement un compte sur le site http://www.wordpress.com/

La mise en place du plugin est rapide, les configurations sont nombreuses et faciles et l’affichage des statistiques est agréable. Jetpack fait parfaitement ce pour quoi il est fait.

Inclure du code dans des articles WordPress

Il m’arrive de temps en temps d’illustrer certains articles avec des portions de code. Cependant, sur WordPress, la disposition du texte casse toutes les indentations et, de plus, aucune coloration syntaxique n’est possible automatiquement de base.

J’ai ainsi testé quelques plugins dont WP-syntax avec WP-syntax Button pour simplifier l’insertion mais ils ne m’ont pas convenus car ils ne sont pas assez paramétrables ou efficaces.

Mon choix a fini par se porter sur WP SyntaxHighlighter qui correspond parfaitement à mes critères, embarque déjà le bouton d’importation rendant l’édition facile et qui est presque entièrement configurable.

Mise en place de Google Analytics

J’aimais bien les statistiques de connexion disponibles sur les blogs hébergés WordPress. J’ai donc cherché à avoir quelque chose de semblable sur mon blog. Pour ce faire, j’ai donc ouvert un compte Google Analytics.

Pour fonctionner, il est nécessaire de copier un bout de code donné par Google sur toutes les pages du site que l’on souhaite observer.

J’ai tout d’abord testé un plugin nommé Google Analytics for WordPress. Après l’avoir un peu tourné dans tous les sens j’ai trouvé que c’était une usine à gaz étant donné que je ne compte pas configurer quoi que ce soit pour l’instant.

J’ai donc décidé de copier à la main le code dans la page header.php. Comme son nom l’indique, elle est insérée en haut de toutes les pages du blog. Une remarque cependant : utilisant le thème WordPress de base, cette page est présente mais tous les thèmes ne l’intègre pas.

Des plugins comme le All in One SEO Pack prennent directement en charge le code à ajouter aux pages et nous évite d’avoir à le faire manuellement. Un espace est prévu pour entrer le tracking ID correspondant.

La dernière configuration que j’ai appliquée à Google Analytics a été de filtrer mon adresse IP afin de ne pas prendre en compte mes visites sur mon blog comme élément de trafic. Pour ce faire, dans les paramètres de compte correspondant à mon profil sur Google Analytics, cliquer sur Admin, puis Filters, New Filter, donner un nom au filtre et choisir exclude, traffic from the IP addresses, that are equal to, puis rentrer l’adresse IP correspondante.

Revision Control, un plugin pratique pour WordPress

Après avoir rédigé quelques articles, je me suis rendu compte d’une option de base de WordPress que je n’ai pas trouvé très pratique. En effet, il conserve de base toutes les révisions d’un même article. La moindre correction orthographique suivie d’un update résultait en l’ajout d’une entrée dans la BDD contenant le nouveau texte de l’article.

Autant cette option peut être intéressante en cas de travail collaboratif, autant lorsque je suis le seul à rédiger des articles et en plus qu’ils sont destinés à n’être relus que par moi, je trouve ça un peu invasif.

J’ai vu qu’il existait plusieurs solutions dont l’ajout dans wp-config.php de la constante :

define('WP_POST_REVISIONS', false);

Le « false » peut être remplacer par un nombre entier qui représentera le nombre de révision que WordPress devra conserver.

Une autre solution, celle que j’ai adoptée, est l’utilisation du plugin Revision Control. Il permet de configurer en 2 clics le nombre de révision de chaque type de page que l’on souhaite conserver.

Si des révisions avaient déjà eu le temps de se mettre en place, on peut les supprimer soit à l’aide du plugin Revision Delete, solution que j’ai choisi, ou alors en tapant directement dans une console MySql :

DELETE FROM wp_posts WHERE post_type = ‘revision’;

Configuration et mise en place de WordPress

Voici un petit article uniquement consacré à WordPress puisque j’ai décidé de l’héberger moi même désormais.

Après pas mal de temps à chercher quels étaient les droits à donner aux différents dossiers pour que WordPress cesse de m’afficher des erreurs de permissions dès qu’il essaye de faire quelque chose, je me suis rendu compte qu’il suffisait d’attribuer www-data comme utilisateur et groupe pour que tout fonctionne. En réalité, j’ai fait un wget pour récupérer la dernière version directement sur le serveur et je l’ai décompressée (tar -xzf latest.tar.gz). Il s’est chargé de conserver les droits.

En ce qui concerne la base de donnée MySql, je voulais créer un utilisateur de blog qui aurait la possibilité de gérer toute la base sans pouvoir toucher aux autres.
J’ai donc fait :

CREATE DATABASE <NOM_DE_LA_BASE>;
GRANT ALL PRIVILEGES ON `<NOM_DE_LA_BASE>`.* TO '<LOGIN>'@'localhost' IDENTIFIED BY '<MOT_DE_PASSE>';

J’obtiens ainsi un utilisateur qui a un accès total à la base de donnée de WordPress, qui ne peut se connecter qu’en local et qui ne peut pas toucher à mes autres BDD.

Pour ce qui est de la réécriture des liens afin d’avoir des permalinks facilement lisibles, j’ai dû activer le module rewrite d’apache en tapant la commande :

a2enmod rewrite

Il m’a fallut ensuite modifier dans /etc/apache2/site-available le fichier default en remplaçant dans la sous-catégorie correspondante à mon site (en l’occurrence <Directory /var/www>) « AllowOverride None » par «  »AllowOverride All ».

Il ne me reste alors plus qu’à configurer le CMS depuis l’interface d’installation disponible depuis l’adresse du site.

Lancement

Après avoir hésiter à réincorporer les posts de mon anciens blog, voici le nouveau en place. Comme je l’explique dans la section « About », je ne destine plus ce blog au développement. Il me servira plus à retrouver des informations que j’ai pu chercher par le passé, qu’à voir l’évolution de mes logiciels.

En ce qui concerne l’hébergement, j’ai profité d’une offre étudiante sur http://www.ikoula.com/. Je possède ainsi un serveur dédié pendant 1 an ayant comme configuration :

  • 1 CPU virtuel Intel Xéon
  • 512 Mo de RAM
  • 25 Go de disque dur
  • Debian 6 64bits
  • 100 Mbs (full duplex, interne/externe) de bande passante

ainsi que le nom de domaine laurentsanselme.com (avec autant de sous-domaine que je le désire) gratuitement.

J’ai par ailleurs pu tester la qualité de leur service consommateur et il est irréprochable. Chaque problème que je rencontrais a été résolu à l’aide de messages personnalisés et répondant à mon cas précis dans l’heure qui suivait ma demande.

Je vais donc profiter de mon année pour continuer de tester cet hébergeur mais il se peut que j’y reste par la suite. Je teste d’ailleurs sur plusieurs plans à la fois puisque j’ai aussi profité de leur offre hébergement web gratuit pendant un an avec un nom de domaine et 80 Go de stockage. Je donnerais donc des retours.