Error fatal de PHP al migrar de Guaraní 3.17 a 3.20 (instancia_exp_local)

SIU-Guaraní SIU-Guaraní - Técnicos
1

Buenas tardes.

Estoy intentando hacer la migración de Guaraní 3.17 a 3.20 en producción, siguiendo los pasos que se detallan en https://documentacion.siu.edu.ar/wiki/SIU-Guarani/Version3.20.0/actualizacion_de_produccion/gestion, en el orden allí indicado.

El servidor está corriendo Ubuntu 22.04.

Verifiqué los requisitos previos, donde se indica que es necesario PHP 7.4; el servidor tiene instalado PHP 8.1.

Al ejecutar ./guarani instancia_exp_local (paso 4), se presenta el siguiente error:
PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /usr/local/proyectos/guarani/vendor/rospdf/pdf-php/src/Cpdf.php on line 2380

Investigando, vi que este error se presenta a partir de PHP 7.4, que es la versión mínima necesaria para Guaraní 3.20, por lo cual entiendo que no fue causado por tener una versión posterior a la mínima requerida.

¿Cómo podría solucionar este problema?

Desde ya, muchas gracias.

2

Hola

En la notación de versiones, la x es un comodín que se utiliza para indicar una versión específica de mayor o igual número principal y secundario, pero cualquier número de versión posterior.

Por ejemplo el que se indica en la documentación para PHP “7.4.x” indica que PHP debe ser compatible con la versión 7.4.x, lo que significa que puede ser cualquier versión de la 7.4, pero siempre y cuando sea la versión principal y secundaria de la 7.4.

Por lo tanto, “7.4.1”, “7.4.2”, “7.4.3”, y así sucesivamente, son todas versiones compatibles con “7.4.x”, pero las versiones “7.3.33”, “8.0.0” no lo son

Saludos!

3

Hola Juan, agrego a lo de Sergio:

Si tenes las versión 3.20.0 vas a tener que usar PHP 7.4, ver Requisitos previos.

Al ejecutar ./guarani instancia_exp_local (paso 4), se presenta el siguiente error: PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported in /usr/local/proyectos/guarani/vendor/rospdf/pdf-php/src/Cpdf.php on line 2380

Guaraní 3.20.0 utiliza la librería rospdf/pdf-php versión 0.12.63, en la cual ya se arregla el problema de usar llaves en lugar de corchetes, es mas en la linea 2380 ya no se correspondería con el error que te da.

El problema debe ser que tenes las versión 3.17 de Guaraní y al tener PHP 8.1 da error, ya que se utiliza la versión 0.12.51 de la librería rospdf/pdf-php, y esta ultima usa llaves {} en lugar de corchetes , fíjate acá.

Creo que el comando ./guarani instancia_exp_local esta pensado para ejecutarse con la versión de PHP 7.1 que es la que utiliza Guaraní 3.17.

Referencias:

https://www.php.net/manual/en/migration74.deprecated.php#migration74.deprecated.core.array-string-access-curly-brace

saludos.
4

4

Gracias por la pronta respuesta.

Creí, erróneamente, que los requisitos previos tenían que cumplirse antes de migrar, pero veo que algo entendí mal.

Voy a intentar desaactualizar PHP a la versión 7.1, a ver si con eso se soluciona el problema y puedo avanzar con la migración.

Muchas gracias.

5

Hola Juan Manuel,

Claro, es un caso raro lo que esta pasando, ya que tenes la versión de 4 dígitos de Guaraní 3.17 con PHP 8.1, pero aunque tengas PHP 7.4 también dará error ya que la librería rospdf/pdf-php esta en la versión 0.12.51.

Lo extraño es que el comando bin/guarani instancia_exp_local cargue el archivo vendor/rospdf/pdf-php/src/Cpdf.php, lo vamos a analizar.

Una solución rápida seria editar el archivo vendor/rospdf/pdf-php/src/Cpdf.php y en los lugares que se use llaves para los arrays reemplazar por corchetes, ej:

Antes: https://github.com/rospdf/pdf-php/blob/0.12.51/src/Cpdf.php#L2375


    /**
     * set the color using hex code.
     */
    public function setHexColor($hex)
    {
        // fill color
        $color = str_replace('#', '', $hex);
        if (strlen($color) == 3) {
            $color = $color{0}
            .$color{0}
            .$color{1}
            .$color{1}
            .$color{2}
            .$color{2};
        }
        $r = number_format(hexdec(substr($color, 0, 2)) / 255, 4);
        $g = number_format(hexdec(substr($color, 2, 2)) / 255, 4);
        $b = number_format(hexdec(substr($color, 4, 2)) / 255, 4);
        $this->setColor($r, $g, $b);
    }

