Hola, tengo una duda con la caché de Symfony2 en el entorno de desarrollo. Cuando cambio cosas en un controlador y quiero comprobarlas, me obliga a vaciar la caché. Ya cambié esto en mi app_dev.php:
//$loader = require_once DIR.'/../app/bootstrap.php.cache'; $loader = require_once DIR.'/../app/autoload.php'; Debug::enable(); require_once DIR.'/../app/AppKernel.php'; $kernel = new AppKernel('dev', true); //$kernel->loadClassCache();
¿Qué más puedo hacer para que esto no ocurra?
Gracias
Respuestas
@HectorPrats, siento que estés sufriendo este problema con Symfony. La buena noticia es que debe tratarse de algún error de configuración porque es completamente seguro que en el entorno de desarrollo puedes cambiar controladores, plantillas y clases y ves los cambios al instante sin tener que borrar la caché.
Lo primero que te aconsejo es que no cambies el contenido del archivo app_dev.php. Te pego a continuación el contenido original tal y como se puede ver en GitHub:
<?php use Symfony\Component\HttpFoundation\Request; use Symfony\Component\Debug\Debug; // If you don't want to setup permissions the proper way, // just uncomment the following PHP line // http://symfony.com/doc/current/book/installation.html#configuration-and-setup //umask(0000); // This check prevents access to debug front controllers that are deployed // by accident to production servers. // Feel free to remove this, extend it, or make something more sophisticated. if (isset($_SERVER['HTTP_CLIENT_IP']) || isset($_SERVER['HTTP_X_FORWARDED_FOR']) || !(in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1')) || php_sapi_name() === 'cli-server') ) { header('HTTP/1.0 403 Forbidden'); exit('You are not allowed to access this file. Check '.basename(FILE).' for more information.'); } $loader = require_once DIR.'/../app/bootstrap.php.cache'; Debug::enable(); require_once DIR.'/../app/AppKernel.php'; $kernel = new AppKernel('dev', true); $kernel->loadClassCache(); $request = Request::createFromGlobals(); $response = $kernel->handle($request); $response->send(); $kernel->terminate($request, $response);
Lo segundo que debes asegurarte es de que tienes bien resuelto el tema de los permisos de Symfony, ya que la carpeta de la caché es una de las que tienen que estar bien configuradas.
La mejor solución para el entorno de desarrollo es cambiar el usuario con el que se ejecuta tu servidor web. Si haces que Apache se ejecute con el mismo usuario de tu consola de comandos, no deberás preocuparte jamás por el tema de los permisos. Si no puedes optar por esta solución, lee este artículo para conocer otras posibles soluciones.
@javiereguiluz
Hola, gracias por la rápida respuesta. Lo que he cambiado lo vi en How to Optimize your Development Environment for Debugging para ver si me lo solucionaba, pero nada.
Trabajo con WAMP (entorno Windows), y lo hago sobre una instalación limpia, recién descargada con Composer. Me pasa con todos en general y, hasta que no borro caché con app\console cache:clear, no me muestra cambios.
@HectorPrats
Por otro lado, no tengo ese problema al cambiar las plantillas. Sólo me ocurre con las cosas realizadas en el controlador.
@HectorPrats
OK, a ver.. después de probar varias cosas... es algo relacionado con el WAMP. Curioso. Algo cachea y no pregunta. Pero sólo a las modificaciones del controlador es cuando da fallo.
@HectorPrats
Como no uso WAMP no te puedo ayudar con los pasos concretos a seguir, pero te comento que me pasó algo parecido hace tiempo. En mi caso yo uso Zend Server y sus creadores decidieron que estaría genial activar por defecto una cosa llamada Zend Cache que es como una especie de caché por encima de todas las demás (APC, OPcache, etc.) Así que es posible que WAMP tenga una super caché parecida.
Otra cosa que podría suceder es que por defecto la configuración de APC o OPcache (o lo que utilice) sea muy exagerada y tarde demasiado tiempo en comprobar si los archivos fuente han cambiado. En OPcache por ejemplo tienes la opción opcache.revalidate_freq con un valor por defecto de 2. Esto significa que si haces una petición y 1 segundo después otra, esta segunda se sirve cacheada aunque haya cambiado el archivo original. Pero si la segunda petición llega 3 segundos después que la primera, entonces sí que se comprueba si ha cambiado el archivo.
@javiereguiluz
¿Te puedes creer que es eso exactamente lo que me pasaba? Estaba en 60. Dios sabe por qué y desde cuándo.
No hay info de esto en la red y sí muchas preguntas, seguro que solucionas el problema a mucha gente.
Gracias Javier.
@HectorPrats