Cree la configuración del personalizador más rápido mediante el uso de Kirki Framework en su proyecto

Publicado: 2019-08-10

Kirki es un marco gratuito de código abierto (con licencia MIT) creado para desarrolladores que buscan agregar controles personalizados a sus temas o complementos.

Aristeides Stathopoulos, el desarrollador principal de Kirki, ha estado trabajando en el marco desde 2014. Gracias a las actualizaciones y mejoras continuas, Kirki ha creado una comunidad en Github que incluye más de 1000 estrellas y 300 bifurcaciones.

Antes de Kirki nunca toqué el personalizador. ¡Kirki me ayudó a comprender el personalizador y hacer mucho en menos tiempo!

LebCit - Desarrollador de temas de WordPress

Controles del personalizador principal de WordPress

WordPress Core incluye un puñado de controles de personalización básicos de forma predeterminada. Por ejemplo: texto, área de texto, casilla de verificación, radio, selección, páginas desplegables, correo electrónico, URL, número, oculto y controles de fecha.

Kirki también es compatible con Core Controls, además de una veintena más. En términos generales, los controles de Kirki cubren los casos de uso más avanzados. Por ejemplo:

  • Tipografía
  • Paletas de colores
  • Editor TinyMCE
  • Campos ordenables

Kirki también ofrece una funcionalidad que no está disponible en Core WordPress, como la generación automática de su salida CSS y secuencias de comandos posteriores al mensaje. Estas funciones, que veremos más adelante en este artículo, pueden reducir fácilmente el tiempo de desarrollo a la mitad.

Kirki es lento

Una crítica común contra Kirki es que es lento. De hecho, esta crítica se usa contra la mayoría de los marcos (incluido WordPress). Tiene sentido, ¿verdad? Estás cargando una gran cantidad de código que quizás nunca uses.

En este caso, la realidad es que es todo lo contrario. La mayoría de las veces, los paneles de control creados con Kirki serán más rápidos que los mismos paneles creados con Core Controls.

Esto se debe a que Kirki agrega una capa de optimización que no está integrada en WordPress.

Cuando se inicializa el Personalizador, WordPress intenta instantáneamente cargar todos los controles, incluso si están dentro de una sección o panel y el usuario aún no puede interactuar con ellos. En comparación, Kirki pospone la carga hasta justo antes de que el usuario interactúe con el control.

Para ver el efecto de esto en la práctica, intentemos agregar 50 controles de color usando cada método.

Método básico:

 para ($i = 0; $i < 50; $i++){
	$wp_customize->add_setting( 'color_setting_hex_' . $i , array(
		'predeterminado' => '#0088CC'
	) );

	// agregar control selector de color
	$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'color_setting_hex_' . $i, array(
		'etiqueta' => 'Control de color',
		'sección' => 'title_tagline',
		'configuraciones' => 'color_setting_hex_' . $ yo,
	) ) );
}

Con Kirki:

 para ($i = 0; $i < 50; $i++) {
     Kirki::add_field('config_id', matriz(
         'tipo' => 'color',
         'configuraciones' => 'color_setting_hex_' . $ yo,
         'etiqueta' => __( 'Control de color', 'kirki'),
         'sección' => 'title_tagline',
         'predeterminado' => '#0088CC',
     ) );
 }

Los resultados:

Como puede ver, la velocidad de carga inicial es considerablemente más rápida cuando se usa Kirki. El código requerido para crear los controles también es más conciso.

Integrando a Kirki en su proyecto

Hay varias formas de integrar Kirki Framework en su proyecto, la documentación oficial hace un buen trabajo al explicar los diferentes métodos.

Recomiendo que los desarrolladores guíen al usuario para que instale la versión del complemento de Kirki, en lugar de incluir el marco directamente dentro del código de su proyecto. Esto se puede hacer usando TGMPA o el script provisto.

El razonamiento detrás de tomar la ruta del complemento es que Kirki se actualiza y mejora con frecuencia. Al instalar la versión del complemento, sus usuarios tendrán acceso instantáneo a correcciones de errores y actualizaciones de seguridad.

Por el contrario, cuando incluye el marco como parte de su proyecto, los usuarios solo recibirán actualizaciones cuando actualice su tema o complemento, lo que puede ser menos frecuente de lo necesario.

Independientemente del método que utilice, asegúrese de verificar que Kirki esté inicializado antes de agregar su configuración:

 // Salida anticipada si Kirki no existe.
if ( ! class_exists( 'Kirki' ) ) {
    regreso;
}

Campos

En el ejemplo de Core Method, primero creamos una configuración y luego creamos un control para ella. En la mayoría de los casos, los dos están directamente relacionados. Kirki simplifica el proceso y nos permite crear un 'Campo' en su lugar. Cuando se crea un campo, crea la configuración y el control en segundo plano para nosotros.

Los campos admiten todos los argumentos de control que esperaría (etiqueta, descripción, sección, predeterminado), así como algunos argumentos específicos de Kirki.

