Guías
Guía

Herramientas esenciales para el desarrollo PrestaShop

Kit de herramientas para desarrolladores PrestaShop: editores de código, depuración, bases de datos, imágenes, control de versiones y stack open source.

Las herramientas que abrimos cada día

Esta es la caja de herramientas a la que nos han llevado 159 módulos publicados y una década de trabajo con PrestaShop. No es relleno de tipo «top 10», sino las cosas concretas que mantenemos en marcha en el equipo TrueNAS que aloja nuestro entorno de desarrollo basado en Docker, más el puñado de aplicaciones de escritorio que abrimos antes del primer café.

Algunas las recomendamos sin dudarlo. Unas cuantas las probamos, las dejamos y las sustituimos por algo más sencillo. Te diremos cuál es cuál.

Editor

VS Code antes que PhpStorm, pero por poco

Usamos VS Code en un escritorio Arch Linux, conectado mediante la extensión Remote-SSH al servidor TrueNAS donde vive cada contenedor Docker. Todo el árbol de módulos se abre como si fuera local, con PHP Intelephense indexando la jerarquía de clases de PrestaShop en segundo plano. Esa configuración ha gestionado cada módulo que hemos publicado desde 2022.

Probamos PhpStorm en serio, dos veces. Su comprensión de PHP es genuinamente más profunda de fábrica, y las herramientas de base de datos son excelentes. Pero consume entre 3 y 4 GB de RAM por proyecto, las pausas de indexación se notan en árboles grandes de PrestaShop y, una vez que dedicas tiempo a Intelephense más un par de extensiones de Smarty, la diferencia se reduce. Pagamos la licencia premium de Intelephense; cuesta 25 $ una sola vez y solo la función de refactorización para renombrar símbolos se amortiza la primera vez que tocas un trait usado por 12 módulos.

Las extensiones que merece la pena instalar desde el primer día:

  • PHP Intelephense: autocompletado que de verdad entiende $this->context->cart->id_customer
  • Smarty Template Support: sin esto, los archivos .tpl son ruido sin colorear
  • GitLens: «quién lo rompió y cuándo» en línea. Imprescindible cuando un módulo funcionaba la semana pasada y ahora no
  • Remote-SSH: el motivo entero por el que elegimos VS Code
  • PHP Debug: el receptor de Xdebug, lo vemos más abajo

Una cosa que no nos molestamos en usar: la interfaz gráfica de la extensión de Docker. Ejecutar sudo docker exec -w "$PWD" <tooling-container> … desde una terminal integrada es más rápido que hacer clic por los paneles.

Xdebug + VS Code: la configuración que se amortiza en una semana

La depuración paso a paso convierte «¿por qué este hook devuelve null?» de una búsqueda de 30 minutos en una respuesta de 2 minutos. El truco está en configurarlo para que se mantenga al margen hasta que lo necesites.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003,
            "pathMappings": {
                "/var/www/html": "${workspaceFolder}"
            }
        }
    ]
}

Dentro del contenedor de PHP:

xdebug.mode=debug
xdebug.start_with_request=trigger
xdebug.client_host=host.docker.internal
xdebug.client_port=9003

Usa start_with_request=trigger para el desarrollo diario; reserva =yes para sesiones breves de depuración. La variante «yes» dispara Xdebug en cada petición de imagen, cada llamada AJAX, cada cron, y en un contenedor de desarrollo con carga eso convierte la tienda en melaza. El modo trigger espera a la cookie de Xdebug Helper antes de hacer nada.

Control de versiones

Git, GitHub, versionado semántico. Aquí no hay debate.

Cada módulo vive en su propio repositorio en ~/modules/<name>/, cada paquete compartido en ~/packages/<name>/. Las etiquetas coinciden con la cadena $this->version del archivo PHP principal del módulo: si un cliente dice «la versión de hace tres meses rompió X», sacamos esa etiqueta exacta en segundos. Los mensajes de commit reciben el trato de los conventional commits (feat:, fix:, refactor:) porque «arreglado un bug» no te dice nada cuando estás auditando una regresión de hace seis meses.

GitHub para todo lo público. También usamos una instancia de Gitea autoalojada (es ligero y un único contenedor Docker), de modo que cada repositorio de módulo también reside en hardware de nuestra propiedad. Si tienes un motivo de peso para autoalojarlo (cumplimiento normativo, red aislada), Gitea es la respuesta correcta; en caso contrario, quédate con GitHub.

