Ada momen yang bikin developer mempertanyakan kewarasannya sendiri: kamu sudah membuktikan sesuatu dengan query langsung ke database, hasilnya jelas, hitam di atas putih, tapi aplikasinya tetap ngotot menampilkan hal yang berlawanan. Saya kena itu waktu membangun ulang beberapa halaman marketing di sebuah proyek WordPress lewat skrip PHP.
Gejalanya: sudah dihapus, tapi masih ada
Halaman-halaman itu penuh widget HTML mentah, sisa pekerjaan lama yang mau saya ganti dengan struktur yang lebih rapi. Karena jumlahnya banyak dan polanya seragam, saya tulis skrip PHP yang membaca _elementor_data, membuang widget-widget HTML itu, lalu menulis balik strukturnya.
Skripnya jalan tanpa error. Saya cek datanya langsung di database untuk memastikan, dan memang bersih: tidak ada lagi satu pun widget HTML yang tersisa di _elementor_data. Sampai titik ini semuanya sesuai rencana.
Lalu saya buka halamannya di editor Elementor.
Widget HTML lamanya masih di sana. Utuh. Persis seperti sebelum skrip saya jalan. Dan di atasnya, Elementor memunculkan peringatan bahwa ada perubahan yang belum tersimpan.
Kombinasi itu yang bikin bingung. Kalau editornya cuma menampilkan konten lama, saya akan langsung curiga cache. Tapi peringatan "perubahan belum tersimpan" itu petunjuk yang berbeda sifatnya: Elementor bukan sedang menyajikan salinan basi tanpa sadar, dia sedang bilang bahwa dia punya versi lain yang menurutnya lebih baru daripada yang tersimpan.
Kenapa ini bukan kasus cache Elementor yang biasa
Refleks pertama saya jelas salah arah: bersihkan cache. Elementor memang menyimpan HTML hasil render dan CSS-nya terpisah dari datanya, dan itu penyebab paling umum kalau halaman live tidak ikut berubah setelah data diubah lewat PHP.
Tapi yang bermasalah di sini bukan halaman live. Yang bermasalah adalah kanvas editornya. Dan editor Elementor tidak membaca cache render sama sekali. Dia membangun kanvas dari data, jadi kalau datanya bersih, seharusnya kanvasnya juga bersih.
Kecuali dia sedang membaca data dari tempat lain.
Akar masalahnya: autosave dibaca lebih dulu daripada data terbit
Di sinilah letak jebakannya. Elementor menyimpan draft kerja kamu sebagai revisi autosave, dan revisi itu punya salinan _elementor_data miliknya sendiri, terpisah dari post yang terbit. Waktu editor dibuka, Elementor mengutamakan revisi autosave itu di atas data terbit, karena dari sudut pandangnya itu adalah pekerjaan terakhir kamu yang belum sempat di-Update. Itu juga sebabnya dia menyodorkan peringatan soal perubahan yang belum tersimpan.
Sekarang gabungkan dengan cara skrip saya bekerja. Skrip PHP saya menulis langsung ke post meta halamannya. Satu tulisan, satu target, selesai. Yang tidak dia sentuh sama sekali: revisi autosave yang mungkin nongkrong di sana sejak sesi editing terakhir sebelum skrip saya jalan.
Jadi urutannya jadi begini:
- Ada sesi editing sebelumnya yang meninggalkan revisi autosave berisi susunan lama.
- Skrip PHP saya membersihkan
_elementor_datadi post yang terbit. - Editor dibuka, melihat ada autosave yang lebih baru dari data terbit, lalu memuat autosave itu.
- Widget HTML lama hidup lagi di kanvas, lengkap dengan tawaran untuk menyimpannya.
Dan bagian yang paling berbahaya ada di langkah keempat. Kalau saat itu saya asal klik Update karena mengira editornya cuma butuh disegarkan, saya akan menulis balik semua widget lama itu ke database dan menghapus hasil kerja skrip saya sendiri. Databasenya benar, editornya salah, dan editorlah yang menang begitu tombol simpan ditekan.
Perbaikannya: akhiri setiap skrip dengan membuang revisi autosave
Solusinya sederhana dan sekarang jadi baris penutup wajib di setiap skrip yang menyentuh _elementor_data:
$pid = 123; // ID halaman yang baru saja ditulis ulang
foreach ( wp_get_post_revisions( $pid, [ 'posts_per_page' => -1 ] ) as $r ) {
if ( wp_is_post_autosave( $r->ID ) ) {
wp_delete_post_revision( $r->ID );
}
}Beberapa detail yang sengaja saya pilih di situ:
wp_is_post_autosave()sebagai saringan. Saya cuma mau membuang autosave, bukan seluruh riwayat revisi. Riwayat revisi itu jaring pengaman kalau ternyata skripnya salah membuang sesuatu. Menghapus semuanya sekaligus memang lebih cepat, tapi kamu ikut membuang satu-satunya jalan pulang.posts_per_page => -1ditulis eksplisit. Saya tidak mau bergantung pada default yang bisa saja disaring plugin lain di instalasi tertentu. Kalau ada satu autosave yang lolos, gejalanya balik lagi dan kamu akan mengira perbaikannya tidak jalan.- Ditaruh di akhir, bukan di awal. Yang mau kamu pastikan adalah setelah tulisan terakhir mendarat, tidak ada apa pun di post itu yang terlihat lebih "baru" daripada data terbit. Kalau autosave dibersihkan di awal lalu editornya sempat terbuka sebelum skripnya selesai, autosave baru muncul lagi dan kamu balik ke gejala yang sama.
Setelah itu, segarkan editornya. Bukan sekadar klik-klik di kanvas, tapi muat ulang halaman editornya.
Kalau Elementor masih mengeluh soal perubahan lokal
Kadang setelah reload pun Elementor masih memunculkan peringatan soal perubahan yang belum tersimpan. Kalau kamu sudah yakin data di database itu versi yang benar, dan kamu memang baru saja menulisnya lewat skrip, jawabannya adalah Discard.
Instingnya memang berat. Tombol itu terasa seperti membuang pekerjaan. Padahal dalam situasi ini yang dibuang justru sisa keadaan lama, dan yang dipertahankan adalah hasil skrip yang sudah kamu verifikasi sendiri di database. Yang benar-benar berbahaya di layar itu bukan Discard, tapi Update.
Yang saya bawa pulang
- Kalau kanvas editor Elementor tidak cocok dengan isi database, jangan langsung menuduh cache. Cache render menjelaskan halaman live yang basi, bukan editor yang basi.
- Peringatan "perubahan belum tersimpan" itu bukan gangguan kecil, itu diagnosisnya. Artinya Elementor sedang memegang versi lain dan lebih memilih versi itu.
- Menulis langsung ke post meta hanya menyentuh satu tempat. Revisi autosave punya salinan datanya sendiri dan akan tetap di sana sampai kamu menghapusnya.
- Setiap skrip PHP yang membangun ulang layout Elementor sebaiknya ditutup dengan pembersihan autosave. Satu blok kecil ini menghemat sesi debugging yang isinya mempertanyakan hasil query yang sebenarnya sudah benar sejak awal.