Aparece theme.json en WordPress 5.8

Aparece theme.json en WordPress 5.8

theme.json en WordPress

Aparece theme.json en WordPress 5.8.

Con la reciente versión del CMS1 más usado (discutiblemente), la versión 5.8, aparece una nueva forma de trabajar con los Temas, más propiamente, con el estilo del Tema.

Según la declaración oficial, «Aparece un nuevo mecanismo para configurar el editor que permite un control más detallado e introduce el primer paso en la gestión de estilos para futuras versiones de WordPress».

Este artículo está basado en gran parte, en una publicación de «André Maneiro» (https://profiles.wordpress.org/nosolosw/).

La razón del theme.json en WordPress

Hasta ahora, la forma tradicional en la que se controlaba el editor, era por medio de llamadas a la función add_theme_support que determinaba el comportamiento global del Tema.

Con la aparición de los bloques, se aprecia una forma diferente de control de los bloques HTML2, dependiendo del comportamiento de los bloques de edición de WordPress.

Este cambio ha provocado la necesidad de un mayor detalle en los elementos CSS3 que, a su vez, aumenta el número de elementos y la complejidad de estos.

Tener un punto central de configuración tiene como objetivo brindar una experiencia más consistente y completa.

Funcionamiento

Al crear un archivo theme.json en el directorio de nivel superior del tema, los temas pueden configurar los ajustes del editor existente (los tamaños de fuente preestablecidos, si los colores personalizados están habilitados, etc.) así como los nuevos a medida que se introducen (el aspecto del «duotono», si los controles de margen y relleno están habilitados, etc.).

Por ejemplo, si queremos deshabilitar todos los colores personalizados, se puede usar el código:

...
{
    "version": 1,
    "settings": {
        "color": {
            "custom": false
        }
    }
}
...

La aparición del archivo theme.json también proporciona una forma para que los autores de temas controlen estas configuraciones por bloque, algo que antes no era posible.

Si lo que quieres es deshabilitar los colores personalizados para todos los bloques excepto el bloque de párrafo, deberás usar el código de la siguiente forma:

...
{
    "version": 1,
    "settings": {
        "color": {
            "custom": false
        },
        "blocks": {
            "core/paragraph": {
                "color": {
                    "custom": true
                }
            }
        }
    }
}
...

Para trabajar con un bloque, se «direcciona» el nombre de bloque, es decir, se apela a un bloque, por su nombre genérico.

Nota: para mantener la compatibilidad con versiones anteriores, las declaraciones add_theme_support existentes del tema se actualizan en las categorías adecuadas para la sección de nivel superior. 

Por ejemplo, si se usa un tema con la declaración add_theme_support('disable-custom-colors'), el resultado será el mismo que el de establecer settings.color.custom a false. Si se declara una configuración en theme.json, esa configuración tendrá prioridad sobre los valores declarados a través de add_theme_support.

Consulta el documento de especificaciones para obtener una lista completa de características y compatibilidad con versiones anteriores add_theme_support.

Cómo acceder a la configuración del tema

Los bloques han sido actualizados para respetar la nueva configuración que proviene de un tema a través de theme.json. Por ejemplo, si un bloque admite un control de margen de la interfaz de usuario, pero el tema tiene un margen deshabilitado en todos los ámbitos, el control de la interfaz de usuario no se mostrará en el editor.

Para que los bloques de terceros también puedan aprovechar este mecanismo, existe el gancho useSetting de React en su función de edición:

    import { useSetting } from '@wordpress/block-editor';
    // En algún lugar de la función de edición de bloques.

    const isEnabled = useSetting( 'spacing.margin' );

    if ( ! isEnabled ) {
        return null;
    } else {
        return <ToggleControl ... />
}

Puedes obtener más información sobre la API y la documentación de useSetting, en la documentación oficial.

Las clases de CSS para los ajustes preestablecidos se crean y se ponen en cola automáticamente

Hasta ahora, para que un tema compatible con bloques funcionase correctamente con el editor de bloques, tenían que declarar ajustes preestablecidos para el editor y también poner en cola las clases correspondientes por separado.

Esto se realiza mediante la correspondiente función en el archivo functions.php, de la siguiente manera:

add_theme_support(
  'editor-color-palette',
  array(  /* define los colores preestablecidos, incluyendo traducciones */
) );

Y luego, en el archivo style.css:

.has-<value>-color { /* ... */ }
.has-<value>-background-color { /* ... */ }
/* etc */

Al usar el theme.json, el tema solo tiene que declarar sus ajustes preestablecidos.

El motor de WordPress configurará las traducciones y se encargará de crear y poner en cola los estilos correspondientes tanto para el editor como para el front-end:

    {
    "version": 1,
    "settings": {
        "color": {
            "palette": [
                {
                    "name": "Color name",
                    "slug": "color-slug",
                    "color": "<color-value>"
                },
                {
                    "name": "...",
                    "slug": "...",
                    "color": "..."
                }
            ]
        }
    }
}

Las propiedades personalizadas de CSS

Otra de las ventajas de eliminar el soporte de IE11, es que muchas funciones de CSS estarán disponibles. Una de estas características ahora disponibles son las propiedades personalizadas de CSS

Cuando un tema agrega ajustes preestablecidos a través del archivo theme.json, el motor pondrá en cola ambas clases y propiedades personalizadas de CSS para ellos.

Por ejemplo:

    {
    "version": 1,
    "settings": {
        "color": {
            "palette": [
                {
                    "name": "Black",
                    "slug": "black",
                    "color": "#000000"
                },
                {
                    "name": "White",
                    "slug": "white",
                    "color": "#ffffff"
                }
            ]
        }
    }
}

creará esta salida en CSS:

/* Una Propiedad CSS Personalizada por valor preset. */
body {
  --wp--preset--color--black: #000000;
  --wp--preset--color--white: #ffffff;
}

/* Las clases correspondientes para cada valor preset. */

.has-black-color { color: var(--wp--preset--color--black) !important; }
.has-black-background-color { background-color: var(--wp--preset--color--black) !important;  }

.has-white-color { color: var(--wp--preset--color--white) !important; }
.has-white-background-color { background-color: var(--wp--preset--color--white) !important;  }

Estilos gestionados para una mejor coordinación

Uno de los eternos focos de conflicto a los que se enfrentan los diseñadores de Temas, son los conflictos que aparecen en un entorno con estilos centrales, temáticos y de usuario, así como en la amplia área de diseño que viene con múltiples bloques que se pueden combinar indefinidamente.

El archivo theme.json absorbe la mayoría de los casos de uso comunes para diseñar bloques con el objetivo de reducir la cantidad de CSS enviado al navegador, mitigar las guerras de especificidad y proporcionar información de estilo actual en los controles de la interfaz de usuario para los usuarios. 

Este es el primer paso para tener un mecanismo que consolide los tres orígenes de estilos (núcleo, tema, usuario).

Por ejemplo, para proporcionar estilos al nivel superior y un par de bloques, usaremos un código parecido a:

{
    "version": 1,
    "styles": {
        "color": {
            "text": "var(--wp--preset--color--primary)"
        },
        "blocks": {
            "core/paragraph": {
                "color": {
                    "text": "var(--wp--preset--color--secondary)"
                }
            },
            "core/group": {
                "color": {
                    "text": "var(--wp--preset--color--tertiary)"
                }
            }
        }
    }
}

Lo que da como resultado la siguiente salida CSS:

/* Estilos de nivel superior para el selector de body. */
body {
  color: var(--wp--preset--color--primary);
}

/* Estilos de bloque para el selector de bloque de párrafo y el bloque personalizado de clase wp-block-group. */
p {
  color: var(--wp--preset--color--secondary);
}
.wp-block-group {
  color: var(--wp--preset--color-tertiary);
}

Cualquier bloque, tanto central como de terceros, puede ser apelado por su nombre.

Acceso a otras funciones

Hay algunas funciones que están habilitadas o deshabilitadas cuando un tema es compatible con un archivo theme.json. Estas son:

  • El editor de plantillas está habilitado.
  • El diseño predeterminado y los estilos de margen para los temas no están en cola y , en su lugar, están habilitadas las nuevas opciones de diseño.
  • Se elimina el div interno para el bloque de grupo wp-block-group__inner-container.
  • Los estilos font-family predeterminados para el editor, no están en cola.

Conclusión

Aunque no nos guste a todos, el editor de bloques ha venido para quedarse. Las reticencias que muchos tenemos sobre la pérdida de control, se van solventando poco a poco (aunque personalmente creo que faltan muchas y no solventarán todas). 😜

Recuerda que aún puedes crear tu propio tema hijo, usando las técnicas que te hemos explicado en otros artículos, esto no es (aún) una imposición.

Mientras tanto, recuerda, #UsaMascarilla, #LavateLasManos, juega, experimenta y, sobre todo, ¡divertirte!


Canales de Telegram: Canal SoloWordpressCanal SoloLinux 


¡Espero que este articulo te sea de utilidad, puedes ayudarnos a mantener el servidor con una donación en PayPal, o también colaborar con el simple gesto de compartir nuestros artículos en tu sitio web, blog, foro o redes sociales!

¡Tus comentarios y preguntas nos ayudan a mejorar, por favor comenta!

 

Chat de SoloWordpress


  1. Content Management System 

  2. HyperText Marckup Language 

  3. Cascading Style Sheet 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

logo solowordpress mails

Suscríbete a SoloWordpress

Recibe todos los nuevos artículos es tu correo electrónico

¡Te has suscrito correctamente!

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Ver nuestra Política de Cookies
Privacidad
Ir al contenido