Alors voilà une petite commande SQL à exécuter sur votre base de données et qui m’a fait gagner jusqu’à 60Mo sur un des sites que j’administre :p

DELETE FROM wp_postmeta WHERE 'meta_key' = 'WyPiekacz_msg';

Prenez soin de remplacer le préfixe wp_ par le préfixe correspondant à votre configuration !

Attention quand même quand vous modifiez votre base de données en live, pensez à faire une sauvegarde

Il ne reste plus qu’à espérer que le plugin soit mis à jour pour prendre en compte ce bug.

Puisque la configuration d’une telle machine est parfois un poil compliquée, voici un tutoriel pour créer pas à pas votre propre serveur local avec VirtualBox et Ubuntu Serveur.

Installer VirtualBox

Tout d’abord, pourquoi VirtualBox ? Bah, parce que c’est gratuit, déjà. Et mine de rien, les machines virtuelles, c’est quand même bien pratique, notamment parce qu’on peut faire des instantanés, sorte de sauvegarde de l’état de la machine à un instant T. Idéal pour revenir en arrière après une mise à jour foireuse par exemple

Commençons par télécharger l’installeur. Vous devriez trouver votre bonheur sur le site officiel ou dans les paquets de votre distribution linux. L’installation de VirtualBox en elle-même ne devrait là encore ne pas vous poser de problème.

Télécharger Ubuntu Server

Là encore, pourquoi Ubuntu, et pourquoi en version serveur ? Bon, ok, c’est gratuit aussi. Ubuntu est l’une des distributions les plus populaires, et dispose d’une communauté assez large pour que dans la quasi totalité des cas, quelqu’un aura déjà rencontré (et avec un peu de chance, aura déjà résolu) le problème que vous vous apprêtez à rencontrer à votre tour.
Quant au choix de la version serveur, c’est une question d’utilité et de performances : d’une part dans la plupart des cas, il est assez peu utile d’avoir une interface graphique sur votre serveur ; d’autre part, les machines virtuelles étant souvent assez gourmandes en mémoire vive, se passer d’une interface graphique permet aussi de limiter la mémoire allouée à notre serveur, et donc de garantir de meilleures performances pour l’ordinateur hôte (théoriquement).

Vous devriez pouvoir télécharger un iso de la dernière version francophone de Ubuntu Server sur ubuntu-fr.org

Cela étant, rien ne vous empêche de choisir une autre distribution et/ou une version dotée d’une interface gratuite, le reste de ce tutoriel reste applicable.

Installer la machine virtuelle

Une fois l’iso sauvegardé sur votre ordinateur, lancez VirtualBox et créez une nouvelle machine virtuelle :

La création d’une nouvelle machine virtuelle se faisant de manière assez intuitive, laissez-vous guider dans les différentes étapes.
Nul besoin d’allouer une quantité importante de mémoire vive, 512Mo ou moins devraient suffire si vous n’envisagez pas de traiter des masses de données.

De même, la taille du disque dur virtuel n’est pas très importante, puisqu’en général on n’a pas de gros besoins pour des sites web. J’ai pour habitude de créer des disques dynamiques (VirtualBox Disc Image) de 10Go, ce qui est normalement amplement suffisant.

Une fois les différentes étapes remplies, votre machine est créée. Mais elle est vide, et il faut maintenant y installer notre OS. Pour cela, il va falloir « insérer » le disque d’installation, c’est à dire l’iso de Ubuntu Server que vous venez de télécharger. Dans le menu Configuration de votre machine virtuelle, rendez-vous dans l’onglet Stockage puis indiquez le chemin vers l’iso :

Il suffira ensuite de lancer la machine virtuelle, de la laisser démarrer sur le cdrom et de procéder à l’installation somme toute standard de votre OS. J’ai pour habitude de n’installer aucun paquet à ce moment de la création de notre serveur, et de le faire à la main par la suite (ce qu’on va voir tout de suite), mais libre à vous d’essayer :p

Configurer la machine virtuelle

Maintenant que nous avons une machine virtuelle en parfait état de fonctionnement, il va falloir la transformer en un véritable serveur web, en y installant les éléments indispensables au bon fonctionnement de la plupart des sites.

Commencez par installer Apache, en tapant la commande suivante en ligne de commande :

sudo apt-get install apache2

Même chose pour PHP (je vous assure, le HTML c’est bien, mais c’est vite limité) :

