Creați setări de personalizare mai rapid utilizând cadrul Kirki în proiectul dvs

Publicat: 2019-08-10

Kirki este un cadru gratuit cu sursă deschisă (licență MIT) creat pentru dezvoltatorii care doresc să adauge comenzi de personalizare temelor sau pluginurilor lor.

Aristeides Stathopoulos, dezvoltatorul principal al lui Kirki, lucrează la cadru din 2014. Datorită actualizărilor și îmbunătățirilor continue, Kirki a construit o comunitate pe Github care include peste 1000 de stele și 300 de furculițe.

Înainte de Kirki, nu am atins niciodată personalizatorul. Kirki m-a ajutat să înțeleg personalizarea și să fac multe în mai puțin timp!
LebCit – Dezvoltator de teme WordPress

Controale de personalizare de bază pentru WordPress

WordPress Core include o mână de comenzi de personalizare de bază în mod implicit. De exemplu: text, zonă de text, casetă de selectare, radio, selectare, pagini drop-down, e-mail, URL, număr, ascuns și comenzi de dată.

Kirki acceptă și comenzile de bază, plus încă aproximativ douăzeci. În general, comenzile Kirki acoperă cazurile de utilizare mai avansate. De exemplu:

Tipografie
Palete de culori
Editor TinyMCE
Câmpuri sortabile

Kirki oferă, de asemenea, funcționalități care nu sunt disponibile în Core WordPress, cum ar fi generarea automată a ieșirii dvs. CSS și a scripturilor postMessage. Aceste caracteristici, pe care le vom analiza mai târziu în acest articol, vă pot reduce cu ușurință timpul de dezvoltare la jumătate.

Kirki este lent

O critică adresată în mod obișnuit la adresa lui Kirki este că este lent. De fapt, această critică este folosită împotriva majorității cadrelor (inclusiv WordPress). Are sens, nu? Încarci o mulțime de cod pe care s-ar putea să nu-l folosești niciodată.

În acest caz, realitatea este că contrariul este adevărat. De cele mai multe ori panourile de control construite folosind Kirki vor fi de fapt mai rapide decât aceleași panouri construite cu Core Controls.

Acest lucru se datorează faptului că Kirki adaugă un strat de optimizare care nu este încorporat în WordPress.

Când Personalizatorul este inițializat, WordPress încearcă instantaneu să încarce toate comenzile, chiar dacă acestea se află într-o secțiune sau panou și utilizatorul nu poate interacționa cu ele încă. În comparație, Kirki amână încărcarea până chiar înainte ca utilizatorul să interacționeze cu controlul.

Pentru a vedea efectul acestui lucru în practică, să încercăm să adăugăm 50 de controale de culoare folosind fiecare metodă.

Metoda de bază:

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

	// adaugă controlul selectorului de culori
	$wp_customize->add_control( nou WP_Customize_Color_Control( $wp_customize, 'color_setting_hex_' . $i, array(
		'label' => 'Controlul culorii',
		'section' => 'title_tagline',
		'settings' => 'color_setting_hex_' . $i,
	) ) );
}

Cu Kirki:

 pentru ($i = 0; $i < 50; $i++) {
     Kirki::add_field( 'config_id', array(
         'type' => 'culoare',
         'settings' => 'color_setting_hex_' . $i,
         'label' => __( 'Controlul culorii', 'kirki' ),
         'section' => 'title_tagline',
         'default' => '#0088CC',
     ) );
 }

Rezultatele:

După cum puteți vedea, viteza inițială de încărcare este considerabil mai rapidă atunci când utilizați Kirki. Codul necesar pentru a crea controalele este de asemenea mai concis.

Integrarea Kirki în proiectul dvs

Există mai multe moduri de a integra Kirki Framework în proiectul dvs., documentația oficială face o treabă bună explicând diferitele metode.

Recomand dezvoltatorilor să îndrume utilizatorul să instaleze versiunea plugin-ului Kirki, în loc să includă cadrul direct în codul proiectului. Acest lucru se poate face folosind TGMPA sau scriptul furnizat.

Motivul din spatele utilizării traseului pluginului este că Kirki este actualizat și îmbunătățit frecvent. Prin instalarea versiunii de plugin, utilizatorii dvs. vor avea acces instantaneu la remedieri de erori și actualizări de securitate.

În schimb, atunci când includeți cadrul ca parte a proiectului dvs., utilizatorii vor primi actualizări doar atunci când vă actualizați tema sau pluginul, care ar putea fi mai puțin frecvent decât este necesar.

Indiferent de metoda pe care o utilizați, asigurați-vă că verificați că Kirki este inițializat înainte de a adăuga setările:

 // Ieșire devreme dacă Kirki nu există.
dacă ( ! class_exists( 'Kirki' ) ) {
    întoarcere;
}

Câmpuri

În exemplul Core Method, am creat mai întâi o setare și apoi am creat un control pentru aceasta. În cele mai multe cazuri, cele două sunt legate direct. Kirki simplifică procesul și ne permite să creăm un „Câmp” în schimb. Când un câmp este creat, acesta creează setarea și controlul în fundal pentru noi.

Câmpurile acceptă toate argumentele de control la care v-ați aștepta (etichetă, descriere, secțiune, implicit), precum și unele argumente specifice Kirki.

