DEV Community: Renzo Castillo

Simple handy bash script to update your PHP versions in cli and fpm with valet Linux

Renzo Castillo — Sat, 02 Dec 2023 23:09:28 +0000

Please consider that this script assumes that you already have php and valet Linux installed.

Just add this to your bash script

load_php() {
    version=$1
    case $version in
        7.4)
            sudo update-alternatives --set php /usr/bin/php7.4
            valet use 7.4
            valet restart
            ;;
        8.1)
            sudo update-alternatives --set php /usr/bin/php8.1
            valet use 8.1
            valet restart
            ;;
        8.2)
            sudo update-alternatives --set php /usr/bin/php8.2
            valet use 8.2
            valet restart
            ;;
        *)
            echo "Invalid PHP version: $version"
            ;;
    esac
}

phpvm() {
    if [ "$1" == "use" ]; then
        shift
        load_php "$1"
    else
        echo "Usage: phpvm use <php_version>"
    fi
}

Now you can do something like phpvm use 7.4 and you will get your php version 7.4 set at your cli and at your php-fpm service.

Credits to Kenmutesh's post

¿ Cómo crear una migración en Laravel para actualizar de forma masiva a todas las claves foráneas ?

Renzo Castillo — Wed, 12 Jan 2022 23:59:22 +0000

En este post te enseñaré a sacarle provecho a Doctrine , que es una librería, que está incluida como dependencia en laravel y en otros frameworks, y que permite gestionar a tus achivos de migraciones de la base de datos. Hace poco tuve que hacer una actualización de una base datos con cierta cantidad de tablas y la verdad que con sólo verlo me cansé en pensar tener que hacer un montón de migraciones secuenciales que prácticamente seguían la misma lógica.

Primero les voy a dejar el código comentado y si quieren colocar esta migración les dejaré la versión sin comentar más abajo.

Bueno el primer paso es obviamente crear tu migración con el comando

php artisan make:migration rebuild_foreign_keys_with_on_delete_cascade_on_update_cascade

Una vez creado nuestro archivo de migración entramos a éste y creamos las funciones que pasaré a explicar dentro del código:

<?php

use IlluminateSupportFacadesSchema;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateDatabaseMigrationsMigration;

class RebuildForeignKeysWithOnDeleteCascadeOnUpdateCascade extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        // Nos conectamos a la BD y llamamos a DoctrineSchemaManager para hacer la magia.
        $con= Schema::getConnection()->getDoctrineSchemaManager();
        // Aquí recuperamos a todos los nombres de las tablas en tu bd.
        $tb_names=$con->listTableNames();
        // Empezaremos a rastrear a todas las claves foráneas por cada tabla
        foreach($tb_names as $tb_name){
            /* Aquí el nombre de la tabla será usado en la función indica la documentación
            de laravel para poder modificar las columnas y demás aspectos de la tabla*/
            Schema::table($tb_name, function (Blueprint $table) use ($tb_name,$con) {
                // Aquí dentro llamaremos a todas las claves foráneas de esta tabla en concreto
                $foreignKeys=$con->listTableForeignKeys($tb_name);
                // Primero obviamente chequeamos si está vacío para evaluar si corremos o no esto.
                if(count($foreignKeys)){
                    /* Una vez que nos aseguramos que hay claves foráneas procedemos con la actualización
                     de ON DELETE NO ACTION a ON DELETE CASCADE. Empezamos a ir clave por clave*/
                    foreach($foreignKeys as $foreignKey){
                        // Recuperamos la columna local o sea la columna que guarda el id de la relación foránea
                        $local_col=$foreignKey->getLocalColumns()[0];
                        // Aquí recuperamos el nombre de nuestra tabla foránea 
                        $foreign_table=$foreignKey->getForeignTableName();
                        // Aquí obtenemos la columna de nuestra tabla foránea
                        $foreign_col=$foreignKey->getForeignColumns()[0];
                        // Aquí obtenemos el nombre actual que tiene la clave foránea
                        $fk_name=$foreignKey->getName();
                        /* Ahora procedemos a romper esta relación foránea,que es lo normal que haríamos
                        si quremos actualizar a una relación foránea de ON DELETE NO ACTION a CASCADE*/
                        $table->dropForeign($fk_name);
                        /* Una vez rota la relación la reconstruimos asumiendo el comportamiento es cascada
                       para los eventos ON DELETE y ON UPDATE de nuestra base de datos */
                        $table
                        ->foreign($local_col, $fk_name)
                        ->references($foreign_col)
                        ->on($foreign_table)
                        ->onUpdate('CASCADE')
                        ->onDelete('CASCADE');
                    }
                }
            });

        }
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */

    /* Para el rollback de esta migración hacemos lo mismo con la única diferencia que
    ahora vamos a devolver la relación a ON DELETE NO ACTION.*/
    public function down()
    {
        $con= Schema::getConnection()->getDoctrineSchemaManager();
        $tb_names=$con->listTableNames();
        foreach($tb_names as $tb_name){
            Schema::table($tb_name, function (Blueprint $table) use ($tb_name,$con) {
                $foreignKeys=$con->listTableForeignKeys($tb_name);
                if(count($foreignKeys)){
                    foreach($foreignKeys as $foreignKey){
                        $local_col=$foreignKey->getLocalColumns()[0];
                        $foreign_table=$foreignKey->getForeignTableName();
                        $foreign_col=$foreignKey->getForeignColumns()[0];
                        $fk_name=$foreignKey->getName();
                        $table->dropForeign($fk_name);
                        $table
                        ->foreign($local_col, $fk_name)
                        ->references($foreign_col)
                        ->on($foreign_table)
                        ->onUpdate('NO ACTION')
                        ->onDelete('NO ACTION');
                    }
                }
            });

        }
    }
}