sudo apt-get install php5 libapache2-mod-php5

MySQL, histoire de pouvoir stocker des données :

sudo apt-get install mysql-server

Et PhpMyAdmin pour avoir une belle interface web pour gérer nos bases de données :

sudo apt-get install libapache2-mod-auth-mysql php5-mysql phpmyadmin

Redémarrez Apache pour qu’il prenne en compte ses nouveaux amis :

sudo /etc/init.d/apache2 restart

Enfin, je vous conseille deux petites manips. Tout d’abord, placez un lien symbolique vers phpmyadmin dans /var/www, pour pouvoir y accéder plus facilement depuis la racine du serveur web :

sudo ln -s /usr/share/phpmyadmin/ /var/www/phpmyadmin

Puis ajoutez-vous au groupe www-data (le groupe du processus Apache) et rendez-le propriétaire de /var/www (prenez soin de remplacer username par votre login) :

sudo usermod -a -G www-data username
sudo chown -R username:www-data /var/www/

C’est presque prêt, ne reste qu’à redémarrer pour s’assurer que tout se passe bien au démarrage de la machine virtuelle :

sudo reboot

Configurer le réseau

Maintenant que nous avons un serveur web fonctionnel, il va falloir y accéder depuis l’extérieur, ou au moins depuis la machine hôte. Plusieurs possibilités existent, mais je vous conseille d’utiliser celle que je vais vous décrire, qui fonctionnera quel que soit l’OS hôte.

Commencez par arrêter votre machine virtuelle :

sudo shutdown -h now

Rendez-vous ensuite dans le menu Préférences de VirtualBox (général et non d’une machine virtuelle) puis dans l’onglet Réseau. Nous allons modifier le réseau privé hôte par défaut de VirtualBox (à priori vboxnet0) en cliquant sur le tournevis, et en renseignant l’onglet Interface comme ceci :

Et l’onglet Serveur DHCP comme ceci :

C’est bon, vous pouvez cliquer sur OK
Ensuite, dans la configuration de votre machine virtuelle, ajoutez une interface réseau en vous rendant dans l’onglet Configuration > Réseau et en activant tout simplement la carte n°2 en mode Réseau privé hôte :

Veillez à conserver la carte n°1 active en mode NAT.

Démarrez ensuite la machine virtuelle pour éditer sa configuration réseau. Une fois logué, tapez :

sudo nano /etc/network/interfaces

Modifiez le fichier pour qu’il ressemble à ça (il s’agit en fait de configurer votre nouvelle carte réseau, aka eth1) :

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet static
        address 10.0.0.2
        netmask 255.255.255.0

Vous venez de spécifier une IP fixe pour la seconde carte réseau, qui permettra de faire en sorte que la machine invitée soit toujours accessible depuis la même adresse.

Pour finir, redémarrez les interfaces réseau pour que les modifications soient prises en compte :

sudo /etc/init.d/networking restart

Vous devriez pouvoir accéder au serveur web de votre machine virtuelle en tapant http://10.0.0.2 dans la barre d’adresse de votre navigateur :

Une fois ces différentes étapes réalisées, je vous conseille d’enregistrer un premier instantané de votre machine virtuelle (touche « host » + T, la touche « host » étant par défaut la touche Pomme/CMD sur Mac et la touche CTRL droite sur les autres OS) :

N’hésitez pas à détailler l’intitulé et la description de chaque Instantané afin de savoir où vous en étiez dans votre travail.
Ainsi, si quelque chose foire pendant la suite, vous pourrez facilement revenir en arrière en sélectionnant la sauvegarde que vous souhaitez via l’onglet Instantanés du menu principal de VirtualBox :

Les instantanés sont un des principaux atouts des machines virtuelles, je vous recommande donc très fortement de les utiliser !

Installer les additions invité

Un autre des nombreux atouts de VirtualBox, c’est le partage de dossiers entre la machine hôte et la machine invitée, possible au travers des additions invité. Ces fameuses additions sont en fait des greffons ajoutés à votre machine virtuelle et qui permettent l’interfaçage avec la machine hôte. Pour les installer, vous devez d’abord installer quelques paquets essentiels dès qu’on touche au noyau linux :

sudo apt-get install build-essential linux-headers-`uname -r` dkms

