Un flujo de trabajo Sass moderno para el desarrollo de temas de WordPress

La creación de CSS moderno y fácil de mantener para temas de WordPress conlleva varios retos que los desarrolladores deben superar. Utilizar Sass (Syntactically Awesome Style Sheets) como preprocesador de CSS puede ayudarte a organizar, mantener y escalar tus estilos de forma más eficaz.

Sin embargo, establecer un flujo de trabajo eficiente con Sass que encaje de forma natural en el desarrollo de WordPress requiere una planificación meditada y conocimientos técnicos.

Esta guía te muestra cómo configurar un flujo de trabajo Sass profesional para el desarrollo de temas de WordPress. Incluye herramientas de construcción modernas, una organización inteligente de archivos y prácticas de despliegue que mejoran la productividad y facilitan el mantenimiento de los estilos.

Antecedentes del uso de Sass para el desarrollo de WordPress

El desarrollo profesional de WordPress a menudo depende de herramientas y flujos de trabajo que van más allá de las capacidades integradas de la plataforma. Sass puede desempeñar un papel clave ayudándote a gestionar la complejidad del CSS con funcionalidades como variables, anidamiento, mixins, importaciones y funciones integradas.

Sass ofrece varias ventajas para el desarrollo de temas. Un tema típico de WordPress incluye estilos para numerosos componentes y partes de la plantilla. En lugar de gestionarlo todo en una única e inmanejable hoja de estilos, Sass permite una arquitectura modular que favorece el mantenimiento y la escalabilidad mediante una estructura programática.

Este enfoque estructurado va más allá de lo que ofrece el CSS estándar y se adapta bien a las exigencias de estilo únicas de WordPress. A diferencia de style.css con WordPress, Sass te permite crear hojas de estilo modulares y específicas para cada propósito que se compilan en archivos CSS optimizados mediante un flujo de trabajo sencillo:

1. Un proceso de creación para compilar archivos Sass en CSS.
2. Una estructura de archivos para organizar tus estilos de forma que se puedan mantener.
3. Herramientas de desarrollo para pruebas locales y control de calidad.
4. Estrategias de despliegue para enviar los cambios a los entornos staging y de producción.

La forma en que implementes este flujo de trabajo dependerá de las herramientas que prefiera tu equipo, del stack técnico y de la complejidad del proyecto. No obstante, la mayoría de las configuraciones de WordPress que utilizan Sass siguen unas prácticas comunes: configurar los mapas de origen para depuración, vigilar los archivos durante el desarrollo y optimizar el resultado para producción.

Una configuración típica separa tus archivos fuente Sass de los activos compilados, lo que facilita el mantenimiento de tu código base y proporciona un resultado limpio al navegador.

3 formas de compilar Sass en proyectos WordPress

La base de cualquier flujo de trabajo Sass es el proceso de construcción que transforma tus archivos Sass en CSS listo para el navegador. Hay varias formas de implementar esto en WordPress.

1. Utilizar plugins: El enfoque directo

La forma más accesible de utilizar Sass en un tema de WordPress es a través de plugins. Este enfoque es ideal si acabas de empezar o estás trabajando en un proyecto pequeño que no requiere un pipeline de construcción completo.

Por ejemplo, WP-Sass gestiona la compilación a través de los hooks de acción nativos de WordPress dentro de wp-config.php, monitorizando el directorio Sass de tu tema en busca de cambios:

<?php

// Include the class (unless you are using the script as a plugin)
require_once( 'wp-sass/wp-sass.php' );

// enqueue a .less style sheet
if ( ! is_admin() )
    wp_enqueue_style( 'style', get_stylesheet_directory_uri() . '/style.scss' );
else
    wp_enqueue_style( 'admin', get_stylesheet_directory_uri() . '/admin.sass.php' );

// you can also use .less files as mce editor style sheets
add_editor_style( 'editor-style.sass' );

?>

Otra opción, Sassify, es un poco más antigua y adopta un enfoque diferente — se conecta a las APIs de WordPress para gestionar la compilación de Sass, las rutas de salida y la configuración de compresión.

Aunque las soluciones basadas en plugins son sencillas, tienen algunas limitaciones:

• Sobrecarga de rendimiento. Estos plugins compilan Sass en el servidor, lo que puede consumir muchos recursos.
• Opciones de compilación limitadas. La mayoría de los plugins de Sass ofrecen una compilación básica, pero carecen de funcionalidades esenciales. Por ejemplo, a menudo hay una compatibilidad limitada con los mapas de código fuente, faltan funciones de prefijación automática, etc.
• Consideraciones de seguridad. Ejecutar un compilador en tu servidor de producción puede aumentar la superficie potencial de ataque, especialmente si el plugin no recibe un mantenimiento regular.
• Problemas de control de versiones. Los archivos CSS compilados a menudo viven en el directorio de tu tema, lo que complica los flujos de trabajo Git limpios. Lo ideal es que los activos compilados permanezcan fuera de tu repositorio.

