Sobre los permisos en symfony y cuál es mi solución

Hola amiguetes!!

Hoy os traigo mi solución al problema de los permisos en Symfony. Todos los desarrolladores que hemos trabajado con este maravilloso framework conoceremos al dedillo que symfony no sabe gestionar muy bien sus propios permisos cuando se encuentra desplegado en el servidor y creo que todos nos hemos tirado bastante de los pelos cuando empezábamos en el mundo de este framework y no sabíamos porque pasaba. Tengo que aclarar que sobre lo que estoy hablando y cómo yo lo soluciono es bajo un Elementary OS, distribución que mama de Ubuntu, con esto quiero decir que no sé que tal se portarán los permisos en otros sistemas operativos (Windows ejem ejem….)

El origen del problema de los permisos en symfony

Todo esto comienza con dos directorios muy importantes para el framework. Estos directorios son app/cache y app/logs. Estas son las carpetas responsables tanto de guardar los logs de lo que va pasando en el framework, como de guardar una copia del proyecto en cache para así reducir tiempos de carga. Estos dos directorios se suelen subdividir en otros tres directorios diferentes, a saber, /dev , /prod y /test que es la estructura lógica para las tres etapas en el ciclo de vida de un proyecto symfony.

Pues bien, el problema del que hablo viene cuando desplegamos el proyecto, me da igual si es en /dev o /prod, en nuestro servidor. Al acceder a nuestra primera vista, symfony nos arroja un error de que no puede escribir bajo las carpetas de app/cache y app/log y eso esta causado por el usuario que ejecuta el proyecto en /var/www.

Directorios del infierno
Directorios del infierno

Cuando tenemos el proyecto en nuestra carpeta de usuario o en cualquier otro directorio que cuelgue de nuestro $HOME no hay problema porque se ejecutará a través de nuestro usuario que pertenece a un grupo de usuarios que tiene los permisos de lectura y escritura para $HOME y subdirectorios, pero lo que pasa bajo el directorio /var/www es que nuestro usuario actual intenta acceder a zonas en las que no tiene permisos ya que el directorio /var/www unicamente esta gestionado por el usuario www-data y entonces es cuando el proyecto peta y nos avisa que no puede escribir bajo el directorio cache y log.

En la documentación oficial te explican muy bien como solucionar el problemas de los permisos en symfony que pasa por borrar lo que hay en estos directorios en nuestro servidor y volver a darle permisos de escritura al usuario mediante el siguientes comando.

$ sudo chmod +a "www-data allow delete,write,append,file_inherit,directory_inherit" app/cache app/logs

Pero según mi experiencia, se tiene que estar ejecutando este comando de cuando en cuando porque en cada despliegue limpio al servidor que se hace, el sistema decide olvidarse de quien tiene permiso y quien no, así que yo utilizo una técnica totalmente diferente para olvidarme de los permisos y centrarme en seguir programando.

Cómo soluciono yo los errores de permisos en symfony

Ojo, que no digo que mi técnica sea la definitiva ni la mejor de todas, de hecho puede que hasta vaya en contra de las buenas practicas del saber hacer informático pero repito que como a mi me funciona y me siento muy a gusto y cómodo con ella pues sigo adelante y creo que así es cómo debería ser. La cosa es que jamás monto un proyecto symfony, por muy pequeño que sea, sin hacer uso de phing.

Para el que no conozca phing, es una herramienta automatizadora de tareas que se escribe en XML. Con phing puedes hacer cualquier cosa ya que permite ejecutar comandos del sistema y así olvidarte de tareas como mover directorios, borrar ficheros o hacer transferencias entre servidores FTP por ejemplo. El primer artículo que escribí en el blog hablaba de phing y os dejaba la configuración que utilizaba yo por aquel entonces para desplegar un proyecto symfony con tan solo darle a un botón. Os recomiendo que le echéis un vistazo antes para ver de lo que es capaz esta herramienta y la de cosas que podeis hacer teniendo un poquito de imaginación.

Así pues, con phing he conseguido automatizar la tarea de borrar los subdirectorios de app/cache y app/logs y darles permisos 777 en cada despliegue. ¿Que no será la mejor solución? Puede. ¿Que es más fácil darle permisos al usuario y olvidarnos? Posiblemente. ¿Que estos directorios únicamente deberían tener permisos 777 en desarrollo? Pues si.

¿Entonces porque lo hago así? Pues no sé xD es mi manera de trabajar y os la quería enseñar. Pero tal vez es mejor que vosotros acudáis a la documentación oficial y seguir los senderos de la rectitud de lo que nos dice symfony. Y con este chorrazo, os dejo con mi solución.

<target name="dar_permisos_chmod">
<echo msg="Borrando directorios en /var/www/proyecto"/>
<exec command="rm -rf /var/www/proyecto/app/cache/ /var/www/proyecto/app/logs/"/>
<echo msg="Dando permisos chmod de escritura a /var/www/proyecto/app/cache y /var/www/proyecto/app/log"/>
<exec command="chmod -R 777 /var/www/proyecto/app/cache /var/www/proyecto/app/logs"/>
</target>

¡Hasta que volvamos a olernos!

Cómo usar Wordpress junto a Symfony mediante configuración de htaccess

