Esqueleto de aplicación web con Codigniter 4 y Shield

Caso todos los framework de PHP, al menos los más populares, tienen una forma más o menos automatizada de comenzar una aplicación web desde cero formando un esqueleto de código utilizable para, a partir de él, comenzar a programar el resto de la aplicación.

En el caso del framework Codeigniter, suponiendo que ya tenemos montado un entorno LAMP donde trabajar, en el cual tengamos además instalado el programa Composer para la gestión de dependencias, el proceso para hacerlo sería el siguiente:

En el directorio raíz de nuestro servidor web, creamos el esqueleto básico de la aplicación usando Composer, con el siguiente comando:

composer create-project codeigniter4/appstarter shield

Esto nos genera una carpeta de nombre shield en la que se ha instalado el código base de Codeigniter 4.

A continuación modificamos el nombre del archivo env, que se encuentra en el primer nivel de directorios de dicha carpeta, llamándole .env

Abrimos ese archivo y modificamos la línea donde se especifica la url base de la aplicación, poniendo la que corresponda a la nuestra. Es muy recomendable crear un host virtual en nuestro servidor web, que en este caso podría llamarse shield.local. La línea quedaría entonces:

app.baseURL = 'http://shield.local'

A continuación tenemos que incluir la información necesaria para hacer la conexión a nuestra base de datos, editando el archivo app/Config/Database.php en el que modificaremos la definición de la variable $default para que quede:

 public array $default = [
        'DSN'          => '',
        'hostname'     => 'localhost',
        'username'     => '<mi_usuario>',
        'password'     => '<mi_password>',
        'database'     => '<mi_database>',
        'DBDriver'     => 'MySQLi',
        'DBPrefix'     => '',
        'pConnect'     => false,
        'DBDebug'      => true,
        'charset'      => 'utf8mb4',
        'DBCollat'     => 'utf8mb4_general_ci',
        'swapPre'      => '',
        'encrypt'      => false,
        'compress'     => false,
        'strictOn'     => false,
        'failover'     => [],
        'port'         => 3306,
        'numberNative' => false,
        'dateFormat'   => [
            'date'     => 'Y-m-d',
            'datetime' => 'Y-m-d H:i:s',
            'time'     => 'H:i:s',
        ],

Con esto ya tendríamos una aplicación funcionando, a la cual se puede acceder entrando en la dirección que corresponda a nuestra aplicación, por ejemplo http://localhost/shield o http://shield.local si hemos definido un host virtual.

Un complemento muy interesante de Codeigniter es Shield. Con él, podemos dotar a nuestra aplicación de funcionalidades de autenticación y autorización de forma muy sencilla. Podemos instalarla mediante Composer ejecutando dentro del directorio raíz de nuestra aplicación losl comandos:

composer require codeigniter4/shield
php spark shield:setup 

Una vez que se ejecutan estos comandos sin error, podemos visitar la página de login que se nos ha creado en http://appStarter.local/login

Si, por ejemplo, queremos que los que usen la aplicación estén obligados a identificarse antes de usarla, no tenemos más que entrar en el fichero app/Config/Filters.php y en la definición de la variable $globals poner qué páginas se pueden visitar sin estar autenticado, que serían solamente aquellas relacionadas con el proceso de identificarse o darse de alta. El archivo quedaría como vemos a continuación, donde la línea a incluir aparece macada en negrita:

    public array $globals = [
        'before' => [
            // 'honeypot',
            // 'csrf',
            // 'invalidchars',
            'session' => ['except' => ['login*', 'register', 'auth/a/*', 'logout']],
        ],
        'after' => [
            'toolbar',
            // 'honeypot',
            // 'secureheaders',
        ],
    ];

De esta forma, si navegamos de nuevo a la dirección inicial de nuestra aplicación. http://shield.local, veremos que nos dirige automáticamente a la página de login.

En la web de Codeigniter podemos consultar más información sobre el uso de Codeigniter y Shield.

Yii: error de permisos en /var/lib/php/sessions

Al probar una instalación limpia de Yii2 basic en Debian 12, salta el error:

Estoy ejecutando Yii2 en un directorio web de usuario colgando de /home/<usario>/public_html. Parece que el usuario con el que se ejecuta Yii no tiene permisos para crear una sesión en la carpeta del sistema, que por defecto pertenece a root.

Una solución rápida pero poco aconsejable es cambiar los permisos de la carpeta /var/lib/php/sessions para que cualquier usuario pudiera grabar información en ella, pero no es aconsejable cambiar los permisos de los directorios por defecto de la instalación. Una mejor solución es cambiar en PHP el directorio en el que se guardan las sesiones, creando previamente uno cerca del lugar donde está situado el raíz de nuestra aplicación web. Para ello insertamos las siguientes líneas en el archivo index.php antes de iniciar la sesión:

ini_set('session.save_path',realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../../session'));

ini_set('session.gc_probability', 1);

session_start();

Hemos creado previamente un directorio «session» dos niveles más arriba en el árbol de directorios de donde tenemos situado el index.php de la aplicación.

La primera línea de código indica a PHP que guarde los archivos de sesión en esa carpeta. La segunda es específica para un sistema Debian, donde el borrado de sesiones obsoletas se hace de forma periódica eliminándolas de las carpetas por defecto. Como hemos cambiado la carpeta donde se guardan, tenemos que decirle que limpie sesiones para que no se nos acumulen.

Error instalando HumHub: Zend OPcache API is restricted by “restrict_api”

Al intentar instalar Humhub en un hosting compartido, me ha saltado este error durante la instalación, el cual es debido a que el servidor tiene restringidas las llamadas a OPcache en la configuración de PHP. En concreto, tiene activa la restricción opcache.restrict_api, la cual permite llamar a funciones de la API de OPcache solamente desde scripts de PHP cuya ruta comience con la cadena especificada.

Atención: este error está corregido ya en la versión 1.13.0 de Humhub, donde se aplica la modificación descrita en el punto 2.

Hay dos formas de solucionar este error, dependiendo de si tenemos acceso o no a la configuración del servidor web.

1) Si tenemos acceso al php.ini

En este caso tenemos que editar el php.ini. Accedemos a él, por ejemplo en un servidor Debian 11 lo haremos con :

sudo nano /etc/php/7.4/apache2/php.ini

Encontraremos la línea a modificar haciendo ctrl+W y buscando «opcache.restrict_api». Veremos que la opción tendrá asignada una cadena de texto, la cual tendremos que borrar dejando la línea:

opcache.restrict_api = ""

Que es la opción por defecto. Guardamos el fichero, reiniciamos el servidor con:

sudo systemctl restart apache2

Y ya no debería de saltar el error cuando hagamos la instalación de HumHub

2) Si no tenemos acceso al php.ini