Sin embargo, a pesar de estas limitaciones, un plugin sigue siendo una buena opción en determinados casos. Por ejemplo, sitios pequeños con requisitos mínimos de estilo, la entrega de un proyecto a un cliente sin los conocimientos técnicos necesarios para trabajar con Sass a un nivel más profundo, o el trabajo con recursos de desarrollo limitados.

2. Utilizar scripts NPM: La solución equilibrada

Si buscas más control y flexibilidad, los scripts NPM podrían ser una alternativa sólida a los plugins. La compilación Sass es un trabajo ideal para NPM, ya que logra un equilibrio entre simplicidad y capacidad. Ofrece mejoras sustanciales con respecto a los plugins para el desarrollo de temas sin la complejidad de los ejecutores de tareas completos:

• Al mantener la compilación separada de la ejecución de WordPress, eliminas la sobrecarga de rendimiento del servidor.
• Obtienes un control preciso sobre cada paso del proceso de compilación.
• El archivo package.json garantiza que todos los miembros del equipo utilicen el mismo proceso de compilación.
• Los scripts npm se integran a la perfección con los pipelines CI/CD.

Aunque este enfoque requiere más configuración inicial que los plugins, ofrece una solución más robusta y escalable para el desarrollo profesional de temas.

Configurar la compilación de Sass con NPM

Empieza creando un archivo package.json. Puedes hacerlo ejecutando

npm init -y

A continuación, instala Dart Sass:

npm install sass --save-dev

A continuación, añade estos scripts a tu package.json:

{
  "name": "your-theme-name",
  "version": "1.0.0",
  "description": "A WordPress theme with Sass",
  "scripts": {
    "sass": "sass src/sass/main.scss:assets/css/main.css",
    "sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css",
    "build": "sass src/sass/main.scss:assets/css/main.css --style=compressed"
  },
  "devDependencies": {
    "sass": "^1.58.3"
  }
}

Esta configuración te proporciona tres scripts útiles:

• npm run sass compila tus archivos Sass una vez.
• sass:watch vigila los cambios y recompila según sea necesario.
• build compila tus archivos Sass para producción con compresión.

Para soportar navegadores antiguos, añade Autoprefixer mediante PostCSS:

npm install postcss postcss-cli autoprefixer --save-dev

Actualiza tus scripts package.json:

{
  "scripts": {
    "sass": "sass src/sass/main.scss:assets/css/main.css",
    "prefix": "postcss assets/css/main.css --use autoprefixer -o assets/css/main.css",
    "build": "npm run sass && npm run prefix"
  },
  "devDependencies": {
    "autoprefixer": "^10.4.13",
    "postcss": "^8.4.21",
    "postcss-cli": "^10.1.0",
    "sass": "^1.58.3"
  },
  "browserslist": [
    "last 2 versions",
    "> 1%"
  ]
}

Para facilitar la depuración, añade mapas de fuentes:

{
  "scripts": {
    "sass": "sass src/sass/main.scss:assets/css/main.css --source-map",
    "sass:watch": "sass --watch src/sass/main.scss:assets/css/main.css --source-map"
  }
}

Por último, para utilizar tu CSS compilado en WordPress, pon en cola tu CSS compilado en functions.php:

function theme_enqueue_styles() {
    $style_path = '/assets/css/main.css';
    $full_path = get_template_directory() . $style_path;
    
    wp_enqueue_style(
        'theme-styles',
        get_template_directory_uri() . $style_path,
        array(),
        file_exists($full_path) ? filemtime($full_path) : false
    );
}
add_action('wp_enqueue_scripts', 'theme_enqueue_styles');

Esta función carga tu CSS compilado y añade la eliminación automática del caché utilizando la hora de modificación del archivo como número de versión.

3. Usar Gulp: La solución integral

Gulp es un potente ejecutor de tareas que destaca en la automatización de procesos de construcción complejos. Para el desarrollo de temas de WordPress con grandes necesidades de estilo, puede ser la solución más completa.
Te permite gestionar la compilación de Sass, la sincronización con el navegador y todo lo demás. ¿Por qué Gulp?

• Gulp gestiona casi todos los aspectos de tu proceso de construcción, como la compilación, la optimización y el despliegue.
• Puedes ejecutar varias tareas simultáneamente, lo que reduce los tiempos de construcción.
• El ecosistema ofrece herramientas para prácticamente cualquier requisito de construcción.
• La integración con BrowserSync permite obtener información instantánea durante el desarrollo.

Aunque Gulp tiene una curva de aprendizaje más pronunciada que otros enfoques, sus ventajas lo convierten en la opción preferida de muchos.

Configuración de Gulp para temas de WordPress

Para empezar a utilizar Gulp, es necesario instalarlo junto con algunos plugins que se encargan de tareas específicas:

# Initialize your project
npm init -y

# Install Gulp and related packages
npm install --save-dev gulp gulp-sass sass gulp-autoprefixer gulp-sourcemaps browser-sync gulp-cssnano

También debes crear un archivo gulpfile.js en el directorio raíz de tu tema, que gestionará algunos pasos diferentes. La primera parte sirve para importar todas las herramientas necesarias:

// 1. Import dependencies
const { src, dest, watch, series, parallel } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();
const cssnano = require('gulp-cssnano');

Cada paquete sirve para un propósito específico:

• gulp: el motor central de tareas
• gulp-sass y sass: compila Sass a CSS.
• gulp-autoprefixer: añade prefijos de proveedor para compatibilidad con navegadores.
• gulp-sourcemaps: genera mapas de código fuente para la depuración.
• browser-sync: Actualiza los navegadores durante el desarrollo.
• gulp-cssnano: minifica CSS para producción.

Desde aquí, puedes definir rutas a tus archivos de origen y destino y crear una función para compilar Sass:

// 2. Define file paths
const files = {
  sassPath: './src/sass/**/*.scss',
  cssPath: './assets/css/'
}

// 3. Sass development task with sourcemaps
function scssTask() {
  return src(files.sassPath)
    .pipe(sourcemaps.init())
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(sourcemaps.write('./'))
    .pipe(dest(files.cssPath))
    .pipe(browserSync.stream());
}

Esta función básicamente encuentra todos tus archivos Sass, inicializa los mapas de fuentes para la depuración y compila Sass a CSS (con gestión de errores). También añade prefijos de proveedor para la compatibilidad del navegador, escribe tus mapas de fuentes, guarda el CSS compilado y actualiza el navegador con los cambios. En definitiva, ¡hace mucho trabajo!

También debes crear una función de construcción lista para la producción, un observador de tareas y una función de exportación:

// 4. Sass production task with minification
function scssBuildTask() {
  return src(files.sassPath)
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(cssnano())
    .pipe(dest(files.cssPath));
}

// 5. Watch task for development
function watchTask() {
  browserSync.init({
    proxy: 'localhost:8888' // Change this to match your local development URL
  });
  
  watch(files.sassPath, scssTask);
  watch('./**/*.php').on('change', browserSync.reload);
}

// 6. Export tasks
exports.default = series(scssTask, watchTask);
exports.build = scssBuildTask;

Esta versión de producción omite los mapas de fuentes y añade la minificación para optimizar el tamaño de los archivos. En general, la configuración te permite ejecutar npx gulp para el desarrollo (con observación de archivos y actualización del navegador) y npx gulp build para las construcciones de producción.

Mejorar tu flujo de trabajo con Gulp

Para proyectos más grandes, es posible que desees separar los estilos según su finalidad. A continuación se muestra un ejemplo:

// Define paths for different style types
const paths = {
  scss: {
    src: './src/sass/**/*.scss',
    dest: './assets/css/'
  },
  editorScss: {
    src: './src/sass/editor/**/*.scss',
    dest: './assets/css/'
  }
}

// Main styles task
function mainStyles() {
  return src('./src/sass/main.scss')
    .pipe(sourcemaps.init())
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(sourcemaps.write('./'))
    .pipe(dest(paths.scss.dest))
    .pipe(browserSync.stream());
}

// Editor styles task
function editorStyles() {
  return src('./src/sass/editor-style.scss')
    .pipe(sourcemaps.init())
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(sourcemaps.write('./'))
    .pipe(dest(paths.scss.dest))
    .pipe(browserSync.stream());
}

Para temas complejos con muchos archivos Sass, también deberías optimizar el rendimiento de la construcción mediante el almacenamiento en caché de los archivos procesados para evitar recompilaciones innecesarias, el seguimiento de las dependencias de Sass para recompilar únicamente los archivos afectados, y mucho más. Sin embargo, esto va más allá del alcance de este artículo.

Otras herramientas de compilación a tener en cuenta

Aunque la mayoría de los desarrolladores se quedan con los scripts NPM o Gulp, puedes encontrar otras alternativas que ofrecen ventajas únicas para el desarrollo de temas de WordPress. Vite y Webpack son dos soluciones comunes.

Webpack destaca en la agrupación de JavaScript y activos, lo que resulta ideal si tu tema utiliza arquitecturas basadas en componentes o frameworks de JavaScript. Su punto fuerte es su capacidad para crear paquetes optimizados mediante la división de código y el «tree shaking» — muy útil para temas complejos con mucho JavaScript.

En cambio, Vite es una herramienta de construcción más reciente que prioriza la velocidad de desarrollo gracias a su enfoque innovador en la carga de módulos. Su servidor de desarrollo proporciona reemplazo instantáneo de módulos en caliente, lo que permite una iteración de desarrollo extremadamente rápida. Aunque su integración con los flujos de trabajo de WordPress sigue evolucionando, es una opción interesante si puedes aprovecharla para tu propio desarrollo de temas.

Para proyectos más sencillos o de preferencia personal, la CLI de Sass ofrece un enfoque directo sin herramientas adicionales:

# Install Sass globally
npm install -g sass

# Compile Sass files
sass --watch src/sass/main.scss:assets/css/main.css

Aunque la compilación manual carece de las funcionalidades de automatización e integración de las herramientas de construcción dedicadas, su simplicidad tiene una ventaja. Este enfoque funciona bien para temas simples con necesidades de estilo sencillas, prototipos rápidos o proyectos pequeños. También puede ser adecuado para quienes prefieren herramientas mínimas.

Cómo estructurar y organizar un proyecto de desarrollo de WordPress con Sass

Más allá del proceso de construcción, organizar eficazmente tus archivos Sass es esencial para el mantenimiento y la colaboración. Una estructura bien planificada hace que tu código sea más fácil de navegar, actualizar y escalar a medida que crece tu tema.

El patrón 7-1: Organización modular para temas complejos

El patrón 7 -1 es una práctica común para organizar archivos Sass en proyectos grandes. Consiste en dividir el código de estilos en siete carpetas temáticas más un archivo principal (main.scss) que importa todos los demás.

Este patrón crea una separación lógica, facilitando la búsqueda y actualización de estilos específicos. Aquí tienes una visión general de la estructura:

• Abstracts. Contiene utilidades que no generan CSS directamente, variables para colores, tipografía y espaciado, funciones para cálculos y lógica, mixins para patrones de estilo reutilizables y marcadores de posición para estilos ampliables.
• Base. Incluye estilos fundamentales y predeterminados, reglas tipográficas, clases de utilidad y selectores de elementos (sin clases). También te permite restablecer o normalizar CSS.
• Components. Alberga componentes de interfaz de usuario reutilizables, como botones, formularios y tarjetas, menús de navegación, widgets y barras laterales, y formatos multimedia (como imágenes y vídeos).
• Layouts. Aquí defines los elementos estructurales, como la cabecera y el pie de página, los sistemas de cuadrículas, las estructuras de contenedores y la disposición de las barras laterales.
• Pages. Aquí se incluyen estilos específicos por página, la portada, diseños de entrada individual, páginas de archivo o landing pages.
• Themes. En esta sección tienes diferentes temas o modos visuales. Temas claros y oscuros, variaciones estacionales, personalizaciones del área de administración y temas específicos de la marca.
• Vendors. La última sección es donde almacenas estilos de terceros, anulaciones de plugins, personalizaciones del framework y estilos de componentes externos.

El archivo principal (normalmente main.scss) importa todos los parciales en un orden específico:

// Abstracts
@import 'abstracts/variables';
@import 'abstracts/mixins';
// Vendors (early to allow overriding)
@import 'vendors/normalize';
// Base styles
@import 'base/reset';
@import 'base/typography';
// Layout
@import 'layouts/header';
@import 'layouts/grid';
// Components
@import 'components/buttons';
@import 'components/forms';
// Page-specific styles
@import 'pages/home';
@import 'pages/blog';
// Themes
@import 'themes/admin';

Este enfoque modular puede evitar la «sopa de CSS» que a menudo afecta a los grandes proyectos. Es un sistema fácil de mantener que se adapta a la complejidad de tu tema.

Estructura centrada en bloques: Organización moderna para el Editor de Bloques y de Sitios

Si tu tema se centra en el Editor de Bloques, a menudo tiene más sentido una estructura que dé prioridad a estos componentes. Esto puede alinear tu organización Sass con el modelo de contenido basado en bloques de WordPress.

La estructura es más sencilla en comparación con el Patrón 7-1:

• Core. Aquí se sitúan tus estilos y configuraciones básicos, como las variables, los mixins, los helpers, el estilo de los elementos base y los Bloques del core de WordPress.
• Blocks. Aquí viven las variaciones personalizadas de los bloques, los estilos ampliados de los bloques del core y los estilos del patrón de bloques.
• Templates. Aquí añadirás tus plantillas de entrada única, plantillas de archivo y plantillas de página personalizadas.
• Utilities. Son clases y herramientas de ayuda, como utilidades de espaciado, clases de tipografía y utilidades de color o fondo.

Esta estructura respalda la naturaleza modular del desarrollo con bloques, facilitando el mantenimiento de la coherencia entre tus variaciones y plantillas.

Consideraciones específicas de WordPress para la organización de Sass

Al organizar Sass para temas de WordPress, hay que tener en cuenta varias consideraciones específicas de la plataforma. La jerarquía de plantillas de WordPress determina qué archivos PHP utilizar para los distintos tipos de contenido.

Aplicar esta jerarquía en tu organización Sass crea conexiones intuitivas entre las plantillas PHP y sus estilos asociados. Por lo tanto, considera organizar los estilos específicos de cada página para que coincidan con la estructura de plantillas de WordPress:

// _archive.scss
.archive {
  // Base archive styles
  
  &.category {
    // Category archive styles
  }
    
  &.tag {
    // Tag archive styles
  }
    
  &.author {
    // Author archive styles
  }
}

