• Beranda
  • Artikel
  • Memandu
  • Bangun Pengaturan Penyesuai Lebih Cepat dengan Menggunakan Kerangka Kirki di Proyek Anda

Bangun Pengaturan Penyesuai Lebih Cepat dengan Menggunakan Kerangka Kirki di Proyek Anda

Diterbitkan: 2019-08-10

Kirki adalah kerangka kerja open-source (berlisensi MIT) gratis yang dibuat untuk pengembang yang ingin menambahkan Kontrol Penyesuai ke tema atau plugin mereka.

Aristeides Stathopoulos, pengembang utama Kirki telah mengerjakan kerangka kerja tersebut sejak 2014. Berkat pembaruan dan peningkatan yang berkelanjutan, Kirki telah membangun komunitas di Github yang mencakup lebih dari 1000 bintang dan 300 garpu.

Sebelum Kirki saya tidak pernah menyentuh penyesuai. Kirki membantu saya memahami penyesuai dan melakukan banyak hal dalam waktu yang lebih singkat!

LebCit – Pengembang Tema WordPress

Kontrol Penyesuai Inti WordPress

WordPress Core menyertakan beberapa Kontrol Penyesuai dasar secara default. Misalnya: teks, area teks, kotak centang, radio, pilih, halaman tarik-turun, email, URL, nomor, tersembunyi, dan kontrol tanggal.

Kirki juga mendukung Kontrol Inti, ditambah sekitar dua puluh lainnya. Secara umum, kontrol Kirki mencakup kasus penggunaan yang lebih canggih. Sebagai contoh:

  • Tipografi
  • Palet Warna
  • Editor TinyMCE
  • Bidang yang Dapat Diurutkan

Kirki juga menawarkan fungsionalitas yang tidak tersedia di Core WordPress, seperti pembuatan otomatis output CSS dan skrip postMessage Anda. Fitur-fitur ini, yang akan kita lihat nanti di artikel ini, dapat dengan mudah memotong waktu pengembangan Anda menjadi dua.

Kirki Lambat

Salah satu kritik yang biasa dilontarkan terhadap Kirki adalah lambat. Faktanya, kritik ini digunakan terhadap sebagian besar kerangka kerja (termasuk WordPress). Masuk akal, bukan? Anda memuat banyak kode yang mungkin tidak pernah Anda gunakan.

Dalam hal ini, kenyataannya adalah sebaliknya. Sebagian besar waktu panel kontrol yang dibuat menggunakan Kirki sebenarnya akan lebih cepat daripada panel yang sama yang dibuat dengan Kontrol Inti.

Ini karena Kirki menambahkan lapisan pengoptimalan yang tidak ada di WordPress.

Ketika Customizer diinisialisasi, WordPress langsung mencoba memuat semua kontrol, bahkan jika mereka berada di dalam bagian atau panel dan pengguna belum dapat berinteraksi dengannya. Sebagai perbandingan, Kirki menunda pemuatan hingga sebelum pengguna berinteraksi dengan kontrol.

Untuk melihat efeknya dalam praktik, mari kita coba menambahkan 50 kontrol warna menggunakan setiap metode.

Metode Inti:

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

	// tambahkan kontrol pemilih warna
	$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'color_setting_hex_' . $i, array(
		'label' => 'Kontrol Warna',
		'bagian' => 'title_tagline',
		'pengaturan' => 'color_setting_hex_' . $aku,
	) ) );
}

Dengan Kirki:

 untuk ($i = 0; $i < 50; $i++) {
     Kirki::add_field( 'config_id', array(
         'tipe' => 'warna',
         'pengaturan' => 'color_setting_hex_' . $aku,
         'label' => __( 'Kontrol Warna', 'kirki' ),
         'bagian' => 'title_tagline',
         'default' => '#0088CC',
     ) );
 }

Hasil:

Seperti yang Anda lihat, kecepatan pemuatan awal jauh lebih cepat saat menggunakan Kirki. Kode yang diperlukan untuk membuat kontrol juga lebih ringkas.

Mengintegrasikan Kirki Ke Proyek Anda

Ada beberapa cara untuk mengintegrasikan Kirki Framework ke dalam proyek Anda, dokumentasi resmi melakukan pekerjaan yang baik untuk menjelaskan berbagai metode.

Saya merekomendasikan pengembang memandu pengguna untuk menginstal versi plugin Kirki, daripada memasukkan kerangka kerja langsung di dalam kode proyek Anda. Ini dapat dilakukan dengan menggunakan TGMPA atau skrip yang disediakan.

Alasan di balik mengambil rute plugin adalah karena Kirki sering diperbarui dan ditingkatkan. Dengan menginstal versi plugin, pengguna Anda akan memiliki akses instan ke perbaikan bug dan pembaruan keamanan.

Sebaliknya, ketika Anda menyertakan kerangka kerja sebagai bagian dari proyek Anda, pengguna hanya akan menerima pembaruan saat Anda memperbarui tema atau plugin Anda, yang mungkin lebih jarang daripada yang diperlukan.

Metode apa pun yang Anda gunakan, pastikan untuk memeriksa Kirki diinisialisasi sebelum Anda menambahkan pengaturan Anda:

 // Keluar lebih awal jika Kirki tidak ada.
jika ( ! class_exists( 'Kirki' ) ) {
    kembali;
}

bidang

Dalam contoh Metode Inti, pertama-tama kita membuat pengaturan dan kemudian membuat kontrol untuk itu. Dalam kebanyakan kasus, keduanya terkait langsung. Kirki menyederhanakan proses dan memungkinkan kita untuk membuat 'Field' sebagai gantinya. Saat sebuah bidang dibuat, ia membangun pengaturan dan kontrol di latar belakang untuk kita.

