Trucos rápidos para publicar un proyecto Symfony

danii . miércoles 15 de diciembre de 2010. a las 19:22

logo de symfony-check.org

Buscando por la web recursos del framework Symfony me he topado con Symfony-check.org, una web a modo de Checklist con un montón de trucos rápidos para el despliegue de un proyecto Symfony en producción. Lo mejor es que haciendo click en cada item éste se abre y nos proporciona toda la información que necesitamos al respecto, lo cual es útil ya que a veces resulta complicado encontrar un trozo de información específico en la extensísima documentación del framework Symfony.

Algunas son bastante obvias y sirven para el despliegue de cualquier proyecto web (como el proveer un favicon y así ahorrarnos un montón de logs de errores 404 absurdos o utilizar un acelerador de PHP). Hay otras que aunque sean obvias, la verdad es que viene bien que nos las recuerden, ya que el framework Symfony tiene tantas opciones de configuracion que es fácil que nos olvidemos de algo. En mi caso por ejemplo, siempre me olvido del lang=»en» que Symfony genera por defecto en el layout que luego decora todas las páginas. Algunas cosas de la lista ya vienen por defecto en Symfony 1.4 (form protection, template escaping), así que sólo por usar la última versión del framework ya las podemos checkear y olvidarnos de ellas.

A mi juicio, las más básicas y útiles son:

  • Personalizar las páginas de error

    Por defecto Symfony viene con un montón de páginas de error que debemos adaptar a nuestro site:

    • Error 404 («Oops! Page Not Found»). De toda la vida, vamos.
    • Error 500 («Oops! An Error Occurred). Muy útil el truco de lanzar una excepción de Symfony para testear este error:
      //lanzamos excepción de Symfony para "simular" error 500
      throw new sfException('Testeando un error 500 de la muerte');
      
    • «Website Temporarily Unavailable». Si la aplicación ha sido deshabilitada (lo cual no debería ser muy común), o si hemos configurado que se bloquee el site mientras que se está limpiando la caché. Para sitios muy grandes el vaciado de la caché puede durar varios segundos así que es recomendable que bloqueemos el site y mostremos una página de error apropiada en este caso.
    • «Login Required» y «Credentials Required», tendremos que personalizarlas solamente si utilizamos el sistema de logins y credenciales de Symfony.
    • «This Module is Unavailable». Este error nos aparecerá si deshabilitamos un módulo dentro de la aplicación. En ese caso, quizás lo más sencillo sería simplemente redireccionar al Error 404.
  • Testear que el servidor de producción está correctamente configurado

    Por suerte, los chicos de Sensio Labs (creadores de Symfony) han publicado un script en PHP (para ejecutar en el server desde linea de comandos) que se encarga de hacerlo por nosotros. Ojo por que el que nos proporcionan en el Cheat Sheet es de la versión 1.2 del framework, y quizás el script no siga siendo el mismo (de la 1.2 a la 1.4 ha habido bastantes cambios en Symfony, aunque quizás el set up del server no ha cambiado). Por si acaso, aquí podéis descargar el script para la versión 1.4.

  • Activar el sistema de caché de Doctrine

    Si estamos utilizando este ORM. Si estamos utilizando otro, pues cambiar a Doctrine, y después activar la caché 😉

  • Optimizar el Routing de Symfony

    Y la última y en este caso realmente importante, asegurarnos de utilizar siempre nombres de ruta y no pares modulo/acción en el helper link_to para optimizar la velocidad del framework, la cual siempre está bajo punto de mira.

En resumen, un recurso muy útil que conviene tener siempre a mano si estamos trabajando con este genial framework. Esperemos que se curren uno para Symfony 2.0, que ya no queda tanto 🙂

Etiquetas: , , ,

1 Comentario
» Feed RSS de los Comentarios

  1. kolom dice:

    Gracias, hace tiempo que buscaba modificar el error 500 y no encontraba la manera

Enviar comentario