Recalculer quoi !?

Mais si, vous savez les compteurs des utilisateurs, triés par rôles dans la page des utiilsateurs de la partie administration !

Table des utilisateurs de WordPress

Il se peut que vous ayez un compteur indiquant (1) – ou 1 de trop, alors que vous n’avez pas – ou moins, de membre associé à ce rôle. Ici pour mon exemple, vous avez supprimé le compte Momo qui était Moderator.

Pourtant, WordPress continue de le prendre en compte.

Comment est-ce possible ?

Et bien, souvenez-vous !

Il se pourrait que vous soyez allé dans la base de données, avec phpMyAdmin avec un plugin portable par exemple, puis que vous ayez supprimé un utilisateur depuis la table wp_users.

Mais avez-vous supprimé les champs des données de cet utilisateur dans la table wp_usermeta ? Pas sûr…

Et c’est là tout le problème, car WordPress ne fait pas de lien entre le nombres de rôles trouvés dans les données utilisateur. Voici un extrait du core :

 * Count number of users who have each of the user roles.
 * Assumes there are neither duplicated nor orphaned capabilities meta_values.

WordPress ne fait que compter les rôles trouvés dans la table wp_usermeta sans tester si l’utilisateur existe encore. Légitime quelque part car vous ne devez normalement pas intervenir de cette façon dans les tables de WordPress. En tout cas, à vos risques et périls…

La preuve, je suis ici pour vous en parler.

Comment régler ce problème de compteur ?

2 solutions comme souvent : une requête MySQL ou une fonction PHP.

#1 – Exécuter une requête MySQL

Ouvrez votre gestionnaire de base de données phpMyAdmin puis exécutez la requête suivante – en prenant soin de remplacer wp_ par votre préfixe de base données WordPress :

DELETE FROM wp_usermeta
WHERE user_id NOT IN ( SELECT concat( ID ) from wp_users )

Cette requête va effacer tous les champs de la table wp_usermeta dont l’ID du membre associé n’est pas dans la table wp_users.

Autrement dit, les champs qui auraient dû être supprimés le seront ici !

#2 – créer une fonction PHP

Autre solution pour ceux qui sont frileux du phpMyAdmin ou qui n’y ont tout simplement pas d’accès, voici le code à copier dans le fichier functions.php de votre thème :

function delete_bad_fields()
{
    global $wpdb;
    $wpdb->query( "DELETE FROM $wpdb->usermeta WHERE user_id NOT IN ( SELECT concat( ID ) from $wpdb->users )" );
}
add_action( 'admin_init', 'delete_bad_fields' );

Puis raffraichissez le panneau administrateur. Si le requête s’exécute plusieurs fois, rien de grave, les prochaines fois ne servent juste à rien.

Vous pouvez supprimer le code de votre fichier maintenant !

Comment prévenir ce problème à l’avenir ?

Si effacer le membre n’est pas possible pour X raisons depuis l’administration de WordPress, exécutez alors ces 2 requêtes, ici pour l’utilisateur dont l’ID est 123 :

DELETE FROM wp_users WHERE ID = 123

DELETE FROM wp_usermeta WHERE user_id = 123

Ou pour dans votre functions.php :

function delete_bad_fields()
{
    global $wpdb;
    $wpdb->query( "DELETE FROM $wpdb->users WHERE ID = 123" );
    $wpdb->query( "DELETE FROM $wpdb->usermeta WHERE user_id = 123" );
}
add_action( 'admin_init', 'delete_bad_fields' );

Edit: ScreenFeed nous parle de wp_delete_user() qui a l’avantage de réassigner les articles à un autre utilisateur, excellente idée, voici le code :

function delete_bad_fields_2()
{
    $delete_this_user_id = 123;
    $reassign_to_user_id = 1;
    $user_exists = new WP_User( $reassign_to_user_id );
    if ( $user_exists &&
         current_user_can( 'delete_user', $delete_this_user_id ) )
      wp_delete_user( $delete_this_user_id, $reassign_to_user_id );
}
add_action( 'admin_init', 'delete_bad_fields_2' );

 Au terme de ce tutoriel, vous serez en mesure de résoudre ce problème de comptabilité. J’attends vos commentaires avec impatience !

#1 – Réinitialisation du mot de passe WordPress via phpMyAdmin

Connectez-vous dans un premier temps à phpMyAdmin via le lien fourni par votre hébergeur (panneau de contrôle cPanel, Plesk ou autre).

Passez en mode structure puis modifier la table wp_users.

