WordPress 7.1 membawa perubahan yang langsung terasa pada bagian situs yang disentuh pengunjung: cara halaman menyesuaikan diri di layar kecil, cara media diproses, dan cara tim meninjau konten bersama. Bagi situs bisnis Indonesia, ini bukan pembaruan kosmetik. Ini alasan untuk memeriksa apakah tema, kumpulan plugin, dan kebiasaan penerbitan masih berjalan baik sebelum perubahan diterapkan ke situs produksi.
Bukan berarti setiap situs harus langsung menekan tombol Perbarui. WordPress 7.0.4 dirilis sebagai pembaruan keamanan untuk menangani eksekusi kode jarak jauh oleh pengguna dengan peran Author atau lebih tinggi melalui unggahan berbahaya pada situs yang memakai Imagick dan Ghostscript. WordPress menyatakan perbaikannya juga dibawa ke cabang lain. Prioritasnya jadi jelas: kenali versi dan status pembaruan setiap situs produksi, lalu uji perpindahan ke 7.1 pada salinan situs. Rilis mayor bukan sekadar klik pemeliharaan.
- Terapkan jalur keamanan yang diketahui, lalu uji rilis mayor di staging.
- Tinjau halaman nyata pada lebar ponsel, tablet, dan desktop, termasuk fokus keyboard.
- Perlakukan blok kustom, unggahan media, formulir, dan izin penerbitan sebagai pemeriksaan terpisah.
- Siapkan cadangan yang dapat dipulihkan serta keputusan rollback sebelum perubahan produksi.
🧭 Perubahan praktis di WordPress 7.1
WordPress 7.1 diberi nama kode “Mary Lou”, untuk pianis, pengaransemen, dan komposer Mary Lou Williams. Rilis ini memadukan perubahan pada penulisan dan desain: gaya blok responsif, Notes serta mention yang lebih kaya, blok Playlist dan Tabs, SVG Icon API publik, editor pos yang selalu berada dalam iframe, serta perubahan penanganan media. Pengumuman resmi juga menyebut dukungan native untuk AVIF, HEIC, dan HDR gain maps.
Bagi bisnis kecil, pertanyaannya lebih sempit. Mana dari perubahan itu yang dapat menyentuh situs publik, alur kerja editorial, atau blok kustom? Gaya responsif dapat mengubah CSS yang dihasilkan. Editor ber-iframe dapat mengungkap asumsi tersembunyi pada blok kustom atau integrasi editor. Pemrosesan gambar di browser bisa memindahkan titik munculnya masalah unggahan. Notes dapat mengubah siapa yang menerima komentar dalam alur tinjau.
Proses rilis yang sehat memisahkan pertanyaan-pertanyaan itu. Pemilik situs tidak perlu menjadi insinyur WordPress. Yang diperlukan adalah keputusan singkat dan tercatat: apa yang akan diuji, siapa yang memberi persetujuan, serta bagaimana versi sebelumnya dipulihkan bila muncul gangguan nyata.
📌 Yang perlu diperiksa sebelum menyentuh produksi
Mulailah dengan inventaris ringkas. Catat versi WordPress dan PHP saat ini, tema aktif, child theme bila ada, plugin aktif, lapisan cache, plugin optimasi gambar, metode cadangan hosting, serta orang-orang yang masih dapat mengakses akun administrator. Buat cadangan yang benar-benar dapat dipulihkan, termasuk berkas dan basis data. Cadangan yang dijanjikan paket hosting baru bernilai setelah jalur pemulihan dan masa retensinya dipahami.
Lalu pilih sekumpulan halaman yang mewakili situs. Sertakan beranda, formulir kontak atau checkout, artikel terbaru, landing page dengan banyak blok, halaman galeri atau gambar besar, serta halaman yang memakai template paling dikustomisasi. Pada situs jasa, kirim satu formulir kontak nyata ke kotak masuk terkontrol. Pada toko, uji penelusuran, keranjang, checkout dalam mode uji pembayaran yang diizinkan, email pesanan, serta aturan stok atau booking tanpa membuat pesanan pelanggan sungguhan.
Tujuannya bukan otomasi menyeluruh dalam satu sore. Tujuannya adalah menutup jalur yang akan membuat bisnis kehilangan prospek, penjualan, atau kepercayaan bila template, aturan gaya, cache, atau integrasi rusak. Ambil tangkapan layar pada lebar desktop dan seluler sebelum pembaruan. Saat muncul komentar bahwa jarak tombol dulu berbeda, bukti visual jauh lebih berguna daripada ingatan.
📱 Gaya responsif membantu, tetapi mengubah pekerjaan peninjauan
WordPress 7.1 menambahkan state gaya responsif untuk viewport tablet dan seluler. Dokumentasi pengembang menjelaskan bahwa gaya dapat diatur lewat Global Styles berdasarkan jenis blok atau pada blok individual. Dalam theme.json, override seluler dan tablet ditempatkan di bawah @mobile dan @tablet; gaya bawaan tetap menjadi gaya desktop. Titik henti bawaan yang didokumentasikan adalah 480px untuk seluler dan 782px untuk tablet. Tema dapat menetapkannya melalui settings.viewport dengan nilai non-negatif berunit px, em, atau rem.
Ini kabar baik bagi tim yang sebelumnya bergantung pada CSS kustom agar tombol, group, jarak, atau layout rapi di layar kecil. Namun peninjauan tidak lagi cukup dilakukan pada satu jendela browser. Sebuah blok dapat tampak benar pada monitor besar, tetapi menimbulkan judul sesak, kartu terpotong, atau ruang kosong canggung pada lebar ponsel.
Jadikan pengujian ini eksplisit. Tinjau halaman pilihan pada lebar ponsel sempit, tablet umum, dan desktop. Gunakan konten nyata, terutama judul produk terpanjang, nama pelanggan panjang, gambar dengan potongan vertikal, serta label tombol yang dapat menjadi dua baris. Periksa fokus keyboard, bukan hanya hover mouse. Catatan pengembang 7.1 menyebut gaya pseudo-state untuk :hover, :focus, :focus-visible, dan :active tersedia pada blok Button dan Navigation Link. Tim merek mungkin senang dengan hover baru, tetapi pengunjung yang memakai keyboard harus tetap melihat fokus secara jelas.
Jangan menganggap tema lama otomatis memperoleh desain seluler yang sudah matang karena Core kini menyediakan kontrol. Blok yang memakai block supports standar mendapatkan gaya responsif, sedangkan blok dengan kontrol gaya kustom mungkin tidak. Blok kustom patut mendapat uji kompatibilitas kecil sendiri. Bila ia memakai kontrol khusus, hasil yang tepat bisa saja “belum ada kontrol responsif baru”, bukan perubahan dadakan di produksi.
🖼️ Perubahan media perlu diuji lewat unggahan nyata
Catatan rilis 7.1 menyebut kompresi, pengubahan ukuran, dan pembuatan thumbnail gambar kini terjadi di browser. Tujuannya mengurangi beban server serta menghindari batas memori PHP atau waktu habis saat unggah. Catatan itu juga mencantumkan dukungan native untuk AVIF, HEIC, dan HDR gain maps. Itu adalah kemampuan, bukan jaminan bahwa semua tema lama, pengoptimal gambar, CDN, atau browser akan bereaksi sama setelah pembaruan.
Pakai staging untuk mengunggah tiga berkas yang menyerupai materi penerbitan bisnis: foto dari ponsel, banner lebar, dan JPEG atau PNG besar dari desainer. Jika tim menerima HEIC dari iPhone atau AVIF dari kamera maupun pemasok, sertakan sampel terkendali. Periksa unggahan asli, ukuran yang dibuat WordPress, crop featured image, tampilannya di halaman depan, gambar dalam alat pratinjau sosial bila itu bagian dari alur kerja, serta hasil setelah cache dibersihkan.
Jangan mengubah ini menjadi perburuan format berkas. Bila situs tidak pernah menerima HEIC dan audiens dilayani baik oleh turunan JPEG serta WebP, tidak ada alasan bisnis untuk mengganti pasokan editorial hanya karena 7.1 mendukung format lain. Perbaikan yang berguna adalah jalur terdokumentasi untuk gambar yang memang diunggah staf. Simpan berkas sumber asli. Beri nama yang mudah dibaca. Tambahkan alt text yang menjelaskan fungsi gambar, bukan kumpulan kata kunci. Pastikan plugin optimasi tidak menggandakan, mengganti, atau gagal menyajikan ukuran gambar yang diminta tema.
Ada konteks keamanan penting di samping pekerjaan media ini. WordPress 7.0.4 menyebut kondisi terdampak sebagai eksekusi kode jarak jauh oleh pengguna Author+ melalui unggahan berbahaya pada situs yang memakai Imagick dan Ghostscript. Pelajaran operasional paling aman bukan mencurigai setiap gambar. Terapkan rilis keamanan, batasi akun Author pada orang yang memang membutuhkannya, dan jangan menganggap izin unggah tidak berisiko.
🧩 Editor kini terisolasi secara konsisten
Menurut WordPress Developer Blog, WordPress 7.1 membuat editor pos selalu ber-iframe. Sebelumnya, perilaku ini dapat berubah berdasarkan jenis tema, versi API blok, atau blok yang ditempatkan di konten. Perubahan itu menghapus mode bersyarat tersebut, termasuk bagi situs yang masih mendaftarkan legacy meta box.
Bagian ini paling penting bagi pengembang dan agensi yang merawat pengalaman editor kustom. Sidebar plugin, stylesheet editor sebuah blok, skrip yang mencari elemen dokumen, atau integrasi yang bergantung pada gaya turunan dapat bertingkah berbeda ketika konten berada di dalam iframe. Halaman publik mungkin baik-baik saja, sementara layar pengeditan membingungkan atau rusak bagi staf.
Batas praktisnya perlu dipahami. Iframe memiliki dokumen dan window sendiri. Kode yang memakai dokumen global untuk memanipulasi kanvas editor mungkin kini menunjuk ke halaman administrator, bukan kanvas. Panduan pengembang WordPress menyarankan mengambil dokumen kanvas dari elemen di dalamnya melalui ownerDocument dan defaultView, lalu memasang serta membersihkan listener pada elemen yang tepat. Ini pekerjaan pemelihara blok atau integrasi, tetapi pemilik situs tetap dapat mengajukan pertanyaan berguna: apakah alur editor yang persis ini sudah diuji pada versi yang akan dipakai?
Periksa juga ekstensi yang menyentuh tabel daftar pos. Rangkuman pengembang menyebut row header utama dipindahkan dari kolom kotak centang ke kolom judul. Perubahan ini meningkatkan aksesibilitas, tetapi dapat memengaruhi CSS atau JavaScript yang ditulis untuk struktur tabel lama. Kustomisasi dashboard yang tampak kecil dapat memperlambat kerja editorial bila menyembunyikan row actions atau mengandalkan selector yang berubah. Buka daftar pos, gunakan tampilan responsif yang sempit, pakai pemilihan massal bila tim menggunakannya, dan pastikan aksi kustom masih muncul.
Uji pekerjaan editorial, bukan hanya halaman akhir. Buka pos yang ada. Buat draf. Tambahkan paragraf, heading, gambar, tombol, embed, pola reusable, dan blok kustom apa pun. Sunting pos dengan legacy meta box bila situs masih memakainya. Pratinjau, simpan sebagai draf, jadwalkan bila dipakai, perbarui, lalu pastikan hasil front-end sesuai struktur yang dimaksud editor. Cari gaya editor yang hilang, kontrol sulit dipakai, galat konsol, perilaku seleksi aneh, serta dialog yang muncul di belakang editor.
Bila vendor plugin menyatakan mendukung 7.1, catat versi dan catatan dukungannya dalam rekam perubahan. Bila belum ada pernyataan, itu tidak otomatis berarti plugin tidak aman. Artinya pemilik situs harus memutuskan apakah hasil staging sudah cukup, perlu menunggu pembaruan, atau plugin itu penting sehingga layak diganti. Label “kompatibel” baru menjadi bukti ketika dikaitkan pada versi plugin dan pengujian yang spesifik.
🗣️ Notes, mention, dan kolaborasi memerlukan aturan
Rilis ini menambahkan dukungan rich text dan @mention pada Notes, sedangkan pengumuman release candidate mencantumkan notifikasi email untuk @mention serta shareable revisions di antara perubahan pada siklus 7.1. Fitur-fitur ini dapat mempercepat review konten. Fitur yang sama dapat menjadi persoalan tata kelola bila klien, pekerja lepas, atau mantan staf masih memiliki akses.
Sebelum membentuk kebiasaan review baru, daftar siapa yang dapat membuat, menyunting, menerbitkan, dan berkomentar. Hapus akun yang tidak lagi diperlukan. Gunakan akun individual, bukan satu login administrator bersama. Berikan peran paling rendah yang masih memungkinkan pekerjaan selesai. Author yang menulis artikel belum tentu perlu memasang plugin atau mengakses tema. Reviewer yang hanya menyetujui copy mungkin memerlukan jalur berbeda.
Buat satu konvensi sederhana untuk Notes. Misalnya, gunakan mention hanya bila respons diperlukan; tulis URL halaman atau judul pos; jelaskan keputusan yang diminta; lalu selesaikan note setelah perubahan diterbitkan atau ditolak. Aturan kecil ini mencegah thread editorial berubah menjadi catatan keputusan setengah jadi yang sulit dicari.
Fitur kolaborasi bukan pengganti cadangan atau pemeriksaan penerbitan. Revisi yang dapat dibagikan membantu review, tetapi bukan bukti bahwa halaman sudah diuji di seluler, formulir berfungsi, atau pernyataan untuk pelanggan telah disetujui. Itu adalah tanggung jawab yang berbeda.
🎨 Alat desain baru perlu menjaga sistem, bukan menerobosnya
WordPress 7.1 membawa SVG Icon API yang memungkinkan plugin mendaftarkan koleksi dan ikon. Developer Blog mencatat allowlist sanitasi yang konservatif untuk SVG terdaftar, serta memperingatkan bahwa pemanggilan wp_get_icon() mandiri dapat tampil dengan fill hitam sendiri bila CSS tidak disediakan. Rilis ini juga mencakup blok Playlist dan Tabs.
Tambahan ini berguna, tetapi situs bisnis cepat kehilangan konsistensi saat setiap halaman baru menemukan bentuk tombol, perlakuan ikon, breakpoint, dan interaksi tab sendiri. Jadikan pembaruan sebagai kesempatan untuk menetapkan sistem kecil: sumber logo dan ikon yang disetujui, teks alternatif, gaya tombol, nilai jarak, hierarki heading, serta halaman yang memang terbantu oleh Tabs.
Tabs tidak otomatis membuat halaman layanan lebih mudah dipahami. Tab dapat menyembunyikan informasi penting dari pembaca cepat, menyulitkan navigasi keyboard, dan mempersulit tautan langsung ke detail. Pakai tab bila pilihan yang dibandingkan benar-benar sejajar, misalnya spesifikasi paket terkait, dan pastikan panel bawaan tetap berguna. Bagian bertumpuk sederhana sering lebih jelas bila kontennya memiliki urutan baca alami.
Untuk SVG, jangan menempelkan kode sembarang dari pencarian gambar ke editor. Gunakan ikon dari sumber terkendali, simpan informasi lisensinya, lalu uji kontras warna, label aksesibel, dan tampilannya pada ukuran kecil. Sanitasi API adalah pengamanan, bukan pengganti peninjauan desain.
Ada aturan praktis lain untuk tiap alat baru. Jangan mengaktifkan semua kontrol di situs klien hanya karena kontrol itu tersedia. Buat satu halaman uji, pilih satu komponen yang memang perlu diperbaiki, lalu bandingkan hasilnya dengan desain yang sudah disetujui. Catat nilai breakpoint dan perubahan gaya di tempat yang dapat dibaca tim. Bila pengaturan responsif hanya tinggal sebagai klik individual di puluhan blok, pemeliharaan berikutnya akan berubah menjadi pencarian manual.
Saat memakai pola, halaman layanan, atau template, pisahkan keputusan konten dari keputusan sistem. Tim pemasaran boleh menyetujui judul dan urutan informasi. Pemelihara situs perlu memastikan heading tidak melompati struktur, tombol tetap mengarah ke tujuan yang benar, tab dapat dioperasikan dengan keyboard, dan ikon tidak menyampaikan makna tanpa label. Pembagian sederhana ini menjaga perubahan visual tidak diam-diam menurunkan aksesibilitas atau jalur konversi.
🔐 Keamanan didahulukan daripada eksplorasi fitur
Keputusan pertama adalah kebersihan versi. WordPress secara tegas menyarankan pembaruan segera untuk 7.0.4 karena rilis itu memperbaiki masalah keamanan. Advisory mengidentifikasi isu tersebut sebagai CVE-2026-65640 dan menautkan advisory GitHub yang terkait. Dalam pengumuman 7.0.4, WordPress juga menyatakan hanya versi terbaru yang didukung aktif.
Untuk situs yang tertinggal beberapa pembaruan, jangan meloncat dari keadaan yang tidak diketahui ke rilis besar saat periode penjualan sibuk. Kenali dulu versi saat ini, dukungan PHP, plugin kritis, dan apakah automatic background updates pernah dimatikan. Terapkan jalur pembaruan keamanan yang direkomendasikan vendor pada jendela pemeliharaan setelah titik pemulihan dipastikan. Berikutnya, uji 7.1 di staging menggunakan tema dan integrasi situs yang sebenarnya.
Keamanan juga ditentukan kebiasaan yang tidak dapat disediakan Core: kata sandi unik, autentikasi multi-faktor bila tersedia, jumlah administrator terbatas, peninjauan plugin dan tema, penghapusan perangkat lunak tidak terpakai, serta cadangan yang dipantau. Situs staging tidak boleh membuka data pelanggan produksi ke publik. Bila data produksi harus disalin untuk pengujian, batasi aksesnya dan patuhi kewajiban privasi bisnis.
Pemeriksaan mingguan singkat lebih baik daripada bersih-bersih dramatis setahun sekali. Tinjau notifikasi pembaruan. Periksa cadangan selesai. Pastikan beranda publik dan alur kontak dapat dimuat. Baca pemberitahuan keamanan dari WordPress serta vendor plugin kritis. Catat tanggal, penanggung jawab, dan hasil. Dengan begitu, pemeliharaan situs menjadi rutinitas operasi, bukan respons darurat.
🧪 Rencana hari rilis yang dapat dipertahankan tim kecil
Rollout praktis dapat dilakukan dalam satu sesi yang terstruktur. Pertama, buat atau segarkan staging dari keadaan produksi yang diketahui. Kedua, perbarui salinan uji dan bersihkan cache staging saja. Ketiga, jalankan daftar periksa halaman serta alur kerja: halaman publik, layout responsif, formulir, unggahan media, pekerjaan editor, pencarian bila digunakan, alur toko atau booking bila digunakan, dan blok kustom. Keempat, catat masalah dengan tangkapan layar, URL, browser, viewport, dan langkah reproduksi.
Kelima, ambil keputusan. Bila gangguan menyentuh checkout, pengambilan kontak, akses akun, halaman inti, atau integritas data, jangan dorong pembaruan hingga masalah dipahami atau rollback siap. Bila masalah terbatas pada detail visual yang tidak kritis, perbaiki di staging atau jadwalkan tindak lanjut dengan jelas, tetapi buat keputusan itu terlihat. Keenam, jadwalkan perubahan produksi pada periode rendah risiko, taruh prosedur pemulihan dan kontak di satu tempat, lalu beri tahu tim mengenai dampak singkat yang mungkin terjadi.
Sesudah pembaruan produksi, ulangi pemeriksaan publik singkat, jangan menganggap hasil staging pasti berpindah tanpa perbedaan. Cache, aturan CDN, variabel lingkungan, pengiriman email, dan layanan pembayaran dapat berbeda. Pastikan versi yang diterapkan, beranda, satu halaman seluler representatif, pengiriman formulir, serta jalur konversi paling penting. Biarkan jendela pemantauan terbuka cukup lama untuk menangkap masalah yang dilaporkan staf atau pelanggan.
Rencana ini tidak menjanjikan risiko nol. Rencana ini memberi tim kecil cara menemukan risiko penting saat biaya perbaikannya masih rendah. Simpan hasil uji, perubahan yang disetujui, dan waktu penerapan dalam catatan singkat. Pada pembaruan berikutnya, catatan itu mempercepat diagnosis dan mengurangi keputusan berdasarkan tebakan.
⚠️ Hal yang tidak diselesaikan oleh rilis ini
WordPress 7.1 tidak dapat memperbaiki plugin yang tidak didukung, hosting tanpa cadangan teruji, tema yang dibangun dari override rapuh, atau proses penerbitan dengan kepemilikan yang tidak jelas. Kontrol responsif tidak otomatis membuat konten ringkas. Penanganan media baru tidak menyediakan hak penggunaan gambar atau alt text bermakna. Notes tidak memutuskan siapa yang berwenang menerbitkan.
Ada pula batas ruang lingkup dalam materi resmi. Field Guide 7.1 menyebut kolaborasi waktu nyata belum diaktifkan, usulan menyembunyikan Classic block dari inserter dibatalkan, React 19 belum masuk, dan pekerjaan lain masih berjalan. Tim sebaiknya tidak membuat roadmap berdasarkan fitur yang belum benar-benar dirilis.
Situs juga boleh menunggu. Bila kampanye, periode pendaftaran, atau perubahan checkout besar sedang berlangsung, langkah tepat mungkin menyelesaikan pembaruan keamanan, mempertahankan konfigurasi stabil saat ini, lalu menjadwalkan uji rilis fitur setelah periode kritis. Penundaan harus disengaja dan dicatat, bukan kebiasaan tanpa batas.
✅ Hasil yang berguna bagi situs bisnis
WordPress 7.1 memberi tim lebih banyak kendali atas gaya responsif, alur media, konsistensi editor, dan review. Nilainya bukan jumlah kontrol baru yang terlihat di dashboard. Nilainya adalah halaman yang tetap mudah dibaca pada ponsel, editor yang dipercaya staf, alur gambar yang tidak gagal pada penggunaan normal, serta rutinitas pembaruan yang mendahulukan keamanan daripada kebaruan.
Mulailah dari inventaris versi dan cadangan yang dapat dipulihkan. Terapkan jalur rilis keamanan. Uji 7.1 memakai tema, plugin, serta perjalanan pelanggan nyata di staging. Tinjau perilaku seluler dan keyboard dengan konten aktual. Baru setelah itu putuskan apakah produksi siap.
Bagi studio web atau pemilik bisnis, disiplin inilah fitur rilis yang paling layak dipertahankan. Ia membuat pembaruan berikutnya tidak terlalu dramatis karena tim sudah mempraktikkan pekerjaan yang benar-benar penting. Dengan begitu, rilis memperbaiki sistem penerbitan yang berjalan, bukan menguji keberuntungan bisnis.
Sumber: pengumuman rilis WordPress 7.1 “Mary Lou”, rilis keamanan WordPress 7.0.4, WordPress 7.1 Field Guide dan rangkuman pengembang, pengumuman WordPress 7.1 RC1, serta dokumentasi lisensi WordPress.