Después: https://github.com/rospdf/pdf-php/blob/0.12.63/src/Cpdf.php#L2379


    /**
     * set the color using hex code.
     */
    public function setHexColor($hex)
    {
        // fill color
        $color = str_replace('#', '', $hex);
        if (strlen($color) == 3) {
            $color = $color[0]
            .$color[0]
            .$color[1]
            .$color[1]
            .$color[2]
            .$color[2];
        }
        $r = number_format(hexdec(substr($color, 0, 2)) / 255, 4);
        $g = number_format(hexdec(substr($color, 2, 2)) / 255, 4);
        $b = number_format(hexdec(substr($color, 4, 2)) / 255, 4);
        $this->setColor($r, $g, $b);
    }

saludos.
2

6

Hola Juan Manuel,

Probemos lo siguiente, proba los pasos de esta documentación, pero el paso 4 hacelo primero antes de actualizar la versión de PHP, es decir con PHP 7.1:

Exportar datos locales. Dentro de la carpeta 'bin' (/bin) ejecutar: ./guarani instancia_exp_local

Dicho comando exporta los perfiles funcionales.

Luego podes actualizar a PHP 7.4 y seguís con el resto de los pasos, con eso no te debería dar el error.

Foro de referencia: Migración de perfiles funcionales y de datos de 3.15 a 3.18 - UNPSJB - nº 2 por sespinola - SIU-Guaraní - Técnicos - Foro Comunidad SIU

saludos.
2

7

Buenas tardes.

Pude solucionar el problema desactualizando PHP a la versión 7.1 y luego subiendo a la 7.4.

Ahora aparece otro problema: al intentar el paso 7 de la actualización (Instalar vía Composer las dependencias del proyecto), ejecuto composer install --prefer-dist --no-dev --optimize-autoloader, y luego de varias advertencias de tipo “Failed to download wikimedia/composer-merge-plugin from dist: [...] Permission denied”, termina apareciendo el siguiente error: “In Filesystem.php line 254: /usr/local/proyectos/guarani/vendor/setasign does not exist and could not be created.”.

La versión de composer instalada es la 2.5.5. En la documentación no se especifica versión mínima ni máxima.

¿Debería desactualizar también composer a una versión anterior, o cómo podría solucionarlo?

Muchas gracias.

8

Hola Juan,

La versión de composer instalada es la 2.5.5. En la documentación no se especifica versión mínima ni máxima.

¿Debería desactualizar también composer a una versión anterior, o cómo podría solucionarlo?

Yo tengo exactamente la misma y me funciona bien:


op@siu_guarani_dev: /usr/local/app # composer --version
Composer version 2.5.5 2023-03-21 11:50:05
Failed to download wikimedia/composer-merge-plugin from dist: [...] Permission denied

Me suena mas a permisos de directorios, quizás la primera vez lo ejecutaste como sudo y ahora si lo ejecutas con otro usuario no te deja, revisa los siguientes posts:

Revisa también los permisos del paso 6 de esta documentación.

saludos.
2

9

Pude solucionar el problema cambiando los permisos de acuerdo a lo indicado en https://stackoverflow.com/questions/22390001/runtimeexception-vendor-does-not-exist-and-could-not-be-created

Aparecieron algunas advertencias, pero ningún error fatal.

Ahora, al llegar al paso 10 (Migrar la base de datos negocio), ejecuto ./guarani migrar_base desde bin/ y aparece este error:

PHP Fatal error: Uncaught Dotenv\Exception\InvalidFileException: Failed to parse dotenv file due to an invalid name. Failed at [echo Entorno cargado.]. in /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Parser.php:74 Stack trace: #0 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Parser.php(30): Dotenv\Parser::parseName() #1 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Loader.php(169): Dotenv\Parser::parse() #2 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Loader.php(107): Dotenv\Loader->processEntries() #3 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Loader.php(91): Dotenv\Loader->loadDirect() #4 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Dotenv.php(123): Dotenv\Loader->load() #5 /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Dotenv.php(80): Dotenv\Dotenv->loadData() #6 /usr/local/proyectos/guarani/vendor/siu-toba/framework/bin/launcher.php(22): Dotenv\Dotenv->load() #7 /usr/local/proyectos/guarani/vendor/siu-toba/framework/bin/toba(2): require_once in /usr/local/proyectos/guarani/vendor/vlucas/phpdotenv/src/Parser.php on line 74

¿Cómo podría solucionarlo? Disculpen la cantidad de consultas, pero no conozco PHP.

Muchas gracias.

10

Hola Juan,

Buscando “Failed to parse dotenv file due to an invalid name” en el foro encontré varios posteos que ya lo resuelven, mira los siguientes:

https://foro.comunidad.siu.edu.ar/index.php?topic=20453
https://foro.comunidad.siu.edu.ar/index.php?topic=21717

Ambos te llevan a la Respuesta #11 del foro 20015, la cual te lleva a las Novedades Técnicas de la 3.18, hay un punto que dice lo siguiente:

Se deben quitar las directivas echo dentro del archivo entorno_toba.env: Se deben quitar las directivas echo dentro del archivo entorno_toba.env por problemas de compatibilidad con SIU-Toba 3.3.4.

saludos.
2

11

Disculpas por la demora.

La sugerencia funcionó correctamente.

¡Muchas gracias!