Espero haberles ayudado y que ahora tengan más tiempo . Si tienen alguna sugerencia, preguntas o mejoras pueden escribirme y procuraré responderles pronto.

Saludos!

Cómo crear respaldos programados en la nube de tu base de datos con webmin

Renzo Castillo — Wed, 12 Jan 2022 23:52:21 +0000

Hola! El procedimiento para crear un respaldo programado en la nube con webmin se divide en los siguientes pasos:

Configuración e instalación de la herramienta por línea de comandos de mega (megatools)
Configuración de webmin para que acepte fechas en el nombre del archivo
Configuración de respaldos programados de la base de datos

Configuración e instalación de la herramienta por línea de comandos de mega (megatools)
Para instalar megatools, configurarlo con su cuenta de mega.co.nz, y saber usar ‘megaput’ y ‘megarm’ , les recomiendo seguir las instrucciones de este post. Asimismo, una vez que terminen de configurar, les recomiendo hacer un par de testeos con megaput y megarm de cualquier archivo que tengan en su servidor para probar si su configuración estuvo bien realizada.
Configuración de webmin para que acepte fechas en el nombre del archivo
Necesitamos otra configuración para hacer que webmin acepte ejecutar este tipo de reemplazos, de lo contrario pensará que el nombre que se coloque en nuestro archivo será ‘estático’. Para este caso usaremos el siguiente formato de fecha unix: %Y-%m-%d . Esto deberá responder al año, mes y día respectivamente. Primero nos dirigimos a Webmin -> Servidores -> Servidor de Base de Datos MySQL. Luego arriba la izquierda encontramos un botón de configuración del módulo y lo seleccionamos para ver opciones más avanzadas. Aquí buscamos la opción Do strftime substitution of backup destinations? Yes, y guardamos.

3.Configuración de respaldos programados de la base de datos
Para este caso lo primero que haremos será dirigirnos al panel de gestión de nuestro servidor de base de datos, que para este caso será MySQL.
Nos dirigimos entonces a Webmin-> Servidores -> Servidor de Base de Datos MySQL.

Una vez aquí, seleccionamos la base de datos de nuestro interés y le damos a Respaldar Base de Datos. Aquí configuraremos los siguientes parámetros.

Backup destination
Seleccionamos ‘path on server’ y aquí debemos asegurarnos de indicar una ruta con parámetros basados en formato de fecha. Por lo cual nuestra ruta absoluta a colocar sería:

/cualquier-directorio/%Y-%m-%d-mi-base-de-datos.sql.gz
Other backup options
Aquí les recomiendo seleccionar la compresión por gzip. Además de ello aquí se ejecutaron los comandos para depurar y para subir a la nube de mega cada archivo de respaldo .
Command to run before backup

rm "/cualquier-directorio/"$(date -d "$date -3 days" +"%Y-%m-%d")-mi-base-de-datos.sql.gz && megarm --config=/root/.secrets/mega.cnf "/Root/mi-carpeta-mega/"$(date -d "$date -14 days" +"%Y-%m-%d")-mi-base-de-datos.sql.gz
Ahora desglosaremos este comando en 2 partes:

rm "/cualquier-directorio/"$(date -d "$date -3 days" +"%Y-%m-%d")-mi-base-de-datos.sql.gz

