Wordpress Custom Post Types Taxonomies Meta Fields Admin UI
WordPress1 September 202610 menit baca
Selesai membaca dokumentasi ini?
Kembali ke rujukan utama WordPress untuk melanjutkan topik lainnya.
Wordpress Custom Post Types Taxonomies Meta Fields Admin UI
Definisi singkat
Empat konsep ini sering dipakai bareng saat membuat fitur content management di WordPress:
- Custom Post Type (CPT): jenis konten baru di luar
postdanpage, misalnyabook,event,product, ataucourse. - Taxonomy: sistem pengelompokan konten, misalnya kategori, tag, atau taxonomy kustom seperti
genredantopic. - Meta field: data tambahan per item konten, misalnya tanggal event, harga, lokasi, rating, atau ISBN.
- Admin UI: layar input dan pengelolaan di dashboard WordPress untuk membuat, mengedit, dan memfilter konten tersebut.
Kalau dirancang dengan baik, empat layer ini membentuk model data yang rapi: konten disimpan sebagai entri utama, taxonomies dipakai untuk klasifikasi, meta dipakai untuk atribut spesifik, dan admin UI menjadi pintu masuk operasional untuk editor.
Kapan memakai CPT vs post/page biasa
Pakai post biasa kalau
Gunakan post kalau kontennya masih cocok dengan model blog klasik:
- ada alur publikasi artikel
- bisa diberi kategori dan tag standar
- fokusnya tulisan kronologis atau editorial
- tidak butuh struktur data yang jauh berbeda dari artikel umum
Contoh yang masih cocok sebagai post:
- artikel blog
- update berita
- tutorial singkat
- pengumuman editorial
Pakai page kalau
Gunakan page kalau kontennya cenderung statis, berhierarki, dan bukan bagian dari feed artikel:
- About
- Contact
- Terms
- Privacy Policy
- halaman landing yang tidak perlu masuk arsip blog
page cocok saat struktur lebih penting daripada kronologi.
Pakai CPT kalau
Gunakan CPT kalau kontennya punya identitas domain sendiri dan tidak enak dipaksa masuk ke post atau page.
Tanda-tandanya:
- punya field khusus yang konsisten
- punya arsip sendiri
- butuh taxonomy sendiri
- punya cara filter dan tampil yang berbeda dari artikel biasa
- editor butuh layar admin yang spesifik
Contoh CPT yang umum:
bookeventportfoliotestimonicourseproperty
Aturan praktis
Pakai pertanyaan ini sebagai saringan:
- Apakah kontennya masih artikel biasa? Kalau ya, pakai
post. - Apakah kontennya halaman statis? Kalau ya, pakai
page. - Apakah kontennya punya field, arsip, dan workflow sendiri? Kalau ya, CPT biasanya lebih sehat.
Jebakan saat terlalu cepat membuat CPT
CPT sering dibuat terlalu cepat hanya karena “biar rapi”. Padahal kalau kebutuhan masih kecil, CPT bisa menambah biaya maintenance:
- template jadi lebih banyak
- query dan archive perlu disetel
- admin UI ikut membesar
- relasi dengan taxonomy dan meta harus dipikirkan dari awal
Kalau kontennya belum jelas bentuknya, mulai dari post atau page dulu sering lebih aman.
Peran taxonomy hierarkis dan non-hierarkis
Taxonomy dipakai untuk mengelompokkan konten berdasarkan dimensi tertentu. Secara konsep, taxonomy menjawab pertanyaan seperti: “konten ini masuk kategori apa?” atau “label apa yang melekat pada konten ini?”
Taxonomy hierarkis
Taxonomy hierarkis punya struktur induk-anak, mirip folder atau kategori bertingkat.
Contoh:
CategoryGenre > Fiction > Sci-FiTopic > Frontend > CSS
Ciri utamanya:
- ada parent dan child
- cocok untuk klasifikasi yang rapi dan terstruktur
- pengguna bisa menelusuri dari umum ke spesifik
Pakai taxonomy hierarkis kalau:
- item konten bisa dikelompokkan dalam pohon kategori
- editor perlu struktur navigasi yang jelas
- kamu ingin arsip bertingkat atau filter yang mengarah ke sub-kelompok
Taxonomy non-hierarkis
Taxonomy non-hierarkis lebih mirip tag atau label bebas.
Contoh:
tagskillspeakerlocation-label
Ciri utamanya:
- tidak punya parent-child
- bisa lebih fleksibel
- cocok untuk label lintas kategori
Pakai taxonomy non-hierarkis kalau:
- relasinya longgar
- satu item bisa punya banyak label
- kamu tidak butuh struktur bertingkat
- editor lebih sering menandai konten daripada mengelompokkannya secara formal
Kapan taxonomy lebih tepat daripada meta
Pilih taxonomy kalau nilainya dipakai untuk mengelompokkan banyak konten dan kemungkinan dipakai di filter, arsip, atau navigasi.
Contoh:
eventdiberi taxonomylocationcoursediberi taxonomytopicproductdiberi taxonomybrand
Kalau nilainya lebih bersifat atribut internal satu item, biasanya meta lebih cocok.
Meta fields: data tambahan per item
Meta field dipakai untuk data yang melekat pada satu post dan bukan bagian dari klasifikasi.
Contoh meta:
- tanggal mulai event
- jam mulai
- harga
- status stok
- rating
- nomor seri
- URL eksternal
- lokasi GPS
Kapan meta field dipakai
Pakai meta field kalau:
- nilainya spesifik per item
- bukan label yang perlu dibagikan ke banyak item
- tidak perlu hierarki atau arsip taxonomy
- lebih cocok ditampilkan sebagai detail atau properti
Bedakan meta vs taxonomy
Pembedaan ini penting karena sering tercampur:
- taxonomy = pengelompokan
- meta = atribut
Contoh:
genre = Sci-Fi→ taxonomyprice = 150000→ metaspeaker = Dewa→ taxonomy kalau dipakai lintas event; meta kalau cuma atribut internal satu entristatus = draft→ biasanya bukan taxonomy publik, lebih cocok status sistem atau field internal
Cara menyimpan meta dengan aman
Saat membangun fitur admin, jangan anggap meta field cuma soal input form. Meta field harus diperlakukan sebagai data yang:
- divalidasi
- disanitasi
- diotorisasi
- diserialisasi dengan konsisten
Gunakan sanitization sesuai tipe data:
- teks →
sanitize_text_field() - textarea →
sanitize_textarea_field() - URL →
esc_url_raw() - angka → cast/validasi numerik
- array kompleks → validasi per elemen sebelum disimpan
Jebakan meta field yang sering muncul
- menyimpan semua data sebagai satu blob tanpa struktur
- tidak memeriksa capability sebelum menyimpan
- tidak menyesuaikan sanitization dengan tipe data
- menulis field yang seharusnya taxonomy sebagai meta, lalu susah difilter
- menaruh data penting hanya di meta tanpa rencana query/indexing
Alur data: content → taxonomy → meta → admin UI
Secara kerja, alurnya biasanya begini:
- Editor membuat atau mengubah konten di admin UI.
- Admin UI mengirim data content utama.
- Taxonomy dipakai untuk klasifikasi dan relasi antar item.
- Meta field menyimpan atribut spesifik item.
- WordPress menyimpan semuanya ke struktur data yang sesuai.
- Template frontend membaca kombinasi content, taxonomy, dan meta untuk render.
Loading diagram...
Membaca diagramnya
- Content utama menyimpan identitas post: judul, isi, slug, excerpt, status.
- Taxonomy menyimpan klasifikasi yang bisa dipakai ulang dan difilter.
- Meta menyimpan properti spesifik per item.
- Admin UI adalah antarmuka untuk mengumpulkan semua input itu dengan urutan dan validasi yang benar.
Cara kerja CPT secara praktis
CPT biasanya diregistrasi lewat register_post_type() pada hook yang tepat, umumnya init.
Contoh ringkas:
phpadd_action('init', function () {
register_post_type('event', [
'label' => 'Events',
'public' => true,
'has_archive' => true,
'show_in_rest' => true,
'supports'
Parameter yang paling sering menentukan perilaku
public: apakah kontennya bisa diakses publikhas_archive: apakah ada halaman arsipshow_in_rest: penting kalau editor atau integrasi memakai REST API / block editorsupports: fitur editor yang aktifrewrite: slug dan struktur URL
Jebakan saat register CPT
- lupa
show_in_restlalu field atau editor modern tidak berperilaku seperti yang diharapkan rewritetidak dipikirkan sejak awal lalu permalink jadi tidak konsistensupportsterlalu minim sehingga editor tidak bisa bekerja nyaman- mengaktifkan terlalu banyak fitur default padahal CPT butuh UI yang sederhana
Cara kerja taxonomy di CPT
Taxonomy bisa dipasang ke CPT supaya konten bisa difilter dan ditampilkan dalam kelompok yang masuk akal.
Contoh:
phpadd_action('init', function () {
register_taxonomy('event_type', ['event'], [
'label' => 'Event Type',
'hierarchical' => true,
'public' => true,
'show_in_rest' => true,
Pilihan desain yang penting
hierarchical => truekalau taxonomy perlu parent-childhierarchical => falsekalau taxonomy lebih mirip tagshow_in_rest => truekalau mau dipakai editor modernrewritekalau taxonomy punya arsip publik
Jebakan taxonomy
- taxonomy dipakai sebagai tempat semua atribut, padahal sebagian harusnya meta
- terlalu banyak taxonomy untuk satu CPT sampai editor bingung
- taxonomy dibiarkan tanpa strategi arsip dan filter
- nama taxonomy, label, dan slug tidak konsisten
Admin UI: bagaimana editor berinteraksi dengan data
Admin UI bukan sekadar form. Ia adalah lapisan operasional yang menentukan apakah struktur data tadi benar-benar mudah dipakai.
Komponen admin UI yang umum
- title field
- content editor
- taxonomy meta box atau panel
- custom meta fields
- featured image
- list table / archive admin
- filter dropdown
- quick edit atau bulk actions jika perlu
Prinsip desain admin UI yang sehat
- Input mengikuti model data, bukan sebaliknya.
- Field penting tampil paling awal.
- Nama field harus jelas secara domain.
- Validation dan error message harus dekat dengan input.
- Field yang jarang dipakai jangan memenuhi layar.
Kapan perlu custom admin UI
Custom admin UI berguna kalau:
- field bawaan WordPress tidak cukup
- editor butuh pengelompokan field yang lebih jelas
- ada validasi khusus
- ada ketergantungan antarfield
- workflow konten cukup kompleks
Kalau kebutuhan masih sederhana, manfaatkan UI bawaan dulu. Terlalu cepat bikin UI custom sering membuat maintenance lebih mahal.
Jebakan saat membangun admin UI
- semua field dibuat jadi satu layar panjang tanpa pengelompokan
- belum ada nonce, capability check, atau sanitization
- field disimpan tanpa memikirkan revisi, autosave, dan REST request
- layout admin dibuat berat, lambat, dan sulit dipindai
- logika render field bercampur dengan logika save
Alur simpan data yang perlu dijaga
Saat user menekan Save/Update, ada beberapa hal yang sebaiknya terjadi berurutan:
- cek capability user
- validasi nonce
- cek apakah request valid dan bukan autosave yang tidak perlu diproses
- sanitasi input
- simpan meta / taxonomy / post data
- tampilkan feedback yang jelas kalau ada error
Kenapa urutan ini penting
Kalau sanitization atau authorization ditunda, data buruk bisa masuk duluan. Kalau handling autosave diabaikan, data bisa tersimpan dua kali atau tertimpa. Kalau admin UI tidak memberi feedback, editor akan bingung apakah perubahan benar-benar disimpan.
Contoh keputusan desain
Skenario 1: fitur event
Gunakan:
- CPT:
event - taxonomy hierarkis:
event_category - taxonomy non-hierarkis:
event_tag - meta: tanggal mulai, tanggal selesai, lokasi, harga
Alasannya:
- event adalah entitas utama
- kategori event bisa bertingkat
- tag dipakai untuk label fleksibel
- atribut event harus disimpan per item
Skenario 2: fitur buku
Gunakan:
- CPT:
book - taxonomy hierarkis:
genre - taxonomy non-hierarkis:
author_tagatautopic - meta: ISBN, jumlah halaman, penerbit, tahun terbit
Alasannya:
- buku punya struktur data sendiri
- genre lebih cocok jadi klasifikasi
- ISBN dan halaman adalah atribut, bukan label
Ringkasan keputusan cepat
- Pakai post kalau kontennya artikel biasa.
- Pakai page kalau kontennya statis dan hierarkis.
- Pakai CPT kalau kontennya adalah domain data sendiri.
- Pakai taxonomy hierarkis kalau butuh parent-child classification.
- Pakai taxonomy non-hierarkis kalau butuh label fleksibel.
- Pakai meta field untuk atribut per item, bukan klasifikasi.
- Bangun admin UI mengikuti struktur data, lalu jaga validation, capability, dan sanitization.
Jebakan umum yang paling mahal
Kalau diringkas, kesalahan paling mahal saat membangun fitur admin WordPress biasanya datang dari tiga hal:
- model data salah: taxonomy dipakai sebagai meta atau sebaliknya
- save flow tidak aman: capability, nonce, sanitization, autosave tidak dijaga
- UI tidak sejalan dengan workflow editor: field terlalu banyak, tidak jelas, dan sulit dirawat
Referensi terkait
register_post_type()register_taxonomy()add_meta_box()save_postadmin_enqueue_scripts- WordPress Custom Post Types Handbook
- WordPress Taxonomies Handbook
- WordPress Plugin Handbook