Comment est géré le cache des notifications dans l'admin ?

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
#1
Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.10.1
#~ Url du site :
#~ Hébergeur / Soft : serveur dédié & wamp
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 1.10.1
#~ Installed Modules:
#~ CMSMailer: 2.0.2
#~ FileManager: 1.2.0
#~ MenuManager: 1.7.7
#~ ModuleManager: 1.5.1
#~ News: 2.12.3
#~ Search: 1.7
#~ ThemeManager: 1.1.4
#~ CGExtensions: 1.27.1
#~ MleCMS: 1.10.5
#~ Toile: 1.6.3
#~ CGSmartImage: 1.6.1
#~ Mmmfs: 1.0.9
#~ SimpleSlider: 0.5
#~ SiteMapMadeSimple: 1.2.2
#~ MicroTiny: 1.1.1
#~ FrontEndUsers: 1.16.4
#~ SelfRegistration: 1.6.13
#~ CGSimpleSmarty: 1.4.10
#~ CGBlog: 1.8.1
#~ CGFeedback: 1.5.4
#~ Config Information:
#~ php_memory_limit:
#~ process_whole_template: false
#~ output_compression: false
#~ max_upload_size: 2000000
#~ default_upload_permission: 664
#~ url_rewriting: mod_rewrite
#~ page_extension:
#~ query_var: page
#~ image_manipulation_prog: GD
#~ auto_alias_content: true
#~ locale:
#~ default_encoding: utf-8
#~ admin_encoding: utf-8
#~ set_names: true
#~ Php Information:
#~ phpversion: 5.2.13-pl1-gentoo
#~ md5_function: On (Vrai)
#~ gd_version: 2
#~ tempnam_function: On (Vrai)
#~ magic_quotes_runtime: Off (Faux)
#~ E_STRICT: 0
#~ memory_limit: 48M
#~ max_execution_time: 60
#~ output_buffering: On
#~ safe_mode: Off (Faux)
#~ file_uploads: On (Vrai)
#~ post_max_size: 16M
#~ upload_max_filesize: 8M
#~ session_save_path: /tmp (1777)
#~ session_use_cookies: On (Vrai)
#~ xml_function: On (Vrai)
#~ Server Information:
#~ Server Api: cgi
#~ Server Db Type: MySQL (mysql)
#~ Server Db Version: 5.0.44
#~ ----------------------------------------------
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~


Je suis tombé sur un truc assez space ce matin

je développe un module en local qui dans le fichier principal possède ce code réduit dans notre cas au plus simple :

Code :
function GetNotificationOutput($priority=2)
  {

        $ret = new stdClass;
        $ret->priority = 1;
        $ret->html="toto";
        return $ret;


  }

Ce code permet normalement de générer des alertes dans l'encart prévu a cet effet dans le backoffice.

Seulement rien n'apparait...

Ok je check les alertes en cours : News me dit avoir un article non publié et CMSMailer me dit que la conf des emails n'est pas réglé (un grand classique)

je supprime la news non publiée, je config CMSMailer....

Seulement rien ne change... je reste avec mes deux alertes obsolètes et toujours pas d'alerte personnalisées..


Au bout de deux heures d'attentes, j'ai enfin les alertes obsolètes de parties...

Je vide le cache via les options du font-office : rien
Je réduit à 15m le délai des cron-tache : rien

bref il y a une gestion de cache assez space dans le backoffice et rien ne permet apparemment de le forcer à se renouveler.

Des idées ? (mis à part vider à la brutale le répertoire tmp)
Répondre
#1
Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: #1.10.1
#~ Url du site :
#~ Hébergeur / Soft : serveur dédié & wamp
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 1.10.1
#~ Installed Modules:
#~ CMSMailer: 2.0.2
#~ FileManager: 1.2.0
#~ MenuManager: 1.7.7
#~ ModuleManager: 1.5.1
#~ News: 2.12.3
#~ Search: 1.7
#~ ThemeManager: 1.1.4
#~ CGExtensions: 1.27.1
#~ MleCMS: 1.10.5
#~ Toile: 1.6.3
#~ CGSmartImage: 1.6.1
#~ Mmmfs: 1.0.9
#~ SimpleSlider: 0.5
#~ SiteMapMadeSimple: 1.2.2
#~ MicroTiny: 1.1.1
#~ FrontEndUsers: 1.16.4
#~ SelfRegistration: 1.6.13
#~ CGSimpleSmarty: 1.4.10
#~ CGBlog: 1.8.1
#~ CGFeedback: 1.5.4
#~ Config Information:
#~ php_memory_limit:
#~ process_whole_template: false
#~ output_compression: false
#~ max_upload_size: 2000000
#~ default_upload_permission: 664
#~ url_rewriting: mod_rewrite
#~ page_extension:
#~ query_var: page
#~ image_manipulation_prog: GD
#~ auto_alias_content: true
#~ locale:
#~ default_encoding: utf-8
#~ admin_encoding: utf-8
#~ set_names: true
#~ Php Information:
#~ phpversion: 5.2.13-pl1-gentoo
#~ md5_function: On (Vrai)
#~ gd_version: 2
#~ tempnam_function: On (Vrai)
#~ magic_quotes_runtime: Off (Faux)
#~ E_STRICT: 0
#~ memory_limit: 48M
#~ max_execution_time: 60
#~ output_buffering: On
#~ safe_mode: Off (Faux)
#~ file_uploads: On (Vrai)
#~ post_max_size: 16M
#~ upload_max_filesize: 8M
#~ session_save_path: /tmp (1777)
#~ session_use_cookies: On (Vrai)
#~ xml_function: On (Vrai)
#~ Server Information:
#~ Server Api: cgi
#~ Server Db Type: MySQL (mysql)
#~ Server Db Version: 5.0.44
#~ ----------------------------------------------
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~


