La variable de entorno WPM_PATH puede impedir que el usuario corra la interfaz web

[acosatom]

La idea de WPM_PATH es poder evitar si o si que el path de la aplicación esté hardcodeado en el código, dándole algo de seguridad al path principal de la aplicación. El problema es que dependiendo de la configuración del servidor, o de si es Apache o NGINX, el usuario puede tener limitaciones a la hora de establecer dicha variable de entorno, por lo que quedará detenido en la interfaz cuando se le informa de que "La variable de entorno [WPM_PATH] no está definida. Asegúrate de definirla".

Por esto, lo ideal sería poder tener una alternativa que pueda ser usada en caso de que no sea viable establecerla, aunque sea en detrimento de una mayor robustez. En todo caso se debería informar al usuario. @P3r4nD

[P3r4nD]

Una forma sencilla podría consistir en tener un archivo .env en la raíz de la interfaz. Si no es posible establecer mediante getenv, leer el .env, el cual sería actualizado durante la instalación con el path correcto. Punto.

Otra idea un poco más elaborada consiste en detectar, durante la instalación, que servidor se está corriendo y preparar el entorno en función de si es Apache, NGINX o Apache + NGINX en modo de proxy inverso. Si es Apache no tiene mayor complicación que crear o añadir en .htaccess un setEnv. Si es NGINX es otro cantar ya que hay que modificar la configuración de NGINX del lado del servidor, entonces se podría informar al usuario para que haga esos cambios manualmente.

Por otro lado como sabes yo no puedo probar la instalación en cPanel, luego se podría optar por la primera opción en espera de que tengamos algún feedback para la instalación en entorno cPanel, ya que dependiendo de la versión de cPanel estoy seguro que habrá que hacer algunas modificaciones para adaptar los paths de cada versión (lo digo de memoria). En este momento se podría implementar la segunda opción...

[acosatom]

Si, por ahora la primera opción podría valer, aunque entonces ya tenemos la variable escrita en el directorio de la interfaz. Pero está claro que todas las alternativas a no tener WPM_PATH definida del lado del servidor, implican guardarla en un archivo oculto, .env, .htaccess. o lo que .sea. En todo caso si se implementa así demás hay que proteger esos archivos:

Por ejemplo para Apache 2.4 alguna de estas:

RedirectMatch 403 /\..*$

<FilesMatch "^\.env">
    Order allow,deny
    Deny from all
</FilesMatch>

location ~ /. {
    deny  all;
}

O algo así para NGINX (que si o si se configura del lado del servidor)

location ~ /\.env { deny all; return 404; }

location ~ /\..*$ { deny all; return 404; }

La segunda opción que comentas, aunque efectivamente sería la apropiada, no cambiará lo que comento aquí...