Il faut ensuite monter l’image disque contenant les additions invité. Pour cela, rendez-vous dans le menu Périphériques de votre machine virtuelle et cliquez sur Installer les additions invité. L’image iso sera ajoutée à votre machine virtuelle. Il suffit ensuite de la monter avec la commande :

sudo mount /dev/cdrom /media/cdrom/

Une fois l’image iso montée, lancez l’installation des additions invité :

cd /media/cdrom/
sudo sh ./VBoxLinuxAdditions.run

Et voilà, les additions invité sont installées. Peu de différence pour vous puisque la plupart ne sont utiles que lorsque l’on utilise une interface graphique, mais ça sera bien utile pour la suite quand même.
Pour que les additions soient bien prises en compte, éteignez encore une fois la machine virtuelle :

sudo shutdown -h now

Créer un dossier partagé

Un dossier partagé sera, comme son nom l’indique, un espace de stockage partagé entre la machine hôte et la machine virtuelle. Vous aurez donc l’équivalent d’un FTP sauf qu’il sera connecté automatiquement et totalement intégré à votre explorateur de fichiers favori.
Voyons comment le paramétrer.

Sur la machine hôte

Rendez-vous dans le menu de configuration de votre machine virtuelle, dans l’onglet Dossiers partagés. Vous pourrez alors ajouter un répertoire de partage de façon temporaire ou permanente, choisir l’étendue des droits pour la machine virtuelle, ou encore paramétrer le montage automatique ou manuel du dossier. Surtout, vous lui donnerez un nom qu’il va falloir retenir parce que vous en aurez besoin pour la suite.

Sur la machine invitée

Redémarrez la machine virtuelle, et montez le dossier partagé avec la commande suivante (en prenant soin de remplacer « NOM_DU_DOSSIER_DE_PARTAGE » par … le nom du dossier de partage :p) :

sudo mount -t vboxsf NOM_DU_DOSSIER_DE_PARTAGE /var/www

Si tout se passe bien, le dossier de partage sera monté à la place de /var/www, le répertoire de base par défaut d’Apache. Autrement dit, votre dossier partagé contiendra tous les sites hébergés sur votre serveur. Libre à vous évidemment de modifier ce comportement, en changeant le point de montage (/var/www) et/ou la configuration d’Apache.

Vous pouvez maintenant configurer votre dossier de partage pour qu’il soit monté automatiquement au démarrage de votre machine virtuelle. Pour cela, il vous faut éditer /etc/fstab :

sudo nano /etc/fstab

Ajoutez la ligne suivante à la fin du fichier :

NOM_DU_DOSSIER_DE_PARTAGE	/var/www	vboxsf	umask=0022,gid=33,uid=33	0	0

Comme précédemment, veillez à remplacer NOM_DU_DOSSIER_DE_PARTAGE par le nom de votre dossier
Le 2e paramètre est le point de montage, le 3e le système de fichiers (à ne pas modifier, c’est le système de fichiers propre aux dossiers partagés de VirtualBox). Pour le reste, si vous ne comprenez pas, mieux vaut ne pas y toucher

Pour tester le bon fonctionnement de ce paramétrage, redémarrez votre serveur virtuel. En cas de problème, n’hésitez pas à retourner dans le menu de configuration de votre machine virtuelle et à désactiver le montage automatique du dossier partagé.

Enfin, pour résoudre les problèmes de droits d’écriture et de lecture éventuels, exécutez les deux commandes suivantes (en remplaçant USERNAME par votre login unix) :

sudo usermod -a -G vboxsf USERNAME
sudo usermod -a -G vboxsf www-data

Ceci ajoutera USERNAME (vous) et www-data (l’utilisateur par défaut d’Apache) au groupe vboxsf, qui a normalement tous les droits sur les dossiers partagés VirtualBox.

Installer openssh pour le copier-coller

Dernière petite astuce : le copier-coller. Sur une installation classique d’une machine virtuelle munie d’une interface graphique, lorsqu’on installe les additions invité VirtualBox, il est possible de faire des copier-coller entre la machine hôte et la machine virtuelle, dans les deux sens. Malheureusement, cette fonctionnalité est dépendante de l’interface graphique, dont votre nouveau serveur de développement est dépourvu.

La solution pour palier à ce problème est d’installer openssh :

sudo apt-get install openssh-server

Connectez-vous ensuite à votre machine virtuelle depuis le terminal de votre machine hôte (pour ceux qui utilisent Windows, PuTTy est votre ami) :

ssh USERNAME@10.0.0.2

Pour rappel, 10.0.0.2 est l’adresse locale de votre serveur virtuel.

Vous avez donc maintenant un serveur de développement en local totalement fonctionnel, et vous pouvez éditer les fichiers de vos sites directement depuis votre machine hôte en utilisant les dossiers partagés. En plus, grâce aux instantanés, vous pouvez vous amuser à bidouiller la configuration de votre serveur sans risque de pertes de données puisque vous pourrez revenir en arrière à tout moment !

Astuce de dernière minute pour ceux qui auraient tout lu : pour pouvoir également effectuer des rollbacks sur les fichiers de vos sites, voire synchroniser ces derniers entre plusieurs postes, pensez à utiliser un logiciel de gestion de versions comme Subversion, ou même DropBox.

Il ne vous reste plus qu’à faire preuve d’imagination pour vos futurs sites

Son but ? Interdire aux utilisateurs Abonnés de se connecter à votre interface d’administration.

Placez donc ce bout de code dans le fichier functions.php de votre thème :

function dfr_control_login() {
	//ne s'applique pas aux contributeurs, auteurs, éditeurs, admins
	if (!current_user_can('edit_posts') ){
		wp_logout();
	}
}
add_action('wp_login','dfr_control_login');

Lorsqu’un utilisateur se connecte, l’action wp_login est déclenchée, et notre fonction s’exécute. Si l’utilisateur en question n’a pas l’autorisation d’éditer des articles (la capacité edit_posts pour WordPress), on exécute la fonction wp_logout() qui va automatiquement le déconnecter.

Les abonnés qui tenteront de se connecter seront donc tout de suite ramenés sur l’écran de login. Le gros défaut de ce hack est qu’il ne fournit aucune explication à l’utilisateur à qui l’on a interdit de se connecter, ce qui peut être assez frustrant. J’espère que cela vous donnera envie de creuser un peu plus pour trouver moyen de mieux faire, et si c’est le cas, partagez donc votre solution en commentaires !

Enfin, je vous encourage à consulter la liste des rôles et capacités de WordPress au cas où vous souhaiteriez adapter ce code pour interdire le login à un type d’utilisateur particulier

Lorsqu’on administre une plateforme de blogs ou un blog multi-utilisateurs, il est parfois utile de jeter un œil aux liens placés dans les articles par les différents contributeurs. En effet, il n’est pas rare d’avoir affaire à quelques spammeurs, qui n’hésitent pas à bourrer leurs contenus de liens vers leurs sites de qualité discutable.
Je ne sais pas pour vous, mais me concernant, je préfère que mes sites ne servent pas de splog

Malheureusement, passer en revue les liens insérés dans les contenus peut s’avérer très chronophage, d’autant plus quand certains petits malins s’arrangent pour que leurs liens ne soient pas facilement visibles (plusieurs liens qui se succèdent, des liens sans anchor text, …).

J’ai donc mis au point ce petit plugin qui permet de gagner un temps considérable sur les tâches de modération de vos sites. Une fois installé et activé, vous verrez apparaître une metabox sur l’interface d’administration de votre site, avec les url cibles (href) et ancres des liens présents dans l’article en cours de modération :

En un coup d’oeil, on peut voir la totalité des liens de l’article et les visiter si besoin. Plus besoin de devoir parcourir à l’oeil nu le code source !

Il n’est pas impossible que ce plugin évolue prochainement pour vous proposer davantage de fonctionnalités, mais en attendant je vous encourage à télécharger dès maintenant WP Link Analysis sur wordpress.org !

La page du plugin sur wordpress.org

• 4h18
• Axenet
• Bruno Hug
• CWM Consulting
• Djolhan
• Elannu
• Florian Giudicelli
• Infiniclick
• Jambon Buzz
• Keeg
• Lionel Miraton
• Nicolas Robineau
• Olivier Andrieu
• Renaud Joly
• SeoBlackout
• SeoMix

Après cette belle liste de liens qui m’a pris au moins 15 minutes à mettre en forme, il est temps de passer aux choses sérieuses. Alors voilà, my 2 cents.

Etat des lieux

Je suis à la fois utilisateur et administrateur de plateformes de contenus, qu’il s’agisse de blogs, d’annuaires, de communiqués de presse ou de digg-likes. J’ai donc une vision des deux côtés de la barrière, si barrière il y a, puisqu’après tout, soyons clairs, le but du jeu reste de faire des liens.

La prolifération des plateformes de communiqués de presse ces derniers temps, qu’ils soient thématiques ou généraliste, est à première vue une bonne chose pour les référenceurs qui les utilisent : davantage de domaines référents, davantage d’endroits où placer ses liens.

Mais cette prolifération risque également d’attirer les yeux du grand G sur ce type de plateformes. On aura beau créer des sites réservés à certaines thématiques, cacher les noms des auteurs ou publier des contenus sans liens pour noyer le poisson, certains ont déjà commencé à intéresser les équipes de lutte anti-spam et autres Quality Raters.

Duper Google

Après Panda, que nous réserve Google en 2012 ?

Aujourd’hui l’enjeu n’est plus de trouver des endroits où publier ses contenus, mais plutôt de trouver le moyen de maquiller suffisamment nos fermes de liens pour qu’elles n’attirent pas l’attention. Je vois des idées fuser dans tous les sens : CMS exotiques, liens vers des sites d’autorité, « un contenu sans liens sortants pour 2 contenus avec », interview de votre site … Au moins la sphère SEO n’a pas cessé de fourmiller, c’est plutôt bon signe.

Il est évident que, la plupart des sites de communiqués de presse SEO, des annuaires ou des digg-likes utilisant des solutions techniques très similaires voire identiques, il doit bien être possible quand on a la puissance de calcul d’un moteur de recherche de les détecter. Encore que … Est-il si facile pour un algorithme de déterminer quel site est une ferme de liens et quel autre présente du « contenu pertinent » ? Doit-on s’attendre à voir fleurir en 2012 un filtre ou une mise à jour de l’algo destinée particulièrement à lutter contre la génération de liens « non-naturels » ?

Je crois pour ma part que nos plateformes de publication ont, pour la plupart, encore de beaux jours devant elles.

Et après ?

Malgré tout, on se retrouve aujourd’hui avec une multitude de sites dont la plupart n’apportent que peu de jus et sont assez peu utilisés. Finalement les plateformes dignes d’intérêt sont toujours les mêmes, et on en a déjà fait le tour. Bien sûr, leur utilisation reste toujours intéressante, et on peut compter sur leurs administrateurs pour faire en sorte qu’elles évoluent.

Mais le modèle du site de communiqués de presse gratuit a peut être fait son temps. Certains ont déjà choisi de lancer des offres payantes permettant de publier des contenus chez eux, et je les comprends : après tout, modérer les articles soumis (je ne parlerai pas de la qualité desdits articles, je ne voudrais vexer personne :p), c’est du temps. Passer du temps bénévolement pour aider des prestataires à satisfaire leurs clients, ça va 5 minutes. Je ne vois pas de raisons pour que ce type de services ne se développe pas, d’autant que la qualité suit.

Je pense que nous devons donc continuer d’être imaginatifs, et trouver de nouvelles pistes pour le netlinking. Nouvelles ou pas d’ailleurs, puisqu’après tout, certaines vieilles recettes fonctionnent toujours aussi bien

WordPress propose déjà une foultitude d’actions prédéfinies dans le noyau. Toutes ces actions (ou hooks) sont déclenchées par les différentes requêtes possibles sur un blog WordPress. Mais il est possible d’aller plus loin !

Déclenchez vous-même une action

Il arrive souvent, lorsqu’on développe un thème ou un plugin, qu’on ait besoin de déclencher une action à un endroit précis d’une page (par exemple) et que cette action ne soit malheureusement pas activée à cet endroit.
Dans ce cas-là la plupart du temps, on modifie la page en question pour y insérer un appel à la fonction qui va bien. Certes, ça fonctionne, et c’est suffisant lorsqu’on n’a qu’une seule fonction à utiliser.
Mais lorsque l’on veut pouvoir faire des choses un peu plus complexes, par exemple exécuter toutes les fonctions correspondantes à une action, on se retrouve souvent limité. Pourtant, une fonction existe dans le core de WordPress pour déclencher des actions : do_action() !

En fait, il suffit d’insérer dans votre code la ligne suivante pour déclencher une action en particulier, et donc exécuter toutes les fonctions qui s’y sont « branchées » :

<?php do_action( $tag ); ?>

Il vous suffit donc de trouver la bonne action à déclencher, et le tour est joué !

Créez vos propres actions !