Bidang mendukung semua argumen kontrol yang Anda harapkan (label, deskripsi, bagian, default), serta beberapa argumen khusus Kirki.

Argumen 'type' memungkinkan Anda memilih salah satu dari 30 tipe kontrol Kirki: https://kirki.org/docs/controls/

Bagian

Bagian Penyesuai memungkinkan Anda untuk mengelompokkan Kontrol bersama-sama. WordPress memiliki enam bagian bawaan yang juga dapat Anda tambahkan kontrolnya:

  • title_tagline – Identitas Situs
  • warna – Warna
  • header_image – Gambar Header
  • background_image – Gambar Latar Belakang
  • static_front_page – Pengaturan Beranda
  • custom_css – CSS tambahan


Bagian di Kirki bekerja persis sama seperti di Core, metode Kirki::add_section() hanyalah pembungkus untuk $wp_customize->add_section() dan menerima parameter dan argumen yang sama.

 Kirki::add_section( 'section_id', array(
     'title' => esc_html__( 'Bagian Saya', 'kirki' ),
     'description' => esc_html__( 'Deskripsi bagian saya.', 'kirki' ),
 ) );

panel

Panel memungkinkan Anda membuat tingkat hierarki lain dengan mengelompokkan Bagian bersama-sama. WordPress Core memiliki satu panel built-in, yaitu 'Menus'.

Sekali lagi, implementasi Kirki hanyalah pembungkus untuk fungsionalitas Core.

 Kirki::add_panel( 'panel_id', array(
     'prioritas' => 10,
     'title' => esc_html__( 'Panel Saya', 'kirki' ),
     'description' => esc_html__( 'Deskripsi panel saya', 'kirki' ),
 ) );

'transportasi' => 'otomatis'

Biasanya saat membuat Kontrol Penyesuai, Anda memiliki dua opsi untuk argumen transport:

  • Refresh – Setiap kali pengguna membuat perubahan, panel pratinjau di-refresh untuk menampilkan perubahan. Ini bisa memakan waktu beberapa detik.
  • postMessage – Setiap kali pengguna membuat perubahan, panel pratinjau diperbarui menggunakan Javascript yang tidak memerlukan penyegaran dan hampir instan.

postMessage tidak diragukan lagi merupakan metode yang unggul untuk memperbarui pratinjau dan harus digunakan jika memungkinkan. Namun, ada satu kelemahan, menggunakan postMessage berarti Anda perlu membuat kode JS khusus untuk setiap kontrol Anda. Implementasi sederhana terlihat seperti ini:

 // Perbarui judul situs secara real time...
wp.customize( 'nama blog', fungsi( nilai ) {
    nilai.bind(fungsi(baru){
        $( '#site-title a' ).html( newval );
    } );
} );

Ketika Anda memiliki banyak pengaturan, ini dapat dengan cepat menjadi berulang.

Di sinilah Kirki bersinar, ia menambahkan opsi ketiga: 'transport' => 'auto'.

'transport' => 'auto' bekerja sama dengan argumen lain yang ditambahkan Kirki bernama 'output'. Ketika kedua nilai ditentukan, Kirki akan membuat skrip postMessage secara otomatis untuk Anda. Artinya, Anda mendapatkan semua manfaat menggunakan postMessage tanpa harus menulis kode Javascript apa pun.

Bidang menggunakan transport => 'auto' terlihat seperti ini:

 Kirki::add_field( 'config_id', array(
     'tipe' => 'warna',
     'pengaturan' => 'color_setting_hex',
     'label' => __( 'Kontrol Warna', 'kirki' ),
     'bagian' => 'warna',
     'default' => '#0088CC',
     'transportasi' => 'otomatis',
     'keluaran' => larik(
         Himpunan(
             'elemen' => 'tubuh',
             'properti' => 'warna-latar belakang',
         ),
     ),
 ) );

Fitur Kirki yang menghemat waktu ini berarti bahwa sebagian besar waktu Anda tidak perlu lagi menulis atau mengantrekan skrip postMessage Anda sendiri.

Keluaran CSS Frontend

Bagian lain dari membuat pengaturan Customizer adalah menghasilkan output CSS di frontend. Contoh sederhana mungkin terlihat seperti ini:

 /**
 * Keluarkan CSS Penyesuai ke wp_head
 */
fungsi wptavern_customizer_css() {
	$bg_color = get_theme_mod( 'color_setting_hex' );
	?>
	<gaya>
		tubuh {
			background-color: <?php echo sanitize_hex_color( $bg_color ); ?>;
		}
	</ gaya>
	<?php
}
add_action('wp_head', wptavern_customizer_css );

Seperti contoh postMessage, penulisan kode ini dapat dengan cepat menjadi berulang jika Anda memiliki banyak pengaturan.

Untungnya, 'transport' => 'auto' menangani output frontend untuk Anda juga. Bahkan dalam contoh sederhana kita, 'transport' => 'auto' telah mengurangi kode yang perlu kita tulis sebesar ~50%.

Kesimpulan

Dalam artikel ini, kita hanya melihat dasar-dasar Kerangka Kirki dan dua argumennya, kita sudah dapat melihat bagaimana hal itu memungkinkan kita untuk membuat Kontrol Penyesuai lebih cepat dan tanpa mengorbankan kinerja.

Saat Anda menyelami Kirki, Anda akan segera menemukan kekayaan fungsionalitas yang ditambahkan di atas Customize API. Tidak mengherankan bahwa ini digunakan di lebih dari 300.000 situs web dan merupakan bagian inti dari beberapa tema WordPress terbesar di pasar.