Este enfoque deja claro de inmediato qué estilos se aplican a contextos de plantillas específicos, a la vez que simplifica el mantenimiento y las actualizaciones.

Organización de la compatibilidad con plugins

Los plugins a menudo inyectan sus propios estilos, y puede que tu tema necesite anularlos. En lugar de dispersar las anulaciones por tus archivos base, considera la posibilidad de aislarlas:

Por ejemplo, la estructura para la integración de WooCommerce podría adoptar una de varias estructuras:

vendors/woocommerce/
├── _general.scss          // Base WooCommerce styles
├── _buttons.scss          // WooCommerce button styles
├── _forms.scss            // WooCommerce form styles
├── _shop.scss             // Shop page styles
└── _single-product.scss   // Single product page styles

Esta organización facilita la actualización de los estilos de compatibilidad del plugin cuando éste se actualiza, mantiene la separación entre los estilos del tema y del plugin, y encuentra rápidamente los estilos específicos relacionados con el plugin.

Y recuerda siempre utilizar un espacio de nombres (namespace) en tus sobrescrituras para evitar conflictos de estilo:

// _woocommerce.scss
.woocommerce {
  .products {
    // Custom product grid styles
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
    gap: 2rem;
  }
    
  .single-product {
    // Single product page styles
    .price {
      font-size: 1.5rem;
      color: $price-color;
    }
  }
}

Este enfoque evita que los estilos de los plugins se filtren en el diseño central de tu tema, a la vez que proporciona anulaciones claras donde las necesites.

Estilo del editor y del administrador

A menudo tendrás que aplicar estilos tanto al front end como a la interfaz del editor de bloques. Para ello, puedes crear una estructura específica para los estilos específicos del administrador:

admin/
├── _editor.scss         // Block editor styles
├── _login.scss          // Login page customization
└── _dashboard.scss      // Dashboard customizations

Para el editor de bloques, compila una hoja de estilos separada y ponla en cola de la siguiente manera:

