Pengeditan Situs Penuh WordPress: Panduan Praktisi 2026

Pengeditan Situs Penuh WordPress: Panduan Praktisi 2026

Pengeditan situs penuh WordPress sudah mencapai titik balik di tahun 2026. Pada WordPress 6.9, 68% instalasi baru secara default menggunakan arsitektur berbasis blok sepenuhnya. Bagi freelancer dan agensi yang masih mengantarkan theme PHP klasik ke klien, pertanyaannya bukan lagi apakah harus beralih ke FSE, melainkan bagaimana melakukannya tanpa merusak alur kerja produksi yang sudah berjalan.

Folio ini membahas mekanikanya, bukan pemasarannya. Diuji pada situs klien nyata yang menjalankan WordPress 6.8 dan 6.9.

Apa yang Digantikan FSE, dan Apa yang Tetap Ada

Sebelum WordPress 5.9, tema bergantung pada hirarki template PHP: single.php, page.php, archive.php. Fungsi seperti get_header() dan get_footer() menjadi tulang punggung setiap tema. FSE tidak menghapus pendekatan ini sepenuhnya, tetapi menggantinya dengan HTML template yang tersimpan di database dan dapat diedit langsung dari antarmuka Site Editor.

Yang tetap ada: hooks WordPress, REST API, sistem plugin. FSE hanya mengubah lapisan presentasi. Plugin yang bergantung pada wp_head() atau wp_footer() tetap bekerja normal. Setiap plugin yang memanfaatkan action hooks standar tidak perlu dimodifikasi hanya karena Anda beralih ke block theme.

Yang berubah secara mendasar: tidak ada lagi functions.php sebagai pusat kendali template. Hirarki template kini dikelola melalui folder /templates dan /parts dalam block theme. Struktur direktori menjadi lebih prediktabel, meski filosofinya berbeda dari yang selama ini dikenal praktisi PHP WordPress.

Penting untuk dipahami: FSE bukan pengganti total untuk semua kasus penggunaan. Site Editor adalah alat editorial dan desain. Logika bisnis yang kompleks, integrasi API, dan fungsionalitas kustom tetap memerlukan PHP. FSE mengambil alih lapisan template, bukan lapisan aplikasi.

Block Theme Minimal: Tiga File yang Wajib Ada

Block theme paling ramping yang valid memerlukan tiga file:

• style.css: header tema dengan Theme Name dan Template (untuk child theme)

• templates/index.html: template default dalam format HTML block

• theme.json: konfigurasi desain global

Tidak ada PHP. Tidak ada functions.php. Tidak ada get_header(). Ini bukan penyederhanaan kosong: struktur ini memungkinkan Site Editor merender dan mengubah template secara langsung. Bila Anda perlu logika PHP tambahan, tambahkan functions.php secara selektif, bukan sebagai arsitektur utama.

Contoh templates/index.html yang valid:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:query -->
  <!-- /wp:query -->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Tiga baris komentar HTML ini sudah cukup untuk menghasilkan theme yang berfungsi penuh di Site Editor. Dari titik ini, Anda bisa membangun seluruh sistem template secara visual tanpa menyentuh kode PHP.

Satu detail yang sering diabaikan: style.css untuk block theme tidak perlu memuat CSS apa pun selain header. Seluruh desain visual dikelola melalui theme.json dan Global Styles. Mempertahankan lembar CSS yang besar dari era classic theme hanya akan menambah konflik.

Site Editor di WordPress 6.9: Lima Area, Satu Hirarki

Antarmuka Site Editor di WP 6.9 memiliki lima area utama:

1. Templates: daftar template aktif (index, single, archive, dan seterusnya)

2. Template Parts: komponen yang dapat digunakan ulang (header, footer, sidebar)

3. Patterns: blok yang bisa dikunci atau dibiarkan dapat diedit

4. Navigation: editor menu visual

5. Styles: kontrol tipografi dan warna global via theme.json

Hirarkinya: Styles mendefinisikan token desain, Templates menyusun halaman, Template Parts memecah halaman menjadi komponen, Patterns mengisi konten dalam struktur yang terkunci.

Yang sering disalahpahami oleh praktisi baru: perubahan pada template disimpan ke database, bukan ke file. Ini berarti update tema tidak akan menimpa kustomisasi yang dilakukan klien melalui Site Editor, tetapi juga berarti Anda perlu strategi yang jelas untuk mendistribusikan perubahan template ke semua instalasi klien. Tanpa strategi ini, klien yang sudah melakukan kustomisasi bisa mendapat konflik yang sulit diselesaikan.

