Hace unos días compartí que estaba creando unas utilidades para recortar esquinas en tarjetas, con idea de estandarizarlas y convertirlas en un patrón oficial dentro de Flowtitude.

Pues bien: no vamos a desarrollar esas utilidades (al menos por ahora), porque he encontrado un plugin que lo resuelve de forma muy elegante —y además abre la puerta a mucho más que un simple «corte».

👉 Se llama Tailwind CSS Corner Shape Plugin.

✨ ¿Qué hace exactamente?

Este plugin aprovecha la propiedad CSS corner-shape para que tus rounded-* de siempre se vean con un estilo más moderno (tipo squircle, bevel y variantes similares), sin tocar tu HTML ni montar soluciones específicas por componente.

En pocas palabras: sigues usando Tailwind como siempre, pero las esquinas pueden verse mucho más refinadas.

✅ Lo mejor (para nuestro día a día)

• Mejora automática de *`rounded-`**: aplicas tus radios normales y el plugin se encarga del “look” de las esquinas.
• Compatible con valores arbitrarios: si usas rounded-[20px], también entra.
• Presets listos: puedes activar estilos como squircle (y otros) de forma directa.
• Degradación limpia: si el navegador no soporta corner-shape, se mantiene el border-radius estándar sin romper nada.

🧩 Cómo lo usaríamos en Tailwind v4 (CSS-first)

En el enfoque de Tailwind v4, se integra de forma muy natural cargando el preset:

@plugin "tailwindcss-corner-shape/presets/squircle";

🎯 Por qué encaja con Flowtitude

Porque respeta tu escala de radios (rounded-*) y convierte esa decisión de diseño en algo más potente, sin meter ruido en el sistema ni obligarnos a mantener utilidades «caseras» para cada caso.

📌 Enlace al plugin https://github.com/bilalharouchi/tailwindcss-corner-shape

La nueva era del WordPress moderno

Estos días estan promocionando PhantomWP, una propuesta muy interesante si lo que queremos es mantener WordPress como gestor de contenido, pero servir la web con un front ultra rápido (generado con Astro).

📌 ¿Qué es exactamente?
PhantomWP conecta tu WordPress actual (sin migraciones) y lo usa como CMS «headless». A partir de ahí te genera un proyecto en Astro (con Tailwind/TypeScript) y lo deja listo para publicar en hosting estático tipo Vercel/Netlify con CDN global.

✨ Por qué esto puede hacer nuestras webs más eficientes

• ⚡ Velocidad real: al generar páginas estáticas, se evitan procesos PHP y consultas a base de datos en cada visita. PhantomWP afirma mejoras típicas de 60–90% en tiempos de carga.
• 🔒 Más seguridad: el frontal público es HTML estático, y el WordPress puede quedar “oculto” (menos superficie de ataque).
• 🧩 Menos “plugin-bloat”: los plugins de front (sliders, popups, etc.) no se trasladan tal cual, pero eso también empuja a reemplazar «peso» por componentes más limpios.
• 🔎 SEO sin romper tu flujo: mantiene el trabajo con plugins SEO habituales (Yoast, RankMath, AIOSEO) y genera sitemap/robots.
• 🚀 Publicación rápida: el flujo está pensado para conectar WP → generar el sitio → previsualizar → desplegar en pocos minutos.

✅ Dónde encaja mejor (muy Flowtitude-friendly)
PhantomWP está pensado para sitios «content-first»: blogs, portfolios, webs de agencia, landing pages, documentación… PhantomWP
Es decir: proyectos donde queremos SEO + contenido + velocidad + estabilidad.

⚠️ Ojo con esto (para no llevarnos sorpresas)
De momento no está orientado a WooCommerce ni a plataformas complejas tipo LMS, reservas, etc. (al menos «todavía»).

Acabo de ver este vídeo y me dejó pensando, porque no es una teoría: un agente de IA para programar (Google Antigravity) terminó borrando por error una partición completa cuando el usuario solo quería «limpiar la caché» del proyecto. Según se cuenta, el problema se agravó por usar modo «Turbo» (menos confirmaciones) y por ejecutar un comando destructivo que acabó apuntando a la raíz del disco D:, eliminando archivos sin pasar por la papelera.

algo parecido me paso con un proyecto, afortunadamente tenia copias...

Ya he empezado a montar los Bloques PRO. La idea es que estén disponibles en una librería remota, para poder mantenerlos actualizados y que los tengáis siempre listos para usar.

Ahora mismo estoy centrado en refactorizar los 5 diseños de loop de productos: los estoy pasando a componentes, limpiando estructura y mejorándolos todo lo posible para que sean más sólidos y reutilizables.

