2011-01-19 12 views
8

Por lo tanto, en uno de nuestros lanzamientos recientes tuvimos muchos eventos que estábamos observando, como controller_action_predispatch. Una vez que el sitio se puso en marcha, comenzamos a darnos cuenta de que a nuestros observadores nunca se les llamaba por ellos. Después de una pequeña investigación uno de nuestros desarrolladores encontraron esta bloque de código en Mage_Core_Model_App alrededor de la línea 292Enterprise Edition Los eventos del controlador no se activan si la memoria caché de la página completa está habilitada

if ($this->_cache->processRequest()) { 
      $this->getResponse()->sendResponse(); 
     } else { 
      $this->_initModules(); 
      $this->loadAreaPart(Mage_Core_Model_App_Area::AREA_GLOBAL, Mage_Core_Model_App_Area::PART_EVENTS); 

      if ($this->_config->isLocalConfigLoaded()) { 
       $this->_initCurrentStore($scopeCode, $scopeType); 
       $this->_initRequest(); 
       Mage_Core_Model_Resource_Setup::applyAllDataUpdates(); 
      } 

      $this->getFrontController()->dispatch(); 
     } 

Como se puede ver si $ this -> _ Cache> processRequest() que es verdad, que es cuando la caché de página completa está habilitado para que nunca llegue al despacho. El desarrollador encontró http_response_send_before que recibe llamadas de cualquier manera pero me parece que esto es un error o nunca deberías usar esos eventos de despacho de controladores para nada si tienes habilitado el caché de página completa. ¿Alguna idea?

Respuesta

7

Dada la naturaleza del almacenamiento en caché de la página completa, yo diría que esto "funciona según lo previsto". Si bien puede ser un poco extraño no tener algunos eventos encendidos, tuvieron que elegir una línea y esta tiene sentido para mí, especialmente porque el controlador nunca se despacha realmente.

Debe utilizar esos eventos de envío del controlador para cualquier cosa que afecte a la página (ya que aún debe generarse), pero si lo está utilizando para el seguimiento y tal, no, no sería apropiado.

+0

Veo lo que dices, obviamente, si tienen la memoria caché y pueden mostrar la página, entonces no sigas toda la ruta de envío. Lo estábamos usando para los parámetros en la url. Parece que usaremos ese otro. ¿Sabes si esto será cierto para la página del carrito y las páginas de pago? Tengo otro proyecto en el que hago algo con controller_action_predispatch_checkout_cart_index y sería una mierda tener que encontrar una forma diferente. Estoy eliminando algo de la sesión –

+0

Es trivialmente comprobable, pero seguiría adelante y supongo que tampoco despacha ese evento. –

+0

Sí, acabo de probar y tiene sentido que no guarden en caché la página completa del carrito y no parece que lo hagan. Llegó a mi evento cada vez. Obviamente, no puede almacenar en caché el carrito y el pago debido a los datos que se ponen para cada usuario y cambia –

1

El único evento fiable para escuchar con y sin la página índice caché habilitada es http_response_send_before.

Cuestiones relacionadas