function theme_editor_styles() {
  add_theme_support('editor-styles');
  add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

Esto mantiene el contexto de tu editor limpio, coherente y visualmente alineado con el front-end.

Implementación del diseño responsivo

Los temas de WordPress deben funcionar en varios tamaños de dispositivo, por lo que necesitas un enfoque sistemático para tu diseño responsivo. Aquí es donde el uso de mixins de Sass puede crear un sistema coherente y mantenible:

// Breakpoint mixin
@mixin respond-to($breakpoint) {
  @if $breakpoint == "sm" {
    @media (min-width: 576px) { @content; }
  }
  @else if $breakpoint == "md" {
    @media (min-width: 768px) { @content; }
  }
  @else if $breakpoint == "lg" {
    @media (min-width: 992px) { @content; }
  }
}

Si mantienes los estilos responsivos contextualmente cercanos a sus definiciones base, crearás un código base más fácil de mantener que muestra claramente cómo se adaptan los componentes a los breakpoints.

Configurar un entorno de desarrollo local

El desarrollo local es una parte esencial de cualquier flujo de trabajo en WordPress, y es aún más importante cuando se utilizan herramientas como Sass. Una configuración adecuada permite una iteración rápida, comentarios en tiempo real y una conexión perfecta entre tu proceso de creación de Sass y tu sitio de WordPress.

DevKinsta es una forma estupenda de configurar un entorno de desarrollo local adaptable a tus necesidades, y su instalación y configuración son sencillas.

Utilizar Gulp para configurar la compilación de Sass dentro del directorio de tu tema es la opción más sencilla. Primero, navega hasta el directorio de tu tema, luego inicializa NPM e instala las dependencias como hemos explicado antes.

A continuación, crea un gulpfile.js con BrowserSync configurado para tu sitio DevKinsta:

const { src, dest, watch, series } = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const autoprefixer = require('gulp-autoprefixer');
const sourcemaps = require('gulp-sourcemaps');
const browserSync = require('browser-sync').create();

// Get your DevKinsta site URL from the dashboard
const siteURL = 'your-site-name.local';

function scssTask() {
  return src('./src/sass/**/*.scss')
    .pipe(sourcemaps.init())
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(sourcemaps.write('./'))
    .pipe(dest('./assets/css/'))
    .pipe(browserSync.stream());
}

function watchTask() {
  browserSync.init({
    proxy: siteURL,
    notify: false
  });
  
  watch('./src/sass/**/*.scss', scssTask);
  watch('./**/*.php').on('change', browserSync.reload);
}

exports.default = series(scssTask, watchTask);

A continuación, configura tu estructura de archivos:

mkdir -p src/sass/{abstracts,base,components,layouts,pages,themes,vendors}
touch src/sass/main.scss

Ahora estás listo para ejecutar npx gulp. Cada vez que cambie un archivo Sass o PHP, tus estilos se compilarán, se inyectarán en el navegador y se actualizarán según sea necesario.

Pasar del desarrollo a producción

Una vez que hayas desarrollado tu tema localmente, necesitas una estrategia fiable para desplegarlo en entornos staging y de producción.

Kinsta te lo pone fácil con entornos staging integrados que se sincronizan directamente con DevKinsta. Con sólo unos clics, puedes pasar tu tema de local a producción:

Esto garantiza que tanto los archivos CSS compilados como los archivos fuente Sass se trasladen de forma segura al staging. Para equipos con necesidades de despliegue más complejas, puedes automatizar los despliegues de staging utilizando Gulp. Aquí tienes un ejemplo:

const { src, parallel, series } = require('gulp');
const rsync = require('gulp-rsync');

// Clean and build tasks defined earlier

// Deployment task
function deployToStaging() {
  return src('dist/**')
    .pipe(rsync({
      root: 'dist/',
      hostname: 'your-kinsta-sftp-host',
      destination: 'public/wp-content/themes/your-theme/',
      archive: true,
      silent: false,
      compress: true
    }));
}

// Export the deployment task
exports.deploy = series(
  parallel(cleanStyles, cleanScripts),
  parallel(styles, scripts),
  deployToStaging
);

Tras el despliegue en el staging, debes realizar pruebas exhaustivas para asegurarte de que el CSS compilado con Sass funciona correctamente:

1. Pruebas visuales. Aquí, verifica que todos los estilos se aplican como se espera en todas las páginas.
2. Pruebas responsivas. Asegúrate de que todos los breakpoints respondan como se espera.
3. Pruebas de rendimiento. Google PageSpeed Insights, Lighthouse y otras herramientas pueden ayudarte a comprobar la carga del CSS.
4. Verificación entre navegadores. Recuerda realizar pruebas en distintos navegadores para detectar problemas de compatibilidad.

Durante las pruebas, presta especial atención a las rutas, la configuración del caché y los permisos de los archivos, ya que son causas comunes de problemas de despliegue. A continuación, puedes desplegar tu tema en producción. El envío selectivo de Kinsta hace que este proceso sea sencillo, manteniendo el control sobre lo que despliegas.

Este es otro momento en el que necesitas asegurarte de que tu CSS recibe la optimización adecuada antes de desplegarlo. Hay algunas formas de hacerlo, como la minificación, la organización de archivos y la eliminación del caché.

Crear integraciones eficaces con el Editor de bloques

El desarrollo moderno de WordPress se centra en el Editor de Bloques, y un buen estilo garantizará la coherencia entre la edición y el front-end.

Por ejemplo, en lugar de organizar los estilos exclusivamente por plantillas de página, considera una organización centrada en bloques. Puedes empezar creando parciales Sass dedicados para cada tipo de bloque:

blocks/
├── _paragraph.scss      // Paragraph block styles
├── _heading.scss        // Heading block styles
├── _image.scss          // Image block styles
├── _gallery.scss        // Gallery block styles
└── _custom-block.scss   // Custom block styles

Esto facilita el mantenimiento de los estilos a medida que evoluciona el core de WordPress y crece la biblioteca de bloques de tu tema. Los estilos de cada bloque pueden existir de forma ordenada y actualizarse de forma independiente.

Dentro de cada archivo de bloque, procura establecer convenciones de nomenclatura claras que se ajusten a las clases de bloque de WordPress:

// _paragraph.scss
.wp-block-paragraph {
  // Base paragraph block styles
  font-family: $body-font;
  line-height: 1.6;
  
  // Block variations
  &.is-style-lead {
    font-size: 1.2em;
    font-weight: 300;
  }
  
  &.has-background {
    padding: 1.5rem;
  }
}

Este enfoque crea una relación directa entre los controles del Editor de Bloques y los estilos resultantes, lo que hace que tu tema sea más predecible y fácil de mantener.

Para mantener la experiencia de edición sincronizada con el front-end, compila hojas de estilo separadas y comparte variables entre ellas:

// In your gulpfile.js
function themeStyles() {
  return src('./src/sass/main.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(dest('./assets/css/'));
}

function editorStyles() {
  return src('./src/sass/editor.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(dest('./assets/css/'));
}

Pon en cola estos estilos de editor específicamente para el contexto del editor de bloques:

function theme_editor_styles() {
  add_theme_support('editor-styles');
  add_editor_style('assets/css/editor.css');
}
add_action('after_setup_theme', 'theme_editor_styles');

Para mantener la coherencia visual, puedes utilizar variables y mixins compartidos en ambas hojas de estilo:

// abstracts/_variables.scss
$primary-color: #0073aa;
$secondary-color: #23282d;
$heading-font: 'Helvetica Neue', Helvetica, Arial, sans-serif;
$body-font: 'Georgia', serif;
// Import in both main.scss and editor.scss

Este enfoque garantiza que los colores, la tipografía y el espaciado permanezcan coherentes entre las experiencias de edición y visualización.

Integración con theme.json

El archivo theme.json es donde los temas de bloques definen la configuración global que afecta tanto al editor como al front end. Alinear tus variables Sass con la configuración de theme.json puede crear un sistema cohesionado. Por ejemplo:

{
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        {
          "name": "Primary",
          "slug": "primary",
          "color": "#0073aa"
        }
      ]
    }
  }
}

