Membuat Halaman Administrasi WordPress Kustom, Bagian 4

Saat kita memulai artikel terakhir dalam serial pembuatan halaman administrasi WordPress kustom di WordPress, saya rasa penting untuk mengulangi bahwa ini tidak dimaksudkan untuk mengatakan bahwa kita harus menghindari Settings API (atau API asli apapun).
Sebenarnya, setiap API memiliki tempatnya, dan kami jelas menggunakan banyak dari mereka melalui kode ini. Tapi sepertinya ada saat di mana Anda mengerjakan plugin kustom atau aplikasi kustom dan Anda harus bisa menerapkan sedikit validasi kustom, serialisasi, routing, dan lain-lain.
Dan itulah yang telah kita lakukan selama seri ini. Jadi saat kita melangkah maju dalam menyelesaikan plugin kita, saya ingin memastikan bahwa Anda mengerti bahwa saya tidak menganjurkan untuk menghindari API asli apa pun. Saya menganjurkan penggunaan API yang tersedia untuk persyaratan proyek Anda.

Untuk Tinjauan Anda

Pada titik ini, saya berasumsi Anda mengikuti artikel sebelumnya. Jika tidak, Anda mungkin akan sulit memahami dari mana asalnya dan mengapa kita membuat beberapa keputusan yang kita buat terkait dengan kode.
Selanjutnya, Anda akan kehilangan beberapa prinsip yang telah kita bahas sebelumnya. Singkatnya, saya merekomendasikan untuk mengejar dan kemudian kembali ke artikel ini.

Sebelum Kita Mulai

Dengan mengatakan bahwa (dan berbicara tentang persyaratan), hanya ada beberapa hal lagi yang perlu dirangkum karena berkaitan dengan plugin ini.
Secara khusus, kita perlu:

• mengambil informasi dari database
• memvalidasi informasinya
• menampilkannya di dashboard
• menampilkan informasinya di front-end

Untungnya, sebagian besar pekerjaan telah dilakukan untuk kita. Kita mendapatkan semua informasi yang kita butuhkan dalam database. Pada titik ini, ini adalah masalah memperkenalkan fungsionalitas yang akan melakukan sesuatu dengan data tersebut.
Seperti biasa, saya berasumsi bahwa Anda memiliki versi kode sumber terbaru dan Anda siap melanjutkan seri ini dan menambahkan sedikit kode sisanya.
Dengan itu, mari kita mulai.

Melengkapi Plugin

Sebelum kita mulai menulis kode, saya ingin menjelaskan bahwa kode yang akan kita tulis sangat mudah, tapi ada tingkat refactor yang mungkin perlu kita perkenalkan begitu kita sampai pada titik dari membuat informasi yang tersedia di back-end dan front-end.
Itu hal yang baik, sungguh.
Tidak hanya akan memberi kita kesempatan untuk berpikir kritis tentang pengorganisasian kode kita, namun juga akan memaparkan beberapa teknik berorientasi objek tambahan yang belum pernah kita lihat di sepanjang rangkaian tutorial sejauh ini.
Dengan pemikiran tersebut, mari bekerja untuk mengambil informasi dari database.

Mengambil Informasi dari Database

Meraih informasi dari database adalah proses yang sederhana. Karena sebelumnya kita pernah bekerja dengan fungsi seperti update_option, ini seharusnya sangat mudah.
Kita akan bekerja dengan get_option. Ini hanya membutuhkan satu argumen, dan itu adalah ID atau kunci yang kita gunakan untuk menyimpan informasinya. Dalam kasus kita, itu adalah tutsplus-custom-data. Jika Anda ingin berkreasi, Anda bisa menyampaikan argumen kedua opsional yang akan dikembalikan jika informasinya tidak ditemukan.
Demi menunjukkan bagaimana ini dapat digunakan, saya akan membuat fungsi mengembalikan string kosong sehingga kita memiliki sesuatu yang valid untuk ditampilkan kepada pengguna (walaupun itu adalah bukan apa-apa). Potongan kode untuk melakukan ini terlihat seperti ini:

1 2 3

<?php $data = get_option( 'tutsplus-custom-data', '' );

