Seleccionar página

migracion

Es curioso el caso con el que me he encontrado recientemente. Os pongo en situación.

Me piden que revise un WordPress que, al activar un Theme que han creado ellos, deja de funcionar. Lo evidente sería pensar que es un error de código en el Theme, pero también hay que saber que ese WordPress ha sido migrado desde un servidor en Linux con Apache, usado como servidor de pre-producción, a un servidor en Windows con IIS, que será el servidor de producción. En el servidor de Linux, todo funcionaba correctamente. Me indican que por lo que han leído el fallo seguramente se deba a la configuración PHP y demás, y que estaba saltando un error 500.

Con esta información, descartamos la idea del error de código. WordPress y Windows no se llevan bien. Se respetan el uno al otro, pero no se llevan bien entre ellos. Y mucho menos si ese WordPress ya ha sido instalado y configurado en un servidor Linux. Toda la configuración a nivel de servidor, evidentemente, no vale. Así que lo primero es comprobar que los Enlaces Permanentes se están creando bien, con un archivo web.config en lugar de un .htaccess.

Pero si realmente este fuera el problema, WordPress simplemente no funcionaría. Ni con el Theme creado por ellos ni con ningún otro Theme. Este no era el caso, puesto que con el Theme por defecto de WordPress, todo funcionaba bien. Así que, tras revisarlo por si las moscas, también queda descartado.

El siguiente paso fue comprobar que la configuración de PHP estuviese correcta. WordPress necesita que ciertos campos en php.ini tengan un valor mínimo, como por ejemplo, el atributo “memory_limit“. Esto es muy común al cambiar de un servidor a otro. Si hemos programado y trabajado con una cierta libertad a cuanto a límites de memoria y de subida de archivos se refiere, al cambiar de servidor podemos encontrarnos con unos límites distintos, y si son más bajos, podría darnos problemas. Así que lo siguiente que revisé fue el límite de memoria en php.ini, pero tenía un valor suficientemente alto para que WordPress funcionase sin problema (algunos plugins complejos, como WPML, necesitan unos 64M para funcionar correctamente, y este servidor los superaba ampliamente).

Así que me centré en buscar qué error estaba saltando en la web. No lo he dicho antes, pero lo único que se veía era una web en blanco, sin contenido de ningún tipo. A veces un error 500 viene con un mensaje de error. Pero no era este el caso. Busqué el index.php de WordPress y activé la salida de errores PHP.

Y me encuentro con el siguiente problema:

Esto cambia bastante las cosas. Tras buscar el archivo que indicaba la ruta y abrirlo, me encuentro con que el código está bien. No existe un } fuera de sitio, como se indica. Así que el error podría ser bien de codificación del archivo, por terminaciones de linea, o bien porque este archivo está siendo incluido en otro archivo de mala manera, o bien porque durante la migración algo no ha ido bien y hay archivos mal copiados/corruptos… Lo cierto es que me sentí más bloqueado incluso que antes. Como si me golpease contra un muro.

¿Y ahora qué?“, me pregunto mientras reviso de nuevo el código. Casi inconscientemente, por puro perfeccionismo y estilo, decido escribir tres letras en el código, y guardar el archivo. Misteriosamente, la web funciona de nuevo. ¿Qué es lo que he hecho?

Muy simple. Las tres letras que escribí fueron “p“, “h“, “p“. Sólo completé una etiqueta <? mal escrita. Como ya sabéis, al programar en PHP, hay que escribir la etiqueta <?php para abrir un bloque de código PHP. Existe una forma contraída, <?, que en teoría funciona igual, pero parece que algunos servidores ya no la admiten porque puede inducir a errores. Este era el caso de este servidor. En el Linux de pre-producción sí se admitía la forma contraída y la web funcionaba, pero en el Windows de producción, no. Al escribir correctamente <?php, el servidor comprendió totalmente su código, y dejó de mostrar el error por un corchete que ahora sí cobraba sentido para él. Evidentemente, había más archivos con fallos similares, que se arreglaron al corregir todos los <? del código. Así que al final, el fallo estaba en el código, que fue lo primero que descarté “por lógica“…

Y por eso, los estándares son importantes y necesarios. No es sólo una cuestión de estilo, también es una cuestión de coherencia.

Y un último consejo. Si estáis pensando en montar un WordPress en un servidor propio, si podéis elegir, que el servidor sea Linux. WordPress y Linux se llevan bastante bien. Os ahorraréis muchos dolores de cabeza.

“La programación puede ser divertida, al igual que la criptografía;
sin embargo, ambas no deberían combinarse”

     .- Kreitzberg and Shneiderman