Localisez le compte dont vous souhaitez changer le mot de passe à l’aide de la colonne user_login. Faites Modifier.

Modification de wp_users

Notez qu’il vous sera impossible de connaître le mot de passe actuellement en place.

A la ligne user_pass, inscrivez votre nouveau de mot de passe puis sélectionnez MD5 dans la liste déroulante.

Mot de passe WordPress crypté

Validez en cliquant sur Exécuter.

Connectez-vous au back office de WordPress à l’aide du nouveau mot de passe.

#2 – Réinitialiser votre mot de passe WordPress via FTP

Il existe une commande PHP permettant de remettre à zéro un mot de passe WordPress à condition de connaître l’identifiant…. et son ID.

L’administrateur du site est toujours le premier compte ce qui facilite grandement les choses – avec un compte admin vous pourrez modifier n’importe quel autre compte utilisateur.

Ouvrez le fichier functions.php présent dans le dossier du thème sous /wp-content/themes/NOM_DU_THEME/ en effectuant une sauvegarde au préalable.

Placez ensuite les lignes de code suivantes en début de fichier :

<?php
$user_id = 1;
$password = 'nouveaumdp';
wp_set_password( $password, $user_id );
?>

Sauvegardez le fichier puis ouvrez la page de connexion. Avant de valider supprimez immédiatement ces lignes de code sans quoi le mot de passe sera réinitialisé à chaque chargement de page et donc à la connexion proprement dite.

Si vous oubliez de les retirer vous resterez bloqué sur la page de connexion tout simplement.

#3 – Réinitialiser votre mot de passe via un script PHP

Comme indiqué par l’auteur de ce script PHP, utilisez cette méthode à vos risques et périls !

Personnellement, je l’ai testé en local sur la version 3.3.1 de WordPress et… elle fonctionne parfaitement donc là voici en détails.

A l’aide de votre éditeur de texte favori, créer un fichier que vous nommerez emergency.php puis collez-y les lignes suivantes :