Haz siempre commit de composer.lock. composer install lo lee; composer update lo regenera. Hemos tenido despliegues de producción rotos porque un composer install nuevo se trajo una versión menor con un cambio de comportamiento: el archivo lock es lo que evita eso.

Docker, y un proyecto Compose por tienda

PrestaShop 1.6 quiere PHP 7.1. PrestaShop 9.1 quiere PHP 8.2 o superior. Ejecutar todo esto en un único host sin contenedores no es algo que intentaríamos. Nuestro equipo TrueNAS ejecuta contenedores PrestaShop separados para las versiones a las que damos soporte, cada uno con su propia base de datos, en su propio puerto, sobre una red Docker compartida. Nada entra en conflicto.

Aquí está la parte en la que nos diferenciamos de la mayoría de tutoriales: no metemos todo el entorno de desarrollo en un único archivo Compose. Probamos ese enfoque durante un año. El problema es que los archivos de Compose quieren controlar el ciclo de vida de un grupo de contenedores, y nuestra realidad son docenas de instancias de larga vida, gestionadas de forma independiente, que necesitan levantarse y apagarse en horarios distintos. Lo que nos funciona es un pequeño proyecto Compose por tienda: el contenedor de la tienda y su propia base de datos, nada más.

Los contenedores de prueba de corta duración se ejecutan con un simple docker run en la misma red compartida. Cada contenedor es algo discreto en sí mismo. Podemos hacer docker restart ps8-dev sin tocar el contenedor de la base de datos, y nunca tumbamos cinco sitios por accidente porque un contenedor vecino se cayera durante un docker compose up.

Si estás empezando desde cero con un único proyecto, Compose está bien. Si vas a acabar gestionando muchas tiendas de larga vida, asigna a cada una su propio proyecto Compose pequeño.

# Conectar a una base de datos en contenedor
sudo docker exec <your-shop>-db mysql -u root -p prestashop

# Ejecutar composer a través del contenedor de herramientas
sudo docker exec -w "$PWD" <tooling-container> composer install --no-dev

# Seguir los registros de un contenedor con fallos
sudo docker logs -f --tail 200 ps9-dev

Podman existe, lo sabemos. Como entorno de ejecución de contenedores sin demonio y sin root, es sólido. Nunca hemos tenido motivo para cambiar: cada tutorial de PrestaShop, cada Dockerfile del ecosistema, da por sentado Docker. El peaje de compatibilidad no merece la pena.

Base de datos

Primero la CLI de mysql, después la interfaz gráfica

Para el 80 % de lo que hacemos (comprobar valores de configuración, encontrar filas huérfanas, vigilar SHOW PROCESSLIST durante una importación lenta) la CLI es más rápida que cualquier interfaz gráfica. Ya estás en una terminal:

# Dentro de un contenedor
sudo docker exec <your-shop>-db mysql -u root -p prestashop

SELECT name, value FROM ps_configuration WHERE name LIKE '%SMTP%';
SELECT COUNT(*) FROM ps_product WHERE active = 1;
SHOW FULL PROCESSLIST;

DBeaver cuando las relaciones importan

En el momento en que escribes joins entre ps_product, ps_product_lang, ps_product_shop, ps_stock_available y ps_image_lang (y eso es básicamente cualquier consulta no trivial de PrestaShop), el autocompletado y los diagramas entidad-relación de DBeaver se ganan su sitio. La tunelización SSH viene incorporada, así que nos conectamos directamente a bases de datos remotas de clientes sin pelearnos con redirecciones de puertos.

Probamos MySQL Workbench. Es más lento, la interfaz se siente más anticuada y la implementación del túnel SSH nos ha dado problemas con desconexiones aleatorias. DBeaver lo sustituyó.

phpMyAdmin: acabará usándolo

Todo hosting compartido con cPanel lo incluye. Cuando el único acceso de un cliente es cPanel, phpMyAdmin es lo que tiene. Está bien. Cumple su función. Eso sí, no lo instales en tu propio equipo de desarrollo: DBeaver es mejor en todos los aspectos que importan.

mysqldump para las copias de seguridad