Esta es la situación habitual cuando intentamos instalar Humhub en un hosting compartido. En este caso tenemos que editar el código de HumHub, prefijando las llamadas a la función opcache_invalidate con el símbolo «@», que es la forma que tiene PHP de evitar que salten los errores de una función cuando es ejecutada, silenciándolos. Si buscamos la cadena «opcache_invalidate» en los ficheros del directorio donde hemos extraído el código fuente de HumHub veremos que aparece en varios de ellos, y que en casi todos ya aparece prefijado con la @, salvo en dos (estoy usando la versión 1.21.1, puede que en versiones anteriores o posteriores la situación sea distinta) que son:

/protected/humhub/libs/DynamicConfig.php

/protected/vendor/yiisoft/yii2/rbac/PhpManager.php

Tenemos que modificar el código de forma que la llamada a la función quede:

@opcache_invalidate($configFile)

en el primer fichero y

@opcache_invalidate($file, true)

en el segundo.

No me gusta solucionar un error simplemente ignorándolo, que es lo que hacemos cuando en PHP prefijamos con @ la llamada a una función, pero dado que los creadores de HumHub lo han hecho así en todas las llamadas a la función salvo en dos, creo que ha sido más por olvido que por intención. Esta solución tiene además el problema de que cada vez que actualicemos la versión de HumHub tendremos que volver a editar dichos ficheros para rehacer los cambios, salvo que la actualización no nos los cambie o nuevas versiones corrijan este problema.