Tapi ini menimbulkan dua pertanyaan:

1. Ke mana ini pergi (terutama jika kita akan me-rendernya di dua tempat di plugin)?
2. Bukankah sebaiknya kita memvalidasi informasi ini?

Kita akan melihat pertanyaan pertama agak nanti di tutorial. Pertama, mari kita membicarakan tentang validasi.

Memvalidasi Informasi

Ada banyak hal yang bisa dikatakan tentang validasi di WordPress. Tapi untuk menjaga agar tutorial ini sesederhana mungkin, kita akan membicarakan validasi masukan. Lagi pula, kita berhadapan dengan masukan pengguna melalui elemen input, jadi masuk akal.
Anda bisa membaca semua tentangnya di Codex, tapi validasi masukan sering didefinisikan sebagai berikut:

Validasi data adalah proses untuk memastikan bahwa suatu program beroperasi pada data yang bersih, benar dan berguna.

Pada artikel terakhir, kami membahas topik sanitasi, yang pada dasarnya memastikan data yang bersih sebelum dimasukkan ke dalam database. Demikian pula, validasi memastikannya bersih, aman, dan mudah dibaca oleh pengguna kita.
Untuk itu, tidak cukup hanya mengambil informasi dari database. Kita perlu memvalidasinya juga. Dalam kasus plugin kita, datanya cukup sederhana sehingga terlihat berlebihan untuk memvalidasi; namun, tujuan dari latihan ini adalah untuk membantu mengembangkan pola pikir tentang bagaimana kita harus melakukan sanitasi, penyimpanan, pengambilan kembali, validasi, dan penyajian data.

Teknik Validasi

Dan sama seperti halnya dengan sanitasi, WordPress menawarkan beberapa fungsi yang mempermudah validasi, terutama yang berkaitan dengan validasi masukan. Dalam situasi ini, kita bisa menjadi agresif sesuka kita.
Dalam kasus kita, mungkin cukup hanya untuk menggunakan esc_attr saat me-render opsinya. Jika kita mengizinkan pengguna untuk memasukkan jenis HTML apa pun, kita mungkin ingin menggunakan wp_kses.
Fungsi yang terakhir mungkin memerlukan tutorial tersendiri, terutama jika Anda baru mengenal WordPress, jadi kita akan tetap dengan yang pertama untuk tujuan kita.

Deserialisasi

Sebelumnya dalam proyek ini, kita membuat sebuah kelas khusus untuk menyimpan informasi ke database. Kita memanggil kelas ini Serializer. Bagi mereka yang tidak ingat persis apa yang dilakukannya:

• Kelas mendefinisikan fungsi yang menjalankan pada hook admin_post dan menyimpan informasi yang dikirim ke server.
• Fungsi memverifikasi bahwa informasi yang aman untuk disimpan dan pengguna memiliki izin untuk menyimpan ke database.
• Fungsi membersihkan data dan menulisnya ke database.

Tapi kita tidak ingin membebani kelas itu dengan tanggung jawab yang tidak masuk akal. Dan karena kita akan menampilkan informasi ini di semua halaman opsi dan front-end situs, akan ada alasan bahwa kita memiliki kelas untuk deserialisasi nilai dan membuatnya dapat diakses oleh keseluruhan aplikasi WordPress.
Jadi di root direktori plugin Anda, buatlah direktori bersama dan tambahkan file yang disebut class-deserializer.php.

Selanjutnya, kita ingin kode kita disiapkan agar:

• didasarkan pada prinsip-prinsip berorientasi objek
• mengambil informasi yang diminta
• memvalidasi informasinya
• mengembalikannya ke pemanggil

Untuk itu, kerangka awal kelas mungkin terlihat seperti ini:

1 2 3 4 5 6 7

<?php    class Deserializer {     public function get_value( $option_key ) {     } }

Ini sederhana, untuk memastikannya. Kita akan menambahkan lebih banyak kode ke dalamnya selama tutorial ini, namun ingatlah prinsip tanggung jawab tunggal, dan ini adalah kelas yang harus digunakan antara dua bagian aplikasi WordPress.
Perhatikan bahwa dalam kode di atas, kita telah mendefinisikan tiga fungsi. Mari kita diskusikan apa yang akan dilakukan masing-masing:

• get_value akan menggunakan kunci opsi yang masuk yang mana, dalam kasus kita adalah tutsplus-custom-data, dan akan mengembalikan nilainya ke pemanggil. Sesuai Standar Pengkodean WordPress, kita perlu menggunakan "late escaping" untuk memastikan kita memvalidasi informasinya dangan benar. Kita akan melihat ia dimainkan sebentar lagi.

Dengan mengatakan, mari kita lanjutkan dan menghentikan fungsinya. Saya juga akan menyediakan PHP DocBlocks untuk menjelaskan fungsi masing-masing.

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

<?php   /**  * Retrieves information from the database.  *  * @package Custom_Admin_Settings  */   /**  * Retrieves information from the database.  *  * This requires the information being retrieved from the database should be  * specified by an incoming key. If no key is specified or a value is not found  * then an empty string will be returned.  *  * @package Custom_Admin_Settings  */   class Deserializer {     /**      * Retrieves the value for the option identified by the specified key. If      * the option value doesn't exist, then an empty string will be returned.      *      * @param  string $option_key The key used to identify the option.      * @return string             The value of the option or an empty string.      */     public function get_value( $option_key ) {         return get_option( $option_key, '' );     } }

Pada titik ini, kode di atas harus mudah diikuti mengingat poin bullet di atas dan komentar di dalam kode.

Menampilkan di Halaman Opsi

Agar menampilkannya di halaman opsi, kita perlu meninjau ulang cara kita menjalankan Submenu_Page di file custom-admin-settings.php. Secara khusus, kita perlu menjalankan deserializer dan menyampaikannya ke constructor dari Submenu_Page.
Pertama, kita perlu menyertakan file tersebut. Ini bisa terjadi tepat setelah kita memeriksa untuk melihat apakah file plugin utama diakses secara langsung:

1 2 3 4   5 6 7 8 9

<?php   // If this file is called directly, abort. if ( ! defined( 'WPINC' ) ) {     die; } // Include the shared dependency. include_once( plugin_dir_path( __FILE__ ) . 'shared/class-deserializer.php' );

Kode di fungsi utama dari root plugin sekarang harus terlihat seperti ini:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

<?php   add_action( 'plugins_loaded', 'tutsplus_custom_admin_settings' );   /**  * Starts the plugin.  *  * @since 1.0.0  */   function tutsplus_custom_admin_settings() {     $serializer = new Serializer();     $serializer->init();     $deserializer = new Deserializer();     $plugin = new Submenu( new Submenu_Page( $deserializer ) );     $plugin->init(); }

Dan constructor untuk Submenu_Page akan terlihat seperti ini:

1 2 3 4 5

<?php    public function __construct( $deserializer ) {     $this->deserializer = $deserializer; }

Dari sini, kita bisa mengatasi halaman opsi. Kita hanya memperbarui atribut value dengan membuat panggilan ke fungsi di deserializer. Ingat, karena kita dengan tanpa syarat mengambil nilai dan akhirnya mengembalikan string kosong jika tidak ada, itu harus bekerja dengan baik.

1 2 3 4 5 6 7

<p>     <label>What message would you like to display above each post?</label>   <br />      <input type="text" name="acme-message"    value="<?php echo esc_attr( $this->deserializer->get_value( 'tutsplus-  custom-data' ) ); ?>"     />   </p>

Dan dengan itu, Anda harus bisa menyimpan dan mengambil nilai Anda di halaman opsi.

Menunjukkan pada Front-End

Kita hampir selesai. Hal terakhir yang perlu kita lakukan adalah menyiapkan plugin untuk menampilkan pesan kustom di front-end. Secara khusus, kita ingin menampilkan apa pun yang telah dimasukkan pengguna pada halaman single post (versus halaman arsip atau jenis halaman lainnya) dan melakukannya di atas setiap posting.
Ini berarti kita perlu melakukan hal berikut:

