20 réflexions sur « Daily Cleaner Optimizer Lite »

1. bonsoir,
   cela parait intéressant, je n’utilisais clean up mais wp-optimize.
   j’ai vu votre message sur wordpress-fr, si je peux me permettre, il faudrait raccourci votre titre, pour que l’article soit bien référencer.
   Votre titre est en H1
   Daily Cleaner Optimizer Lite

   Vous commencez votre article par un H2 en mettant
   un plugin très léger pour nettoyer et optimiser WordPress automatiquement

   Par contre très bien de mettre comme installation en H3

   1. Bonjour,
      Excellente idée, je viens de raccourcir le titre.

      J’ai aussi wp-optimize, mais je ne l’active que de façon occasionnelle.
      Il a plusieurs défaut :

      • Il se charge en permanence dans la mémoire PHP, même lorsqu’un visiteur visite votre site, ce qui est inutile puisqu’il n’est pas utilisable en dehors du tableau de bord.
      • Il consomme 0,24 Mo de mémoire PHP (8 fois plus que le mien), ce qui sur les pages perso de FREE est rédhibitoire.
      • Il ne nettoie pas mieux que Clean Up, une seule fois, en 3 ans, il a trouvé un fichier à supprimer que Clean up n’avait pas détecté.

2. Bonjour,
   J’ai installé votre plugin mais le lien dans le tableau de bord n’apparait pas (?) et je ne vois pas d’options de réglages dans la liste des extensions.
   Merci pour l’information au sujet de WP-Optimize mentionnée dans votre texte.

   J’utilise WPML pour traduire mon site et en traduisant les chaînes à l’aide de WPML, je constate que deux frameworks (NextGen et le thème Photocrati) que je n’utilise plus sont toujours mentionnés dans la liste des chaînes à traduire. Cela me dit qu’ils sont toujours présents dans la BD. Est-ce que votre plugin effaceraient ces éléments?

   Merci,
   Marcel

   1. Bonjour,
      Ce plugin n’a aucune option ni aucun réglages, il apparait sous forme de widget dans le tableau de bord comme celui de la photo de l’article au point 5.

      S’il n’apparait pas dans la liste des extensions, c’est parce que vous n’avez pas installé le bon dossier. Parfois, lors de la décompression, il se crée plusieurs dossiers portant le nom du fichier imbriqué les uns dans les autres. Vous devez placer celui qui contient le fichier daily-clean-opt-lite.php

      Concernant les chaînes à traduire, ces chaînes sont situés dans les fichiers .po et .mo et ne sont pas situées dans la base de données. Ces fichiers sont à corriger avec le logiciel poedit.

      Si ces chaînes sont présentes dans la table wp_options, il faut utiliser un nettoyeur spécifique de la table wp_options (comme le plugin clean options) ou alors carrément supprimer via phpMyAdmin toutes les options crées par ces plugins dans la table.
      Bonne journée

3. Sympathique plugin tésté et approuvé!

