J’ai enfin trouvé un plugin qui me permette de publier automatiquement mes billets sur Identi.ca : Identi.ca Tools.

J’ai cherché de longues heures : pas grand chose pour Identi.ca …

Pour Twitter, ça oui, on a le choix. Mais personnellement, je publie vers Identi.ca et mes « dents » sont automatiquement relayés vers Twitter.

J’avais essayé le plugin « WordIdentica », mais bien qu’il soit simple (juste les userid / mot de passe à mettre), je n’ai jamais réussi à avoir mes articles publiés vers Identi.ca !  :-(

Par contre, aucun problème avec ce plugin Identi.ca Tools

J’utilise les options

• « Create a dent when you post in your blog » : je publie sur Identi.ca chaque fois que je publie un article sur mon blog
• « Create a dent when you post in your blog » : je veux avoir automatiquement sur mon blog, un billet par jour qui reprend mes billets sur Identi.ca (un résumé)

J’ai choisi de ne pas créer un article sur mon blog WP pour chaque « dent » (tweet sur Identi.ca) … Ce serait trop lourd, beaucoup trop ! Parfois je « retweet » (redent) des dizaines de messages d’Identi.ca. Avoir un article sur mon blog à chaque fois serait vraiment trop.

De plus, j’ai configuré Identi.ca pour retransmettre automatiquement mes messages vers Twitter, et j’ai un plugin qui m’affiche sur mon blog tous mes Tweets. Donc, afficher aussi ceux de Identi.ca ferait double emploi.

Voilà, simple et efficace !

Ce qui m’inquiète un peu, c’est que ce plugin « Identi.ca Tools » ne semble plus suivi !  Plus de mises à jour depuis 680 jours, et l’auteur, Matt White, semble introuvable. Son site est fermé…  Inquiétant… mais pour le moment, son plugin fonctionne bien avec WP 3.0. C’est ce qui compte.

Billet également publié sur WebActus.net, en collaboration avec Romain Amardeil, Maxime Legrand et Sylvain Ratton.

J’utilise WordPress depuis déjà longtemps, et je gérais encore manuellement les mises à jour de WordPress et des extensions (Plugins).

La présence de failles de sécurité récentes dans des versions WordPress précédentes a fait pas mal de bruit sur le Net (WP 2.8.4 est corrigé).

Je me décide donc à utiliser une méthode plus efficace et plus rapide de mise à jour : les mises à jour automatique.

Le sujet semble hyper simple… mais il ne l’est pas et j’ai lu beaucoup de messages d’utilisateurs ne parvenant pas à configurer cette mise à jour « automatique ».
Personnellement, je n’ai pas non plus compris tout de suite comment cela fonctionnait !

Par automatique, on veut dire : vous sélectionnez l’extension à mettre à jour, vous introduisez un mot de passe, vous cliquez ok et la mise à jour se fait. Cette mise à jour ne se fera pas sans votre accord.

Que se passe-t-il quand une extension WordPress doit être mise à jour ?

Si vous avez installé la barre de menu d’administration (« Ozh’ Admin Drop Down Menu« , je vous le conseille ), le nombre d’extensions à mettre à jour est indiqué dans la barre :

Vous cliquez sur « extensions » et vous arrivez dans la page de gestion des extensions (oh … étonnant !).

Il est très tentant de cliquer simplement sur « Lancer la mise à jour automatique »

Vous arrivez sur cette page :

Cela peut semble simple pour certains, mais j’ai hésité longtemps sans savoir ce que je devais mettre, et en cherchant sur le Net, d’autres utilisateurs étaient dans le même cas que moi !

Que mettre ?
J’ai d’abord pensé « c’est pour aller chercher en FTP la mise à jour, donc il me faut l’accès FTP sur un serveur où se trouve les mises à jour disponibles« …

Le fait que j’ai un logon, userid et mot de passe, sur le forum de WordPress.org, m’a induit en erreur. J’ai essayé de mettre ce logon dans la page de configuration de la connexion, de façon à aller télécharger « automatiquement » les mises à jour sur le site WordPress… (J’aurais pu y mettre le logon FTP à un de mes serveurs sur le quel j’aurais mis les mises à jour…)

Et bien, ça ne fonctionne pas, car ce n’est pas du tout ça ! C’est plus simple

Le script de mise à jour ira de toute façon chercher les mises à jour chez WordPress ! Pas besoin de lui dire où aller.
Par contre, il a besoin d’un accès FTP (ou FTPS) sur votre serveur, celui où vous avez installé WordPress, pour y downloader les modules…

Ok, compris !

J’ai trainé, car je n’avais pas d’accès FTP sur ce serveur. J’avais toujours tout fait en SSH/SCP. Mais finalement, ce n’est pas un problème niveau sécurité car ce serveur est derrière un modem ADSL qui fait office de routeur/firewall. Si je n’ouvre pas le port 21 dans ce routeur ADSL, aucune connexion extérieur ne pourra rentrer sur mon serveur FTP.

J’ai donc installé PureFTPd sur ce serveur Ubuntu (je ferai un billet sur PureFTPd dans les tous prochains jours).

J’ai configuré un utilisateur virtuel « uploadblog », qui n’a accès qu’à FTP (pas au système, pas en console) pour faire cette mise à jour.

Je rentre donc les informations suivantes :

et je clique sur « Continuer »

Le script de mise à jour n’a pas pu créer le dossier /wp-content/upgrade…
C’est logique. J’ai donné des droits assez restrictif sur les dossiers de mon serveur, et le script (utilisateur « uploadblog » ou « www-data », à vérifier) n’a pas pu créer le dossier.

Adaptez évidemment le dossier à votre installation.
Sur mon site, c’est « /home/www/didier/blog », chez vous c’est peut-être « /var/www/wordpress ».

Je vérifie en console (ssh) :

$ cd /home/www/didier/blog
$ ls -l
total 412
...
-rw-r--r-- 1 www-data www-data 92937 2009-09-08 00:10 sitemap.xml
-rw-r--r-- 1 www-data www-data 14048 2009-09-08 00:10 sitemap.xml.gz
drwxr-xr-x 7 didier   didier    4096 2009-08-12 08:37 wp-admin
-rw-r--r-- 1 didier   didier   40543 2009-08-12 08:37 wp-app.php
-rw-r--r-- 1 didier   didier     220 2009-08-12 08:37 wp-atom.php
-rw-r--r-- 1 didier   didier     274 2009-08-12 08:37 wp-blog-header.php
-rw-r--r-- 1 didier   didier    3649 2009-08-12 08:37 wp-comments-post.php
-rw-r--r-- 1 didier   didier     238 2009-08-12 08:37 wp-commentsrss2.php
-rw-r--r-- 1 didier   didier    1087 2008-12-13 21:05 wp-config.php
-rw-r--r-- 1 didier   didier    3167 2009-08-12 08:37 wp-config-sample.php
drwxr-xr-x 8 didier   didier    4096 2009-09-08 02:16 wp-content
...

Effectivement,le dossier wp-content n’est pas accessible en écriture, ni en FTP par l’utilisateur « uploadblog », ni par l’utilisateur « www-data » (Apache2).

Je crée manuellement le dossier :

:/home/www/didier/blog$ cd wp-content/
:/home/www/didier/blog/wp-content$ sudo mkdir upgrade
[sudo] password for didier:
:/home/www/didier/blog/wp-content$ sudo chown www-data:www-data upgrade

:/home/www/didier/blog/wp-content$ ls -l

drwxr-xr-x  2 www-data www-data 4096 2009-09-07 03:36 backup-db
...
drwxr-xr-x 22 didier   didier   4096 2009-08-22 00:58 plugins
drwxr-xr-x 44 didier   didier   4096 2009-08-12 08:37 themes
drwxr-xr-x  2 www-data www-data 4096 2009-09-08 02:35 upgrade
drwxr-xr-x  6 www-data www-data 4096 2009-06-27 00:44 uploads
...

De cette façon, seul Apache2 a accès en écriture sur le dossier upgrade (et je limite les dossiers aux quels Apache2 à accès en écriture au maximum).

Je réessaye la mise à jour :

Caramba ! Encore raté !

En effet, ce n’est pas Apache2 qui doit pouvoir écrire… Le script PHP doit certainement faire un FTP sur ce dossier.
Et ce n’est pas le userid utilisé pour se connecter en FTP (« uploadblog ») qui doit avoir accès, car cet utilisateur est virtuel, il n’existe pas au niveau Linux ! L’utilisateur qui fait le FTP et donc qui va télécharger la mise à jour est l’utilisateur sous le quel tourne PureFTPd !

Dans mon cas, PureFTPd tourne avec le user « ftpuser » qui fait partie du groupe « ftpgroup » :

:/home/www/didier/blog/wp-content$ sudo chown ftpuser:ftpgroup upgrade

Je réessaye :

Mouwai, j’aurais dû y penser !

Le reste s’est bien passé :

:/home/www/didier/blog/wp-content/upgrade$ ls -l
total 4
drwxr-xr-x 3 ftpuser ftpgroup 4096 2009-09-08 03:09 ozh-admin-drop-down-menu

Voyons les permissions sur le dossier Plugins :

:/home/www/didier/blog/wp-content$ ls -l

drwxr-xr-x  2 www-data www-data 4096 2009-09-07 03:36 backup-db
...
drwxr-xr-x 22 didier   didier   4096 2009-08-22 00:58 plugins
drwxr-xr-x 44 didier   didier   4096 2009-08-12 08:37 themes
drwxr-xr-x  3 ftpuser  ftpgroup 4096 2009-09-08 03:09 upgrade
drwxr-xr-x  6 www-data www-data 4096 2009-06-27 00:44 uploads

Effectivement, le FTP ne peut pas écrire dans ce dossier.
Je corrige les droits :

:/home/www/didier/blog/wp-content$ sudo chown -R ftpuser:ftpgroup plugins

et je réessaye :

Caramba ! Caramba !

La nouvelle version de l’extension est donc téléchargée, décompressée… mais le script n’arrive pas à la copier dans le dossier Plugins.

Pourtant, c’est bien « ftpuser:ftpgroup » qui doit être le owner de ce dossier !

Je cherche dans les logs :

$ less /var/log/apache2/didier-error_log

...
[Tue Sep 08 02:40:28 2009] [error] [client 192.168.168.23] PHP Warning:  ftp_mkdir() [<a href='function.ftp-mkdir'>function.ftp-mkdir</a>]:
 0 Kbytes used (0%) - authorized: 102400 Kb in /home/www/didier/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php on line 240,
 referer: http://didier.misson.net/blog/wp-admin/
update.php?action=upgrade-plugin&plugin=ozh-admin-drop-down-menu%2Fwp_ozh_adminmenu.php&_wpnonce=d0a8dc5c83

Ce n’est pas très clair,mais le script prend assez longtemps.

Vérifions la configuration PHP :

$ sudo vi /etc/php5/apache2/php.ini

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 30     ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 128M      ; Maximum amount of memory a script may consume (128MB)

Ca me semble court 30 secondes ! Le script dure plus longtemps que ça !

Je modifie… et finalement ça fonctionne :

On remarque que la mise à jour a désactivé l’extension. C’est normal. Il est d’ailleurs fortement conseillé lors d’une mise à jour manuelle de désactiver l’extension avant de faire la mise à jour.

Donc, il faut réactiver l’extension
C’est passé avec ces paramètres :

max_execution_time = 99     ; Maximum execution time of each script, in seconds (30)
max_input_time = 99 ; Maximum amount of time each script may spend parsing request data (60)
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 188M      ; Maximum amount of memory a script may consume (128MB)

$ sudo /etc/init.d/apache2 restart
[sudo] password for didier:
 * Restarting web server apache2

Attention, je n’ai pas dit que vous deviez obligatoirement augmenter ces 3 paramètres, ni les augmenter aussi fort !

Dans mon cas, en augmentant seulement le « max_execution_time » de 30 à 60 secondes, ça ne changeait rien.
J’ai encore augmenté les 2 variables « …time » et j’ai aussi augmenté la « memory_limit » de PHP car j’avais aussi vu des messages d’erreur « PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted«   lors de l’exécution de « wordpress-backup« .

C’était donc clairement une question de limitation de ressources pour PHP5, temps maximum et quantité mémoire.

A vous de voir en fonction de votre configuration, de la puissance de votre serveur, de vos sites Web (les scripts consomment plus ou moins de temps et de mémoire) et à vous de faire des essais en augmentant progressivement ces paramètres (pas trop quand même) jusqu’au moment où cela fonctionne.

En tout cas, on ne peut pas dire que ce soit simple !
Si ça marche du premier coup, par chance, ou car vous avez un super serveur hyper rapide qui va arriver à faire la mise à jour dans les 30 secondes (valeur par défaut dans php.ini), tant mieux pour vous…

Si ça ne fonctionne pas, ce n’est vraiment pas simple pour un utilisateur WordPress qui n’a pas l’habitude d’aller en ligne de commande, de trouver la solution !
J’espère que ce billet vous aura aider.

DoFollow or NoFollow ? That’s the question !

Par défaut dans WordPress, et dans beaucoup d’autres systèmes de blogs, les commentaires des visiteurs sont mis en « NoFollow », c’est à dire que Google quand il visitera votre blog, indexera vos billets, mais pas les liens inclus dans les commentaires de vos visiteurs. Cela permet par exemple de ne pas suivre et indexer les liens spams de certains commentaires !

L’idée était bonne pour lutter contre le spam et d’éviter, si votre blog est connu et très visité (je n’en suis pas encore là), que les sites de ces pourrisseurs d’Internet ne gagnent en référencement.
Mais ce n’est plus nécessaire maintenant. Des anti-spams existent et fonctionnent en général bien (par exemple Aksimet pour WordPress). Par contre, c’est pénalisant pour vos visiteurs réguliers et corrects dont les liens ne sont pas référencés.

Un peu de lecture à ce sujet, avec les arguments pour le DoFollow ou le NoFollow :

• I follow, you follow, we follow ! par Maigret
• Plugin WordPress do follow

Soyons logique : le partage de l’information, et donc les commentaires et liens laissés par vos visiteurs, sont importants. Autant qu’ils soient référencé par Google.

J’ai fait mon choix. Je passe ce blog en Follow.

Pour cela, il faut retirer le « NoFollow » ajouté automatiquement par WordPress à chaque lien dans un commentaire.

Le plus simple pour cela est d’installer le plugin « DoFollow ».

L’installation en est vraiment très simple puisque ce plugin est consitué d’un seul fichier PHP !

Sur la page de DoFollow, copiez l’adresse du lien « Download DoFollow.php » : cliquant dessus avec la touche droite de votre souris et faites « copier l’adresse du lien »

Allez sur votre serveur, dans mon cas en SSH. Sur ce serveur, télécharger simplement le fichier dans le dossier « plugins » de votre installation WordPress :

cd /home/www/didier/blog/wp-content/plugins
wget http://kimmo.suominen.com/sw/dofollow/dofollow.php

Il reste à activer cette nouvelle extension dans votre interface WordPress.
Après activation, vous pouvez modifier les options par défaut :

Par défaut, la première option est sélectionnée : les liens de tous les commentaires postés seront immédiatement suivis par les moteurs de recherche, et donc indexés.

Si vous voulez vous laisser un petit délais pour vérifier les commentaires avant que Google (ou autre) ne les indexe pour être certain que ce n’est ni du spam, ni un commentaire contraire au but de votre blog, vous pouvez indiquer un délais. Dans ce cas, les liens resteront en nofollow pendant ce délais. Ca vous laisse le temps de les vérifier et éventuellement de marquer le commentaire comme spam et de le supprimer. Si vous l’avez conservé (en théorie il est donc acceptable), ses liens passeront en DoFollow après 1 jour (dans mon cas, vous pouvez modifier).

J’ai préféré ne mettre cette restriction qu’aux utilisateurs non enregistrés. Je considère normalement les utilisateurs enregistrés comme digne de confiance…

Mes premières modifications du thème WordPress Bloggingpro NFT, pour le mettre en bleu plus foncé et ajouter une « favicon« , contenaient quelques erreurs.

Voici le bloggingpro_nft_blue.

Quelques thèmes WordPress vraiment intéressants sont disponibles sur le site TheBuckmaker.com.

Aeros, thème avec 2 colonnes

Les thèmes Aer, Aeros et Aerodrome sont très plaisants, simples et clairs.

Aer, un thème simple et clair avec une seule colonne

Aerodrome, thème 3 colonnes avec possibilité de mettre d’encart publicitaire ou bannière

Merci à Joe pour ces thèmes splendides.

A la demande de Cédric Fardel, j’ai adapté le thème Bloggingpro NFT en renforçant les couleurs bleues. Ça donne assez bien :

J’ai également modifié légèrement quelques détails, comme la liste des articles : à partir de la page 2 les photos et liens n’étaient plus affichés.

Voici le fichier de ce thème en version Bleu : bloggingpro_nft_blue. (version corrigée du 1er février 2009)

Le thème WordPress Bloggingpro NFT est un thème simple et clair, qui convient parfaitement si vous désirez un blog très lisible et facile d’accès.

Malheureusement, avec WordPress en français, un défaut d’affichage important apparait en début de page :

Plusieurs personnes ont ce problème, mais la correction du thème ne semble jamais être sortie officiellement. L’auteur travaillant avec WordPress anglais, il n’était pas dans les même conditions.

Le message d’erreur est :

Project-Id-Version: WordPress 2.6 Report-Msgid-Bugs-To: wp-polyglots@lists.automattic.com POT-Creation-Date: 2008-12-11 00:56 0000 PO-Revision-Date: 2008-12-11 10:52 0100 Last-Translator: Xavier Borderie Language-Team: WordPress-Francophone (www.http://wordpress-fr.net/) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rosetta-Version: 0.1 X-Poedit-Country: FRANCE X-Poedit-SourceCharset: utf-8 X-Poedit-KeywordsList: _e;_c;__ X-Poedit-Basepath: . Plural-Forms: n

Je pense que ce bug peut se manifester dans toutes les langues autres que l’anglais. Il parait que ça fonctionne correctement en anglais…

La solution se trouve dans les nombres messages laissés dans le post de l’auteur, mais elle est peu expliquée et contient une petite erreur de nom de fichier.

Je n’ai donc pas trouvé immédiatement et j’ai cherché par moi-même. Je n’arrivais d’abord pas à trouver dans quel fichier php se trouvait l’erreur.

En analysant le code source de la page HTML (dans Firefox tout simplement), on voit ceci :

<div id="bgcontain">
<!-- header START -->

<div class="HeaderBG">
 <div class="Header">

<h1><a href="http://didier.misson.net/blog/">Un peu de tout</a></h1>
<div class="Desc">Un blog libre utilisant WordPress</div>  

  <div class="TopMenu">
   <ul>
     <li class="pagenav">Project-Id-Version: WordPress 2.6
Report-Msgid-Bugs-To: wp-polyglots@lists.automattic.com
POT-Creation-Date: 2008-12-11 00:56 0000
PO-Revision-Date: 2008-12-11 10:52 0100
Last-Translator: Xavier Borderie <xavier-a-borderie-point-net>
Language-Team: WordPress-Francophone (www.http://wordpress-fr.net/) <traduction à wordpress tiret fr point net>
MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

A ce moment, je fais le lien avec ce commentaire que je n’avais pas compris, et je cherche dans le fichier header.php du thème.

Effectivement, en appliquant la correction indiquée, tout s’arrange, le message d’erreur disparait, et la ligne de menu réapparait.

Corriger la ligne wp_list_pages :

<div class= »TopMenu »>
<ul>
<?php wp_list_pages(‘depth=1&sort_column=menu_order&title_li=‘ . __( ») .  » ); ?>
</ul>
</div>
en :

<div class= »TopMenu »>
<ul>
<! correction Misson Didier 20090112 : problem with French WordPress and menu missing : replace ‘ . __( ») .  » );  by ‘ .  » )   >
<?php wp_list_pages(‘depth=1&sort_column=menu_order&title_li=‘ .  » ); ?>
</ul>
</div>

C’est nettement mieux

Voici le thème avec le fichier header corrigé (le reste n’est pas modifié) :

bloggingpro_nft_corrected

Il y a quelques semaines, j’ai adopté le thème Maple Leaf, écrit par Template Lite Theme et traduit par Aurélien Paulus. Il me plait. Par rapport à mon ancien thème, il ajoute l’affichage de l’auteur, ce qui était important pour moi car occasionnellement un ami poste quelques billets sur ce blog.

Voici donc le thème Maple Leaf d’origine :

Maple Lead est plutôt un thème « Automne »… alors qu’actuellement la neige recouvre le paysage.

En dehors de la disposition que je ne désirais pas modifier, j’avais envie de changer les couleurs. J’ai aussi profité de cet hivers plus rigoureux que d’autres pour faire quelques photos du paysage autour de Braine-l’Alleud. Autant utiliser les photos que j’ai faites

Et ma version modifiée Maple Leaf Winter :

Voici donc mon blog avec un thème hiver, dérivé de Maple Leaf. J’y ai juste changé les couleurs dans la feuille de style CSS, utilisé mes photos et retouché les icônes et autres éléments graphiques pour être en accord avec les teintes générales dans les dégradés de bleu.

Je vais bien évidemment mettre à disposition ce thème Winter (ok, c’est fait : vous pouvez le télécharger). Le temps de vérifier et nettoyer mes bricolages

La nouvelle version de WordPress, la 2.7 « Coltrane », est disponible depuis ce jeudi 11 novembre.

Pas mal d’améliorations au niveau de l’interface, de l’administration et de la gestion des commentaires.

Je vous invite à lire plus en détail le billet de Papy Geek à ce sujet.

WordPress 2.6 est disponible depuis ce mardi 15 juillet.

J’étais encore en 2.3.3. Il faut préciser que la version 2.4 n’est jamais sortie et la 2.5 est sortie le 29 mars 2008. A ce moment là, je n’ai pas fait la mise à jour vers 2.5 (pas urgent que je me disais). Maintenant que la 2.6 est là, je ne vais quand même pas prendre 2 versions de retard

Voilà, c’est fait ! Je suis en WordPress 2.6.

Mise à jour assez facile :

1. télécharger la nouvelle version depuis www.wordpress-fr.net
2. décompresser dans un dossier
3. dans l’administration de votre blog, AVANT la mise à jour, désactiver les extensions (plugins) et éventuellement remettre le thème par défaut
4. se déconnecter de l’interface d’administration
5. FAIRE un BACKUP de votre base de données ! (euh… ok… j’avoue que je ne l’ai pas fait… mais il y a quand même un risque)
6. recopier les dossiers de la nouvelle version 2.6 sur les anciens dossiers (écraser)
7. retourner dans l’administration de votre blog (refaire logon)
8. A ce moment, WordPress détecte que le code a été mis à jour et qu’il faut, pour que cela reste cohérent, faire une mise à jour de la base de données. En théorie cette mise à jour est relativement rapide et sans problème
9. Si la mise à jour s’est bien passée, et que votre blog semble répondre normalement avec le thème par défaut et sans aucune extension, réactiver les extensions et remettre votre thème habituel

L’annonce de la version 2.6 ainsi qu’un résumé des nouvelles possibilités a été faite sur wordpress.org (en)