Avec cette fonction, vous pouvez également créer vos propres actions, tout simplement en remplaçant $tag par un nom d’action qui n’existe pas dans le core de WordPress (ni dans vos plugins ou votre thème), et en y branchant ensuite les fonctions qui vont bien.
De cette façon, vous pouvez adapter encore un peu plus ce CMS à vos besoins.

Vous trouverez davantage d’informations et des exemples d’utilisation de do_action sur la page du Codex correspondante.

Dans sa configuration de base, WordPress n’autorise l’emploi que de quelques balises HTML seulement dans les descriptions des catégories (a, strong notamment). Cependant, dans nos réflexions de SEO, on apprécie souvent de pouvoir travailler la description des catégories, ne serait-ce que pour limiter le duplicate content. Et pour cela, on aimerait bien avoir la possibilité d’utiliser d’autres balises HTML.

Un petit bout de code à placer dans le fichier functions.php de votre thème permet de régler ce léger problème :

$filters = array('term_description','category_description','pre_term_description');
foreach ( $filters as $filter ) {
    remove_filter($filter, 'wp_filter_kses');
    remove_filter($filter, 'strip_tags');
}

Un peu d’explications : WordPress considère les catégories comme des terms, traités de la même façon que les tags ou les taxonomies. Quand on crée ou modifie une catégorie, elle est donc soumise aux mêmes règles que n’importe quel terme. Dans des termes un peu plus techniques, les filtres term_description et pre_term_description s’appliquent de la même façon que category_description, au moment où la description est enregistrée en base de données.
Pour pousser la réflexion un peu plus loin, il suffirait d’ajouter les filtres adéquats dans l’array $filters pour pouvoir également utiliser du HTML dans les descriptions de tags ou de taxonomies.

Quant aux filtres que nous retirons, wp_filter_kses fait appel à la librairie kses pour retirer une bonne partie des balises HTML présentes dans une chaîne de caractères, en ne laissant que certaines balises autorisées (strong, a, em …).
Enfin, la fonction PHP strip_tags retire notamment le code PHP et JavaScript. Nous avions vu l’utilisation de cette fonction adaptée pour WordPress lorsque nous voulions supprimer le HTML dans les commentaires.

Avec ces 5 lignes de code, nous pouvons maintenant ajouter toutes les balises que nous voulons dans les descriptions de nos catégories. Faites vous plaisir !

Ce petit hack illustre encore une fois les larges possibilités offertes par WordPress en quelques lignes de code. Pour les plus pressés ou pour ceux qui ne souhaitent pas se pencher dans le code, sachez qu’il existe des plugins qui vous permettront de faire la même chose et ajouteront un éditeur Wysiwyg pour vous faciliter la rédaction des descriptions. N’étant pas un fervent utilisateur de plugins, je vous laisse chercher

Articles complémentaires :

• Supprimer les balises HTML dans les commentaires
• Supprimer le html dans le titre des articles

Aujourd’hui, je vous propose de rajouter une metabox sur la page d’ajout et d’édition d’articles, qui ne s’affichera qu’aux administrateurs du site, et leur permettra de pouvoir aller directement sur le profil de l’auteur de l’article, sans passer par la liste de tous les utilisateurs, sans effectuer une recherche parmi les utilisateurs, sans passer par la case départ et malheureusement sans toucher 20 000F.

Pour les pressés, je vous propose d’aller voir directement le code complet. Pour les autres, voyons les choses un peu plus en détail.

Commençons par la création d’une metabox. Les metaboxes sont tous les blocs visibles sur les pages d’édition de l’interface d’administration de WordPress :

Vous pouvez très facilement les réduire, les déplacer, les cacher ou afficher davantage de boites en cliquant sur « Options de l’écran » en haut à droite de la page. Et il est très facile d’en ajouter de nouvelles grâce à la fonction add_meta_box() :

//création de la metabox (id css, titre, fonction contenu, type de page, contexte, priorité)
function dfr_author_metabox() {
	add_meta_box( 'dfr_author_metabox', 'Auteur', 'dfr_author_metabox_callback', 'post', 'side', 'high');
}
//affichage de la metabox
if (current_user_can('manage_options')) {
	add_action('admin_init', 'dfr_author_metabox', 1);
}

