base de datos

A pesar de que el módulo Backup and Migrate está pensado para facilitarnos las tareas relacionadas con copias de la base de datos y que con él podremos exportarlas importarlas o descargarlas; al momento de utilizarlo para traspasar nuestro Drupal de un entorno de desarrollo al de producción, nos podríamos encontrar con varios errores, principalmente si en nuestro Drupal tenemos instalados varios módulos o mucho contenido, el traspaso de tablas no funcionará.

Existen nuevas formas de conectar entornos utilizando la exportación de configuración, mediante Drush y repositorios, pero en mi experiencia personal, suele dar problemas a la hora de implementarlo, porque generalmente los Planes básicos de hosting e incluso, algunos Planes avanzados, no incluyen la memoria suficiente para ejecutar los comandos o permisos para poder implementar correctamente lo necesario.

Por esta razón, si haz desarrollado tu proyecto Drupal en un servidor local, y sólo quieres traspasarlo al entorno de producción sin que tengas que perder demasiado tiempo en averiguar cómo hacerlo, te presento los tres fundamentos que deberías saber para llevar a cabo el proceso con el mínimo esfuerzo. 

REQUISITOS A TOMAR EN CUENTA SI QUIERES TRASPASAR UN DRUPAL AL ENTORNO DE PRODUCCIÓN

1. TRASPASAR TODOS LOS ARCHIVOS A AL CARPETA PÚBLICA DEL SERVIDOR DE DESTINO

        Lo primero que deberás hacer es comprimir la carpeta completa de tu proyecto drupal y subirla a tu servidor de producción, tomando en cuenta que la ubicación cambiará si haz realizado la instalación usando Composer o descargando el Drupal directamente de la página oficial.

        En la mayoría de los proveedores de hosting o alojamiento web, cuando contratamos el servicio de dominio + hosting, el nombre o dominio apunta  a la carpeta "public_html" o "html" y espera encontrar el archivo index.php para mostrar la web; en el caso de Drupal 8 y 9, si hemos realizado la instalación descargando el archivo directamente desde la Página oficial de drupal, entonces, sólo tendremos que copiar todo el contenido del Drupal dentro de la carpeta pública, donde estará este archivo index.php, pero si hemos optado por utilizar Composer para nuestro proyecto, que es la nueva recomendación para instalar Drupal a partir de la versión 8, nos encontraremos con que al carpeta principal ahora se encuentra dentro de "web", por lo que tendríamos que modificar la ruta  a la que apunta el dominio principal, para que se dirija a public_html/web

2. COPIAR LA BASE DE DATOS EN PRODUCCIÓN

   Cómo ya sabrás, Drupal funciona al conectar los archivos físicos con la base de datos correspondiente. Así que para esto ocurra, una vez tengas todos los archivos de tu proyecto Drupal en el servidor de producción, sólo tendrías que importar la base de datos y modificar los parámetros de conexión en el archivo settings.php.

   Opción A Backup and Migrate:
        Si decides utilizar Backup and Migrate, tendrías que realizar una instalación nueva en el servidor de producción, utilizando los mismos archivos que haz copiado, asignándole la base de datos vacía y al terminar la instalación de producción, activas el módulo Backup and Migrate, configuras el archivo "/private" para que te funcione la copia de seguridad y lo siguiente sería exportar desde tu servidor de desarrollo e importarla en el de producción.

   Opción B Exportación Base de datos:
        Si el Drupal que haz desarrollado tiene varios módulos o demasiado contenido, es posible que el módulo Backup and Migrate no te permita realizar la importación, aunque suele funcionar la mayoría de las veces sin mayores inconvenientes. Sin embargo, también puedes exportar la base de datos de tu entorno local usando el siguiente comando desde tu consola 

   mysqldump -u usuario -p -q nombre_bbdd > bbdd.sql

   Esto te permitirá utilizar la opción --quick o -q para que MySQL exporte fila a fila en lugar de meter en buffer toda la tabla y agotar la memoria. Ver documentación.

   De esta forma al importarla en tu servidor de producción, no te dará errores de tiempo de ejecución o conexión.

3. ACTUALIZAR SETTINGS.PHP:

        Ló último que deberás tener en cuenta, es que al pasar a un entorno de producción, necesariamente tendrás que modificar los detalles de acceso a la base de datos que están declarados en tu settings.php

               Cuando instalamos Drupal, el añadirá las líneas que conectan con la base de datos al final del archivo settings.php, deberías buscar en la parte inferior y encontrarás una líneas parecidas a las siguientes:

$databases['default']['default'] = array (
  'database' => 'midb',
  'username' => 'misuariodb',
  'password' => '1234567',
  'prefix' => '',
  'host' => 'localhost',
  'port' => '3306',
  'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
  'driver' => 'mysql',
);
$settings['config_sync_directory'] = 'sites/default/files/configurador856978854adfasdf4a44454/sync';

