Yang tersisa di halaman daftar acara per venue tinggal bar pencarian. Atribut data-ecsa-target di markup-nya kosong, dan daftar acara yang biasanya ada di bawah bar itu hilang dari semua halaman venue sekaligus. Datanya sendiri utuh, tidak ada satu event pun yang terhapus.
Situs ini bukan buatan saya. Pekerjaan saya di sana hanya revisi atas permintaan kontak di pihak klien. Situsnya WordPress dengan tema Hello Elementor lewat child theme, halamannya dibangun di Elementor, dan acaranya memakai The Events Calendar (TEC) 6.17.3 bersama dua addon dari Cool Plugins. Salah satu addon itu, Events Search & Filter Bar for The Events Calendar, yang selanjutnya saya sebut ECSA, naik ke v2.0.0 yang dirilis 24 Agustus 2026, dan versi itu adalah rewrite total.
Satu shortcode di v1, sepasang di v2
Di v1, satu shortcode mengerjakan dua hal sekaligus: kotak pencarian dan daftar event di bawahnya, lewat atribut show-events="5". Shortcode v1 di blok bawah ini adalah isi widget di salah satu halaman venue sebelum saya ubah. Di v2, pekerjaan itu dipecah jadi sepasang shortcode yang diikat lewat atribut target, satu untuk bar dan satu untuk hasil, dengan nilai target yang sama di keduanya.
# v1: satu shortcode, bar sekaligus daftar
[events-calendar-search placeholder="Search Events" show-events="5" disable-past-events="false" layout="medium"]
# v2: bar dan hasil terpisah, diikat nilai target yang sama
[events-calendar-search target="ecsa-x"]
[events-calendar-search-results target="ecsa-x"]Keenam halaman venue masih membawa shortcode v1 yang identik byte per byte, jadi yang dirender v2 di semuanya hanya bagian bar.
Setelan global tidak menggantikan target
ECSA punya setelan global di Events Addons → Search & Filter Bar. Saya ubah results_mode di sana dari none ke inline, dan atributnya memang sampai ke halaman. Hasilnya tetap tidak dirender, karena tidak ada target yang menunjuk wadahnya.
Itu saya periksa dengan dua cara, tanpa cookie lewat curl dan di browser dengan JavaScript aktif. Dua cara itu menutup dua kemungkinan yang berbeda. Curl tanpa cookie memperlihatkan HTML yang diterima pengunjung anonim, sedangkan browser dengan JavaScript aktif ikut menjalankan apa pun yang dirender belakangan di sisi klien. Keduanya sepakat, jadi kesimpulannya sederhana: shortcode di halamannya memang harus diganti.
Daftar halaman diambil dari sitemap, bukan dari laporan
Laporan dari pihak klien hanya menyebut tiga halaman yang terdampak. Daftar yang benar saya dapat dengan meng-crawl seluruh sitemap lalu menyaring halaman yang memuat ecsa-bar, dan hasilnya enam halaman venue. Cara itu yang saya pegang kalau kejadian serupa berulang, bukan daftar dari klien. Penyaringan berdasarkan markup tidak bergantung pada ingatan siapa pun soal halaman mana memakai plugin apa.
Menebak URL dari nama kota juga tidak menolong di situs ini. Dua URL hasil tebakan untuk dua venue ternyata tidak 404. Keduanya dialihkan 301 ke halaman acara milik satu venue lain, jadi tebakan yang keliru tetap berakhir di halaman yang salah dengan status 200 dan tidak pernah terlihat sebagai error.
Mengganti isi widget lewat command API Elementor
Isi baru widget di keenam halaman seragam, hanya nilai target-nya yang unik untuk tiap venue. Widget shortcode di keenam halaman itu bahkan punya id Elementor yang sama, karena halaman-halamannya hasil duplikasi satu sama lain. CSS kustom lama di widget yang sama juga sudah mati, karena menyasar markup v1.
Penggantiannya tidak saya lakukan dengan menyetir panel editor. Saya memakai command API milik Elementor sendiri:
// versi disederhanakan: container adalah container widget shortcode di dokumen yang sedang terbuka
const shortcode = `[events-calendar-search placeholder="Search Events" target="<TARGET>"]
[events-calendar-search-results target="<TARGET>"]`;
$e.run('document/elements/settings', { container, settings: { shortcode } });
$e.run('document/save/default');Alasannya, jalur ini juga yang dipakai panel, jadi Elementor sendiri yang menulis JSON-nya dan revisi tetap terbentuk. Jalan pintas berupa menyusun _elementor_data sendiri lalu mengirimnya lewat POST sengaja saya hindari, karena risikonya merusak seluruh halaman. Keenam halaman selesai pada 27 dan 28 Agustus 2026, dan kontak di pihak klien sudah saya kabari bahwa halamannya beres.
Daftarnya kembali tampil, dan bersamanya muncul persoalan yang berbeda. Per 27 Agustus 2026, lima dari dua belas kartu bertanggal lama, ada yang sampai 23 September 2023. Dugaan awal saya, bahwa view TEC benar dan plugin pencarian yang salah membaca tanggal, terbukti keliru. Yang benar, indeks TEC tidak sinkron dengan tanggal tersimpan. View bawaan TEC sendiri sama rusaknya, jadi mengganti widget pun tidak akan memperbaikinya. Itu persoalan TEC yang terpisah dari shortcode, dan tidak saya bahas di sini.
URL polos masih basi, URL ber-query sudah benar
Pada 28 Agustus 2026, sesudah keenam halaman disimpan, salah satu halaman venue masih menyajikan HTML lama di URL polos, konsisten di tiga permintaan berturut-turut. URL yang sama dengan query string apa pun langsung menyajikan versi yang benar. Header respons keduanya sama persis, cf-cache-status: DYNAMIC dengan max-age=0.
Dari situ saya menyimpulkan cache-nya ada di origin, dan purge Cloudflare tidak akan menolong. Kesimpulan itu salah. Begitu Cloudflare di-purge, halaman itu langsung bersih. Di situs ini, cf-cache-status: DYNAMIC tidak berarti Cloudflare tidak menyimpan. Dua langkah yang terasa wajar juga tidak mempan untuk halaman yang basi, yaitu menyimpan ulang halaman lewat Elementor dan mencari tombol purge di wp-admin.
Cara memisahkan cache dari perbaikan yang gagal ternyata sederhana. Bandingkan URL polos dengan URL bersuffix ?cb=<angka>. Kalau yang ber-query benar dan yang polos salah, itu cache, bukan kerja yang gagal. Pemeriksaan terakhirnya tetap harus di URL polos, karena cache-buster justru menyembunyikan persoalan ini.
# sketsa yang disederhanakan: URL dan PENANDA hanya contoh
URL="https://example.com/venue/acara/"
PENANDA="string yang hanya ada di versi baru halaman"
curl -s "$URL" | grep -c "$PENANDA" # URL polos, yang diterima pengunjung
curl -s "$URL?cb=$(date +%s)" | grep -c "$PENANDA" # URL ber-queryKeluhan berikutnya: halaman venue tidak pernah terfilter
Pada 31 Agustus 2026 keluhan baru datang dari pihak klien, diteruskan lewat kontak yang sama. Menurut mereka semua halaman venue menampilkan event lintas venue, dan permintaannya "revert the changes made".
Premis keluhan itu keliru, dan bisa dibuktikan. Riwayat revisi salah satu halaman venue, sampai revisi tertua yang bertanggal 26 Mei 2025, semuanya memuat shortcode yang sama tanpa atribut venue atau kategori. Dalam catatan penelusuran saya tanggal 28 Agustus, halaman yang sama sudah tercatat menampilkan event dari empat venue lain, sama seperti sebelum rusak, karena shortcode v1 tidak pernah punya atribut venue dan keenam halaman menyimpan string yang identik byte per byte. Yang berubah hanya jumlah yang terlihat. Di v1 tampil 5 kartu lewat show-events="5", sedangkan v2 menampilkan 12 secara default.
Riwayat revisi itu saya baca lewat REST. Endpoint revisi dengan context=edit mengembalikan meta._elementor_data, jadi isi widget versi lama bisa dibaca utuh:
GET /wp-json/wp/v2/pages/<id>/revisions/<rev>?context=editYang akhirnya dipasang di halaman venue
Pasangan shortcode v2 ternyata bukan keadaan akhirnya. ECSA gratis tidak bisa memfilter venue, karena daftar atribut resmi shortcode-nya tertutup pada target, view, per-page, facets, search-fields, columns, card-size, card-fields, date-format, template, warna, control-size, dan corner-radius. Tampilan yang persis seperti grid lama ditambah filter venue hanya bisa didapat dengan membeli ECSA Pro. Saya memilih jalur gratis sesudah melihat preview-nya, dengan konsekuensi kehilangan grid tiga kolom.
Lima halaman venue lalu berhenti memakai shortcode ECSA. Widget shortcode-nya diganti widget Elementor the-events-calendar-addon dari plugin Events Widgets (events-widgets-for-elementor-and-the-events-calendar), yang difilter per kategori event. Halaman keenam tidak ikut, karena menurut pihak klien venue-nya sudah tutup, dan atas permintaan mereka halamannya dialihkan 302 ke homepage. Kotak pencarian ECSA ikut hilang dari kelima halaman, karena bar dan hasilnya tinggal di widget yang diganti. Konsekuensi itu saya sampaikan sebelum dikerjakan dan tidak dibantah. Lagi pula memang konsisten, karena bar itu mencari se-situs dan bertentangan dengan halaman per venue.
Satu jebakan di widget baru itu layak dicatat. ectbe_ev_category adalah select2 multiple, jadi nilainya harus array. Kalau diisi ID kategori berupa string seperti '<ID>', widgetnya ter-render kosong tanpa error. Nilainya harus ['<ID>']. Karena kategori event sekarang satu-satunya kunci filter halaman venue, event baru yang tidak tampil di halaman venue mana pun perlu diperiksa kategorinya lebih dulu.
Shortcode yang sudah tersimpan tidak ikut bermigrasi
Plugin bisa saja memecah shortcode-nya di versi mayor, tapi shortcode lama yang sudah tersimpan di konten halaman tetap seperti semula. Di kasus ini keenam halaman masih membawa string v1 sesudah update, dan setelan global yang sudah diubah tidak menggantikan target yang tidak ada. Jadi sesudah update mayor pada plugin yang hidup lewat shortcode, yang perlu diperiksa adalah halaman-halaman pemakainya. Daftarnya paling aman diambil dari markup di seluruh sitemap, bukan dari ingatan siapa pun, dan pemeriksaan terakhirnya di URL polos.
Kalau sesudahnya ada yang bilang dulu tampilannya tidak begini, riwayat revisi lewat REST bisa menjawabnya dengan isi widget yang benar-benar tersimpan waktu itu.