Esto va a tardar un poquito porque no quiero hacerlo con prisas: prefiero hacerlo bien desde el principio y que lo que salga sea realmente útil y mantenible.

Después de esta fase, seguiré con:

• Un par de diseños de ficha de producto (single)
• Las páginas de Mi cuenta, Carrito y Checkout

Iré compartiendo avances conforme tenga piezas listas para enseñar.

De vez en cuando surgen casos que ya no son una duda rápida, sino una intervención real en un proyecto (revisar un setup, ajustar algo concreto, validar una estructura, etc.).

Para poder ayudar sin romper la planificación, a partir de ahora lo gestionaré como Intervención Express:

✅ Prioridad
✅ Trabajo acotado por bloques
✅ Objetivo claro + entrega final con resumen y próximos pasos

📌 Esto no sustituye el soporte de la membresía.

Si te interesa, deja un 👍 y lo priorizo para lanzarlo cuanto antes.

En uno de los proyectos en los que estoy trabajando me encontré con un detalle de diseño muy concreto: necesitaba poder «eliminar» (recortar) una esquina diferente en cada tarjeta, como en la captura.

La típica solución rápida sería hacerlo a medida en cada componente… pero como esto se repite más de lo que parece, he preferido hacerlo bien: he creado unas clases de utilidad para poder aplicar este efecto de forma consistente y reutilizable, sin depender de hacks puntuales.

✅ Qué permiten estas utilidades

• Elegir qué esquina se recorta (arriba-izq, arriba-der, abajo-izq, abajo-der)
• Mantener el efecto compatible con tarjetas reales (padding, border, background, hover, etc.)
• Poder usarlo tanto en layouts simples como en grids de tarjetas

🧠 Siguiente paso
Antes de publicarlo «tal cual», le voy a dar una pensada más profunda para dejarlo más estandarizado (nombres, tamaños, compatibilidad con tokens, escalas…) y así poder integrarlo dentro del sistema de diseño de Flowtitude como un patrón oficial, no como una solución aislada.

Cuando lo tenga redondo, comparto:

• las clases finales,
• ejemplos listos para copiar/pegar,
• y una mini guía de uso (cuándo sí / cuándo no).

Estoy trabajando en una nueva plantilla de checkout y, como podéis ver en la captura, ya está muy avanzada. Y ojo: no es solo un lavado de cara. La idea es mejorar la experiencia real de compra, especialmente en móvil y cuando usas pagos rápidos.

✅ Qué incluye (además del nuevo diseño):

• Resumen del carrito más claro y limpio, con mejor jerarquía visual.

• En las secciones de dirección de envío y facturación, añadimos la opción de convertir las etiquetas (labels) en placeholders (para un look más minimal y compacto, sin perder estructura).

• Botones de pago rápido (Apple Pay / Google Pay / Link) separados del botón principal de “Finalizar compra”, para que el usuario entienda mejor:

  • pago inmediato vs checkout estándar
    y no mezcle acciones.

🔧 En qué punto estamos ahora
Estamos en la fase de pulir el último bloque, especialmente la parte de la convivencia y comportamiento de los pagos rápidos (alineación, jerarquía, consistencia y sensación «pro» en todos los casos).

Ya puedes actualizar a la última versión de WindPress (3.3.72), el plugin que usamos para integrar Tailwind CSS en WordPress dentro del ecosistema Flowtitude. Esta actualización es sobre todo de compatibilidad y mejoras internas, pero para nosotros es importante porque asegura que el «motor Tailwind» siga siendo estable sobre la base de WordPress 6.9.

🧱 Compatibilidad con WordPress 6.9

• WindPress 3.3.72 marca oficialmente la compatibilidad con WordPress 6.9.
• Traducido: podemos ir preparando la actualización a 6.9 con más tranquilidad, sabiendo que el puente entre WordPress + Tailwind + Bricks sigue en buen estado.

🧠 Soporte inicial para la Abilities API (experimental)

En la 3.3.69 se ha añadido soporte inicial (experimental) para la nueva WordPress Abilities API, que es el sistema con el que WordPress empieza a exponer sus capacidades (“lo que puede hacer un sitio o plugin”) de forma estándar para automatización y herramientas externas.

Para nosotros, a corto plazo:

• No cambia tu forma de trabajar día a día.
• Pero abre la puerta a mejores integraciones con automatizaciones e IA en el futuro (por ejemplo, orquestar tareas de WindPress / Flowtitude desde fuera de WordPress de forma más limpia).

🧩 Mejoras internas que sí se notan en proyectos reales

