Fonctionnalités principales - Sondages simples ou multi-choix (limite de choix configurable). - Fenêtre d’ouverture (dates de début/fin) et statuts : brouillon, publié, clôturé. - Anti-doublon de vote : par membre (UID), par invité (cookie + IP) . - Résultats en temps réel avec totaux et pourcentages. Blocs : Sondage en cours (affiche les sondages actuellement ouverts). Derniers résultats (paramétrable : limite, votes minimum, n’afficher que les sondages terminés). Administration : Création/édition rapide des sondages (options collées “une par ligne”). Dashboard avec KPI (totaux, activité 24h/7j), top sondages, derniers votes, sondages qui se terminent bientôt, sondages ouverts sans vote, derniers sondages créés. Liste des votes avec filtres (par option, UID/IP) et pagination. Export CSV enrichi (résumé + détail, séparateur au choix, encodage UTF-8 ou “Excel”, pourcentages arrondis). Compatibilité confirmée avec XOOPS 2.5.11, PHP 7.4 → 8.3, MySQL 8.0. Installation Dézippez l’archive et copiez le dossier sondages_pro dans /modules/. Installez le module depuis Administration → Modules. Placez les blocs souhaités (ex. Sondage en cours, Derniers résultats). Créez votre premier sondage (collez les options “une par ligne”). Mise à jour Si vous venez d’une version de test, lancez “Mettre à jour le module” puis videz le cache (templates_c) si nécessaire. Bonnes pratiques Évitez de supprimer/modifier des options une fois le sondage publié et des votes enregistrés (les votes orphelins ne sont plus affichés). En cas de changement, il est préférable de clôturer et dupliquer le sondage. Pour les invités derrière un même IP/NAT, le contrôle anti-doublon reste “best effort”.