4. Bonjour,
   merci pour cette maj du plugin que j’utilise depuis quelques mois.
   mais je constate maintenant dans le tableau de bord une liste importante de tables non optimisées, et qui le restent même après le lancement de l’outil alors qu’il affiche 0 fichier. Quelle peut être la raison ?

   Je viens juste de passer en wp 4.2.2 mais le pb existait avant.

   Merci.

   1. Bonjour,
      Je ne constate pas ce problème sur mon site.

      Pour analyser le problème ouvrez PhpMyAdmin et vérifiez les pertes des tables avant optimisation. Faites au besoin un capture d’écran ou notez les pertes table par table.
      Puis activez l’optimisation via le plugin et rafraichissez PhpMyAdmin pour vérifier si ces mêmes tables ont été optimisées ou non ou alors si elles ont encore exactement les mêmes pertes.

      Si votre site est très fréquenté, WordPress modifie certaines tables de lui-même lors des visites, donc, les tables peuvent avoir été nettoyées puis actualisées par la visite d’un internaute.
      En tous cas regarder de près avec PhpMyAdmin permettra d’y voir plus clair.
      Bonne journée.

      1. merci de votre réponse.
         En fait, le nombre de fichiers indiqué passe bien à 0 après optimisation mais une liste de 29 fichiers reste au dessus, présentant pour chacune des tables une perte de 426 770 432 octets.
         Mon site n’est pas fréquenté car je suis en train de le développer et il n’est pas annoncé officiellement (l’adresse n’est pas connue).

         Voici ce que je relève :
         • avant optimisation : 10 fichiers mentionnés dans le plugin, aucune perte n’est mentionnée (20 octets) avec phpmyadmin
         • après optimisation : 0 fichiers dans le plugin mais toujours 29 tables listée avec la même perte, 0 octets dans phpmyadmin.

         Je ne sais pas dire ce qui a déclenché le fait que cela fonctionnait parfaitement avant et depuis quand j’observe ce phénomène.
         Merci pour votre aide et bonne journée également.
         Cdlt.

         1. Bonsoir,
            Franchement, je n’ai aucune idée de l’origine de ce problème qui est vraiment étrange.

            Que se passe t-il lorsque vous optimisez les tables avec phpMyAdmin ? Le problème est-il le même ?

            Sinon, pouvez-vous faire une capture d’écran et me l’envoyer par mail ?
            Cordialement.

            1. merci de vos réponses rapides.
               Comment optimisez-vous les tables avec phpmyadmin ? j’ai bien trouvé le choix « Suggérer des optimisations quant à la structure de la table » lorsqu’on est dans l’onglet structure d’une table. Est-ce ça ? si oui, je l’ai fait sur une table, mais cela ne change rien.
               je peux faire des copies d’écran mais à quelle adresse mail puis-je vous les envoyer ?
               Merci.

               1. Bonjour,
                  Comme expliqué dans cette vidéo d’une minute et demi. Sauf qu’au lieu de cliquer sur « Tout cocher », il suffit de cliquer sur « Cocher tables avec pertes«  : Optimiser les tables d’une base de données

                  Remarquez que vous pouvez aussi choisir ces autres options si jamais votre base de données a un problème :

                  • « Vérifier la table »
                  • « Analyser la table »
                  • « Réparer la table »
                  1. alors, je découvre de nouvelles fonctionnalités !
                     • Vérifier les tables donne toutes les tables OK
                     • Analyser donne « table is already up to date » pour les tables OK, cad n’apparaissant pas dans ma liste, mais donne seulement « OK » pour celles qui sont listées
                     • réparer donne « OK » pour les 1ères, et « The storage engine for the table doesn’t support repair » pour les autres
                     • optimiser donne « OK » pour les 1ères et « Table does not support optimize, doing recreate + analyze instead » pour les autres.

                     Certaines tables sont des tables que j’ai créées d’autres sont celles provenant de plugins.
                     J’ai essayé de activer/désactiver, voire supprimer W3 cache, mais cela ne change rien.

                     1. Bon, donc, il y a un problème avec vos tables puisque même phpMyAdmin dit que certaines ne sont pas optimisable ou réparable !
                        Je vous conseille de faire une sauvegarde complète de votre base de données avec phpMyAdmin.

                        • Quelles sont les tables qui ne supportent pas l’optimisation ?
                        • Celles qui ne supportent pas la réparation ?
                        • Sont-ce des tables que vous avez créé vous-même ?
                        • Crées par un plugin ?
                        • Si vous les avez créé vous même, comment avez-vous fait pour les créer ?
                        • Par quelle procédure (importation, création via requête MySQl, autre ?) ?

                        m-à-j 16 h55 min :
                        D’après mes recherches sur le net, c’est parce que ces tables de données sont en InnoDB et non pas en MyISAM.

                        1. C’est vrai, c’est bien le cas. Merci pour vos recherches, je suis désolé de ne pas avoir trouvé moi-même et de vous avoir fait faire des recherches.
                           Comme je le disais, certaines tables sont des tables que j’ai créées d’autres sont celles provenant de plugins (broken llink checker, etc…). Ce qui me surprend c’est qu’il me semble que ce listing apparait depuis peu, alors que j’utilisais les plugins avant que ça n’apparaisse.
                           Pensez-vous qu’il y ait un risque à convertir les tables en MyISAM ? pour cela, j’ai vu qu’il suffisait d’exécuter une requête SQL :

                           ALTER TABLE `table` ENGINE=MYISAM;

                           quitte à le faire à chaque mise à jour des plugins…
                           Autre alternative : laisser tel quel, mais j’imagine que cela prend plus de place dans la BD puisque les tables ne sont pas optimisées ?
                           encore merci et j’espère que mes questions de néophyte auront pu aider quelqu’un dans le même cas…

                           1. Bonsoir,
                              Je viens de trouver une requête MySQL qui permet d’optimiser une table InnoDB. C’est celle-ci :

                              ALTER TABLE table.name ENGINE=InnoDB;

                              Voir : Table does not support optimize, doing recreate + analyze instead
                              Exécutez cette requête MySQL sur une seule table InnoDB via l’onglet SQL de phpMyADmin (après avoir sauvegardé cette même table).

                              Il n’y a pas de risques à convertir en MyISAM. InnoDB permet plusieurs requêtes simultanées sur une même table, ce qui est préférable pour un site web extrêmement visité. Mais, MyISAM fonctionne très bien sur WordPress.

                              Prenez quand même la précaution de sauvegarder la base de données entière au cas où vous ne réussiriez pas du premier coup.

                              Si cela apparait depuis peu, c’est parce que depuis peu votre serveur est au minimum en MySQL 5.5.5 (les tables sont créées depuis lors en InnoDB par défaut) alors que les versions de MySQL antérieures créaient des tables en MyISAM par défaut.

                              De mon côté, je vais chercher à améliorer le plugin pour qu’il distingue de lui-même les tables InnoDB et les MyISAM tout en donnant des informations détaillées pertinentes à l’usager puisque les tables InnoDB n’auraient pas besoin parait-il d’optimisation !?

                              En tous cas merci de m’avoir signalé ce problème, un problème qui se posera avec tous les plugins d’optimisation de la base de données.
                              Bonne soirée

                           2. Merci beaucoup pour toutes vos précieuses infos et le support apporté.
                              La version de mysql que j’utilise est 5.5.43-0+deb7u1, mais effectivement, lorsque je créé une table, celle-ci est par défaut en InnoDB, je n’avais pas vu ce détail !

                              Bonne soirée

                           3. Bonjour,
                              La version MySQL 5.5.43 est supérieure à 5.5.5 car 43 > 5.
                              Pour améliorer le plugin, il suffit que le plugin exécute la requête précédente. Mais le problème est que cette dernière ne fonctionne que lorsque elle est exécutée depuis l’onglet SQL de phpMyAdmin mais pas lorsqu’elle est exécutée via la classe $wpdb de WordPress (qui sert normalement à exécuter des requêtes sur la base de données).
                              A l’heure actuelle, je ne sais pas s’il s’agit d’un bug de WordPress ou non.

                              Je vais contacter à mon tour les développeurs de WordPress pour leur montrer le problème.
                              Dès que j’obtiens une réponse satisfaisante, j’améliorerai le plugin.
                              Bonne journée

5. Bonsoir,
   Je reviens vers vous car je viens de créer 2 nouvelles tables (qui sont donc en InnoDB par défaut) et je m’aperçois que même après l’optimisation, elles présentent 427 819 008 octets de perte.
   Sont-elles d’après vous optimisées malgré l’avertissement de WP ?
   J’avais résolu le pb précédent en les convertissant toutes en MyISAM.
   Merci.
   Cordialement.

   1. Bonsoir,
      C’est un problème que j’ai aussi constaté et dont je n’ai pas réussi à déterminer la cause. Je me demande s’il ne s’agit pas tout simplement de la taille de la table de données. En effet, l’optimisation des tables InnoDB consiste à réécrire complètement la table. Je me demande si sur certains serveurs, selon la taille de la table cette opération échoue tout simplement. J’ai cherché sur le net des explications à ce problème et je n’en ai pas encore trouvé. Donc, pour l’instant, j’en suis réduit à faire des conjectures.

      néanmoins il est toujours possible d’optimiser les tables manuellement avec phpMyAdmin comme indiqué ici : Comment optimiser une base de données dans phpMyAdmin?

      1. OK merci beaucoup !
         bonne soirée.

Les commentaires sont fermés.