Este comando básicamente remueve al backup del servidor que sea de hace 3 días atrás, esto con la finalidad de optimizar recursos y retener menos backups.

megarm --config=/root/.secrets/mega.cnf "/Root/mi-carpeta-mega/"$(date -d "$date -14 days" +"%Y-%m-%d")-mi-base-de-datos.sql.gz
Este otro comando remueve del directorio mega a todos aquellos backups que sean de hace 14 días atrás, esto porque generalmente querrás tener respaldos más antiguos en la nube.

Command to run after backup
megaput --config=/root/.secrets/mega.cnf --path=/Root/Yaku.app/DEV/backups --disable-previews "/backups/"$(date +%Y-%m-%d)-mi-base-de-datos.sql.gz
Este comando se ejecuta posterior a la creación del backup en el servidor en la carpeta indicada, y su propósito es enviar el backup generado a la nube de MEGA.

Backup schedule
Send backup status email to
Aquí colocamos un correo electrónico al cual quisieramos que nos llegue la confirmación del backup
Send email for
Aquí marcaremos ‘Only on failure’ para que no nos lleguen todo el tiempo, sólo en caso falle el respaldo.
Scheduled backup enabled?
Yes, at times chosen below ..Simple schedule ..Daily(at midnight)
Una vez marcada estas opciones le damos a ‘Save’ y guardamos nuestra configuración. Si todo ha marchado correctamente, los respaldos deberían empezar a generarse y podrán visualizarlos directamente en su cuenta de Mega así como en su servidor webmin.

How to create a migration in Laravel to massively update all foreign keys in your database

Renzo Castillo — Thu, 04 Nov 2021 15:43:02 +0000

In this post I will show you how to take advantage of Doctrine, which is a library that is included in laravel as well as in other frameworks, and it allows you to manage your php migration files. I recently had to update a database with a certain number of tables and the truth is that just by looking at it I got tired of thinking about having to do a lot of sequential migrations that practically followed the same logic.

I am going to leave you the commented code in case you want to place this migration file in your own laravel project.

Well the first step is obviously to create your migration using this command

php artisan make:migration rebuild_foreign_keys_with_on_delete_cascade_on_update_cascade

Once our migration file is created, we enter it and create the functions that I will explain within the code:

<?php


use IlluminateSupportFacadesSchema;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateDatabaseMigrationsMigration;
class RebuildForeignKeysWithOnDeleteCascadeOnUpdateCascade extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        // We connect to the DB and we call DoctrineSchemaManager to perform the magic for us.
        $con = Schema::getConnection()->getDoctrineSchemaManager();
        // Here we retrieve all the database table names
        $tb_names = $con->listTableNames();
        // Now we start to retrieve all the foreign key for each table
        foreach ($tb_names as $tb_name){
            // Here the table name will be used in the function that laravel docs indicate to modify columns and other table attributes.
            Schema::table($tb_name, function (Blueprint $table) use ($tb_name, $con){
                // Here we retrieve all foreign keys from this specific table
                $foreignKeys = $con->listTableForeignKeys($tb_name);
                // First of all we obviously check if its empty in order to evaluate if it should be executed or not.
                if (count($foreignKeys))
                {
                    /* Once inside, we make sure that there are not foreign keys and we proceed to the update from ON DELETE NO ACTION to ON DELETE CASCADE
We loop key by key */
                    foreach ($foreignKeys as $foreignKey)
                    {
                        // Here we retrieve the local column, that means the column that saved the id of the foreign key relationship.
                        $local_col = $foreignKey->getLocalColumns()[0];
                        // Here we retrieve the name of our foreign table
                        $foreign_table = $foreignKey->getForeignTableName();
                        // Here we retrieve our foreign key column
                        $foreign_col = $foreignKey->getForeignColumns()[0];
                        // Here we retrieve the foreign key name
                        $fk_name = $foreignKey->getName();
                        /* Now we proceed to break the foreign relationship, which is the proper way to rebuild a foreign key relationship.*/
                        $table->dropForeign($fk_name);
                        /* Once the foreign key relationship has been broken , we rebuild it  taking into account that new events should be  ON DELETE and ON UPDATE CASCADE */
                        $table
                            ->foreign($local_col, $fk_name)
                            ->references($foreign_col)
                            ->on($foreign_table)
                            ->onUpdate('CASCADE')
                            ->onDelete('CASCADE');
                    }
                }
            });
        }
    }


    /**
     * Reverse the migrations.
     *
     * @return void
     */


    /* The rollback migration function should be almost the same with only one differente which is to switch back the foreign key relationship to ON DELETE NO ACTION AND ON UPDATE NO ACTION.*/
    public function down()
    {
        $con = Schema::getConnection()->getDoctrineSchemaManager();
        $tb_names = $con->listTableNames();
        foreach ($tb_names as $tb_name)
        {
            Schema::table($tb_name, function (Blueprint $table) use ($tb_name, $con)
            {
                $foreignKeys = $con->listTableForeignKeys($tb_name);
                if (count($foreignKeys))
                {
                    foreach ($foreignKeys as $foreignKey)
                    {
                        $local_col = $foreignKey->getLocalColumns()[0];
                        $foreign_table = $foreignKey->getForeignTableName();
                        $foreign_col = $foreignKey->getForeignColumns()[0];
                        $fk_name = $foreignKey->getName();
                        $table->dropForeign($fk_name);
                        $table
                            ->foreign($local_col, $fk_name)
                            ->references($foreign_col)
                            ->on($foreign_table)
                            ->onUpdate('NO ACTION')
                            ->onDelete('NO ACTION');
                    }
                }
            });
        }
    }
}