On indique à la fonction add_meta_box l’id css de notre nouvelle metabox (doit être unique, sinon attendez-vous à des problèmes ), le titre du bloc, la fonction de callback, c’est à dire celle qui gèrera l’affichage du contenu, le type de post sur lequel on veut ajouter la metabox (post, page ou type personnalisé), le contexte (au centre, sur la colonne de droite …) et la priorité (l’ordre d’affichage en quelque sorte, plus la metabox est prioritaire, plus son emplacement sera proche du haut de la page).

Ensuite on s’assure de n’afficher notre metabox qu’aux utilisateurs qui peuvent gérer les options (if (current_user_can('manage_options'))), c’est à dire aux administrateurs. Si vous souhaitez permettre également aux éditeurs de voir la metabox, il faudra utiliser une capacité de niveau moins élevé pour ce test.

Enfin, si notre utilisateur est effectivement administrateur du site, on ajoute la metabox (avec une priorité 1 ici pour qu’elle soit vraiment très haut dans la page).

Reste à savoir ce que notre boîte va afficher :

//contenu de la metabox
function dfr_author_metabox_callback() {
	global $wpdb;

	$author_ID = get_post($post->ID)->post_author;
	$role = $wpdb->get_var("SELECT meta_value FROM {$wpdb->usermeta} WHERE meta_key = '{$wpdb->prefix}capabilities' AND user_id = {$author_ID}");
	$rarr = unserialize($role);
	$roles = is_array($rarr) ? array_keys($rarr) : array('non-user');

	?><ul>
	<li><?php the_author_meta('nickname',$author_ID); ?> (<?php echo $roles[0]; ?>)</li>
	<li><a href="<?php echo get_author_posts_url($author_ID); ?>"><?php the_author_posts(); ?> article(s) publié(s)</a></li>
	<?php
	if( function_exists( 'get_compteur' )) {
		?><li><?php echo get_compteur($author_ID); ?> article(s) refusé(s)</li><?php
	}
	?>
	<li><a href="<?php echo get_bloginfo('url'); ?>/wp-admin/user-edit.php?user_id=<?php echo $author_ID; ?>">Editer le profil</a></li>
	</ul><?php
}

On commence par récupérer l’ID de l’auteur, ce qui nous permettra de récupérer plus facilement les informations dont on a besoin.
Ensuite on récupère le rôle de l’auteur de l’article. Ce rôle est enregistré dans la base de données, sous la forme d’une variable sérialisée, qu’on va donc convertir avec unserialize(). On obtient un tableau contenant les rôles éventuels de l’auteur. Si on n’en trouve aucun, on lui attribue le « rôle » non-user.

Passons ensuite à l’affichage proprement dit. J’ai choisi d’afficher l’identifiant (nickname) de l’auteur, son rôle, un lien vers ses articles déjà publiés (avec un compteur du nombre d’articles publiés), et si mon magnifique plugin wp-compteur est installé, le nombre d’articles refusés pour cet auteur.
Enfin, j’ai ajouté un lien permettant d’aller modifier le profil de l’utilisateur si besoin était.

Rien ne vous empêche d’ajouter d’autres informations si vous le souhaitez.

Le code complet :

if (is_admin()) {
	//création de la metabox (id css, titre, fonction contenu, type de page, contexte, priorité)
	function dfr_author_metabox() {
		add_meta_box( 'dfr_author_metabox', 'Auteur', 'dfr_author_metabox_callback', 'post', 'side', 'high');
	}
	//affichage de la metabox
	if (current_user_can('manage_options')) {
		add_action('admin_init', 'dfr_author_metabox', 1);
	}
	//contenu de la metabox (html)
	function dfr_author_metabox_callback() {
		global $wpdb;

		$author_ID = get_post($post->ID)->post_author;
		$role = $wpdb->get_var("SELECT meta_value FROM {$wpdb->usermeta} WHERE meta_key = '{$wpdb->prefix}capabilities' AND user_id = {$author_ID}");
		$rarr = unserialize($role);
		$roles = is_array($rarr) ? array_keys($rarr) : array('non-user');

		?><ul>
		<li><?php the_author_meta('nickname',$author_ID); ?> (<?php echo $roles[0]; ?>)</li>
		<li><a href="<?php echo get_author_posts_url($author_ID); ?>"><?php the_author_posts(); ?> article(s) publié(s)</a></li>
		<?php
		if( function_exists( 'get_compteur' )) {
			?><li><?php echo get_compteur($author_ID); ?> article(s) refusé(s)</li><?php
		}
		?>
		<li><a href="<?php echo get_bloginfo('url'); ?>/wp-admin/user-edit.php?user_id=<?php echo $author_ID; ?>">Editer le profil</a></li>
		</ul><?php
	}
}