Llevas varios meses desarrollando una aplicación web con Symfony, has entendido todos los conceptos, MVC, Routing, Symfony Rewrite… ahora toca tener un blog que hable de las maravillas de tu aplicación y a través de ella puedas atraer a tu público objetivo. Tu primera opción es delegar a los sabios e instalar un CMS, tal vez tus primeras opciones sean WordPress o Joomla. Cuando estas en plena faena te das cuenta que no es tan fácil como te habías imaginado, empiezas a buscar por todos los rincones de StackOverflow que línea concreta hará que tu htaccess no se queje. Tras mucho buscar sigues sin encontrar nada y cada vez te desesperas más porque no consigues hacer funcionar tu WordPress o Joomla y una idea nueva te viene a la cabeza, desarrollar tu propio CMS, intentas alejarla de tu cabeza porque no quieres pasar por ello cuando ya existen soluciones mejor programadas de lo que podrías hacer tu. Con esta línea temporal he intentado resumir lo que me ha pasado a mi durante la semana pasada y por fin he encontrado la solución.

 

Cómo hacer que WordPress y Symfony cohabiten juntos

En mi semana de investigación y desespero he visto muchas soluciones de todo tipo pero desgraciadamente no funcionaban, o por lo menos, yo al ser un manco no conseguía hacer funcionar en mi proyecto. He visto un par de Bundles interesantes como este para hacer un merge de las funcionalidades de WordPress y Symfony y utilizar ambas dos herramientas dentro del mismo proyecto. También he visto miles de configuraciones del fichero htaccess diferentes, creo que me salen las Regexp por las orejas y es que nunca se me han dado muy bien, siempre las he tenido atragantadísimas.

Dentro de un proyecto Symfony, la parte pública en la que están los controladores frontales es la carpeta /web, pues bien, dentro de la carpeta /web he creado el directorio /blog en el que se alojará toda la instalación de WordPress.

La configuración del fichero htaccess de la carpeta web es la siguiente

DirectoryIndex app.php
DirectoryIndex app.php
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ app.php [QSA,L]
</IfModule>
<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        RedirectMatch 302 ^/$ app.php/
    </IfModule>
</IfModule>

Y la configuración del fichero .htaccess del directorio blog es la siguiente:

DirectoryIndex index.php
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /blog/index.php [QSA,L]
</IfModule>

Con esta configuración lo que estamos haciendo es que cada petición que hagamos a nuestra aplicación, sean los controladores frontales y el sistema de re escritura de symfony los que se encarguen de procesarla y servirla y que cuando queramos acceder a nuestro blog o a algún recurso contenido en el directorio /blog, que sean los controladores de WordPress los encargados de procesar la solicitud. Con estas configuraciones estamos delegando en dos actores diferentes.

Puede que no sea la mejor opción si nos ponemos muy puristas pero es la solución que a mi me ha funcionado.

Si estabais con el mismo problema que yo y habéis caído por casualidad en este blog, espero que os funcione a la perfección como a mi, en cualquier caso podéis utilizar los comentarios para sugerir otras opciones. Y por lo que a mi me respecta…

¡Hasta que volvamos a olernos!

Symfony Framework vs el reto de Viajes y Estudios

Un nuevo proyecto ha nacido. El reto fue lanzado por la empresa sevillana propietaria de la página Viajes y Estudios. En este artículo contaré como estoy ayudando a dicha empresa a mejorar su página web y ayudarles a que tengan un posicionamiento más óptimo.

El escenario

Es de todos bien sabido que en la época de aprendizaje es una muy buena experiencia pasar unas semanas en otro país para practicar el idioma y adquirir ciertas habilidades que no podrías aprender en otro lugar. En esto se basa la premisa de esta empresa, su claim “Colecciona experiencias, no cosas” es una llamada a la acción perfecta para todos aquellos estudiantes que quieren salir de España una temporada con el objetivo de viajar y aprender idiomas.

Sigue leyendo

Phing, automatizar tareas, instalación y ejemplo de despliegue en local

La primera vez que conocí un automatizador de tareas fue con Ant para Java, desde el primer momento me quede maravillado del poder de esta herramienta, desde poder crear y borrar carpetas o ficheros hasta desplegar todo un proyecto entero mediante ssh y tan solo haciendo click. La verdad es que es muy útil para olvidarte de tener que hacer ciertas tareas repetitivas.
Despues de unos años trabajando con Java y con Ant, volví al mundo de PHP. Tenía que empezar un proyecto con Symfony y obviamente queria poder tener la posibilidad de hacer todo lo que hacia con Ant, así que me puse a investigar y descubrí que existe una herramienta para automatizar tareas en PHP y aquí es donde entra Phing, que no es otra cosa que un port de Ant.
Tal y como aparece en su documentación oficial:

PHing Is Not GNU make; it’s a PHP project build system or build tool based on ​Apache Ant. You can do anything with it that you could do with a traditional build system like GNU make, and its use of simple XML build files and extensible PHP “task” classes make it an easy-to-use and highly flexible build framework.

Con Phing, al igual que con Ant, se define un fichero XML en el que se especifican las diferentes tareas que queremos automatizar, como he dicho, estas tareas pueden ir desde la creación de directorios, dar permisos, despliegues de proyectos o la ejecución de test unitarios.

Sigue leyendo