# Siempre --single-transaction para InnoDB (PrestaShop usa InnoDB)
mysqldump -u root -p --single-transaction prestashop \
  | gzip > backup_$(date +%Y%m%d).sql.gz

# Solo estructura: útil para comparar esquemas entre versiones de PrestaShop
mysqldump -u root -p --no-data prestashop > schema.sql

Sin --single-transaction, una copia tomada durante pedidos activos contiene filas inconsistentes entre ps_orders, ps_order_detail y ps_stock_available. Lo aprendimos por las malas restaurando un volcado de un viernes por la noche que tenía tres pedidos en el limbo.

Caja de herramientas de PHP

Múltiples versiones de PHP, y por qué no nos molestamos en local

El consejo clásico es «instala PHP 7.4, 8.1, 8.2 y 8.3 en paralelo con ondrej/php ». Nosotros no. Cada contenedor Docker trae su propia versión de PHP; de la matriz se encarga el contenedor, no el host. Nuestro host ejecuta una sola versión de PHP en un contenedor de herramientas dedicado para Composer, PHPStan, scripts de grunt, y nada más.

Si usas LAMP directamente en un portátil, sin contenedores ni máquinas virtuales, claro, instala el PPA. Si ya estás sobre Docker, no.

Composer: con una trampa

Composer 2 es innegociable para cualquier módulo moderno de PrestaShop. Gestiona la autocarga, las dependencias, todo. Una cosa específica de nuestra configuración que señalamos porque hemos caído en ella: en nuestros módulos, varios paquetes compartidos (prestashop-admin, prestashop-integrity, prestashop-license y compañía) viven en vendor/myprestarocks/ pero se sincronizan mediante scripts, no se declaran en composer.json. Un composer install a secas los borra, la autocarga da un 500 en la siguiente petición y te pones a perseguir un bug fantasma.

O declara cada dependencia en composer.json, o incorpora un paso de sincronización a tu flujo de publicación. No mezcles los dos sin recordar qué paquetes son cuáles.

PHPStan: empiece bajo, suba despacio

PHPStan caza los bugs que viven en las ramas que normalmente no recorres: null sobre un objeto posiblemente nulo, tipo de retorno que no cuadra, código muerto. Lo ejecutamos en el nivel 5 en la mayoría de los módulos. El nivel 8 es alcanzable en código nuevo, menos en cualquier cosa que toque las clases ObjectModel heredadas de PrestaShop, que siguen filtrando tipos mixed por todas partes.

composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse src/ --level=5

Psalm es la alternativa. Ambos son excelentes. PHPStan tiene la comunidad más grande y más extensiones específicas de PrestaShop dando vueltas; por eso lo usamos.

PHP_CodeSniffer: para enviar a Addons

Si vendes módulos a través de PrestaShop Addons, tu código tiene que pasar el estándar de codificación de PrestaShop. phpcs + phpcbf es el ciclo:

vendor/bin/phpcs --standard=PSR12 src/
vendor/bin/phpcbf --standard=PSR12 src/

Más allá de los envíos a Addons, un estilo consistente tiene que ver sobre todo con la higiene de los diffs. Cuando cada archivo sigue los mismos patrones, los cambios reales destacan en las PR en lugar de quedar enterrados bajo ruido de espacios en blanco.

OPcache: no es una herramienta que se instala, sino una de la que se mantiene pendiente

OPcache está activado por defecto en todo contenedor moderno de PHP. Dos problemas nos afectan una y otra vez: el OPcache del pool web mantiene bytecode obsoleto tras un despliegue (hay que reiniciar la caché o estarás ejecutando el código antiguo), y los pools CLI y web tienen cachés separadas (limpiar una no limpia la otra). Incorpora un paso de «reiniciar OPcache tras el despliegue» a cada script de publicación. Lo aprendimos una vez, luego lo volvimos a aprender, y luego lo metimos en alias de shell.

Herramientas de navegador

Las Herramientas de desarrollo de Chrome: las pestañas que de verdad usamos

La pestaña Network es lo más abierto de todo el equipo. Filtra a XHR, observa la cascada AJAX durante un añadir al carrito, encuentra la petición que devuelve 200 con HTML cuando debería devolver JSON. Casi todo ticket de «el checkout está roto» empieza aquí.