<?php
/*
	This program is free software; you can redistribute it and/or modify
    	it under the terms of the GNU General Public License as published by
    	the Free Software Foundation; either version 2 of the License, or
    	(at your option) any later version.

	This program is distributed in the hope that it will be useful,
    	but WITHOUT ANY WARRANTY; without even the implied warranty of
    	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    	GNU General Public License for more details.

	You should have received a copy of the GNU General Public License
    	along with this program; if not, write to the Free Software
    	Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/

require('./wp-blog-header.php');

function meh() {
global $wpdb;

		if (isset($_POST['update']))
		{
			$user_login = ( empty( $_POST['e-name'] ) ? '' : sanitize_user( $_POST['e-name'] ) );
			$user_pass  = ( empty( $_POST[ 'e-pass' ] ) ? '' : $_POST['e-pass'] );
			$answer = ( empty( $user_login ) ? '<div id="message"><p><strong>The user name field is empty.</strong></p></div>' : '' );
			$answer .= ( empty( $user_pass ) ? '<div id="message"><p><strong>The password field is empty.</strong></p></div>' : '' );
			if ( $user_login != $wpdb->get_var("SELECT user_login FROM $wpdb->users WHERE ID = '1' LIMIT 1") )
			{
				$answer .="<div id='message' class='updated fade'><p><strong>That is not the correct administrator username.</strong></p></div>";
			}
			if( empty( $answer ) )
			{
				$wpdb->query("UPDATE $wpdb->users SET user_pass = MD5('$user_pass'), user_activation_key = '' WHERE user_login = '$user_login'");
				$plaintext_pass = $user_pass;
				$message = __('Someone, hopefully you, has reset the Administrator password for your WordPress blog. Details follow:'). "\r\n";
				$message  .= sprintf(__('Username: %s'), $user_login) . "\r\n";
				$message .= sprintf(__('Password: %s'), $plaintext_pass) . "\r\n";
				@wp_mail(get_option('admin_email'), sprintf(__('[%s] Your WordPress administrator password has been changed!'), get_option('blogname')), $message);
$answer="<div id='message' class='updated fade'><p><strong>Your password has been successfully changed</strong></p><p><strong>An e-mail with this information has been dispatched to the WordPress blog administrator</strong></p><p><strong>You should now delete this file off your server. DO NOT LEAVE IT UP FOR SOMEONE ELSE TO FIND!</strong></p></div>";
			}
		}

		return ( empty( $answer ) ? false : $answer );
	}

$answer = meh();
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>WordPress Emergency PassWord Reset</title>
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
	<link rel="stylesheet" href="<?php bloginfo('wpurl'); ?>/wp-admin/wp-admin.css?version=<?php bloginfo('version'); ?>" type="text/css" />
</head>
<body>
<div>
  	<form method="post" action="">
<h2>WordPress Emergency PassWord Reset</h2>
<p><strong>Your use of this script is at your sole risk. All code is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness. Further, I shall not be liable for any damages you may sustain by using this script, whether direct, indirect, special, incidental or consequential.</strong></p>
<p>This script is intended to be used as <strong>a last resort</strong> by WordPress administrators that are unable to access the database.
Usage of this script requires that you know the Administrator's user name for the WordPress install. (For most installs, that is going to be "admin" without the quotes.)</p>
<?php
echo $answer;
?>
<p><input type="submit" name="update" value="Update Options" /></p>

<fieldset>
<legend>WordPress Administrator</legend>
<label><?php _e('Enter Username:') ?><br />
		<input type="text" name="e-name" id="e-name" value="<?php echo attribute_escape(stripslashes($_POST['e-name'])); ?>" size="20" tabindex="10" /></label>
</fieldset>
<fieldset>
<legend>Password</legend>
<label><?php _e('Enter New Password:') ?><br />
		<input type="text" name="e-pass" id="e-pass" value="<?php echo attribute_escape(stripslashes($_POST['e-pass'])); ?>" size="25" tabindex="20" /></label>
</fieldset>

	<p><input type="submit" name="update" value="Update Options" /></p>
  	</form>
	</div></body></html>

<pre>

Envoyez ce fichier à la racine de votre serveur – au même niveau que le célèbre fichier wp-config.php.

Ouvrez votre navigateur Internet puis lancez le script en indiquant http://monsite.com/emergency.php comme URL – prenez soin de remplacer le domaine par le votre.

Changez le mot de passe à l’aide du formulaire en spécifiant dans un premier temps l’identifiant administrateur.

En cas d'urgence, appelez le script PHP !

Indiquez le nouveau mot de passe puis faites Update Options.

Supprimez immédiatement le script emergency.php présent sur votre serveur. Notez que vous recevrez le nouveau de mot de passe sur la boite mail du compte administrateur – ce qui peut poser un risque de sécurité si votre compte a été piraté.

Si vous le préférez, le fichier PHP est disponible en téléchargement direct :

Avec les 3 techniques de remise à zéro de mot de passe WordPress évoquées ici, vous devriez être en mesure de faire face à toutes les situations. Vous connaissez d’autres méthodes alternatives de réinitialisation ? Partagez-les !

Connectez-vous dans un premier temps sur phpMyAdmin. Inutile de me demander la méthode officielle de connexion… elle dépend directement de votre hébergeur. Recherchez donc un module si rapprochant ou demandez de l’aide à ce dernier.

Modifiez ensuite la table intitulée wp_links.

Edition de la table wp_links

Cliquez à présent sur le bouton Modifier – en forme de crayon, pour link_description.

Augmentez la valeur du champ au-delà de 255

Entrez une nouvelle valeur dans le champ Taille. Agissez en fonction de vos besoins mais n’indiquez pas une valeur exponentielle car cela augmentera inutilement la taille de votre base.

Pour confirmer le changement, cliquez sur le bouton Sauvegarder.

Le champ description du module Liens est à présent capable d’accueillir plus de données. Les plus accros d’entre nous appliqueront une modification CSS dans l’admin pour augmenter visuellement la taille du champ… ce sera pour un prochain tutoriel !

N.B : avant toute intervention dans votre base de données WordPress, faites une sauvegarde complète !

Étape n°1 – Édition du fichier wp-config.php

Situé à la racine de votre serveur FTP, le fichier wp-config.php abrite les identifiants de connexion à la base de données.

Ainsi, localisez la ligne suivante qui contient le préfixe des tables de la base :

$table_prefix  = 'wp_';

Il s’agit donc de modifier la valeur par défaut fixée sur wp_

Indiquez un préfixe différent que le classique wp_

Évidement, si celle-ci est déjà fixée sur une autre valeur, parcourez les autres tutoriels du site.

N’oubliez pas de sauvegarder le fichier modifié.

Etape n°2 – Changer le préfixe de l’ensemble de vos tables WordPress

Cette étape est de loin la plus fastidieuse et la plus risquée !

Il vous faut intervenir dans votre base à l’aide de phpMyAdmin ou de l’outil de gestion proposé par votre hébergeur. Connectez-vous donc sur l’administration de votre serveur pour y accéder.

Utilisez les commandes SQL pour un renommage de masse

Exécutez à présent les requêtes SQL suivantes en prenant soin d’indiquer votre nouveau préfixe :

Rename table wp_commentmeta to wplabo_commentmeta;
 Rename table wp_comments to wplabo_comments;
 Rename table wp_links to wplabo_links;
 Rename table wp_options to wplabo_options;
 Rename table wp_postmeta to wplabo_postmeta;
 Rename table wp_posts to wplabo_posts;
 Rename table wp_terms to wplabo_terms;
 Rename table wp_term_relationships to wplabo_term_relationships;
 Rename table wp_term_taxonomy to wplabo_term_taxonomy;
 Rename table wp_usermeta to wplabo_usermeta;
 Rename table wp_users to wplabo_users;

Étape n°3 – Modifications de certains tables de la base MySQL

Si vous en restez là, WordPress ne vous donnera plus les droits d’accès à votre administration. Vous obtiendrez alors, ce type d’erreur :

Faisons en sorte d'obtenir les droits d'accès à votre administration WordPress

Adaptez ce qui suit avec votre nouveau préfixe !

Édition de la table wp_options

Il nous faut donc intervenir dans wp_options, recherchez donc la valeur wp_user_roles dans la colonne option_name et indiquez votre nouveau préfixe.

Cette valeur est située à la ligne 96.

Remplacez le préfixe wp_ par celui que vous venez de définir

Édition de la table wp_usermeta

Changez à présent tout les anciens préfixes de la colonne meta_key au nombre de 5 dans mon cas.

Le nombre de champs à éditer peut varier en fonction de votre version de WordPress

Félicitations ! Nous voici arriver au terme de ce tutoriel qui vous aura montrer comment changer manuellement le préfixe de votre base de données WordPress. Votre site bénéficie à présent d’un niveau de sécurité accru contre les hackers.

N.B : cet article regroupe 22 requêtes MySQL pour le CMS WordPress. Avant toute intervention dans votre base de données, faites une sauvegarde préalable. Vous êtes responsable de vos actions !

Avertissements

Utilisation de phpMyAdmin

Pour exécuter les requêtes listées ici vous devez être capable de vous connecter à phpMyAdmin, un outil généralement accessible depuis l’administration de votre hébergeur (via cPanel ou Plesk par exemple).

Rendez-vous ensuite dans l’onglet SQL correspondant à la base de données préalablement sélectionnée dans la partie gauche de l’interface.

Si vous n’avez jamais utilisé phpMyAdmin, faites très attention ! Vous pourriez tout supprimer en 1 clic de souris, je dis bien un !

Préfixe de la base wp_

Pour chacune des requêtes ci-dessous, n’oubliez pas de remplacer le préfixe wp_ par celui correspondant à votre base de données MySQL.

Il est fort probable que vous n’ayez pas gardé le préfixe par défaut comme il est recommandé par souci de sécurité.

Sauvegarde de votre base

Avant toute intervention dans phpMyAdmin, faites une sauvegarde de votre base MySQL en suivant le tutoriel pour savoir comment sauvegarder automatiquement la base de données MySQL.

Requêtes sur les custom fields

#1 – Ajouter un custom field à tous les articles et pages

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT ID AS post_id, 'MonCustomField'
AS meta_key, 'MaValeur' AS meta_value FROM wp_posts
WHERE ID NOT IN (SELECT post_id FROM wp_postmeta WHERE meta_key = 'MonCustomField');

Cette requête ajoute un champ personnalisé (custom field) à tous les articles présents dans la base.

Pensez à remplacer MonCustomField par le nom du champ en question et MaValeur par la valeur de votre choix.

#2 – Ajouter un custom field dans les articles uniquement

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT ID AS post_id, 'MonCustomField'
AS meta_key, 'MaValeur' AS meta_value
FROM wp_posts WHERE ID NOT IN
(SELECT post_id FROM wp_postmeta WHERE meta_key = 'MonCustomField')
AND `post_type` = 'post';

La même chose que précédemment – avec les mêmes conseils, mais pour les articles seulement.

#3 – Ajouter un custom field dans les pages uniquement

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT ID AS post_id, 'MonCustomField'
AS meta_key, 'MaValeur' AS meta_value
FROM wp_posts WHERE ID NOT IN
(SELECT post_id FROM wp_postmeta WHERE meta_key = 'MonCustomField')
AND `post_type` = 'page';

La même chose que précédemment – avec les mêmes conseils, mais pour les pages seulement.

#4 – Supprimer un custom field de tous les articles et pages

DELETE FROM wp_postmeta WHERE meta_key = 'MaValeur';

Cette requête a déjà été expliquée dans le tutoriel Supprimer des champs personnalisés (custom fields) dans WordPress.

#5 – Supprimer un custom field de tous les articles uniquement

DELETE FROM wp_postmeta WHERE meta_key = 'MyField'  AND `post_type` = 'post';

Idem que précédemment mais pour les articles uniquement.

#6 – Supprimer un custom field de toutes les pages uniquement

DELETE FROM wp_postmeta WHERE meta_key = 'MyField'  AND `post_type` = 'page';

Idem mais pour les pages seulement.

#7 – Changer la valeur d’un custom field

UPDATE `wp_postmeta`
SET `meta_value` = REPLACE(meta_value, 'AncienneValeur', 'NouvelleValeur')
WHERE `meta_key` LIKE 'MonCustomField';

Remplacez AncienneValeur par la valeur à modifier et NouvelleValeur par la valeur qui doit prendre la place de l’ancienne.

Précisez également le custom field concerné en modifiant MonCustomField.

Requêtes sur les révisions

#8 – Effacer l’historique des révisions d’articles et de pages

DELETE FROM `wp_posts` WHERE `post_type` = 'revision'

Cette requête supprime le versionning de vos articles et de vos pages ; autrement dit, les sauvegardes d’état du contenu.

Pour en savoir plus et aller plus loin en spécifiant une date avant suppression, rendez-vous sur le tutoriel Supprimer les révisions d’articles de WordPress.

#9 – Rechercher les articles d’une catégorie donnée

SELECT post_title FROM wp_posts p
JOIN wp_term_relationships r ON r.object_id = p.ID
JOIN wp_term_taxonomy t ON r.term_taxonomy_id = t.term_taxonomy_id
JOIN wp_terms terms ON terms.term_id = t.term_id
WHERE t.taxonomy ='category'
AND terms.name = 'NomCatégorie'
AND p.post_type = 'post';

Cette requête liste les articles présents dans une catégorie déterminée par NomCatégorie.

#10 – Modifier le statut de publication de vos articles d’une catégorie donnée

UPDATE wp_posts p
JOIN wp_term_relationships r ON r.object_id = p.ID
JOIN wp_term_taxonomy t ON r.term_taxonomy_id = t.term_taxonomy_id
JOIN wp_terms terms ON terms.term_id = t.term_id
SET p.post_status = 'publish'
WHERE t.taxonomy ='category'
AND terms.name = 'NomCatégorie'
AND p.post_type = 'post';

Comme précédemment, remplacez le mot-clé NomCatégorie par la catégorie concernée et indiquez le statut de publication de votre choix dans SET p.post_status = ‘publish’ ; soit publish, pending ou draft.

Requêtes de statistiques

#11 – Nombre d’articles publiés en 2010

SELECT COUNT(*) FROM wp_posts WHERE post_status="publish"
AND post_date BETWEEN '2010-01-01' AND '2010-12-31';

Cette requête vous retournera le nombre d’articles parus au cours de l’intervalle de temps défini. N’oubliez pas de formater vos date à l’anglaise et inversant l’ordre du type année, mois, jour.

#12 – Nombre total de commentaires pour vos articles en 2010

SELECT SUM(comment_count) FROM wp_posts WHERE post_status="publish"
AND post_date BETWEEN '2010-01-01' AND '2010-12-31' GROUP BY post_status;

Cette requête MySQL vous renvoie la somme des commentaires validés au cours de l’année 2010. Là encore, vous pouvez varier l’intervalle de temps ou même supprimer la période pour obtenir le total de commentaires – total qui est affiché dans le Tableau de bord de WordPress.

#13 – Top 10 des articles les plus commentés en 2010

SELECT post_title,comment_count FROM wp_posts WHERE post_status="publish"
AND post_date BETWEEN '2010-01-01' AND '2010-12-31'
ORDER BY comment_count DESC LIMIT 0,10;

Cette commande affiche la liste des 10 articles ayant reçu le plus de commentaires en 2010.

#14 – Top 10 des meilleurs commentateurs sur votre site en 2010

SELECT comment_author,COUNT(comment_count) AS F01
FROM wp_comments,wp_posts WHERE comment_approved=1
AND comment_post_ID=ID AND comment_date BETWEEN '2010-01-01'
AND '2010-12-31' GROUP BY comment_author ORDER BY F01 DESC LIMIT 0,10;

Renvoies la liste des 10 lecteurs ayant le plus commenté sur votre site en 2010.

Une nouvelle fois, vous pouvez faire varier l’intervalle de temps.

De là à créer un widget pour afficher le Top commentateur… il n’y a qu’un pas !

Requêtes sur les URLs de WordPress

#15 – Changer l’URL du site et l’URL d’installation (Siteurl et Homeurl)

UPDATE wp_options
SET option_value =
replace(option_value, 'http://www.vieuxsite.fr', 'http://www.nouveausite.fr')
WHERE option_name = 'home' OR option_name = 'siteurl';

WordPress stocke le chemin absolu de l’URL de votre site et de l’accueil dans la base de données.

Si vous transférez celui-ci d’un serveur local vers un hébergement en ligne, votre site ne fonctionnera car les URLs d’installation pointeront vers les dossiers locaux.

Cette requête est donc là pour résoudre ce problème.

#16 – Changer GUID

UPDATE wp_posts
SET guid = REPLACE (guid, 'http://www.vieuxsite.fr', 'http://www.nouveausite.fr');

Après avoir migré votre blog à partir d’un serveur local sur votre serveur en ligne, ou d’un ancien domaine vers un nouveau domaine, vous aurez besoin de réparer les URLs pour le champ GUID dans la table wp_posts. Un point crucial pour convertir correctement vos permaliens en cas d’erreurs de saisie.

#17 – Changer les URLs de contenu

UPDATE wp_posts
SET post_content =
REPLACE (post_content, 'http://www.vieuxsite.fr', 'http://www.nouveausite.fr');

Pour rappel, les liens présents dans vos articles et pages de WordPress sont inscrites en chemin absolu dans la base de données – et non pas en relatif. Vous devez donc là encore indiquer l’adresse du nouveau site.

#18 – Changer le chemin des images seulement

UPDATE wp_posts
SET post_content =
REPLACE (post_content, 'src="http://www.vieuxsite.fr', 'src="http://amazon.nouveausite.fr');

Si vous avez décidé de basculer vos images dans le cloud computing avec Amazon CloudFront par exemple, il est nécessaire de changer massivement les liens pointant vers chacune de vos images.

Il est également nécessaire de mettre à jour le GUID des fichiers joints :

UPDATE wp_posts
SET  guid = REPLACE (guid, 'http://www.vieuxsite.fr', 'http://amazon.nouveausite.fr')
WHERE post_type = 'attachment';

#19 – Mettre à jour les meta de vos articles

UPDATE wp_postmeta
SET meta_value = REPLACE
(meta_value, 'http://www.vieuxsite.fr','http://www.nouveausite.fr');

De la même façon que les requêtes d’URLs précédentes, celle-ci agira sur les différentes informations insérées dans vos articles comme les custom fields pour mettre à jour les adresses.

Requêtes administratives

#20 – Modifier le compte utilisateur admin

UPDATE wp_users SET user_login = 'Nouveau pseudo' WHERE user_login = 'Admin';

Très utile, cette commande permet de changer le pseudo du compte admin créé par défaut. Cette requête n’est plus utile pour les dernières versions de WordPress qui permette une telle chose dès l’installation.

#21 – Remettre à zéro le mot de passe

UPDATE wp_users SET user_pass = MD5( 'nouveau_mot_de_passe' )
WHERE user_login = 'votre_pseudo';

Utilisez cette requête pour modifier à votre convenance le mot de passe de n’importe quel utilisateur WordPress. Il suffit d’indiquer le nouveau mot de passe et le nom de l’utilisateur concerné.

Pour en savoir plus, rendez-vous sur le tutoriel Modifier le mot de passe d’un utilisateur WordPress via phpMyAdmin.

#22 – Supprimer les commentaires en attente de modération

DELETE from `wp_comments` WHERE `comment_approved` = '0';

Envoyez cette requête pour supprimer la totalité des commentaires qui n’ont pas encore été validés. Utile dans certains cas de spamming importants !

Sources

Cette liste a été constituée à partir de nombreux articles trouvés au fil de mes recherches Google et d’anciens tutoriels sur WordPress Channel.

Tout le mérite revient donc à ses auteurs passionnés de WordPress pour leur travail !

• Requêtes MySQL utiles sur le forum francophone de WordPress ;
• 4 hacks pour extraire des statistiques de WordPress ;
• 13 useful WordPress SQL queries you wish you knew earlier ;

Cette liste de requêtes MySQL pour le CMS WordPress n’est sans doute pas exhaustive ! N’hésitez pas à proposer vos propres requêtes pour qu’elles soient ajoutées dans cet article.

Procédure de réinitialisation du mot de passe

Il nous faut dans un premier accéder à phpMyAdmin qui n’est autre que l’outil de gestion des bases de données MySQL via un navigateur Internet.

Pour faire simple, c’est un genre de Microsoft Access.

Ce module est accessible via votre hébergeur, votre plateforme cPanel ou Plesk. Reportez-vous à la documentation de votre hébergeur pour en savoir plus.

Une fois connecté à phpMyAdmin, localisez la table wp_users à partir de la colonne de gauche.

Cliquez dessus pour voir apparaître l’intégralité des comptes utilisateurs de votre site WordPress.

Les mots de passe sont cryptés par défaut.

A l’aide de la colonne user_login, identifiez l’utilisateur dont le mot de passe doit être modifié puis cliquez sur l’icône en forme de crayon pour l’éditer.

Dans le champ user_pass, inscrivez votre nouveau mot de passe puis n’oubliez pas de sélectionner MD5 dans la colonne Fonction.

Saisissez votre mot de passe dans le champ user_pass

Validez en cliquant sur le bouton Exécuter.

Votre mot de passe est à présent réinitialisé et vous remarquerez que celui-ci a bien été crypté dans la table des utilisateurs de WordPress.

Retournez ensuite sur votre page de connexion WordPress et saisissez les nouveaux identifiants de connexion. Vous êtes maintenant connecté avec votre nouveau mot de passe !

Étude de cas : droits insuffisants

Ce tutoriel part d’une expérience récente pour le moins désagréable. Suite au piratage d’un site client, l’un des comptes utilisateurs s’était retrouvé sans aucun droit d’administration.

Autrement dit, j’obtenais le traditionnel message Vous n’avez pas les droits suffisants pour accéder à cette page dès lors que je tentais de me connecter. J’ai donc résolu le problème en modifiant le mot de passe d’un autre compte utilisateur qui m’a permis de me connecter sur l’administration WordPress et donc, au final, de réattribuer les pleins pouvoirs au compte administrateur.

Cet exemple d’application n’est là que pour illustrer l’intérêt de connaître une méthode de réinitialisation des mots de passe directement depuis la base MySQL. C’est en apprenant de la sorte que vous gagnerez en sécurité sur votre site WordPress !

Crédits photo : pbkwee

N.B : cet article fait suite à un mail que j’ai reçu dernièrement à propos d’un bug sur WordPress Channel. L’erreur n’était pas lié à MySQL mais cette personne m’a indiqué 2 liens très intéressants (en anglais) concernant la création de cette fameuse page d’erreur de base de données personnalisée. J’ai donc librement adapté le premier des 2 à ma façon, dont l’original est accessible sur Digging Into WordPress.

Intérêts d’une page d’erreur

Cette page est essentielle et je trouve dommage que personne ne m’en ait encore parlé… depuis le temps que j’utilise WordPress, je n’avais encore jamais lue d’informations à ce sujet !

1. Ainsi, le premier avantage consiste à ne pas indiquer au monde entier que vous subissez un problème lié à votre base de données. La planète n’a pas besoin d’être au courant de ce type d’information et encore moins les hackers… un message personnalisé est donc nettement plus intéressant ;
2. Deuxième point qui rejoint en partie le précédent. Cette page étant entièrement sur-mesure, vous pouvez donc saisir le texte de votre choix et même y ajouter des éléments visuels – un logo, par exemple. Toutefois, rappelons qu’il n’est pas conseillé de surcharger inutilement votre serveur pour le coup ;
3. Troisième point important du point de vue de Google. Ce fichier PHP va retourner une erreur 503 dans l’en-tête indiquant un problème passager. Les robots de Google ne devrait donc pas indexer cette page et revenir plus tard indexer le reste de votre site ;
4. Quatrième point capital à mes yeux, vous serez notifié par e-mail dès qu’une erreur surviendra. Très pratique pour surveiller l’apparition de ce type d’erreur et surtout pour n’en manquer aucune ;

Méthode de création détaillée

Une fois de plus, créez un tel fichier d’erreur avec WordPress n’a rien de compliqué !

A l’aide de votre client FTP favori, localisez le dossier /wp-content/. A l’intérieur de celui-ci, créez donc un nouveau fichier que vous nommerez db-error.php.

Copiez / collez les lignes de code suivantes :

<?php // custom WordPress database error page wpchannel.com
 header('HTTP/1.1 503 Service Temporarily Unavailable');
 header('Status: 503 Service Temporarily Unavailable');
 header('Retry-After: 3600'); // 1 hour = 3600 seconds
 mail("wpchannel@gmail.com", "Database Bug", "Le site rencontre des soucis techniques (MySQL).", "From: WordPress Channel");

?>
<!DOCTYPE HTML>
<html dir="ltr" lang="fr-FR">
 <head>
 <title>503 Service Temporarily Unavailable</title>
 <style type="text/css">
 h1, p {
 font-family: Helvetica, sans-serif;
 font-size: 24px;
 color: #333;
 }
 p {
 font-size: 14px;
 }
 </style>
 </head>
 <body>
 <h1>C'est quoi ce bug ???</h1>
 <p>Bon ok, j'ai bidouillé ma base de données et j'ai planté le site... pas de soucis, le problème n'est que temporaire ! Ou alors, mon hébergeur rencontre quelques bugs... allez savoir pourquoi !</p>
 </body>
</html>

Il ne vous reste plus qu’à sauvegarder le fichier pour valider le tout. Bien entendu, vous pouvez modifier à votre guise les différents éléments et notamment les lignes de texte humoristiques…

Pour les plus téméraires, vous pouvez vous amuser à planter votre base de données en éditant par exemple le fichier wp-config.php situé à la racine de votre installation WordPress. Supprimez par exemple le mot de passe… et voyez le résultat sur votre blog !

Non seulement, vous verrez la page d’erreur mais vous serez également averti par e-mail d’un bug MySQL.

J'ai planté WordPress Channel pour le fun...

Cette technique est donc un moyen supplémentaire de maîtriser les messages d’erreurs qui peuvent survenir sur un site. Dans le même ordre d’idée, vous pouvez créez un modèle de page personnalisé pour les erreurs de type 404 !

Crédits photo : Jon Bishop (spazcer)

N.B : avant d’opérer une quelconque modification dans votre base de données, je vous recommande fortement de visionner le podcast Sauvegarder automatiquement votre base de données MySQL.

Il est donc conseillé d’effacer les révisions d’articles. Toutefois, pour aller plus loin, nous allons faire en sorte que les X dernières soient conservées pour allier performances et sécurité.

#1 – Effacer toutes les révisions d’articles

Exécutez la requête SQL ci-dessous pour supprimer la totalité des versions d’articles. Après cette action, il vous sera impossible de restaurer l’un d’eux à une date antérieure.

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

#2 – Effacer les révisions en fonction d’une date

Pour ne garder que l’historique récent de vos articles, préférez cette requête. La dernière ligne indique une date que vous pouvez modifier ; en l’occurrence, le 1er janvier 2010. Avant celle-ci, toutes les sauvegardes seront supprimées.

DELETE a,b,c

FROM wp_posts a

LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)

LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)

WHERE a.post_type = 'revision'

AND a.post_date < '2010-01-01';

Pour aller plus loin

Il est possible de désactiver le versionning des articles. A l’aide de votre client FTP favori, connectez-vous à la racine de votre site WordPress puis ouvrez wp-config.php.

Ajoutez ensuite la ligne suivante :

define('WP_POST_REVISIONS', false);

En indiquant un chiffre à la place du paramètre false, vous limiterez le nombre de sauvegardes – à 5 dans cet exemple. Idéal pour un système optimisé et sécurisé

define('WP_POST_REVISIONS', 5);

Les révisions d’articles constituent un atout majeur de WordPress. Il n’est pas rare de devoir revenir en arrière après une modification malencontreuse. Entre performances SQL et niveau de risques, à vous de trouver un juste milieu !

Crédits photo : mookxi

La base de données MySQL de WordPress se doit d’être optimisée de façon régulière. Appliquez les consignes de ce tutoriel vidéo selon une base mensuelle me paraît conseillé.

Pour rappel, votre base de données contient vos articles, vos pages, vos commentaires, vos liens, vos configurations de plugins ainsi que votre configuration générale de WordPress. Bref, chaque partie de l’administration WordPress dispose d’une table de stockage dans la base MySQL.

A la différence, le serveur FTP stockera vos contenus multimédias tels que les photos, les vidéos, les sons ou n’importe quel autre type de documents.