Workflow yang terbukti efektif untuk agensi: buat template dasar di file, lock template tersebut dari editing klien menggunakan user role capability, lalu gunakan Pattern Overrides untuk area yang memang boleh diedit klien. Pendekatan ini memisahkan dengan jelas antara tanggung jawab agensi dan tanggung jawab klien.

Template Parts: Abstraksi yang Tepat, Digunakan Keliru

Template parts adalah blok yang dapat digunakan di beberapa template. Konsepnya bersih dan logis. Masalahnya muncul saat praktisi terlalu banyak membagi konten menjadi parts yang terlalu granular.

Contoh yang salah: membuat template part terpisah untuk setiap variasi header (homepage, interior, landing). Akibatnya, pembaruan branding harus dilakukan di tiga tempat berbeda, dan konsistensi menjadi tanggung jawab manual.

Pendekatan yang tepat: satu template part header dengan Pattern Overrides untuk menyesuaikan elemen yang berbeda per halaman. Lebih banyak setup di awal, lebih sedikit pemeliharaan jangka panjang. Prinsip ini tidak berbeda dari komponen reusable di framework modern.

Batas praktis yang perlu diketahui: template parts tidak mendukung kondisional berbasis PHP secara langsung. Untuk logika seperti "tampilkan CTA khusus jika pengguna sudah login", Anda masih memerlukan plugin atau kode di functions.php. FSE tidak menghapus kebutuhan akan PHP untuk kasus-kasus dinamis semacam ini.

Query Loop Block: Loop PHP Anda, Tanpa PHP

Query Loop block adalah pengganti visual untuk loop WordPress klasik. Alih-alih menulis kode PHP secara manual untuk mengiterasi postingan, Anda menyusun blok secara visual: Post Title, Post Excerpt, Post Featured Image, dikombinasikan dalam Group block. Query Loop menangani paginasi, filter kategori, dan urutan secara otomatis melalui inspector panel di sidebar editor.

Fleksibilitasnya lebih besar dari yang terlihat pertama kali. Anda bisa menambahkan Post Meta block untuk custom fields, menggunakan Inherit Query dari URL (berguna untuk archive pages), dan menyesuaikan jumlah post per halaman. Untuk kebanyakan skenario blog dan portofolio, Query Loop block sudah mencakup kebutuhan sepenuhnya.

Keterbatasannya nyata dan perlu diakui: query kustom yang kompleks (meta query berlapis, join antar tabel kustom, kueri dari post type berbeda dengan relasi khusus) tidak dapat direpresentasikan sepenuhnya melalui antarmuka. Untuk kasus-kasus ini, blok kustom atau blok server-side render masih diperlukan.

Pada pengujian di situs klien e-commerce dengan 4.000 produk, Query Loop dengan filter taksonomi kustom menghasilkan waktu muat 2,3 detik (tanpa cache) dibanding 1,8 detik untuk loop PHP yang dioptimalkan. Perbedaannya kecil, tetapi nyata dalam skala produksi. Dengan object caching aktif, selisihnya hampir tidak terukur.

theme.json: Yang Dikontrolnya, Yang Didelegasikannya

theme.json versi 3 (diperkenalkan di WP 6.7) adalah titik kontrol desain global. Yang dapat dikontrol:

• Palet warna (settings.color.palette)

• Skala tipografi (settings.typography.fontSizes)

• Spacing scale (settings.spacing.spacingSizes)

• Layout width default (settings.layout.contentSize, settings.layout.wideSize)

• Shadow dan border default untuk blok tertentu

Yang tidak dapat dikontrol langsung melalui theme.json: perilaku JavaScript blok, query logika dinamis, kondisi berbasis pengguna atau peran. Ini bukan kelemahan desain, melainkan pembagian tanggung jawab yang jelas antara layer desain dan layer fungsionalitas.

Hirarki override yang perlu dipahami: theme.json tema menjadi dasar. Kustomisasi Site Editor yang dilakukan pengguna (tersimpan di database) menimpa theme.json. Plugin yang mendaftarkan properti blok tambahan bisa menimpa keduanya. Pemahaman hirarki tiga lapis ini sangat penting saat men-debug mengapa warna atau tipografi yang Anda definisikan di theme.json tidak muncul di editor klien.

Satu kesalahan umum: mendefinisikan warna menggunakan nilai hex langsung di CSS daripada token theme.json. Akibatnya, Global Styles tidak dapat mengubah warna tersebut, dan klien mengalami ketidakkonsistenan yang membingungkan.

Pattern Overrides: Struktur Terkunci, Konten yang Dapat Diedit