Después de eso: la Consola para los errores de JS que lanzan los módulos del front-end de PrestaShop y que los usuarios nunca reportan; Elements para editar CSS en vivo antes de tocar los archivos de plantilla; Application para reventar una cookie de carrito atascada; Performance cuando una página se siente lenta pero el servidor dice que está bien (casi siempre es JS que bloquea el renderizado). Lighthouse está en la pestaña Audits: lo ejecutamos en la página de inicio, en categoría y en producto. Esas tres cubren las principales rutas reales de usuario.

Playwright antes que Selenium, siempre

Playwright gestiona las páginas cargadas de AJAX de PrestaShop sin el baile de tiempos que Selenium te obliga a hacer. El mecanismo de espera automática simplemente funciona. Lo usamos para las suites de regresión de Checkout Revolution y Performance Revolution: esos dos módulos tocan suficiente del flujo de checkout como para que no podamos publicarlos sin un pase de extremo a extremo automatizado.

const { chromium } = require('playwright');

(async () => {
    const browser = await chromium.launch();
    const page = await browser.newPage();
    await page.goto('http://localhost:8080/en/2-home-accessories.html');
    await page.click('.product-miniature:first-child a');
    await page.click('.add-to-cart');
    await page.waitForSelector('.cart-products-count');
    const cartCount = await page.textContent('.cart-products-count');
    console.log(`Cart items: ${cartCount}`);
    await browser.close();
})();

Este ejemplo inicia Chromium; cambia el tipo de navegador importado y la llamada de inicio para usar Firefox o WebKit. Selenium seguirá vivo dentro de 10 años, y está bien; sencillamente nosotros no lo usamos.

MCP de las Herramientas de desarrollo de Chrome + Claude Code: la incorporación nueva de esta lista

Esta es la que ha cambiado de verdad nuestro flujo de depuración este año. Ejecutamos Claude Code con el servidor MCP de las Herramientas de desarrollo de Chrome, que permite a Claude manejar un navegador real: hacer capturas, leer mensajes de consola, inspeccionar peticiones de red, evaluar scripts en el contexto de la página. «Abre el carrito, añade este producto, captura el paso de checkout y dime por qué no se aplica el código de descuento» funciona como una sola instrucción.

No reemplaza a la persona al volante. Quita la parte en la que cambias de contexto entre el editor y el navegador quince veces por hora. Para los bugs de CSS sobre todo, conseguir que Claude verifique un despliegue contra el DOM en vivo es más rápido que refrescar tú mismo.

Gráficos

GIMP para mapa de bits, Inkscape para vectorial, y Photopea cuando vamos con prisa

GIMP 3.0 (publicado en 2025) por fin arregló lo peor de la ergonomía de la interfaz y la compatibilidad con PSD. Lo usamos para editar imágenes de producto, banners e iconos de administración. ¿Es Photoshop? No. ¿Resuelve todas las tareas de imagen de PrestaShop? Sí.

Inkscape produce la salida SVG más limpia de todo lo que hemos probado: los iconos de administración pasan directos de Inkscape a las plantillas de los módulos. La salida SVG es lo bastante pequeña como para incrustarla en Smarty en lugar de servirla como archivo.

Photopea es la que abrimos más de lo que esperábamos. Funciona en el navegador, abre PSD y se ejecuta íntegramente en el lado del cliente. Cuando un cliente envía una maqueta PSD y necesitamos exportar una sola capa, abrir Photopea es más rápido que arrancar GIMP. Para nuestra automatización de portadas de caja en 3D (impulsada por la API de scripting de Photopea), de hecho hace trabajo de verdad en cada publicación.

ImageMagick: el caballo de carga sin interfaz

¿5000 imágenes de producto a 4000x4000 que tienen que pasar a versiones WebP de 800x800? mogrify en un bucle. Este es uno de los raros casos en los que la herramienta de CLI no solo es aceptable, sino que es realmente la respuesta correcta:

# Redimensionar todas a 800x800, calidad JPEG al 85%
for f in *.jpg; do
    convert "$f" -resize 800x800 -quality 85 "resized/$f"
done

# De PNG a WebP, misma calidad visual, ~30% más ligero
convert product.png -quality 80 product.webp