Aunque varias notas del changelog son “internas”, nos afectan de forma práctica:

• Gutenberg + «Generate Cache on Save»
  Se corrige un problema por el que los assets de esa función no se cargaban bien en Gutenberg.
  👉 Si usas bloques con Tailwind y confías en esa opción, ahora el CSS debería generarse y cargarse de forma más consistente.
• Rutas en Windows
  Se arregla un fallo de manejo de rutas en sistemas Windows.
  👉 Importante si trabajas en local con Windows: menos errores raros al generar o leer archivos de CSS/JS.
• Nuevo parser interno (@windpress/oxide-parser)
  Han sustituido la dependencia del escáner antiguo por el nuevo parser.
  👉 Esto debería hacer que la detección de clases Tailwind en el contenido sea más robusta y más preparada para las novedades de Tailwind 4.
• Corrección en los bundles ZIP del plugin (3.3.70 y 3.3.71)
  El empaquetado interno del plugin (los archivos ZIP) no se generaba correctamente y ya está corregido.
  👉 A ti no te cambia nada en el uso diario, pero asegura que las actualizaciones y builds del plugin lleguen completas y sin sorpresas.

En resumen: no es una versión «espectacular» en características visibles, pero sí un paso importante para tener WindPress alineado con WordPress 6.9 y el futuro de la Abilities API, y para que nuestro stack WordPress + Tailwind + Flowtitude sea un poco más sólido. 💪🧡

Nosotros todavía no la estamos usando en Flowtitude, porque primero tiene que añadirle soporte WindPress, que es quien se encarga de integrar Tailwind en nuestros proyectos WordPress.

Aun así, es una versión importante porque trae sobre todo mejoras internas de estabilidad y depuración, que serán muy útiles cuando lleguen a nuestro entorno.

🧱 ¿Por qué nos importa en Flowtitude?

Cuando WindPress se actualice a esta versión, los cambios que más vamos a notar son:

• ✅ Compilaciones más fiables
  Mejor gestión de los archivos que Tailwind analiza para generar las clases, lo que reduce casos del tipo “esta clase está en la plantilla pero no aparece en el CSS”.
• 🔍 Errores más fáciles de entender
  Los errores de CSS indicarán archivo y línea, así que localizar un fallo en el CSS de Flowtitude o en tus ajustes personalizados será mucho más rápido.
• 🧩 Mejor comportamiento con utilidades avanzadas
  Tailwind ajusta cómo trata las clases con valores personalizados (arbitrarios), combinaciones raras, etc., lo que ayuda en layouts complejos y en patrones más avanzados.
• ⚙️ Flujo de compilación más estable
  Se han pulido varios detalles del CLI, lo que debería traducirse en menos “cosas raras” cuando WindPress genere el CSS.

👉 En resumen:
Por ahora es solo una noticia importante de cara al futuro.
Cuando WindPress anuncie soporte para Tailwind 4.1.18, revisaremos cómo encaja con Flowtitude.

Más información: https://github.com/tailwindlabs/tailwindcss/releases/tag/v4.1.18

Hoy os comparto un proyecto que empieza a sonar fuerte en el mundillo de WordPress aunque no he tenido tiempo de probar: Mosaic. No es “otro page builder más”, sino un theme builder + sistema de diseño completo pensado para trabajar con HTML y CSS reales manteniendo un flujo visual tipo Webflow.

En resumen, ¿de qué va y en qué se basa?

• 🔧 Theme builder completo: permite crear todo el tema (headers, footers, templates, etc.) con una arquitectura de “masters” que heredan diseños, al estilo plantillas maestras.
• 🎨 Editor visual + sistema de clases: trabajas visualmente, pero con clases reutilizables, variables de estilo, breakpoints, componentes e interacciones, loops y datos dinámicos. La idea es construir un design system, no solo páginas sueltas.
• 📚 Temas base propios: incluye temas como Blank, Gibraltar y Monolith, que son más bien frameworks con librerías grandes de bloques (400+ bloques y 50+ páginas en un tema, según ellos).
• 🧱 Orientado a rendimiento y control: el marcado final refleja lo que construyes (control sobre etiquetas semánticas como header, nav, section, etc.), pensado para quien quiere evitar el “div soup” típico de algunos constructores.
• 🧪 Estado actual: está en beta pública (v0.9.3) y el roadmap ya habla de soporte para WooCommerce, constructor de bloques Gutenberg y mejoras de rendimiento.

De momento se puede probar en beta de forma gratuita, así que si os interesa la idea de un constructor más cercano a un design system profesional que a un page builder clásico, puede ser un juguete interesante para trastear y ver por dónde evoluciona.