Jumat, 26 Juni 2026
WordPress 7.0 Resmi Dirilis: Apakah Plugin Anda Sudah Siap?
WordPress 7.0 hadir dengan tampilan admin Modern, editor iframe yang lebih konsisten, minimum PHP 7.4, AI Client, Connectors API, dan kemampuan baru bagi pengembang blok. Panduan ini membahas risiko kompatibilitas, prioritas pengujian Network Site Details dan Search Protection, penggunaan Plugin Check, serta langkah aman memperbarui “Tested up to” menjadi 7.0.
WordPress 7.0 telah resmi tersedia sejak 20 Mei 2026. Bagi pemilik situs, pembaruan ini membawa antarmuka admin yang lebih modern, fondasi integrasi AI, perubahan pada editor berbasis iframe, dan peningkatan persyaratan minimum PHP. Bagi pengembang plugin, pesan utamanya lebih sederhana: jangan memperbarui label kompatibilitas sebelum pengujian selesai, tetapi jangan pula membiarkan pengguna menebak-nebak terlalu lama.
Analisis Digital Bisnis PT MSP untuk pengelola situs, pemilik bisnis, administrator WordPress, dan pengembang plugin.
Ringkasan Utama
- WordPress 7.0 dirilis pada 20 Mei 2026 dan kini menjadi rilis utama terbaru dalam cabang 7.0.
- Plugin perlu diuji pada lingkungan staging sebelum nilai
Tested up todiubah menjadi7.0. - Area pengujian terpenting mencakup tampilan admin Modern, editor iframe, kompatibilitas PHP 7.4–8.3, keamanan, performa, serta alur utama plugin.
- Plugin Check membantu menemukan masalah teknis, tetapi hasil otomatis tetap harus dilengkapi pengujian manual dan regresi.
- Berdasarkan pemberitahuan kompatibilitas yang diterima, Network Site Details dan Search Protection masih tercatat
Tested up to: 6.8.5dan perlu dievaluasi untuk WordPress 7.0.
WordPress 7.0 Bukan Sekadar Perubahan Tampilan
Secara visual, pengguna akan segera mengenali warna, tipografi, komponen, dan transisi baru di area administrasi. Namun, dampak terbesar bagi ekosistem plugin justru berada di bawah permukaan. WordPress 7.0 Field Guide mencatat lebih dari 419 tiket Core Trac, lebih dari 300 perbaikan bug, puluhan perubahan editor, dan lebih dari 90 tiket yang berfokus pada wp-admin.
“This guide outlines major developer features and breaking changes in 7.0.”
WordPress 7.0 Field Guide, Make WordPress Core
Skala tersebut menjelaskan mengapa uji kompatibilitas tidak boleh berhenti pada pertanyaan “apakah plugin bisa diaktifkan?”. Plugin dapat aktif tanpa fatal error, tetapi tetap bermasalah pada tata letak admin, hak akses, proses ekspor, request REST, penyimpanan opsi, pemuatan aset, atau interaksi editor. Kompatibilitas yang layak diumumkan harus berarti fungsi utama benar-benar bekerja dalam kondisi yang realistis.
Mengapa Nilai “Tested up to” Sangat Penting?
Kolom Tested up to di readme.txt adalah sinyal kepercayaan yang terlihat langsung di direktori WordPress.org. Nilai itu membantu calon pengguna menilai apakah pengembang masih memelihara plugin dan apakah rilis WordPress terbaru sudah masuk ke proses quality assurance.
Nilai tersebut bukan jaminan bahwa plugin bebas dari seluruh bug, bukan sertifikasi keamanan, dan bukan pengganti changelog. Namun, ketika disertai pembaruan rutin, dokumentasi yang jelas, dan respons dukungan yang baik, label kompatibilitas menjadi bagian penting dari reputasi digital plugin. Bagi bisnis, reputasi itu memengaruhi tingkat instalasi, retensi pengguna, ulasan, rekomendasi komunitas, dan peluang memperoleh tautan organik dari situs teknologi.
Karena itu, ada dua kesalahan yang perlu dihindari. Pertama, menaikkan nilainya tanpa pengujian. Kedua, sudah menguji tetapi tidak memperbarui metadata, sehingga plugin tetap terlihat tertinggal. Praktik yang benar adalah menguji, mendokumentasikan hasil, memperbaiki regresi, lalu memperbarui readme.txt pada direktori stable tag yang benar.
Status Dua Plugin yang Perlu Diprioritaskan
Berdasarkan pemberitahuan kompatibilitas yang menjadi dasar evaluasi ini, dua plugin berikut masih menggunakan nilai 6.8.5:
| Plugin | Nilai Saat Ini | Target Setelah Lulus Uji | Fokus Pengujian |
|---|---|---|---|
| Network Site Details | Tested up to: 6.8.5 |
Tested up to: 7.0 |
Network Admin, daftar situs, kolom tambahan, penyortiran, Screen Options, ekspor CSV, hak akses, dan jaringan berskala besar. |
| Search Protection | Tested up to: 6.8.5 |
Tested up to: 7.0 |
Alur perlindungan pencarian, pengguna anonim dan login, respons yang diizinkan atau ditolak, kompatibilitas cache, multisite bila didukung, dan pesan antarmuka. |
Penting untuk menahan perubahan metadata sampai pengujian benar-benar selesai. Artikel ini tidak menyatakan kedua plugin telah kompatibel; artikel ini menjabarkan standar pengujian yang perlu dipenuhi sebelum klaim tersebut dipublikasikan.
Perubahan WordPress 7.0 yang Harus Diperiksa Pengembang Plugin
1. Tema Admin Modern dan Risiko Regresi Visual
WordPress 7.0 menjadikan Modern sebagai skema visual admin baru. Pembaruan menyentuh header admin, Customizer, pemilih skema warna, multisite, serta komponen yang menggunakan paket @wordpress/components. Plugin yang menambahkan halaman pengaturan, metabox, tabel, notifikasi, modal, tombol, tab, atau formulir perlu diperiksa ulang pada ukuran layar berbeda.
Masalah umum biasanya berasal dari warna yang ditulis langsung di CSS, asumsi tinggi elemen, selector terlalu spesifik, ikon yang tidak sejajar, fokus keyboard yang tidak terlihat, serta komponen React yang memakai properti lama. Pengujian sebaiknya mencakup skema Modern dan skema lain yang tersedia, mode kontras, zoom browser, navigasi keyboard, serta tampilan seluler. Jangan hanya menilai “cantik atau tidak”; periksa apakah tombol utama tetap jelas, pesan kesalahan terbaca, label terhubung ke input, dan urutan fokus masuk akal.
2. Editor Semakin Konsisten Berjalan di Dalam Iframe
Perubahan editor iframe merupakan salah satu area teknis paling penting. Dalam WordPress 7.0, pemeriksaan berfokus pada blok yang benar-benar digunakan di sebuah post. Jika seluruh blok yang disisipkan memakai Block API versi 3 atau lebih tinggi, post editor akan dijalankan dalam iframe. Blok versi lama tetap memperoleh jalur kompatibilitas, tetapi pengembang dianjurkan melakukan migrasi.
Konsekuensinya, CSS dan JavaScript yang mengasumsikan kanvas editor berada di dokumen induk dapat gagal. Audit kode yang melakukan query DOM global, menyuntikkan style langsung ke halaman editor, bergantung pada selector internal Gutenberg, atau memasang event listener tanpa memperhatikan dokumen iframe. Gunakan mekanisme enqueue dan metadata blok yang direkomendasikan WordPress, scope selector secara ketat, dan uji blok bersama kombinasi blok pihak ketiga.
Rujukan teknis lengkap tersedia dalam Iframed Editor Changes in WordPress 7.0.
3. PHP 7.2 dan 7.3 Tidak Lagi Didukung
WordPress 7.0 menaikkan versi minimum PHP yang didukung menjadi 7.4.0, sementara versi minimum yang direkomendasikan tetap PHP 8.3.
“The new minimum supported version of PHP will be 7.4.0.”
Make WordPress Core
Untuk plugin, perubahan ini memiliki dua dampak. Pertama, pipeline pengujian perlu mencakup PHP 7.4 sebagai batas minimum dan PHP 8.3 sebagai target rekomendasi. Kedua, pengembang perlu memutuskan kebijakan kompatibilitas plugin secara eksplisit. Plugin boleh tetap mendukung kombinasi WordPress lama dan PHP lama selama kodenya memang kompatibel, tetapi jangan menggunakan sintaks PHP baru tanpa memperbarui nilai Requires PHP.
Periksa deprecated notices, type errors, perubahan perilaku library, warning yang muncul pada PHP 8.x, dan penanganan nilai null. Jalankan pengujian dengan WP_DEBUG, WP_DEBUG_LOG, dan SCRIPT_DEBUG aktif di staging. Detail resmi tersedia dalam Dropping support for PHP 7.2 and 7.3.
4. AI Client: Fondasi Baru, Bukan Kewajiban Menambah Fitur AI
WordPress 7.0 memperkenalkan AI Client bawaan berupa API PHP yang bersifat provider-agnostic. Plugin dapat mendeskripsikan kebutuhan model dan mengirim prompt melalui antarmuka yang konsisten, sementara WordPress menangani routing ke provider yang telah dikonfigurasi pemilik situs.
“A provider-agnostic PHP API that lets plugins send prompts to AI models.”
Introducing the AI Client in WordPress 7.0
Ini bukan berarti setiap plugin harus menambahkan AI. Bagi banyak plugin, tidak ada perubahan yang diperlukan. Nilai strategisnya adalah standardisasi: pengembang yang memang membutuhkan generative AI tidak perlu membangun integrasi provider dari nol untuk setiap layanan. Pelajari AI Client WordPress 7.0 sebelum merancang fitur.
Implementasi tetap membutuhkan tata kelola data. Jelaskan kapan data dikirim ke pihak ketiga, minta persetujuan yang relevan, batasi capability, sanitasi input, escape output, dan jangan menyimpan rahasia API dalam log. AI Client menyederhanakan integrasi; ia tidak menghapus kewajiban keamanan dan privasi.
5. Connections Screen dan Connectors API
Layar baru Settings > Connectors menyediakan titik pengelolaan koneksi eksternal, terutama API key untuk provider AI. WordPress 7.0 menampilkan connector unggulan untuk Anthropic, Google, dan OpenAI, serta menyediakan Connectors API agar plugin dapat bekerja dengan metadata dan mekanisme autentikasi yang lebih konsisten.
Bagi bisnis digital, pendekatan terpusat dapat mengurangi duplikasi halaman pengaturan dan kebingungan pengguna. Bagi pengembang, ini membuka peluang integrasi yang lebih mudah ditemukan dan dikelola. Namun, plugin tidak boleh mengasumsikan bahwa connector selalu tersedia atau sudah dikonfigurasi. Gunakan feature detection, tampilkan fallback yang jelas, dan hindari pengalaman yang berhenti pada layar kosong.
Baca Introducing the Connectors API in WordPress 7.0 untuk struktur registry, autentikasi, dan lifecycle.
6. Client-Side Abilities API
Abilities API yang diperkenalkan pada WordPress 6.9 kini memiliki counterpart JavaScript untuk kemampuan di sisi klien, seperti navigasi atau penyisipan blok. Perubahan ini relevan bagi plugin yang membangun workflow, command palette, automasi, atau integrasi dengan browser agent.
Daftarkan ability dengan nama dan tujuan yang jelas, terapkan pemeriksaan izin pada sisi server, dan jangan menganggap validasi antarmuka sebagai lapisan keamanan. Untuk plugin yang tidak memakai Abilities API, fitur ini bukan hambatan kompatibilitas. Namun, arsitekturnya layak dipahami karena dapat menjadi bahasa integrasi antaraplikasi WordPress di masa depan. Rujukan: Client-Side Abilities API in WordPress 7.0.
7. Registrasi Blok Hanya dengan PHP
Blok sederhana yang dirender di server kini dapat dibuat hanya dengan PHP. Fitur ini ditujukan untuk blok yang tidak memerlukan interaksi tinggi, bukan sebagai pengganti paradigma client-side. Bagi tim yang mengelola classic theme, workflow server-driven, atau komponen informasi sederhana, pendekatan ini dapat mengurangi kompleksitas build JavaScript.
Gunakan fitur ini ketika manfaatnya jelas, bukan sekadar karena baru. Blok interaktif, pengalaman real-time, dan UI kompleks tetap memerlukan arsitektur sisi klien yang memadai. Detailnya tersedia di PHP-only block registration.
Metode Pengujian Plugin yang Disarankan
Langkah 1: Siapkan Staging yang Dapat Diulang
Buat salinan staging dengan data yang cukup mewakili kondisi produksi, tetapi hilangkan atau samarkan data sensitif. Simpan backup database dan file sebelum pengujian. Catat versi WordPress, PHP, database, web server, tema aktif, dan plugin pendamping agar bug dapat direproduksi.
Langkah 2: Gunakan Matriks Versi, Bukan Satu Konfigurasi
Minimal, uji WordPress 7.0 pada PHP 7.4 dan PHP 8.3. Tambahkan PHP 8.1 atau 8.2 jika versi tersebut banyak dipakai pengguna. Uji dengan tema default dan satu tema yang umum dipakai. Untuk plugin multisite, lakukan pengujian single site dan network-activated bila keduanya didukung.
Langkah 3: Jalankan Plugin Check
Plugin Check memeriksa persyaratan direktori dan praktik pengembangan, termasuk internasionalisasi, aksesibilitas, performa, dan keamanan.
“Plugin Check is a tool for testing whether your plugin meets the required standards.”
WordPress.org Plugin Directory
Gunakan antarmuka Tools > Plugin Check atau perintah WP-CLI. Prioritaskan error keamanan, akses data tanpa capability, output yang belum di-escape, input yang belum disanitasi, penggunaan fungsi deprecated, dan masalah prefix. Tetap lakukan review manusia karena WordPress menegaskan bahwa alat ini bukan pengganti pemeriksaan manual.
Langkah 4: Uji Alur Bisnis Utama
Buat daftar tindakan yang benar-benar dilakukan pengguna, lalu uji dari awal hingga akhir. Untuk Network Site Details, contoh alurnya adalah membuka Network Admin, menampilkan kolom, menyortir data, mengubah Screen Options, dan mengekspor CSV pada jumlah situs kecil maupun besar. Untuk Search Protection, uji permintaan pencarian normal, permintaan yang seharusnya dibatasi, perbedaan peran pengguna, URL dengan karakter khusus, pagination, cache, dan respons ketika JavaScript dinonaktifkan bila relevan.
Langkah 5: Periksa Keamanan, Aksesibilitas, dan Performa
Pastikan setiap aksi sensitif memiliki capability check dan nonce yang tepat. Sanitasi data sebelum disimpan dan escape sesuai konteks saat ditampilkan. Uji navigasi keyboard, label formulir, focus state, kontras, serta pesan error. Pantau query database, ukuran aset, waktu ekspor, penggunaan memori, dan request eksternal. Kompatibel secara fungsi tetapi lambat atau tidak dapat diakses tetap merupakan pengalaman yang buruk.
Langkah 6: Catat Bukti dan Hasil Regresi
Simpan checklist, tangkapan layar, log error, hasil Plugin Check, dan versi commit yang diuji. Catatan ini mempercepat reproduksi bug, memudahkan review rekan kerja, dan menjadi dasar yang lebih kuat ketika menyatakan kompatibilitas kepada publik.
Cara Memperbarui “Tested up to” dengan Benar
Setelah seluruh pengujian kritis lulus dan regresi telah diperbaiki, ubah baris berikut di readme.txt pada stable tag yang akan dirilis:
Tested up to: 7.0Jangan menambahkan patch version pada nilai ini kecuali format direktori memang memerlukannya. Periksa juga Stable tag, nomor versi plugin, Requires at least, Requires PHP, changelog, dan upgrade notice. Metadata yang saling bertentangan dapat membingungkan pengguna dan menyulitkan dukungan.
Setelah commit atau deployment ke WordPress.org, buka halaman plugin sebagai pengguna publik dan pastikan nilai baru tampil. Uji paket yang benar-benar diunduh dari direktori, bukan hanya working copy lokal. Langkah terakhir ini penting karena kesalahan tag, file yang tertinggal, atau proses build dapat membuat paket publik berbeda dari versi yang diuji.
Apakah WordPress Beta Tester Masih Diperlukan Setelah Rilis?
WordPress Beta Tester sangat berguna sebelum rilis untuk memasang Nightly, Beta, atau Release Candidate. Karena WordPress 7.0 sudah resmi dirilis, pengujian kompatibilitas akhir sebaiknya menggunakan paket stable 7.0. Plugin Beta Tester tetap berguna untuk mengantisipasi maintenance release dan perubahan berikutnya, tetapi jangan menjalankannya di situs produksi.
Prinsipnya tetap sama: backup terlebih dahulu, gunakan staging, dokumentasikan channel pembaruan, dan pastikan tim mengetahui bahwa lingkungan tersebut bukan produksi.
Pertanyaan yang Sering Diajukan
Apakah cukup mengaktifkan plugin tanpa error?
Tidak. Aktivasi hanya menguji satu titik. Kompatibilitas mencakup seluruh alur utama, UI admin, penyimpanan data, keamanan, performa, cron, REST API, multisite, editor, ekspor, dan proses uninstall bila tersedia.
Haruskah semua plugin mengadopsi AI Client?
Tidak. AI Client adalah fondasi opsional. Plugin yang tidak membutuhkan model AI tidak perlu menambah fitur AI hanya untuk menyatakan kompatibilitas dengan WordPress 7.0.
Apakah minimum PHP plugin harus langsung menjadi 7.4?
Tidak selalu. WordPress 7.0 membutuhkan PHP 7.4, tetapi plugin mungkin tetap mendukung WordPress lama pada PHP lama. Tetapkan Requires PHP berdasarkan sintaks dan dependency plugin yang benar-benar digunakan, lalu uji kombinasi yang diklaim.
Kapan “Tested up to: 7.0” boleh dipublikasikan?
Setelah versi plugin yang akan didistribusikan lulus pengujian pada WordPress 7.0, masalah kritis telah diperbaiki, dan paket stable tag telah diverifikasi sama dengan build yang diuji.
Apa prioritas pertama untuk dua plugin PT MSP?
Prioritaskan regresi wp-admin dan multisite untuk Network Site Details, serta alur otorisasi dan respons pencarian untuk Search Protection. Keduanya kemudian harus melewati Plugin Check, uji PHP 7.4–8.3, dan pemeriksaan paket rilis.
Kesimpulan: Kompatibilitas adalah Produk, Bukan Sekadar Metadata
WordPress 7.0 menghadirkan perubahan yang relevan bagi pengalaman admin, arsitektur editor, standar PHP, dan integrasi generasi baru. Bagi pengembang plugin, respons terbaik bukan terburu-buru mengganti angka di readme.txt, melainkan menjalankan pengujian yang terukur dan dapat dipertanggungjawabkan.
Setelah Network Site Details dan Search Protection lulus uji pada WordPress 7.0, pembaruan Tested up to: 7.0 akan menjadi sinyal sederhana tetapi penting: plugin dipelihara, pengembang hadir, dan pengguna dapat melakukan pembaruan dengan keyakinan yang lebih baik.
Tidak ada komentar:
Posting Komentar