Je suis tombé sur un truc assez space ce matin

je développe un module en local qui dans le fichier principal possède ce code réduit dans notre cas au plus simple :

Code :
function GetNotificationOutput($priority=2)
  {

        $ret = new stdClass;
        $ret->priority = 1;
        $ret->html="toto";
        return $ret;


  }

Ce code permet normalement de générer des alertes dans l'encart prévu a cet effet dans le backoffice.

Seulement rien n'apparait...

Ok je check les alertes en cours : News me dit avoir un article non publié et CMSMailer me dit que la conf des emails n'est pas réglé (un grand classique)

je supprime la news non publiée, je config CMSMailer....

Seulement rien ne change... je reste avec mes deux alertes obsolètes et toujours pas d'alerte personnalisées..


Au bout de deux heures d'attentes, j'ai enfin les alertes obsolètes de parties...

Je vide le cache via les options du font-office : rien
Je réduit à 15m le délai des cron-tache : rien

bref il y a une gestion de cache assez space dans le backoffice et rien ne permet apparemment de le forcer à se renouveler.

Des idées ? (mis à part vider à la brutale le répertoire tmp)
Répondre
#2
et finalement comme à mon habitude, c'est après avoir posté que tout se débloque...

Citation :127.0.0.1 bess Automated Task Succeeded GatherNotificationsTask 11/21/11 14:24:24

donc c'est bien une tache cron qui réactive les notifications... bon ben note pour moi même : si un jour t'es emmerdé : sélectionne l'option "a chaque demande" dans la selectbox des durées entre deux taches cron et adieu le cache.
Répondre
#2
et finalement comme à mon habitude, c'est après avoir posté que tout se débloque...

Citation :127.0.0.1 bess Automated Task Succeeded GatherNotificationsTask 11/21/11 14:24:24

donc c'est bien une tache cron qui réactive les notifications... bon ben note pour moi même : si un jour t'es emmerdé : sélectionne l'option "a chaque demande" dans la selectbox des durées entre deux taches cron et adieu le cache.
Répondre
#3
Petite réflexion par rapport à la mise à jour à la demande, ca veut dire qu'à chaque requête, TOUTES les tâches qui sont dans lib/tasks vont être exécutées à chaque action ? Y compris en frontend ? Ou bien uniquement celles effectuées dans l'admin ?

Ne faut-il pas utiliser l'option "a chaque action" seulement quand on développe le site, et plus quand il est en ligne ?
www.web-ep.be - Développeur Web Freelance - Développeur/Intégrateur CMS Made Simple (création de sites, développement de modules/plugins/templates sur mesure), spécialisé dans les sites pour l'immobilier.
Répondre
#3
Petite réflexion par rapport à la mise à jour à la demande, ca veut dire qu'à chaque requête, TOUTES les tâches qui sont dans lib/tasks vont être exécutées à chaque action ? Y compris en frontend ? Ou bien uniquement celles effectuées dans l'admin ?

Ne faut-il pas utiliser l'option "a chaque action" seulement quand on développe le site, et plus quand il est en ligne ?
www.web-ep.be - Développeur Web Freelance - Développeur/Intégrateur CMS Made Simple (création de sites, développement de modules/plugins/templates sur mesure), spécialisé dans les sites pour l'immobilier.
Répondre
#4
tu me pose une colle :|
Répondre
#4
tu me pose une colle :|
Répondre
#5
En regardant un peu le code, je dirais que oui. Sauf si la tâche a été programmée pour ne s'exécuter que tous les X temps depuis la dernière exécution (géré à la main siteprefs). A ce moment, la tâche est appelée mais stoppée avant son exécution complète, mais ca reste à mon sens des appels de fonctions et des chargements d'objets intempestifs. (a vérifier hein j'ai pas analysé en détail)
www.web-ep.be - Développeur Web Freelance - Développeur/Intégrateur CMS Made Simple (création de sites, développement de modules/plugins/templates sur mesure), spécialisé dans les sites pour l'immobilier.
Répondre
#5
En regardant un peu le code, je dirais que oui. Sauf si la tâche a été programmée pour ne s'exécuter que tous les X temps depuis la dernière exécution (géré à la main siteprefs). A ce moment, la tâche est appelée mais stoppée avant son exécution complète, mais ca reste à mon sens des appels de fonctions et des chargements d'objets intempestifs. (a vérifier hein j'ai pas analysé en détail)
www.web-ep.be - Développeur Web Freelance - Développeur/Intégrateur CMS Made Simple (création de sites, développement de modules/plugins/templates sur mesure), spécialisé dans les sites pour l'immobilier.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)