open_basedir en Plesk y PrestaShop: arreglarlo sin ponerlo a none

Dos casos del grupo con el mismo origen. En uno, el back-office de un PrestaShop 1.7 mostraba un aviso open_basedir restriction in effect en classes/module/Module.php. En el otro, tras clonar una web en Plesk, el gestor de módulos daba Failed opening required con la ruta de un módulo. En los dos se arregló poniendo open_basedir a none en Plesk, y otro miembro del grupo avisó enseguida: eso quita una capa importante de seguridad. Se puede arreglar sin quitarla.

Los errores

Warning: file_exists(): open_basedir restriction in effect. File(...) is not within the allowed path(s) ... classes/module/Module.php

Compile Error: require_once(): Failed opening required '.../modules/statsregistrations/statsregistrations.php'

El segundo era un PrestaShop 1.7.8.8 con PHP 7.4, recién clonado con la herramienta de Plesk. Al desactivar ese módulo en modo depuración, el error pasaba a otro módulo distinto: señal de que el problema no era del módulo, sino del acceso a los ficheros.

Qué es open_basedir

Es una directiva de PHP que limita las carpetas que pueden abrir los scripts de una web. En Plesk, por defecto, cada web solo puede leer su propio espacio y la carpeta temporal: el valor es {WEBSPACEROOT}{/}{:}{TMP}{/}.

Sirve para contener daños. Si alguien consigue subir un script malicioso a tu tienda, con open_basedir activo ese script no puede leer los ficheros de otras webs del mismo servidor ni los del sistema. Con none, sí. En un servidor con una sola tienda el riesgo es menor; en uno con varias webs, o con un WordPress viejo al lado, es una puerta abierta entre todas.

Por qué salta el aviso

• Tras clonar o mover una web: una causa probable es que el valor de open_basedir estuviera personalizado con una ruta escrita a mano: la copia conserva la ruta de la web original. PHP no deja abrir los ficheros de la nueva, y fallan justo los require de los módulos.
• Cuando se comprueba una ruta fuera de las permitidas: el aviso de file_exists() dice qué fichero se intentó comprobar, y esa ruta es la pista. En el primer caso era /views/templates/hook/HookDashboardZoneTwo.tpl, sin nada delante: una ruta que no está dentro de ninguna web, señal de que algún módulo del panel de inicio pedía su plantilla con la ruta mal formada. Ahí open_basedir solo hace visible el fallo: con none el aviso desaparece, pero el módulo sigue igual.

Cómo arreglarlo sin quitar la protección

1. En Plesk, entra en Sitios web y dominios, elige el dominio y abre su configuración de PHP.
2. Mira el valor de open_basedir. Si tiene rutas escritas a mano, sobre todo de otro dominio, vuelve al valor por defecto: {WEBSPACEROOT}{/}{:}{TMP}{/}.
3. Si el aviso menciona una ruta legítima que tu tienda necesita fuera de su espacio, añádela al final, separada con dos puntos, en lugar de quitar la restricción.
4. Guarda y vacía la caché de PrestaShop (var/cache).
5. Recarga el back-office y el gestor de módulos.

Si dejaste open_basedir en none para salir del paso, vuelve a ponerlo cuando lo tengas arreglado.

Si clonas webs a menudo

Después de clonar, revisa en la web nueva tres cosas que se copian con los datos de la original: la configuración de PHP (incluido open_basedir), el dominio guardado en la base de datos y el .htaccess. Muchos errores raros tras un clonado son una ruta o un dominio de la web de origen que se ha quedado dentro.

Si tu servidor tiene varias tiendas y no tienes claro cómo está configurado, en Rekire lo revisamos dentro de nuestros bonos de horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación