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 post dan page, misalnya book, event, product, atau course.
• Taxonomy: sistem pengelompokan konten, misalnya kategori, tag, atau taxonomy kustom seperti genre dan topic.
• 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:

• book
• event
• portfolio
• testimoni
• course
• property

Aturan praktis

Pakai pertanyaan ini sebagai saringan:

1. Apakah kontennya masih artikel biasa? Kalau ya, pakai post.
2. Apakah kontennya halaman statis? Kalau ya, pakai page.
3. 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:

• Category
• Genre > Fiction > Sci-Fi
• Topic > 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:

• tag
• skill
• speaker
• location-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:

• event diberi taxonomy location
• course diberi taxonomy topic
• product diberi taxonomy brand

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 → taxonomy
• price = 150000 → meta
• speaker = Dewa → taxonomy kalau dipakai lintas event; meta kalau cuma atribut internal satu entri
• status = 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:

1. Editor membuat atau mengubah konten di admin UI.
2. Admin UI mengirim data content utama.
3. Taxonomy dipakai untuk klasifikasi dan relasi antar item.
4. Meta field menyimpan atribut spesifik item.
5. WordPress menyimpan semuanya ke struktur data yang sesuai.
6. Template frontend membaca kombinasi content, taxonomy, dan meta untuk render.

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:

php

add_action('init', function () {
    register_post_type('event', [
        'label' => 'Events',
        'public' => true,
        'has_archive' => true,
        'show_in_rest' => true,
        'supports' => ['title', 'editor', 'thumbnail', 'excerpt'],
        'rewrite' => ['slug' => 'events'],
    ]);
});

Parameter yang paling sering menentukan perilaku

• public: apakah kontennya bisa diakses publik
• has_archive: apakah ada halaman arsip
• show_in_rest: penting kalau editor atau integrasi memakai REST API / block editor
• supports: fitur editor yang aktif
• rewrite: slug dan struktur URL

Jebakan saat register CPT

• lupa show_in_rest lalu field atau editor modern tidak berperilaku seperti yang diharapkan
• rewrite tidak dipikirkan sejak awal lalu permalink jadi tidak konsisten
• supports terlalu 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:

php

add_action('init', function () {
    register_taxonomy('event_type', ['event'], [
        'label' => 'Event Type',
        'hierarchical' => true,
        'public' => true,
        'show_in_rest' => true,
        'rewrite' => ['slug' => 'event-type'],
    ]);
});

Pilihan desain yang penting

• hierarchical => true kalau taxonomy perlu parent-child
• hierarchical => false kalau taxonomy lebih mirip tag
• show_in_rest => true kalau mau dipakai editor modern
• rewrite kalau 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

1. Input mengikuti model data, bukan sebaliknya.
2. Field penting tampil paling awal.
3. Nama field harus jelas secara domain.
4. Validation dan error message harus dekat dengan input.
5. 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:

1. cek capability user
2. validasi nonce
3. cek apakah request valid dan bukan autosave yang tidak perlu diproses
4. sanitasi input
5. simpan meta / taxonomy / post data
6. 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_tag atau topic
• 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_post
• admin_enqueue_scripts
• WordPress Custom Post Types Handbook
• WordPress Taxonomies Handbook
• WordPress Plugin Handbook