I hope that this method has helped you. If you have any suggestions, questions or improvements you can write to me and I will try to answer them as soon as possible.

How to create scheduled cloud backups of your database using mega with webmin

Renzo Castillo — Thu, 04 Nov 2021 15:32:16 +0000

Hi! The procedure to create a scheduled backup in the cloud with webmin is divided into the following steps:

Configuration and installation of the mega command line tool (megatools): To install megatools, configure it with your mega.co.nz account, and know how to use 'megaput' and 'megarm', I recommend you to follow the instructions in this post. Once you have finish the installation and configuration of mega tools, I recommend doing a couple of tests with megaput and megarm of any file they have on their server to test if their configuration was well done.
Configuring webmin to accept dates in the file name: We need another configuration to make webmin agree to run this type of override, otherwise it will think that the name that is placed in our file will be 'static'. For this case we will use the following unix date format:% Y-% m-% d. This should respond to the year, month and day respectively. First we go to Webmin -> Servers -> MySQL Database Server. Then at the top left we find a module configuration button and select it to see more advanced options. Here we look for the option Dostrftimesubstitution of backup destinations? Yes, and we save.
Configuring scheduled database backups: In this case, the first thing we will do is go to the management panel of our database server, which for this case will be MySQL. We then go to Webmin-> Servers -> MySQL Database Server. Once here, we select the database of our interest and we click Backup Database. Here we will configure the following parameters.

Backup destination: We select 'path on server' and here we must make sure to indicate a route with parameters based on date format. Therefore our absolute path to place would be:

/ any-directory/%Y-%m-%d-mi-data-base.sql.gz

Other backup options: Here I recommend selecting compression by gzip. In addition to this, the commands to debug and upload each backup file to the mega cloud were executed here.
Command to run before backup:

rm "/ any-directory /" $ (date -d "$ date -3 days" + "% Y-% m-% d") - my-database.sql.gz && megarm --config = /root/.secrets/mega.cnf "/ Root / my-mega-folder /" $ (date -d "$ date -14 days" + "% Y-% m-% d") - my-base-of -data.sql.gz

Now we will break this command down into 2 parts:

rm "/ any-directory /" $ (date -d "$ date -3 days" + "% Y-% m-% d") - my-database.sql.gz

This command basically removes the backup from the server that is 3 days old, this in order to optimize resources and retain fewer backups.

megarm --config = / root / .secrets / mega.cnf "/ Root / my-mega-folder /" $ (date -d "$ date -14 days" + "% Y-% m-% d") - my-database-sql.gz

This other command removes from the mega directory all those backups that are from 14 days ago, this because generally you will want to have older backups in the cloud.

Command to run after backup:

megaput --config = / root / .secrets / mega.cnf --path = / Root / Yaku.app / DEV / backups --disable-previews "/ backups /" $ (date +% Y-% m-% d ) -my-database-sql.gz

This command is executed after the backup is created on the server in the indicated folder, and its purpose is to send the generated backup to the MEGA cloud.

Backup schedule:

Send backup status email to: Here we place an email to which we would like the backup confirmation to reach us
Send email for: Here we will mark 'Only on failure' so that they do not reach us all the time, only in case the backup fails.
Scheduled backup enabled? Yes, at times chosen below ..Simple schedule ..Daily (at midnight)

Once these options are selected, we click 'Save' and save our configuration.

If everything has gone well, the backups should start to be generated and you can view them directly in your Mega account as well as on your webmin server.