$settings['file_temp_path'] = 'sites/default/files/tmp';
$settings['file_private_path'] = 'sites/default/files/private';

          Las dos últimas líneas, son si quieres configurar la carpeta para archivos temporales y la de archivos privados dentro de tu servidor, puedes usar "../tmp" y "../private" para que las carpetas sean creadas por el servidor o por ti a nivel de la carpeta principal.

     NOTA: En el caso de instalaciones multisitio, tendrás que revisar el archivo "sites/sites.php", que es el que indica los diferentes dominios o subdominios con las carpetas a las que apunta cada instalación, deberías ver algo parecido a lo siguiente:

$sites['misito1.localhost'] = 'sitio1';
$sites['misitio2.localhost'] = 'sitio2';

     Econtrarás el archivo settings.php dentro de cada una de las carpetas especificadas, donde deberás actualizar los datos para que puedan conectarse en cada caso con la base de datos que le corresponde a cada sitio.

     Si te consideras como yo, uno de los apasionados por utilizar Drupal, o estás a punto de comenzar a probar las versiones más actuales, en las que se implementaron grandes cambios, como la estructura a partir del Framework Symfony, o la integración en el núcleo, de varios módulos que en versiones anteriores a Drupal8, debían descargarse manualmente, es posible que te haya saltado una duda razonable, ¿cuál sería la mejor manera de comenzar a diseñar tu proyecto web?.

     Debido a la gran cantidad de opciones disponibles en este CMS, a veces podría resultar abrumador encontrar las primeras indicaciones, que te permitan comenzar poco a poco a experimentar, las mejores alternativas, para lograr una web fácil de mantener, actualizar y con diseño sea flexible y adaptado a cualquier dispositivo.

   ¿Qué es mejor de utilizar en Drupal Blocks o Paragraphs?

        Todos los que hemos trabajado en las versiones 6 o 7 de Drupal, pudimos conocer o experimentar, en algún momento, con el uso de los bloques, para aplicarlo sobretodo en la página principal, ya que nos permitía dividir en zonas, cualquier página y a su vez añadir contenidos referenciados, a través del uso del campos especiales o vistas.

        A partir de la versión 8, además de la implementación en entidades, se añadió el módulo que marcó para siempre, según mi punto de vista, la forma en que podríamos construir una web más versátil, tanto de cara a los administradores, o gestorese de contenidos, como al usuario final. Me refiero a los Paragraphs; que añadieron múltiples maneras de manipulación de los contenidos, además de ofrecer un sustituyo mucho más potente, que el fieldgroup o los bloques convencionales.

       No obstante, cada proyecto tiene sus propias necesidades y es decisión nuestra implementar, las mejores alternativas, para sacar provecho a cualquiera de las opciones con las que disponemos.

     Ejemplo práctico (Web básica) con Paragraphs

          Supongamos que los requerimientos fundamentales de nuestro proyecto serán, una página de inicio y varias páginas interiores, como por ejemplo, Conctacto, Quienes somos, Blog y/o Listado de productos. Además en la página principal, tendremos varios elementos: un carrusel con las promociones, un pequeño resumen sobre lo que hace nuestra empresa, otro apartado con los productos o servicios destacados, una galería de imágenes y un formulario. Y para nuestras páginas interiores, tendremos una imagen de cabecera, con algún texto descriptivo del contenido, un título principal, y algunos textos, imágenes o formulario de contacto, cuyos contenidos variarán según la página, compartiendo el mismo diseño de cabecera y estructura general.

          Podríamos crear o configurar dos tipos de contenido principales, uno llamado "pagina_inicio", al que añadiríamos un sólo campo llamado, del tipo paragraphs, por ejemplo "contenidos", y dentro tendríamos varios paragraph, que a su vez apuntaran a todos los contenidos que pensamos mostrar.De esta forma, la página principal sería muy sencilla de personalizar y actualizar sin necesidad de grandes conocimientos ni experiencia previa.

          Puedes visitar https://demo.webcontodo.com/ para ver cómo queda.

    En el caso de la páginas interiores, como compartirán la cabecera, los títulares principales, y envolveremos el resto de elementos dentro de algún contenedor, tipo bootstrap, para garantizar un diseño responsivo; el enfoque sería parecido al anterior, con algunas variaciones y podríamos reaprovechar algunos de los paragraphs, para no tener que crear nuevas plantillas individuales en cada caso.

     En resumen, con este planteamiento, podríamos ofrecer la posibilidad de personalizar rápidamente todas las páginas de la web, cambiando de orden los elementos, añadiendo o removiendo elementos existentes, creando estructura que podrían llegar a ser bastante complejas, dependiendo de las necesidades y todo sin la necesidad de invertir demasiado tiempo en la aplicación de correcciones o definición de los estilos, ya que casi todo el contenido mostrado sería reutilizable, escalable como proyecto y fácil de aplicar, incluso en entornos diferentes con algunos cambios.

     Aunque el uso de los bloques tradiciones nos permite un resultado parecido para nuestra página de inicio, tiene la desventaja de no formar parte de la página como tal, sino que tendríamos que modificarla desde su propia página de configuración en la url "estructura/diseño de bloques", esto no resulta nada práctico para el gestor de contenidos, además de que puede crear mucha confusión al tener que cambiar de pantallas para comprobar los resultados. 

     Además, con respecto a las páginas interiores, aunque pudiéramos poner un bloque "Cabecera", que apareciera en todas las páginas interiores, tampoco sería parte de su estructura, tendríamos que añadir una nueva cabecera por cada una de las páginas, volviendo al problema principal que es la configuración fuera de nuestro contenido.

     Como dije al principio, Drupal nos ofrece múltiples maneras de enfocar nuestros proyectos, y es decisión nuestra aplicar la que mejor nos convenga. Los bloques también ofrecen la novedad de "Bloques personalizados", que podrían resolver algunas de los inconvenientes con respecto a los tradicionales, pero en definitiva, considero que será mucho más práctico el uso de paragraphs para implementar en cualquier proyecto.

     Si tomamos en cuenta, la posibilidad de crear módulos personalizados, para cada tipo de paragrahps, signficaría que en cada proyecto nuevo podríamos simplemente instalar dichos módulos y realizar unos cambios mínimos de configuración y tendríamos un resultado cuyas prestaciones nos ahorrarían muchos dolores de cabeza.

