WordPress 7.1 Live: Panduan Upgrade Aman untuk Website Bisnis

WordPress 7.1 dirilis pada 19 Agustus 2026, bertepatan dengan WordCamp US 2026. Kalau Anda punya website bisnis di WordPress, kemungkinan besar Anda sudah melihat notifikasi update di dasbor, atau mungkin Anda sengaja menundanya karena ada banyak plugin yang belum pernah Anda cek.

Fakta yang perlu Anda tahu: tidak ada alasan untuk panik, dan juga tidak ada alasan untuk menundanya. Rilis ini bersifat inkremental. Tidak ada perubahan merusak yang diumumkan, dan tidak ada kenaikan minimum versi PHP yang baru. Tapi “tidak merusak” bukan berarti “boleh diklik sembarangan”.

Disclaimer: contoh di bawah memakai WP-CLI, karena itu cara yang saya gunakan di server klien dan paling bisa diaudit. Kalau Anda memakai cPanel atau Plesk, prinsipnya sama persis, hanya perintahnya yang berbeda.

Perubahan Utama yang Perlu Anda Tahu

Satu perubahan di WordPress 7.1 paling mungkin merusak sesuatu yang Anda miliki: editor blok kini berjalan di dalam iframe.

Artinya, area penyuntingan artikel dipisahkan dari dokumen admin WordPress. Konsekuensinya:

Kalau website Anda memakai tema bawaan dan plugin populer tanpa kode kustom sendiri, Anda kemungkinan besar tidak akan merasakan apa-apa.

Sembilan Cek Sebelum Tekan Tombol Update

Bagian ini butuh sekitar dua puluh menit, dan hasilnya memberi tahu Anda layak atau tidak menekan tombol.

Cek 1: Backup yang benar-benar pernah di-restore

Ini bukan backup, tapi backup yang sudah pernah dipulihkan. Bedanya segalanya. Backup yang belum pernah dicoba restore adalah sekadar harapan.

# Database dan file, sebelum apa pun
wp db export ~/pre-71-$(date +%F).sql
tar czf ~/pre-71-files-$(date +%F).tgz wp-content/

Simpan salinannya di luar server. Backup di server yang sama dengan yang Anda jaga tidak berguna jika server itu yang tumbang.

Cek 2: Cari blok kustom milik Anda sendiri

WordPress 7.1 hanya mengancam blok yang Anda tulis sendiri. Jadi mulailah dari situ, bukan dari plugin pihak ketiga.

# Semua blok yang terdaftar, dan siapa yang mendaftarkannya
wp eval 'foreach ( WP_Block_Type_Registry::get_instance()->get_all_registered() as $n => $b ) { if ( 0 !== strpos( $n, "core/" ) ) { echo $n . "\n"; } }'

Kalau nama blok di daftar itu berasal dari plugin pihak ketiga yang Anda pakai sendiri, atau dari tim Anda, maka blok itu wajib dicek. Kalau dari plugin yang rutin dirawat, itu urusan vendor, tapi tetap baca changelog-nya untuk catatan 7.1.

Cek 3: Grep asumsi yang sekarang salah

# Script editor yang mengakses dokumen level atas
grep -rn "document.querySelector" wp-content/themes/ wp-content/plugins/

# Style blok pada hook yang salah
grep -rn "enqueue_block_editor_assets" wp-content/themes/ wp-content/plugins/

Kalau tema Anda punya `editor-style.css` atau memasukkan CSS editor secara manual, kemungkinan besar style-nya perlu dipindahkan dari `enqueue_block_editor_assets` ke `enqueue_block_assets`.

Cek 4: Versi PHP

WordPress 7.1 berkembang baik di PHP 8.1 atau lebih baru, dan terbaiknya di 8.3.

wp eval 'echo PHP_VERSION . "\n";'

Kalau Anda masih di 8.0 atau lebih lama, tangani itu lebih dulu, dan secara terpisah. Mengganti PHP dan Core di jendela waktu yang sama berarti ada dua variabel berubah sekaligus. Saat site rusak, Anda tidak akan tahu penyebabnya.

Cek 5: Kompatibilitas plugin, dengan jujur

Klaim “tested up to” di header plugin adalah klaim, bukan hasil uji. Urutkan plugin berdasarkan dampak paling besar kalau plugin itu berhenti bekerja.

Cek 6: Style editor milik Anda sendiri

Kalau tema Anda punya `editor-style.css`, buka tiga tipe post berbeda setelah update, lalu bandingkan dengan tampilan front-end. Gejalanya halus, bukan crash: font yang jatuh ke default, spasi yang runtuh, tombol yang bergeser.

Cek 7: Jalankan Site Health dulu

wp site-health check --format=table

Bersihkan apa pun yang ia tandai sebelum Anda menambah satu variabel baru. Update yang mendarat di site yang sudah tidak sehat akan jadi masalah diagnostik sepanjang minggu.