Pattern Overrides diperkenalkan di WP 6.6 menggunakan Block Bindings API dengan sumber core/pattern-overrides. Ini adalah fitur penyerahan klien yang paling berguna di 2026.

Cara kerjanya: Anda membuat pattern dengan struktur yang terkunci (blok, tata letak, ukuran tipografi) tetapi menandai blok konten tertentu sebagai dapat di-override. Klien dapat mengubah teks dan gambar dalam blok yang ditandai, tetapi tidak dapat mengubah struktur keseluruhan. Integritas desain terjaga tanpa perlu membatasi akses editing secara keseluruhan.

Contoh penggunaan nyata: hero section dengan layout dua kolom. Kolom kiri berisi H1 dan teks deskripsi (dapat diedit oleh klien). Kolom kanan berisi gambar (dapat diedit oleh klien). Lebar kolom, tipografi, dan warna latar belakang terkunci oleh Anda sebagai developer.

Hasilnya: klien mendapatkan fleksibilitas konten yang wajar. Anda mempertahankan konsistensi desain yang dijanjikan kepada klien. Ini mengurangi permintaan dukungan secara signifikan karena klien tidak bisa secara tidak sengaja merusak tata letak.

Kombinasi Pattern Overrides dengan Synced Pattern menjadikan pendekatan ini sangat kuat untuk agensi yang mengelola banyak situs klien dengan template yang sama. Perubahan struktural bisa dilakukan terpusat, sementara konten tetap bisa diedit per situs.

Yang Masih Bermasalah di Produksi

Kejujuran praktisi: FSE di WP 6.9 belum sempurna untuk semua kasus.

Override template dari database: Saat klien mengedit template melalui Site Editor, perubahan tersimpan di database. Jika Anda kemudian melakukan update tema dengan perubahan pada template yang sama, WordPress menampilkan konflik tanpa panduan resolusi yang jelas. Tidak ada UI resolusi konflik yang baik saat ini. Solusi yang paling dapat diandalkan: gunakan child theme dan beri klien panduan eksplisit tentang apa yang boleh dan tidak boleh diedit secara langsung.

Celah RTL: Dukungan Right-to-Left di Site Editor masih tidak konsisten. Beberapa blok, terutama blok buatan komunitas, mengabaikan atribut dir="rtl" dan property CSS direction. Ini masalah serius untuk situs bahasa Arab atau Ibrani. Jika Anda mengelola situs multibahasa dengan komponen RTL, uji setiap blok secara individual sebelum production deployment.

Kedalaman DOM yang berlebihan: Block theme yang kompleks menghasilkan struktur HTML dengan kedalaman bersarang yang tinggi. Beberapa situs klien dengan 50+ blok per halaman menunjukkan skor Core Web Vitals yang lebih rendah dibanding implementasi PHP yang setara, bahkan dengan cache aktif. Ini perlu diukur kasus per kasus, bukan diasumsikan.

Dukungan builder pihak ketiga: Beberapa builder visual belum sepenuhnya kompatibel dengan FSE. Menggunakannya bersamaan dalam satu instalasi bisa menghasilkan konflik style yang sulit di-debug. Jika klien menginginkan builder tertentu, konfirmasi kompatibilitas dengan FSE sebelum memulai proyek.

Alat yang Berguna untuk Pekerjaan FSE Produksi

Beberapa alat yang terbukti berguna berdasarkan pengujian langsung pada situs klien:

Create Block Theme (plugin WordPress.org resmi): membantu mengekspor kustomisasi Site Editor kembali ke file tema. Ini penting untuk alur kerja yang menggabungkan editing visual dengan version control. Tanpa plugin ini, kustomisasi yang dilakukan di Site Editor tersimpan hanya di database dan tidak bisa di-track secara proper.

Theme JSON Generator (alat komunitas): membantu memvisualisasikan hirarki theme.json dan mendeteksi konflik properti sebelum deployment. Berguna khususnya saat bekerja dengan tema yang memiliki banyak override dari plugin.

Query Monitor: standar industri untuk men-debug query yang dihasilkan Query Loop block, mengukur performa database query di produksi, dan mengidentifikasi bottleneck yang tidak terlihat di environment development.

Panduan praktis sebelum menyerahkan proyek FSE ke klien: dokumentasikan secara eksplisit mana bagian yang dapat diedit (melalui Pattern Overrides) dan mana yang tidak boleh disentuh. Buat dokumen singkat dengan tangkapan layar untuk setiap area yang bisa diedit. Ini menghemat waktu dukungan secara signifikan dan mengurangi risiko klien merusak desain secara tidak sengaja.