Una de las ventajas más importantes de utilizar el CMS o Gestor de contenidos Drupal, para la creación y/o mantenimiento de páginas web, es la potente y eficaz forma de gestionar los usuarios y sus respectivos permisos o accesos relacionados, en función de las necesidades del proyecto. 

Drupal ofrece la posibilidad de permitir o restringir toda clase de accesos a cualquier tipo de usuario que visite la web, mediante la creación y asignación de Roles. 

Para que podamos entender más fácilmente de qué se trata, pensemos en dos empleados de una pequeña tienda, dónde ambos podrán atender a los clientes, reponer mercancía y recibir a los proveedores cuando sea necesario, pero sólo uno de ellos podrá acceder a la caja fuerte para entrar o sacar dinero de ella.

Si aplicamos este ejemplo a una web realizada con Drupal, tendremos que crear dos tipos de roles, por ejemplo, "dependiente" y "responsable de caja", ambos usuarios tendrán el rol de "dependiente" para atender a los clientes, reponer mercancía y recibir a los proveedores, mientras uno de ellos tendrá, además, el rol "responsable de caja", con los permisos para  acceder a la caja fuerte para entrar o sacar dinero de ella.

En la siguiente imagen, verás más claramente la idea, en este caso, el jefe del equipo de redacción, es el único que tendrá todos los permisos relacionados con la creación, edición, aprobación y borrado de los contenidos; por debajo de él, todos los gestores de contenido, podrán crear y editar, pero no eliminar ni publicar ningún contenido, si no están autorizados previamente por su jefe. Y el resto de personas que accedan a la parte pública de la web, tendrán la posibilidad de ver todos los contenidos publicados que hayan sido autorizados.

En Drupal, podremos acceder a la gestión de usuarios, roles y permisos desde el Menú usuarios, que nos llevará a tres listados diferentes divididos por pestañas; la primera nos muestra los usuarios con los detalles sobre su fecha de creación, última vez que han accedido, el rol o roles asignados y desde aquí podremos añadir nuevos usuarios o filtrar por varias opciones disponibles.

Por defecto, al instalar Drupal, se crea automáticamente el Rol "Administrador", con permiso a toda la web y sus funcionalidades, por lo que es recomendable crear inmediatamente otro usuario con accesos restringidos, para evitar que el cliente final pueda ocasionar daños irreversibles una vez entregado el proyecto.

En la segunda pestaña, podremos asignar o modificar los permisos y accesos a tipos de contenido, módulos, traducciones, taxonomías y otras opciones dependiendo de lo que hayamos instalado en nuestro proyecto, además tendremos la opción de permitir o limitar lo que pueden ver o no los usuarios, dependiendo de sí están logueados o no.

Por último, está la pestaña de roles, en esta parte es dónde tendríamos que crear los roles "dependiente" y "responsable de caja", del ejemplo inicial y entonces, podremos asignarles los permisos para realizar la tareas que espera nuestro cliente para uno o varios usuarios específicos.

Mi recomendación en caso de que estén empezando con algún proyecto en Drupal, es que empieces por crear un rol, por ejemplo "Editor" y le asignes los permisos para crear, editar y borrar contenidos y a continuación, crear un usuario "Gestor de contenido" y le asignes el rol Editor. 

Para probar que los permisos funcionan correctamente para tu nuevo rol, tendrás que asignarle al Editor, los permisos de "Usar enlaces contextuales", "Acceder a la página de resumen de contenido", "Administrar contenido", "Usar la barra de herramientas".

De esta forma, si abres otro navegador y accedes con los datos de acceso de tu nuevo usuario, podrás ver el menú de administrador, pero con acceso limitado al listado de contenidos que haz especificado para tu usuario.