J’espère que ce petit hack vous sera utile pour gérer vos sites communautaires

Cela dit, le rôle de contributeur est parfois un peu trop limité : par défaut, WordPress interdit aux contributeurs l’upload de médias via le fameux menu Envoyer/Insérer :

Pourtant, cette fonction est parfois indispensable. Plutôt que de passer vos contributeurs en auteurs, je vous propose de rajouter les quelques lignes suivantes au fichier functions.php de votre thème :

if ( current_user_can('contributor') && !current_user_can('upload_files') )
	add_action('admin_init', 'dfr_upload_contributeurs');

function dfr_upload_contributeurs() {
	$contributor = get_role('contributor');
	$contributor->add_cap('upload_files');
}

On commence par vérifier que l’utilisateur actuel est contributeur, et qu’il ne peut pas uploader de média (pour éviter d’exécuter la fonction pour rien). Si c’est le cas, on ajoute à l’aide de dfr_upload_contributeurs() la capacité upload-files au rôle Contributeur. De cette manière, les contributeurs verront eux aussi apparaître le menu Envoyer/Insérer sur la page d’ajout et d’édition d’articles.

Si la fonction native de WordPress the_excerpt() permet d’afficher l’extrait configuré dans l’interface d’administration, ou à défaut les 55 premiers mots de l’article (en retirant les éventuelles balises de code source), ce comportement n’est pas toujours adapté à nos usages.

Suite à la demande de l’ami Bruno Hug, je vous propose une petite fonction à placer dans le fichier functions.php de votre thème, pour personnaliser quelque peu le comportement de WordPress concernant l’extrait.

add_action( 'save_post', 'dfr_custom_excerpt', 10, 1);
function dfr_custom_excerpt($post_id) {
	//récupération de l'extrait et du contenu du post
	global $wpdb;
	$sql = "SELECT post_content,post_excerpt FROM ".$wpdb->prefix."posts WHERE ID = ".$post_id;
	$result = $wpdb->get_row($sql);

	//si un extrait existe
	if($result->post_excerpt) {
		//on en retire le code et on ne garde que les 150 premiers caractères
		$extrait = substr(wp_strip_all_tags($result->post_excerpt),0,150);
		//on met à jour la base de données
		$wpdb->update($wpdb->prefix."posts",
			array('post_excerpt'=>$extrait),
			array('post_id'=>$post_id)
		);
	}
	//sinon on utilise le contenu
	else {
		//on supprime les tags HTML et on prend les 150 premiers caractères
		$extrait = substr(wp_strip_all_tags($result->post_content),0,150);
		$wpdb->update($wpdb->prefix."posts",
			array('post_excerpt'=>$extrait),
			array('post_id'=>$post_id)
		);
	}
}

Le fonctionnement est très simple : quand un article est sur le point d’être sauvegardé en base de données, le filtre save_post est déclenché, et notre fonction s’exécute :

add_action( 'save_post', 'dfr_custom_excerpt', 10, 1);

Cette ligne permet également de définir un ordre de priorité pour l’exécution de notre fonction (le 3e argument, laissé ici à la valeur par défaut : 10) et de spécifier quand c’est possible le nombre d’argument que notre fonction accepte (ici 1, référez-vous au Codex WordPress pour savoir quelles actions permettent le passage d’arguments). L’argument en question sera ici l’ID de l’article.

On se sert ensuite de la variable globale $wpdb qui permet les accès à la base de données pour récupérer l’extrait et le contenu du post. Ensuite, si un extrait a été configuré par l’utilisateur, on en supprime purement et simplement tout le code HTML, JavaScript, CSS, PHP … de la même manière qu’on l’a fait pour supprimer le HTML dans les commentaires ou dans les titres. On en profite pour en réduire la longueur à 150 caractères à l’aide de la fonction PHP substr().
Si aucun extrait n’a été rédigé, on appliquera le même traitement aux 150 premiers caractères de l’article. Enfin l’extrait sera sauvegardé en base de données.

De cette manière, vous êtes certains d’avoir toujours un extrait formaté de la même manière à afficher dans vos pages. N’hésitez pas à personnaliser cette fonction pour l’adapter à vos besoins !