Activar xdebug en XAMPP

Después de instalar XAMPP en Windows, para poder hacer debug de una aplicación en PHP con Netbeans hay que hacer unos pequeños cambios en el php.ini que viene por defecto. A partir de este momento consideraremos <xampp_home> el directorio donde hayamos instalado XAMPP, por ejemplo «c:\xampp»

Abrimos el fichero <xampp_home>\php\php.ini

Al final del mismo encontraremos la parte que se refiere a Xdebug. Tendremos que descomentar, es decir, quitar el «;» (las líneas que comienzan con un «;» son consideradas comentarios) de las líneas siguientes:

zend_extension = «C:\xampp\php\ext\php_xdebug.dll»

xdebug.remote_enable = 1
xdebug.remote_handler = «dbgp»
xdebug.remote_host = «127.0.0.1»

Ojo: también tendremos que poner el remote_enable a «1», que por defecto viene a «0». De forma que esas líneas del fichero nos quedan así:

xdebug_php_ini

Reiniciamos el servidor Apache y ya podemos hacer debug de programas PHP en Netbeans

(Tomado de la entrada: http://www.wikihow.com/Configure-XDebug-in-XAMPP-%281.7.2/Later%29-on-Windows )

Drupal 5 con PHP 5.3

El gestor de contenidos Drupal en su versión 5 sólo es compatible con las versiones de PHP hasta la 5.2, por lo que los sitios web que continúan usando la versión 5 de Drupal no funcionarán correctamente en los servidores en los que se haya actualizado el PHP a la versión 5.3 o superior.
Como algunos de estos sitios no es posible actualizarlos a la versión 6 de Drupal (o no hay medios para hacerlo) la única forma de hacer que funcionen lo más correctamente posible es aplicando el patch que aparece explicado en este enlace.
Para instalarlo primero tendremos que descargarnos dicho patch, nos situaremos en el directorio raiz en el que tengamos instalado nuestro Drupal 5, y posteriormente lanzaremos el comando:
patch -p1 < <path_al_fichero>/drupal5php53_0.patch
En caso de que al aplicar el patch no se produjeran los efectos esperados, es posible revertir lo realizado con el comando:
patch -p1 -R < <path_al_fichero>/drupal5php53_0.patch
Para más información sobre la forma de aplicar «parches» en Drupal, consultar este enlace.

PHP no funciona en userdir

Es una tontería, pero puede dar lugar a algún que otro dolor de cabeza: a veces por defecto la instalación de php tiene desactivada la ejecución en los directorios personales (por ejemplo en Ubuntu) por lo que si después de hacer una instalación de apache2 y php5 habilitas el módulo userdir, y generas un fichero php con la función phpinfo() o cualquier otro script de php, lo más seguro es que te aparezca una página en blanco, en vez de ver la información esperada.
La solución es fácil, basta con editar el fichero
/etc/apache2/mods-available/php5.conf
Al final del mismo verás que hay una parte que indica que hay que comentar unas lineas para que los scripts de php funcionen en un directorio de usuario. Esa parte tiene que quedar así:
# Running PHP scripts in user directories is disabled by default
#
# To re-enable PHP in user directories comment the following lines
# (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
# prevents .htaccess files from disabling it.
#<IfModule mod_userdir.c>
# <Directory /home/*/public_html>
# php_admin_value engine Off
# </Directory>
#</IfModule>

Y eso es todo. Después de reiniciar el servidor Apache (service apache2 restart) los scripts de php ya funcionan.
También se podría poner la directiva a «On», pero si lo hacemos así, entonces no podríamos ponerla a «Off» en los ficheros .htaccess si en algún momento queremos hacerlo.