Cek 8: Ambil screenshot kondisi sekarang

Lima halaman yang penting: beranda, halaman layanan, satu artikel, toko, dan checkout.

# opsional, kalau Anda punya CLI screenshot
npx playwright screenshot --full-page https://tokosaya.id/ /root/shots/beranda.png

Screenshot membuat percakapan jauh lebih mudah. “Tampilannya berbeda” jauh lebih sulit dibicarakan daripada dua gambar yang bisa dibandingkan berdampingan.

Cek 9: Pilih jam yang tepat

Bukan Jumat sore. Bukan satu jam sebelum email kampanye dikirim. Untuk sebagian besar website bisnis di Indonesia, pagi hari cukup tenang sehingga masalah dua puluh menit tidak akan terlihat.

Staging Dulu. Setiap Kali

Kalau Anda belum punya lingkungan staging, itu yang pertama harus dibuat. Ini satu kebiasaan yang mengubah update dari kejadian yang langka menjadi rutinitas.

Di staging, jalankan:

wp core update --version=7.1
wp core update-db

Lalu buka editor, bukan front-end. Buka sidebar, dialog, dan setiap blok kustom yang Anda pakai. Buka satu template di Site Editor. Buka grid media library kalau koleksinya besar. Kirim satu form.

Kalau sepuluh menit berlalu tanpa kejutan, baru ulangi di site live.

Gelombang Upgrade untuk Site yang Banyak

Kalau Anda mengurus beberapa website, mengurutkan pekerjaan adalah setengah dari pekerjaan.

Gelombang 0. Site Anda sendiri. Site contoh, site staging, tempat kerusakan tidak mengganggu siapa pun. Ini hari rilis.

Gelombang 1. Site klien yang sederhana. Tema bawaan, plugin sedikit, tidak ada blok kustom. Site ini yang jadi tikus percobaan: cukup variasi nyata untuk memunculkan masalah, cukup rendah risikonya kalau ada masalah. Dua sampai tiga hari setelah rilis.

Gelombang 2. Site yang biasa saja, termasuk site e-commerce dan site dengan klien yang punya editor. Hanya setelah gelombang 1 berjalan bersih beberapa hari.

Cara Menangani Backlog Plugin dengan Benar

Ini kesalahan yang sering saya lihat: menggabungkan update Core dengan sapuan update plugin dan theme. Jadi lebih hemat waktu, dan kehilangan kemampuan untuk mendiagnosis apa pun.

Kalau setelah itu site Anda salah, Anda tidak tahu penyebabnya, dan satu-satunya jalan kembali adalah membelah upgrade yang sudah di-deploy. Pisahkan minimal satu hari. Core dulu, verifikasi, lalu plugin.

Cara Rollback dengan Benar

Kalau Core benar-benar merusak, ternyata ada jalur kembali:

# Kembali ke minor sebelumnya, file saja
wp core update --version=7.0.4 --force

# Kalau database juga perlu kembali
wp db import ~/pre-71-$(date +%F).sql

Dua hal yang sering orang salah paham di sini:

Pertama, opsi `–force` mengganti file Core, tapi tidak membatalkan routine upgrade database. Itulah kenapa ekspor di Cek 1 bukan opsional.

Kedua, me-rollback Core sementara plugin dibiarkan pada versi pasca-update bisa menghasilkan site yang lebih buruk daripada kedua keadaannya. Keduanya harus kembali, atau tidak sama sekali.

Kapan Sebenarnya Anda Harus Menunda

Tabel ini lebih berguna daripada rumored update:

Perlu ditegaskan: ini bukan alasan menunda tanpa akhir. Ada security update yang tidak boleh ditinggal di server produksi terbuka hanya karena tim berdebat. Jawabannya bukan “tunggu sampai tidak ada lagi update”, tapi “siapkan staging, siapkan smoke test, dan sediakan orang yang bertanggung jawab atas keputusan rollback”.

Checklist Singkat

Kalau Anda hanya mengingat satu bagian, ingat yang ini.

2. Pastikan backup itu bisa di-restore

3. Cek daftar blok kustom Anda

4. Pastikan PHP minimal 8.1, upgrade terpisah dari Core

5. Jalankan Site Health dan bersihkan

6. Screenshot lima halaman penting

7. Update di staging, uji editor bukan front-end

8. Verifikasi, lalu update di live

9. Simpan catatan versi untuk setiap site

Dan satu hal terakhir: tuliskan alasan rollback Anda sebelum menjalankan. Kalau Anda tidak bisa menjelaskan dalam satu kalimat apa saja kondisi kegagalan yang membuat Anda mundur, Anda belum punya rencana, Anda cuma punya harapan.

—

Ada yang punya pengalaman upgrade WordPress 7.1 di website bisnis? Ceritakan di komentar, terutama kalau ada plugin yang bermasalah. Catatan ini jadi jauh lebih berguna untuk pemilik usaha lain yang punya masalah serupa.