Puedes hacer coincidir esto en tus archivos Sass:

// Match theme.json values
$color-primary: #0073aa;

// Generate matching custom properties
:root {
  --wp--preset--color--primary: #{$color-primary};
}

Esta sencilla sincronización garantizará que tus estilos personalizados funcionen en armonía con los controles incorporados y el sistema de estilos globales del Editor de bloques.

Optimización del rendimiento con Sass

La optimización del rendimiento es un factor fundamental para los temas profesionales de WordPress. Más allá de la compilación básica, los flujos de trabajo de Sass pueden aportar otras técnicas para mejorar la velocidad de carga y la experiencia del usuario (UX).

Implementar CSS crítico para una carga más rápida

El CSS crítico es una técnica de optimización que extrae y alinea el CSS mínimo que tu sitio necesita para mostrar el contenido «por encima del pliegue». Las rutas críticas de renderización, en general, son importantes cuando se desarrolla para WordPress; optimizar tu CSS crítico puede mejorar los tiempos de carga percibidos al reducir el CSS que bloquea la renderización.

Escribir CSS crítico es una habilidad en sí misma — añadir Sass aumentará la dificultad. Empieza por crear un archivo Sass separado específicamente para los estilos críticos, y luego configura tu proceso de construcción para que compile este archivo por separado:

// critical.scss - Only include styles for above-the-fold content
@import 'abstracts/variables';
@import 'abstracts/mixins';

// Only essential styles
@import 'base/reset';
@import 'layouts/header';
@import 'components/navigation';