Argumentul „tip” vă permite să alegeți unul dintre cele 30 de tipuri de control ale lui Kirki: https://kirki.org/docs/controls/

Secțiuni

Secțiunile de personalizare vă permit să grupați Comenzile împreună. WordPress are șase secțiuni încorporate la care puteți adăuga și comenzile:

title_tagline – Identitatea site-ului
culori – Culori
header_image – Imagine de antet
background_image – Imagine de fundal
static_front_page – Setări pentru pagina de pornire
custom_css – CSS suplimentar

Secțiunile din Kirki funcționează exact la fel ca în Core, metoda Kirki::add_section() este pur și simplu un wrapper pentru $wp_customize->add_section() și acceptă aceiași parametri și argumente.

 Kirki::add_section( 'section_id', array(
     'title' => esc_html__( 'Secțiunea mea', 'kirki' ),
     'description' => esc_html__( 'Descrierea secțiunii mele.', 'kirki' ),
 ) );

Panouri

Panourile vă permit să creați un alt nivel de ierarhie prin gruparea secțiunilor. WordPress Core are un panou încorporat, care este „Meniuri”.

Din nou, implementarea Kirki este pur și simplu un înveliș pentru funcționalitatea Core.

 Kirki::add_panel( 'panel_id', array(
     'prioritate' => 10,
     'title' => esc_html__( 'Panoul meu', 'kirki' ),
     'description' => esc_html__( 'Descrierea panoului meu', 'kirki' ),
 ) );

'transport' => 'automat'

În mod tradițional, atunci când creați controale de personalizare aveți două opțiuni pentru argumentul de transport:

Actualizează – De fiecare dată când utilizatorul face o modificare, panoul de previzualizare este reîmprospătat pentru a afișa modificările. Acest lucru poate dura câteva secunde.
postMessage – De fiecare dată când utilizatorul face o modificare, panoul de previzualizare este actualizat folosind Javascript, care nu necesită reîmprospătare și este aproape instantaneu.

postMessage este, fără îndoială, metoda superioară de actualizare a previzualizatorului și ar trebui folosită acolo unde este posibil. Cu toate acestea, există un dezavantaj, utilizarea postMessage înseamnă că trebuie să creați un cod JS personalizat pentru fiecare dintre controalele dvs. O implementare simplă arată cam așa:

 // Actualizați titlul site-ului în timp real...
wp.customize( 'nume blog', function( value ) {
    value.bind( function( newval ) {
        $( '#site-title a' ).html( newval );
    });
});

Când aveți o mulțime de setări, acestea pot deveni rapid repetitive.

Aici strălucește Kirki, adaugă o a treia opțiune: „transport” => „auto”.

„transport” => „auto” funcționează împreună cu un alt argument pe care Kirki îl adaugă numit „ieșire”. Când ambele valori sunt definite, Kirki va genera automat scripturile postMessage pentru dvs. Ceea ce înseamnă că beneficiați de toate beneficiile utilizării postMessage fără a fi nevoie să scrieți codul Javascript.

Un câmp care utilizează transport => „auto” arată astfel:

 Kirki::add_field( 'config_id', array(
     'type' => 'culoare',
     'settings' => 'color_setting_hex',
     'label' => __( 'Controlul culorii', 'kirki' ),
     'section' => 'culori',
     'default' => '#0088CC',
     'transport' => 'automat',
     'ieșire' => matrice(
         matrice(
             'element' => 'corp',
             'property' => 'culoare de fundal',
         ),
     ),
 ) );

Această funcție de economisire a timpului a lui Kirki înseamnă că de cele mai multe ori nu va mai fi nevoie să scrieți sau să puneți în coadă propriile scripturi postMessage.

Ieșire CSS pentru front-end

O altă parte a creării setărilor de personalizare este generarea de ieșire CSS pe front-end. Un exemplu simplu ar putea arăta astfel:

 /**
 * Ieșiți CSS de personalizare la wp_head
 */
funcția wptavern_customizer_css() {
	$bg_color = get_theme_mod('color_setting_hex');
	?>
	<stil>
		corp {
			culoare de fundal: <?php echo sanitize_hex_color( $bg_color ); ?>;
		}
	</stil>
	<?php
}
add_action('wp_head', wptavern_customizer_css);

La fel ca exemplul postMessage, scrierea acestui cod poate deveni rapid repetitivă dacă aveți o mulțime de setări.

Din fericire, „transport” => „auto” se ocupă și de ieșirea frontend pentru tine. Chiar și în exemplul nostru simplificat, „transport” => „auto” a redus codul pe care trebuie să-l scriem cu ~50%.

Concluzie

În acest articol, ne-am uitat doar la elementele de bază ale cadrului Kirki și două dintre argumentele sale, deja putem vedea cum ne permite să creăm controale de personalizare mai rapid și fără a compromite performanța.

Când vă scufundați în Kirki, veți descoperi rapid multitudinea de funcționalități pe care le adaugă peste API-ul Personalizare. Nu este surprinzător faptul că este utilizat pe peste 300.000 de site-uri web și este o parte esențială a unora dintre cele mai mari teme WordPress de pe piață.