• Mengatur fungsi yang akan menggunakan hook the_content.
• Membaca nilainya menggunakan deserializer kita.
• Masukkan nilai sebelum konten (mungkin dengan elemennya sendiri).

Untungnya, ini bukanlah pekerjaan yang banyak, terutama karena kita memiliki sebagian besar pekerjaan yang perlu kita mulai. Namun, kita perlu membuat area plugin yang secara khusus bertanggung jawab menangani front-end dari situs.
Untuk itu, buatlah direktori public di root direktori plugin Anda dan tambahkan class-content-messenger.php.

Di dalam kelas, kita perlu mendefinisikan constructor yang akan menerima deserializer sebagai ketergantungan. Constructor (dan properti yang diperlukan) akan terlihat seperti ini:

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18

<?php   /**  * A reference to the class for retrieving our option values.  *  * @access private  * @var    Deserializer  */   private $deserializer;   /**  * Initializes the class by setting a reference to the incoming deserializer.  *  * @param Deserializer $deserializer Retrieves a value from the database.  */   public function __construct( $deserializer ) {     $this->deserializer = $deserializer; }

Kemudian kita perlu membuat fungsi init yang akan mendaftarkan fungsi internal (yang akan kita sebut display) untuk me-render konten beserta pesan baru.

1 2 3 4 5 6 7 8 9

<?php   /**  * Initializes the hook responsible for prepending the content with the  * option created on the options page.  */   public function init() {     add_filter( 'the_content', array( $this, 'display' ) ); }

Setelah itu, kita perlu memperbarui file plugin utama sehingga ia menjalankan kelas baru kita dan menyampaikan deserializer ke constructor. Maka ia akan menginisialisasi kelasnya.
Pertama, kita akan menyertakannya:

1 2 3 4 5

<?php    // Include the shared and public dependencies.   include_once( plugin_dir_path( __FILE__ ) . 'shared/class-deserializer.php' );  include_once( plugin_dir_path( __FILE__ ) . 'public/class-content-messenger.php' );

Lalu kita akan menjalankannya:

01 02 03 04 05 06 07 08 09 10 11

<?php   function tutsplus_custom_admin_settings() {     // Code removed for brevity...     // Setup the public facing functionality.     $public = new Content_Messenger( $deserializer );     $public->init();     }

Dari sini, kita seharusnya siap berangkat. Pastikan Anda telah memasukkan nilai pada halaman opsi. Simpan pekerjaan Anda dan periksa halaman single post di situs Anda. Seharusnya terlihat seperti ini:

Jika tidak, bandingkan kode Anda dengan yang ada di atas (atau apa yang terlampir) dan pastikan bahwa Anda telah menyiapkan semua kelas, fungsi, dan hook Anda dengan benar.

Sebuah Kata Tentang Pandangan dan Ketergantungan

Meskipun kita telah membicarakan tentang prinsip tanggung jawab tunggal sepanjang rangkaian ini, kita sebenarnya belum banyak membicarakan topik lanjutan yang dapat kita gunakan untuk membuat kode lebih bersih dan mengikuti praktik yang lebih baik.
Beberapa topik ini mencakup hal-hal seperti autoloading PHP dan hal-hal seperti Dependency Injection. Saya tidak membicarakan hal ini karena mereka berada di luar fokus utama dan pokok utama serial khusus ini bertujuan untuk mengajar.
Tergantung pada bagaimana serial ini diterima, saya akan mempertimbangkan untuk membuat beberapa tutorial khusus mengenai topik ini.

Kesimpulan

Dan dengan itu, kita menyimpulkan serial pembuatan halaman administrasi kustom. Saya berharap, sepanjang serial ini, Anda telah mempelajari beberapa hal di luar cara standar untuk membuat halaman administrasi.
Selain itu, saya harap Anda telah melihat bagaimana Anda dapat menerapkan beberapa teknik pengembangan perangkat lunak dalam pekerjaan sehari-hari Anda dengan WordPress. Selanjutnya, saya berharap diskusi tentang pandangan dan ketergantungan telah memicu minat terhadap topik yang lebih lanjut juga. Inilah hal-hal yang saya harap bisa saya bahas di tutorial masa depan juga.