menu
Tutorial Drupal
Drupal es un gestor de contenidos flexible, con el que podemos realizar multitud de websites con reglas de uso realmente complejas. En contrapartida, esa flexibilidad genera dificultad para aprender Drupal.
Desde Atenea tech os proponemos algunos artículos que os ayudarán a hacer más fácil la curva de aprendizaje. También podéis ver nuestra página de formación, donde publicamos los cursos que realizamos.
Artículos en el blog
Spanish · 26/08/2022
Jordi Serra i Bravo
Programar sin debugar debería estar prohibido para cualquier desarrollador que se precie. El problema es que a veces no nos lo ponen fàcil, y ese es el caso de docker en MacOS. Después de una dura batalla, hemos conseguido hacer funcionar xdebug en docker y poder debugar con PhpStorm. En este artículo os detallamos toda la configuración necesaria para poner dicho entorno en funcionamiento.
Fichero docker-compose.yml
En el lado de Docker, el contenido del fichero docker-compose.yml deberá contener lo siguiente, por debajo del bloque php – environment:
PHP_XDEBUG: 1
PHP_XDEBUG_MODE: debug,develop
PHP_IDE_CONFIG: serverName=my-ide
PHP_XDEBUG_IDEKEY: "PHPSTORM"
PHP_XDEBUG_CLIENT_HOST: host.docker.internal
PHP_XDEBUG_CLIENT_PORT: 9003
PHP_XDEBUG_REMOTE_AUTOSTART: 1
PHP_XDEBUG_REMOTE_CONNECT_BACK: 0
PHP_XDEBUG_START_WITH_REQUEST: 1
PHP_XDEBUG_IDEKEY variará en función de nuestro IDE favorito para desarrollar. En este ejemplo hemos usado PhpStorm, de ahí ese valor. Por ejemplo, para Visual Studio Code seria “VSCODE”.
En al versión 3 de xdebug se usa el puerto 9003 por defecto, mientras que en la versión 2 era el 9000. Este setting, PHP_XDEBUG_CLIENT_PORT, sería redundante, pero por la paranoia prefiero que esté presente y descartar errores por esta causa.
Spanish · 18/05/2020
Luis Ortiz
El próximo tres de junio se publicará la novena versión mayor de Drupal.
Históricamente, una nueva versión de este tipo no solo suponía la incorporación de una colección, a veces abrumadora, de nuevas características; si no que rompía lo que en informática denominamos la compatibilidad hacia atrás, obligado a los programadores a adaptar sus módulos y temas contribuidos y a los dueños de sitios, en la mayoría de los casos, a reconstruirlos usando la nueva versión.
Por suerte, la novena versión que se publicará en unos escasos quince días, supone un cambio en este paradigma. Actualizar el sitio de Drupal 8.9 a 9.0 será tan sencillo como actualizar de Drupal 8.8 a 8.9.
Veamos cómo se ha conseguido esto.
El problema: nuevas características vs. compatibilidad hacia atrás
Todo sistema informático, con el paso del tiempo, incorpora nuevas características e intenta mantener la compatibilidad hacia atrás. Desgraciadamente, ambos conceptos actúan como fuerzas opuestas: sistemas que se preocupen de mantener la compatibilidad hacia atrás harán casi imposible la incorporación de nuevas características y, en el caso contrario, incorporar muchas novedades hará imposible mantener la compatibilidad con paquetes antiguos.
Spanish · 29/04/2019
Siddharta Navarro
El pasado viernes 25 de abril tuve el placer de realizar una presentación para la Drupalcat, Comunidad Catalana de Drupal, que realiza charlas mensuales (podéis apuntaros al Meetup aquí). En dicha charla llamada "Qué es lo que he aprendido vendiendo Drupal 10 años", pude compartir mi experiencia comercial en Atenea tech. Fue un debate muy entretenido en el que pudimos hablar de temas relacionados con la charla, como los tipos de proyectos para lo cuales Drupal es adecuado o cuales son las mejores maneras de buscar clientes potenciales.
Foto cortesía de @drupalcat
Os dejo la charla aquí para que los que no pudisteis, y acabo agradeciendo de nuevo a Drupalcat la oportunidad de colaborar de nuevo, como ya hice en la anterior ocasión hablando sobre el módulo Paragraphs.
Spanish · 18/04/2019
Luis Ortiz
Al trabajar en proyectos de desarrollo lo normal es contar con varios entornos en que el código se está ejecutando.
Por ejemplo, en nuestros proyectos es normal que:
- cada uno de los miembros del equipo tenga un entorno local donde escribe y prueba código,
- tengamos un entorno de integración donde las aportaciones de cada programador se unen y se prueba su correcto funcionamiento conjunto,
- exista un entorno de staging (o puesta en escena) donde los editores del sitio puedan probar las nuevas características y subir contenido de prueba, y
- haya uno o más de un entorno de producción donde está el contenido real accesible por los usuarios finales.
Estos entornos tienen un orden: local, integración, staging y producción. Solemos decir que algo está más abajo cuando está más cercano a los entornos locales y más arriba cuando está más cercano de producción.
Spanish · 15/01/2018
David López
En muchas ocasiones nos encontramos peculiaridades de cada entorno que pueden causar incidencias cuando el entorno cambia, por ejemplo cuando ponemos una web en producción o cuando implementamos ciertos cambios en una web que ya está en producción, las diferencias entre el entorno que se uso para desarrollar y el entorno de producción son causa de incertidumbre, y en ocasiones pueden ser también causa de dolores de cabeza y de tiempo invertido innecesariamente. Versiones de php, motores de base de datos, apache, nginx, varnish, etc. pueden convertirse en una gran molestia si no lo tenemos en cuenta desde el principio y si no disponemos de un entorno adaptado a las peculiaridades de cada proyecto.