# Miniaturas cuadradas para las páginas de categoría
mogrify -resize 300x300^ -gravity center -extent 300x300 -path thumbs/ *.jpg

Hemos heredado pipelines de procesamiento de imágenes hechos en Node con sharp y otro en Python con Pillow. Ambos funcionan. Ninguno es más rápido que llamar a convert desde bash. Para operaciones por lotes en las que no necesitas control a nivel de píxel, ImageMagick es la respuesta.

Infraestructura de servidor

TrueNAS + ZFS: los cimientos

Todo el entorno de desarrollo vive en un equipo TrueNAS con 64 GB de RAM. ZFS nos da dos cosas que nos costaría reemplazar: las instantáneas (podemos rebobinar el conjunto de datos entero de Docker a «antes de esa actualización arriesgada de un módulo» en segundos) y las sumas de verificación de extremo a extremo (la corrupción silenciosa de bits se detecta y se corrige automáticamente, lo que importa cuando este disco guarda cada módulo que vendemos).

La raíz de datos de Docker vive en el pool SSD. Lo ejecutamos con live-restore activado para que reiniciar el demonio de Docker no tumbe todos los contenedores.

Nginx Proxy Manager, y la única regla

NPM nos da URLs limpias (ps8-dev.mypresta.rocks, ps9-dev.mypresta.rocks) con SSL de Let's Encrypt automático en todas nuestras instancias de desarrollo. La interfaz web es realmente buena: ningún archivo de configuración de Nginx que editar a mano.

Una regla que no romperemos: nunca hagas docker network connect ni disconnect sobre el contenedor de NPM mientras está en marcha. El contenedor queda bien; las reglas de iptables no se recuperan; el puerto 443 deja de responder; todos los sitios se caen. Pon NPM fuera de línea de forma limpia, cambia las redes, vuelve a levantarlo. Si alguna vez te has preguntado por qué tu proxy inverso dejó de servir HTTPS de repente, es esto.

WireGuard: cada portátil lo tiene

Las configuraciones de WireGuard tienen 10 líneas y conectan al instante. Comparado con OpenVPN es a la vez más rápido y menos delicado. Cada portátil del equipo tiene una entrada de peer; el servidor de desarrollo vive detrás de un cortafuegos doméstico y es accesible desde cualquier cafetería sin redirigir puertos.

Rclone para las copias de seguridad externas

Los ZIP de los módulos y los volcados de base de datos se sincronizan con Backblaze B2 cada noche. Rclone habla con más de 70 proveedores; elegimos B2 por el precio. La línea de cron es:

rclone sync ~/releases/ b2:mpr-releases/ --progress
rclone copy ~/backups/db/ b2:mpr-db-backups/

La copia externa no es algo que esperes a necesitar. La primera vez que la necesites, ya es demasiado tarde.

Uptime Kuma

Un único contenedor Docker conoce cada tienda de cliente y cada servicio interno, y avisa a Discord cuando algo se pone en rojo. «Nos dimos cuenta antes de que llamaras» es una mejor experiencia de soporte que «tu sitio lleva 4 horas caído, lo estamos mirando ahora».

Herramientas de compilación

Node.js: fije la versión

Nuestros contenedores ejecutan Node 20 LTS. La configuración de webpack del tema Hummingbird de PrestaShop es sensible a las diferencias de versión de Node; hemos visto cómo una actualización a Node 22 rompía en silencio la compilación de producción. nvm sobre hierro, node:20-bullseye en contenedores: fija y olvídate.

Grunt: para empaquetar los ZIP de los módulos

Cada uno de nuestros módulos se entrega con un Gruntfile.js. grunt en la raíz del módulo: sube la versión, excluye .git + node_modules + archivos de desarrollo, compila Sass, ejecuta el validador y deja un ZIP limpio en ~/releases/. Sin esto, el proceso de publicación es una secuencia de pasos manuales que alguien, tarde o temprano, equivoca a las 2 de la madrugada.

Webpack corre en Hummingbird (y en cualquier tema hijo que construyamos sobre él). El webpack.config.js preconfigurado del núcleo de PrestaShop está bien. Rara vez lo tocamos.

Dart Sass, y la trampa del BOM

Usa Dart Sass. Node Sass y Ruby Sass están muertos.

sass src/scss/admin.scss:views/css/admin.css --style=compressed
sass --watch src/scss/:views/css/