function criticalStyles() {
  return src('./src/sass/critical.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(cssnano())
    .pipe(dest('./assets/css/'));
}

Para implementar este CSS crítico en tu tema, simplemente lo alineas en las etiquetas head mientras asincronizas la carga del CSS de relleno:

function add_critical_css() {
  $critical_css = file_get_contents(get_template_directory() . 
    '/assets/css/critical.css');
  echo '' . $critical_css . '';
  
  // Async load full CSS
  echo '';
}
add_action('wp_head', 'add_critical_css', 1);

Esta técnica puede mostrar el contenido más rápidamente mientras el resto de los estilos se cargan en segundo plano. Sin embargo, no todas las páginas necesitan todos los estilos de tu tema. La carga condicional basada en la plantilla o tipo de contenido actual puede aumentar aún más el rendimiento.

Puedes hacerlo cargando CSS específico de la plantilla en el archivo functions.php de tu tema:

function load_template_specific_css() {
  // Base styles for all pages
  wp_enqueue_style('main-styles', 
    get_template_directory_uri() . '/assets/css/main.css');
    
  // Product page specific styles
  if (is_singular('product')) {
    wp_enqueue_style('product-styles', 
      get_template_directory_uri() . '/assets/css/product.css');
  } 
  // Archive page specific styles
  elseif (is_archive()) {
    wp_enqueue_style('archive-styles', 
      get_template_directory_uri() . '/assets/css/archive.css');
  }
}
add_action('wp_enqueue_scripts', 'load_template_specific_css');

Este enfoque reduce la carga de CSS de cada página, mejora los tiempos de carga y mantiene una alta calidad de diseño.

Implementar un control inteligente del caché

Gestionar tu caché siempre va a beneficiar al usuario final, ya que obtiene los estilos más recientes a la vez que aprovecha el almacenamiento en caché de los activos no modificados. La eliminación automática del caché mediante Sass se realiza dentro de la cola de estilos de tu tema:

function enqueue_styles_with_cache_busting() {
  $css_file = get_template_directory() . '/assets/css/main.css';
  $version = filemtime($css_file);
  
  wp_enqueue_style('main-styles', 
    get_template_directory_uri() . '/assets/css/main.css', 
    array(), $version);
}
add_action('wp_enqueue_scripts', 'enqueue_styles_with_cache_busting');

Esta técnica utiliza la hora de modificación del archivo como número de versión, lo que garantiza que los navegadores sólo almacenen en caché el CSS hasta que cambie, y luego descarguen automáticamente la versión actualizada.

Gestionar los mapas de fuentes de forma segura

Los mapas de fuentes son muy valiosos durante el desarrollo, pero pueden exponer tu código fuente Sass en producción. Aquí es donde podría ser útil implementar una gestión de mapas de código fuente específica para cada entorno:

// In your gulpfile.js
const isProduction = process.env.NODE_ENV === 'production';

function styles() {
  return src('./src/sass/main.scss')
    .pipe(gulpif(!isProduction, sourcemaps.init()))
    .pipe(sass().on('error', sass.logError))
    .pipe(autoprefixer())
    .pipe(gulpif(!isProduction, sourcemaps.write('./')))
    .pipe(dest('./assets/css/'));
}

Para una depuración controlada en producción, es posible que quieras proporcionar mapas de origen solo a los administradores:

function conditional_source_maps() {
  // Only for administrators with debug parameter
  if (current_user_can('manage_options') && isset($_GET['debug_css'])) {
    wp_enqueue_style('debug-maps', 
      get_template_directory_uri() . '/assets/css/main.css.map');
  }
}
add_action('wp_enqueue_scripts', 'conditional_source_maps', 999);

Esto mantiene las ventajas de los mapas de código fuente para la depuración y protege tu código fuente de una exposición innecesaria — una gran victoria para todos.

Crear flujos de trabajo en equipo eficaces

Los flujos de trabajo y las normas coherentes son esenciales para cualquier equipo que trabaje en temas de WordPress con Sass. Para los flujos de trabajo específicos de Sass, deberías intentar establecer normas claras en algunas áreas clave.

Por ejemplo, intenta definir convenciones y patrones de nomenclatura coherentes para variables, mixins y clases:

// Variables: use kebab-case with descriptive prefixes
$color-primary: #0073aa;
$font-heading: 'Helvetica Neue', sans-serif;
$spacing-base: 1rem;

// Mixins: verb-based naming
@mixin create-gradient($start, $end) {
  background: linear-gradient(to bottom, $start, $end);
}

// Classes: BEM convention
.card {
  &__header { /* header styles */ }
  &__body { /* body styles */ }
  &--featured { /* featured variant */ }
}

También es una buena idea estandarizar la forma en que los nuevos archivos se incorporan al proyecto. Aquí tienes algunos ejemplos de normas que podrías aplicar:

• Los nuevos componentes irán al directorio de componentes.
• Cada componente tendrá su propio archivo.
• Todos los archivos utilizarán el mismo orden de importación.
• Los parciales empezarán siempre con guión bajo.

Además de esto, define también requisitos para los comentarios del código y la documentación. Puedes «codificar» estas normas en un archivo de configuración .stylelintrc para automatizar su cumplimiento:

{
  "extends": "stylelint-config-standard-scss",
  "rules": {
    "indentation": 2,
    "selector-class-pattern": "^[a-z][a-z0-9-]*$",
    "max-nesting-depth": 3,
    "selector-max-compound-selectors": 4
  }
}

Las revisiones del código son importantes para Sass porque los pequeños cambios pueden tener efectos de gran alcance en la apariencia de tu tema. Tus propios procesos de revisión deben abordar específicamente el estilo de varias maneras:

• Cumplimiento de la guía de estilo. Asegúrate de que los nuevos estilos se adhieren al sistema de diseño actual de tu proyecto.
• Consideraciones de rendimiento. Revisa todos los resultados de tu CSS en busca de oportunidades de optimización.
• Compatibilidad entre navegadores. Verifica que los estilos que construyas funcionen en todos los navegadores necesarios.

Por supuesto, debes incluir estas cuestiones específicas de Sass en las listas de verificación de revisión de código de tu equipo para mantener unos altos estándares en todo tu código base.

Estrategias de control de versiones para proyectos Sass

Hay varias consideraciones específicas de Sass dentro del control de versiones que merecen tu atención. Una decisión importante es si debes o no incluir en el repositorio el CSS ya compilado. Hay dos escuelas de pensamiento que influirán en tu elección:

• No commit CSS mantiene tu repositorio limpio, pero requiere pasos de construcción durante el despliegue.
• Hacer commit del CSS aumentará el tamaño de tu repositorio, pero también garantizará que los archivos que despliegues coincidan exactamente con lo que pruebas.

Si decides que no quieres hacer commit de los archivos compilados, asegúrate de que se excluyen correctamente en tu archivo .gitignore:

# .gitignore
.sass-cache/
*.css.map
*.scss.map
node_modules/
/assets/css/

Por último, revisa la estructura de tus ramas en busca de cambios de estilo y piensa cómo gestionarás esos cambios para los nuevos componentes (como las ramas de funcionalidad), las variaciones visuales (para las que podrías utilizar ramas temáticas) y las actualizaciones importantes del diseño (quizás utilizando ramas específicas para cada estilo).

Resumen

Un flujo de trabajo Sass moderno puede transformar el desarrollo de tu tema de WordPress de un reto a un proceso estructurado y mantenible.

Los componentes clave de un flujo de trabajo Sass eficaz incluyen un proceso de construcción sencillo pero capaz, una organización de archivos bien pensada, optimizaciones del rendimiento y flujos de trabajo en equipo sólidos. A medida que evoluciona el Editor de bloques, una implementación de Sass flexible y robusta te permite adaptarte sin dejar de ofrecer resultados de alta calidad.

Y si buscas un alojamiento para WordPress que admita este tipo de flujo de trabajo — desde acceso SSH y WP-CLI hasta entornos staging con un solo clic — Kinsta ofrece una plataforma fácil de usar para desarrolladores, construida para admitir herramientas modernas desde el primer momento.