Bonjour à toutes et à tous, Je vous présente TDPerfBench, un module simple et pratique pour XOOPS, pensé pour aider les webmasters à mesurer les performances réelles de leur serveur dans un contexte XOOPS (PHP + MySQL + disque). ✅ Important : TDPerfBench est 100% réservé à l’administration XOOPS ➡️ Aucune page publique, aucun affichage côté visiteurs. 🔧 À quoi sert TDPerfBench ? TDPerfBench permet de lancer des tests de performance et de conserver un historique afin de comparer facilement les résultats : après une mise à jour PHP / MySQL après une optimisation (OPcache, réglages MySQL, cache…) après une migration serveur ou simplement pour diagnostiquer un ralentissement 🧪 Profils de benchmark Le module propose plusieurs profils : Light : test rapide Normal : recommandé (bon compromis) Stress : test plus long / plus exigeant Chaque run produit : un score global (plus il est haut, mieux c’est) des temps détaillés par composant (en ms) 📊 Ce qui est mesuré TDPerfBench mesure plusieurs “composants” typiques : DB (MySQL) : performances base de données CPU (PHP) : calculs côté PHP IO (Disque) : lecture/écriture de fichiers (latence disque) TPL : opérations de rendu/traitement type template Le module affiche ensuite : un tableau détaillé des temps, un graphique Temps par composant, et un graphique Score sur les 20 derniers runs (par profil). 🖥️ Contexte matériel (pour mieux comprendre le score) Pour rendre les résultats plus lisibles, TDPerfBench enregistre aussi des informations sur l’état du serveur au moment du test, par exemple : modèle CPU + nombre de cœurs RAM totale / libre disque total / libre charge système (load average) PHP SAPI OPcache (activé ou non + mémoire) ➡️ L’objectif : aider l’administrateur à savoir si son site devient “demandeur” en ressources, ou si une optimisation / upgrade est nécessaire. 📌 Où trouver le module ? Tout se passe dans l’administration XOOPS : Dashboard : lancer un test + voir le dernier résultat Historique : liste des runs Détails d’un run : analyse complète + graphiques Si ça vous intéresse, je peux publier des captures / exemples de résultats, et vos retours sont les bienvenus pour améliorer le module. Voici un tutoriel complet et “communauté XOOPS” pour présenter TDPerfBench (benchmark serveur) + expliquer toutes les pages/fonctions du module et comment lire les résultats. 1) À quoi sert TDPerfBench ? TDPerfBench est un module 100% administration (aucun affichage public) qui te permet de : Mesurer la performance réelle de ton serveur (dans TON contexte XOOPS : PHP + MySQL + disque). Garder un historique des tests, pour comparer après : une mise à jour PHP/MySQL, un changement de serveur, une optimisation (OPcache, réglages MySQL, etc.), une surcharge ou un ralentissement. Il produit : un score (plus il est haut, mieux c’est), des temps par composant (ms), et des infos de puissance serveur (CPU/RAM/Disk/Load/OPcache…) pour interpréter le résultat. 2) Où se trouvent les pages du module ? Tout est dans l’admin : Dashboard : modules/tdperfbench/admin/index.php Lancer un test : modules/tdperfbench/admin/run.php (appelé par le formulaire du dashboard) Historique : modules/tdperfbench/admin/history.php Détails d’un run : modules/tdperfbench/admin/view.php?id=XX Important : si tu vois la page “Accès refusé”, c’est normal : module réservé aux admins. 3) Installation (XOOPS) Copie le dossier tdperfbench/ dans XOOPS_ROOT_PATH/modules/. Installe le module via Administration XOOPS → Modules. Vérifie que les tables sont créées (XOOPS ajoute automatiquement le préfixe, ex: xe53_tdperfbench_runs). Tables SQL utilisées TDPerfBench stocke : les runs (résumés) les métriques (détail par composant) l’environnement serveur (CPU/RAM/Disk/OPcache) Tables (sans préfixe, XOOPS ajoute le préfixe tout seul) : tdperfbench_runs tdperfbench_metrics tdperfbench_settings tdperfbench_run_env 4) Comment lancer un benchmark ? Depuis le Dashboard (admin/index.php) Tu choisis un profil : Light : rapide (test court) Normal : bon compromis (recommandé) Stress : plus long / plus “dur” (utile pour détecter limites) Puis tu cliques Lancer. 👉 Cela envoie un POST vers run.php avec un token de sécurité XOOPS (anti-CSRF). 5) Ce que fait le module “techniquement” A) admin/index.php — Dashboard Rôle : Affiche un résumé “module admin only” Propose le formulaire Lancer un test Affiche le dernier résultat (date, profil, score, versions PHP/MySQL…) Points clés : Utilise $xoopsSecurity->getTokenHTML() pour injecter le token. Récupère le dernier run via SELECT ... ORDER BY id DESC LIMIT 1. B) admin/run.php — Exécute le benchmark et enregistre tout en MySQL Rôle : Vérifie que la requête est bien POST. Vérifie le token XOOPS (sinon “token invalide”). Exécute les tests selon le profil sélectionné. Calcule un score. Enregistre : une ligne dans tdperfbench_runs plusieurs lignes dans tdperfbench_metrics une ligne d’environnement dans tdperfbench_run_env Redirige vers view.php?id=…. Les tests typiques (métriques) Même si le détail exact dépend de ton implémentation, le module suit généralement ces composants : DB (MySQL) : opérations SQL répétées (insert/select/update) pour mesurer la latence et la capacité. CPU (PHP) : calculs répétitifs (hash/loops) pour mesurer la vitesse CPU côté PHP. IO (Disque) : écriture/lecture de fichiers temporaires pour mesurer le débit/latence disque. TPL (Smarty/Template) : rendu “template-like” ou opérations de formatage pour simuler un traitement XOOPS. Chaque test produit : un ms_total un champ extra (infos utiles : nombre d’itérations, requêtes, taille de fichier…). Le score Principe : plus la somme des ms est basse, plus c’est performant. le score est une “conversion” qui monte quand les ms baissent. Règle simple : Score haut = mieux, ms bas = mieux. C) admin/history.php — Historique des runs Rôle : Liste les runs (date, profil, score, versions…) Permet d’ouvrir le détail avec view.php?id=… C’est la page idéale pour : comparer normal vs stress comparer avant/après une mise à jour serveur. D) admin/view.php — Détail complet d’un run + graphiques Rôle : Charge le run demandé via id Charge les métriques associées (tdperfbench_metrics) Charge l’environnement serveur (tdperfbench_run_env) Affiche : des KPI (date, profil, score, total ms) un tableau “Détail des tests” des graphiques Chart.js : Temps par composant Score sur les 20 derniers runs (même profil) (et selon ta version) Infos serveur (RAM/Disk/Load/OPcache) ✅ Pour les graphiques, Chart.js doit être présent ici : modules/tdperfbench/assets/vendor/chartjs/chart.umd.min.js Si tu n’as pas de graph, le symptôme n°1 est : Chart.js 404 (mauvais chemin) ou un JS error console. 6) Comment interpréter les résultats (vraiment) A) Temps par composant (ms) Tu vois souvent un bar chart du style : DB = 120 ms CPU = 80 ms IO = 300 ms TPL = 50 ms Lecture : IO très haut → stockage lent (disque saturé, VPS low-cost, I/O throttling…) DB très haut → MySQL lent (index, charge, config, disque, buffer pool…) CPU haut → CPU faible ou serveur chargé TPL haut → peut indiquer rendu coûteux (souvent moins critique que IO/DB) B) Score (20 derniers runs) But : voir une tendance détecter régressions : “depuis 2 jours, score baisse” C) Environnement serveur (pour donner du contexte) C’est là que ça devient “explicite” : CPU model + cores : plus de cores ≠ toujours plus rapide, mais ça aide. RAM total/free : si free très faible → risque de swap → énorme baisse de perf. Disk total/free : free faible peut impacter (selon FS). Load average (1/5/15) : si load_1 dépasse le nombre de cœurs → serveur probablement surchargé. PHP SAPI : fpm/apache/cgi… (utile pour comprendre le setup). OPcache : ON = mieux OFF = souvent moins bon (recompilation répétée) mémoire OPcache trop faible = parfois “cache plein” = pertes. Ce que l’admin doit regarder : résultat + état serveur au moment du test. Exemple : “score faible MAIS load très haut” ⇒ ce n’est pas forcément “serveur nul”, c’est “serveur occupé”. 7) Conseils “best practice” pour publier des résultats Pour une mesure propre : Lance 3 runs Normal à 2 minutes d’intervalle. Prends la moyenne ou garde le meilleur des 3 (évite les pics). Fais la même chose après : upgrade PHP config OPcache upgrade MySQL migration serveur Tu peux même noter dans le champ notes : “Avant optimisation” “Après OPcache 256MB” “Après migration NVMe” 8) Dépannage (les erreurs les plus fréquentes) “Token invalide” Cause : le formulaire n’a pas envoyé de token, ou run.php ne fait pas check() correctement, ou tu as une page en cache/proxy qui renvoie un vieux token. Solution : vérifier que index.php a bien : $xoopsSecurity->getTokenHTML() vérifier que run.php fait bien le check avant exécution. “Run introuvable” Cause : l’ID n’existe pas ou le run n’a pas été inséré (erreur SQL) Solution : vérifier la table _runs et les logs PHP. tester un run et voir si une ligne est créée. Pas de graphiques Cause : mauvais chemin Chart.js (404) erreur JS Solution : ouvrir console navigateur (F12) vérifier la présence du fichier : /modules/tdperfbench/assets/vendor/chartjs/chart.umd.min.js 9) Résumé “présentation forum XOOPS” (copiable) Module admin-only Profil light/normal/stress Historique + view détaillé Mesure DB/CPU/IO/TPL Capture environnement serveur (CPU/RAM/Disk/Load/OPcache) Graphiques Chart.js Objectif : comparer et diagnostiquer

XOOPS Pulse est un module de statistiques léger pour XOOPS, pensé pour aider les webmasters à mieux comprendre l’audience de leur site sans outils externes. Il enregistre automatiquement des “hits” (visites) et collecte des informations utiles comme la page consultée, le type d’appareil (mobile/desktop), le navigateur, le système d’exploitation, la résolution/viewport, la langue, le fuseau horaire, le mode sombre, ainsi qu’une IP anonymisée. Dans l’administration du module, vous disposez ensuite d’un tableau de bord et de graphiques (activité par jour/heure, répartition OS/navigateurs, mobile vs desktop, dark vs light, top pages). Le module intègre aussi un système de filtrage via pulse_config.php (exclusion bots, IP/réseaux, UID spécifiques, gestion des invités) et une purge automatique pour limiter la rétention des données. ✅ Important : toutes les statistiques et pages du module sont visibles uniquement depuis l’administration XOOPS (aucun affichage public). 🔒 RGPD : les adresses IP ne sont pas stockées en clair — Pulse enregistre une IP masquée/anonymisée, par exemple 192.168.1.123 devient 192.168.1.0 (ou 192.168.1.x), ce qui limite l’identification directe des visiteurs et respecte les bonnes pratiques RGPD.