Una cosa que nos mordió una vez y solo una: Dart Sass puede emitir un BOM UTF-8 al principio del CSS compilado. En la mayoría de navegadores es inofensivo. En la configuración de un cliente, con una combinación concreta de nginx + CDN, el BOM hacía que la primera regla de CSS se descartara en silencio. La solución:

sed -i '1s/^\xEF\xBB\xBF//' output.css

Si una hoja de estilos parece rota sin motivo, comprueba si hay un BOM.

Correo y comunicación

Thunderbird es lo que usamos para los buzones de los clientes. IMAP en todos los dominios, OpenPGP incorporado, calendarios vía CalDAV. Hemos probado clientes web y están bien para el Gmail personal; para gestionar más de 8 buzones profesionales, la bandeja de entrada unificada y el motor de filtros de Thunderbird ganan.

Discord para la comunidad de PrestaShop y para el chat de nuestro propio equipo. Slack cuando un cliente lo impone. Element/Matrix es la respuesta correcta para soberanía total, pero el efecto de red de Discord ganó esa batalla por nosotros.

Para las notas, ejecutamos un wiki de Outline en nuestra propia infraestructura: ahí viven los runbooks de clientes, la documentación de infraestructura y los post-mortems. Sencillos archivos README.md en Markdown en cada repositorio de módulo cubren la documentación de cada módulo. El truco está en elegir un sistema y ser consistente; la elección concreta entre Outline, Obsidian, Trilium y Markdown a secas importa menos de lo que la gente cree.

Nuestros propios scripts

Esta sección no aparece en la mayoría de listas de «herramientas de desarrollo» porque la mayoría solo cubren software estándar. Tras diez años con PrestaShop hemos acumulado una pequeña biblioteca de scripts de shell en ~/scripts/ que de verdad nos ahorran horas a la semana:

  • nuke-module.sh: borra un módulo de un contenedor por completo: archivos, ps_module, ps_authorization_role, ps_hook_module, configuración, caché de Smarty, OPcache. La única forma sensata de probar un flujo de instalación desde una pizarra realmente limpia cuando una instalación previa medio fallida ha contaminado la base de datos.
  • fix-container-perms.sh: cambia el propietario de los archivos montados por bind a www-data dentro de un contenedor. Resuelve el problema de «los archivos aparecen como 3002:3002» cada vez que sincronizamos del host al contenedor.
  • sync-prestashop-*.sh: propaga los paquetes compartidos (prestashop-admin, prestashop-integrity, prestashop-license, prestashop-compat, etc.) desde las fuentes maestras en ~/packages/ a cada módulo que los usa. Se ejecuta tras arreglar un bug compartido en un único sitio para empujarlo a los 159 árboles de módulos.
  • El pipeline de envío/certificación/compilación: grunt más unos cuantos scripts envoltorio que suben la versión, validan el ZIP contra las reglas estáticas de PrestaShop, lo certifican, sincronizan los paquetes de vendor y empujan a GitHub en un único comando.

Si estás publicando más de dos o tres módulos, construye los tuyos. La inversión se devuelve la primera vez que una noche de publicación va sobre ruedas porque no se saltó ningún paso manual.

Por dónde empezar si se empieza hoy

La lista de consejos es más corta de lo que parece:

  1. Instala Docker. Asigna a cada tienda su propio proyecto Compose pequeño.
  2. Instala VS Code con PHP Intelephense, Smarty, GitLens, Remote-SSH, PHP Debug. Configura Xdebug en tu contenedor de PHP con start_with_request=trigger.
  3. Pon cada repositorio de módulo en Git. Las etiquetas coinciden con el $this->version del módulo.
  4. Añade Composer a un módulo, haz que funcione la autocarga y copia ese patrón al resto.
  5. Instala GIMP, Inkscape, ImageMagick. Los vas a necesitar antes de lo que crees.
  6. Configura Uptime Kuma en cuanto tengas un único sitio de producción que vigilar.

No intentes adoptar la lista entera de golpe. Docker + VS Code + Git + Xdebug es el núcleo. Todo lo demás se va apilando encima a medida que el trabajo lo exige.

Lecturas relacionadas

Módulos relacionados

Preguntas relacionadas

Volver arriba