Tu veux savoir combien de personnes lisent tes articles ? Je te propose une approche simple mais futée pour mettre en place un compteur de vues dans WordPress.
🎯 Le principe du compteur de vues WordPress : ultra simple !
L’idée est basique : quand quelqu’un arrive sur un article, on compte potentiellement une vue. WordPress nous facilite la vie avec son hook :
add_action('wp', 'count_post_view');
Pourquoi ce hook ? C’est a ce moment que WordPress est correctement chargé, on peut commencer a utiliser les fonctions de WordPress. Donc c’est tout bon et suffisant (pas besoin de init par exemple)
🔍 La logique WordPress : filtrer les mauvaises vues
Mais attention, toutes les visites ne sont pas des vraies vues ! On va filtrer tout ça :
if (!is_singular('post')) return; // Nope, pas un article
if (wp_doing_ajax()) return; // Une requête AJAX, on zappe
if (is_whitelisted_ip()) return; // C'est nous, on compte pas
if (is_bot()) return; // Un robot, next !
if (has_recent_view()) return; // Déjà vu récemment, on passe
1. Les IPs à exclure
On ne veut pas compter nos propres visites (développement, tests…) :
function is_whitelisted_ip() {
$excluded_ips = [
'127.0.0.1', // Localhost
'176.101.102.103', // Ton IP de dev
// etc..
];
return in_array($_SERVER['REMOTE_ADDR'], $excluded_ips);
}
2. Les robots, dehors !
Les bots s’annoncent poliment (avec le userAgent), profitons-en :
$bots = ['bot', 'crawler', 'spider', 'slurp', 'googlebot'];
3. Identifier les visiteurs proprement
On crée un identifiant unique et anonyme pour chaque visiteur :
$visitor_id = hash('sha256',
$_SERVER['REMOTE_ADDR'] .
NONCE_SALT . // Notre petit secret
$_SERVER['HTTP_USER_AGENT']
);
4. Pense a afficher les vues
Il faut bien voir les vues dans le Bo :
add_filter( 'manage_posts_columns', 'add_views_column' ); add_action( 'manage_posts_custom_column', 'display_views_column', 10, 2 );
💾 Stockage des vues WordPress : tout en base de données !
Exit les cookies, on garde tout en base de données :
CREATE TABLE wp_post_views_log (
id bigint(20) NOT NULL AUTO_INCREMENT,
post_id bigint(20) NOT NULL,
visitor_id varchar(64) NOT NULL,
view_date datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
KEY post_visitor (post_id,visitor_id),
KEY view_date (view_date)
)Analyse de l’intérêt d’une table dédiée vs meta
Solution avec meta uniquement :
$visitor_id = get_visitor_id(); $views_log = get_post_meta($post_id, '_post_views_log', true) ?: array(); $views_log[$visitor_id] = time(); update_post_meta($post_id, '_post_views_log', $views_log);
Problèmes :
- Performance : La meta stocke un array qui grossit continuellement
- Nettoyage : Difficile de nettoyer les anciennes entrées
- Requêtes : Compliqué de faire des requêtes complexes (par date, par visiteur…)
- Scalabilité : Limite de taille de la meta en base
Solution avec table dédiée :
SELECT COUNT(*) FROM wp_post_views_log WHERE post_id = 123 AND visitor_id = 'xyz' AND view_date > DATE_SUB(NOW(), INTERVAL 24 HOUR)
Avantages :
- Performance : Index optimisés
- Nettoyage : Simple suppression par date
- Requêtes : Statistiques avancées possibles
- Scalabilité : Pas de limite de taille
Les performances : Meta vs Table dédiée
Imaginons 1000 vues sur un article. Pour vérifier si un visiteur a déjà vu l’article dans les dernières 24h :
meta 🐌
$views_log = get_post_meta($post_id, '_post_views_log', true); // On récupère un GROS tableau de 1000 entrées // On boucle dessus... for... foreach... 🥱 // On compare les timestamps un par un... 😴 // C'est long, c'est moche, ça pique les yeux
table dédiée 🚀
Je vais pas remettre le code un peu plus haut mais => Une requête, un index, c’est plié ! 💪
Bref, c’est mieux et c’est comme ça. Point final, on en parle plus ! 😎
En résumé
- Une visite = une vue potentielle
- On filtre les cas indésirables
- On identifie proprement les visiteurs
- On stocke tout en base
- On nettoie régulièrement
C’est tout ! Simple, efficace et maintenable.
Conclusion
Le gros du code est là, tu as les éléments principaux et la logique pour le faire fonctionner et l’ajuster avec tes besoins spécifiques.
Dans mon cas, je l’ai mis en place avec :
- Une petite classe PHP pour tout organiser proprement
- Un style custom en back-office pour une meilleure lisibilité
- La possibilité de trier les articles par nombre de vues
- Une colonne dédiée dans l’interface d’administration

Pour aller plus loin…
Il y a encore pleins de choses qu’on pourrait rajouter ! 🚀
Quelques idées pour pousser le concept :
Côté Front-end 🎨
- Afficher le compteur de vues sur les articles
- Visualiser les articles populaires (et pourquoi pas un bloc Gut ?)
Côté Back-office 🛠
- Un bouton « Reset compteur » par article
- Une action de masse pour réinitialiser plusieurs compteurs
- Implémenter un nettoyage automatique des vues > 30 jours
Notifications et Statistiques 📊
- Envoyer un mail quand un article cartonne (1000+ vues)
- Générer des rapports hebdomadaires de performance
- Créer un dashboard avec des graphiques d’évolution
Et bien d’autres possibilités…


Excellent ! Merci pour cet article 😀