El argumento 'tipo' le permite elegir uno de los 30 tipos de control de Kirki: https://kirki.org/docs/controls/

Secciones

Las secciones del personalizador le permiten agrupar los controles. WordPress tiene seis secciones integradas a las que también puede agregar sus controles:

  • title_tagline – Identidad del sitio
  • colores – colores
  • header_image – Imagen de encabezado
  • background_image – Imagen de fondo
  • static_front_page – Configuración de la página de inicio
  • custom_css – CSS adicional


Las secciones en Kirki funcionan exactamente igual que en Core, el método Kirki::add_section() es simplemente un contenedor para $wp_customize->add_section() y acepta los mismos parámetros y argumentos.

 Kirki::add_section( 'section_id', array(
     'título' => esc_html__( 'Mi Sección', 'kirki' ),
     'descripción' => esc_html__( 'Descripción de mi sección.', 'kirki' ),
 ) );

Paneles

Los paneles le permiten crear otro nivel de jerarquía agrupando secciones. WordPress Core tiene un panel incorporado, que es 'Menús'.

Nuevamente, la implementación de Kirki es simplemente un contenedor para la funcionalidad principal.

 Kirki::add_panel('panel_id', matriz(
     'prioridad' => 10,
     'título' => esc_html__( 'Mi panel', 'kirki'),
     'descripción' => esc_html__( 'Descripción de mi panel', 'kirki' ),
 ) );

'transporte' => 'auto'

Tradicionalmente, al crear controles personalizados, tiene dos opciones para el argumento de transporte:

  • Actualizar : cada vez que el usuario realiza un cambio, el panel de vista previa se actualiza para mostrar los cambios. Esto puede tomar un par de segundos.
  • postMessage : cada vez que el usuario realiza un cambio, el panel de vista previa se actualiza mediante Javascript, que no requiere una actualización y es casi instantáneo.

postMessage es, sin duda, el método superior para actualizar la vista previa y debe utilizarse siempre que sea posible. Sin embargo, hay una desventaja, usar postMessage significa que necesita crear un código JS personalizado para cada uno de sus controles. Una implementación simple se parece a esto:

 // Actualizar el título del sitio en tiempo real...
wp.customize('nombre del blog', función(valor) {
    valor.bind( function( newval ) {
        $( '#título-sitio a' ).html( newval );
    });
});

Cuando tiene muchas configuraciones, esto puede volverse repetitivo rápidamente.

Aquí es donde brilla Kirki, agrega una tercera opción: 'transporte' => 'auto'.

'transporte' => 'auto' funciona junto con otro argumento que Kirki agrega llamado 'salida'. Cuando se definen ambos valores, Kirki generará automáticamente los scripts posteriores al mensaje por usted. Lo que significa que obtiene todos los beneficios de usar postMessage sin tener que escribir ningún código Javascript.

Un campo que usa transport => 'auto' se ve así:

 Kirki::add_field('config_id', matriz(
     'tipo' => 'color',
     'configuraciones' => 'color_setting_hex',
     'etiqueta' => __( 'Control de color', 'kirki'),
     'sección' => 'colores',
     'predeterminado' => '#0088CC',
     'transporte' => 'auto',
     'salida' => matriz(
         formación(
             'elemento' => 'cuerpo',
             'propiedad' => 'color de fondo',
         ),
     ),
 ) );

Esta característica de ahorro de tiempo de Kirki significa que la mayor parte del tiempo ya no necesitará escribir o poner en cola sus propios guiones posteriores al mensaje.

Salida de CSS de interfaz

Otra parte de la creación de la configuración del Personalizador es generar la salida CSS en la interfaz. Un ejemplo simple podría verse así:

 /**
 * Envíe el CSS del personalizador a wp_head
 */
función wptavern_customizer_css() {
	$bg_color = get_theme_mod('color_setting_hex');
	?>
	<estilo>
		cuerpo {
			color de fondo: <?php echo sanitize_hex_color ($bg_color); ?>;
		}
	</estilo>
	<?php
}
add_action('wp_head', wptavern_customizer_css);

Al igual que el ejemplo de postMessage, escribir este código puede volverse repetitivo rápidamente si tiene muchas configuraciones.

Afortunadamente, 'transport' => 'auto' también se encarga de la salida de la interfaz. Incluso en nuestro ejemplo simplificado, 'transport' => 'auto' ha reducido el código que necesitamos escribir en ~50%.

Conclusión

En este artículo, hemos analizado solo los conceptos básicos de Kirki Framework y dos de sus argumentos, ya podemos ver cómo nos permite crear controles personalizados más rápido y sin comprometer el rendimiento.

Cuando se sumerja en Kirki, descubrirá rápidamente la gran cantidad de funciones que agrega además de la API de personalización. No sorprende que esté en uso en más de 300 000 sitios web y sea una parte fundamental de algunos de los temas de WordPress más importantes del mercado.