Desde hace unas cuantas semanas, y tal y como anuncié en este blog, estamos trabajando con un nuevo gestor de proyectos: qdPM. Con el paso del tiempo hemos detectado un error, que se repite con bastante insistencia, y que no está suficientemente documentado. De hecho, en el foro de qdPM se habla de la existencia de este error, pero en la versión 9. Nosotros trabajamos con la 8.2. Alejando Moreno, uno de mis alumnos, logró solucionarlo de manera bastante limpia. Así que procedemos a explicar a continuación cómo arreglar el problema.
Descripción del error
La mayoría de personas que se encuentran con este error identifican siempre el mismo procedimiento: estoy trabajando con el software sin problema y, cuando vuelvo a abrirlo para trabajar al día siguiente, aparece este mensaje:
O algo parecido a: Fatal error: require(): Failed opening required ‘E:/htdocs/qdpm/qdpm-v9/core/lib/vendor/symfony/lib/plugins/sfDoctrinePlugin/lib/database/sfDoctrineDatabase.class.php’ (include_path=’.;C:\php\pear’) in E:\TM\core\lib\vendor\symfony\lib\autoload\sfAutoload.class.php on line 188.
En realidad el error se refiere a un solo fichero, siempre el mismo (sfDoctrineDatabase.class.php), y luego puede variar la ruta que viene a continuación (depende de la instalación de cada uno). Aunque el mensaje dice que es la línea 188 la que falla, con el fin de identificarlo mejor, lo hemos llamado error 188.
¿Por qué se produce?
Primero tenemos que saber que este software se ha creado con Symphony, un framework para trabajar con PHP que tiene determinadas particularidades a la hora de gestionar la información. Una de ellas conlleva lo siguiente: el programa almacena la ruta absoluta (unidad de disco incluida) del sitio desde el que se realiza la instalación.
Si esta instalación se realiza con una solución XAMP, por ejemplo, desde un pendrive, se le asignará la ruta que tenga esa unidad de disco en el ordenador original. Si, a continuación, nos llevamos el pendrive a otro ordenador y la unidad de disco cambia, qdPM será incapaz de encontrar los ficheros de configuración de la base de datos (porque los está buscando en una unidad que no existe) y, por lo tanto, no podrá acceder al programa, mostrando el mensaje tan desconcertante que enseñamos al principio. Evidentemente, este problema se produce sólo en entorno Windows.
La solución
En realidad la forma de solucionar esto es bastante sencilla: sólo tienes que cambiar la letra de la unidad donde se encuentra en pendrive, y ponerle la misma que tenía en el momento de la instalación. Por ejemplo, en la captura de pantalla del principio de esta entrada nos dice que se espera encontrar el fichero de configuración en la unidad G:
Aunque la cosa puede variar un poco, dependiendo de la versión de Windows con la que se trabaje, la filosofía es siempre la misma:
1.- Ir a inicio, localizar “Mi PC”, colocar el cursor encima, darle al botón de la derecha y seleccionar la opción “Administrar”. En la primera captura se muestra el proceso en Windows XP. En la segunda, en Windows 10.
2.- Aparecerá el “administrador de equipos”. A continuación debemos seleccionar “administración de discos”, con lo que aparecerán todos los discos duros del ordenador, y la unidad que tienen asignada en la actualidad.
3.- Seleccionamos la unidad del pendrive (en este caso E:) y, pulsando el botón de la derecha, seleccionaremos “cambiar la letra y rutas de acceso de unidad”.
4.- Del listado de posibles letras que nos ofrece le asignamos aquella que el programa está buscando, y que es desde la que originalmente se realizó la instalación.
Es probable que salga algún mensaje preguntando si deseamos realizar este proceso. Se le dice que “sí”, y se continúa.
Ya sólo queda volver al navegador, poner la url correspondiente y qdPM volverá a funcionar sin problema.
Gracias, Alejandro, por tu trabajo 😉
Manuel De la Penna dice
Hola, es mas simple borrar el contenido de la carpeta “cache” del proyecto de symfony, no hace falta más que eso, los paths se generan nuevamente de manera correcta
Saludos
Manuel De la Penna
Lic. en Sistemas
Jose A. Senso dice
Pues sí, tienes razón, Manuel. Yo estaba obsesionado con que el error era de UniformServer o de nuestra red pero, por lo que me cuentas, la cosa es mucho más sencilla que todo eso.
Muchas gracias por tu aportación 🙂
un saludo,
Jose.