Event Masa Depan Langsung Tampil, Jadwal Lewat Langsung Terbit
Uji paritas agenda: event_date mengatur urutan tampil, scheduled_at mengatur keterlihatan konten.
Ringkasan
Jadi pas uji paritas agenda di portal pemda, event olahraga langsung muncul di dua halaman publik, dan announcement dengan scheduled_at yang udah lewat langsung published tanpa perlu apa-apa. Dugaan soal cron atau worker ternyata salah, karena kontraknya ala WordPress: status ditentukan pas POST, bukan dibalik manual. Ada tiga model yang hasilnya sama, bedanya cuma di mana keputusan publish diambil.
Saya menjalankan skenario uji paritas untuk permukaan agenda di sebuah portal pemerintah daerah. Sebuah event berjenis OLAHRAGA dengan tanggal kegiatan masih beberapa hari ke depan saya buat, lalu saya cek dua permukaan publik: bagian rubrik per-jenis di halaman /informasi dan EventsSection di halaman utama. Event itu langsung tampil di keduanya.
Di skenario kedua, sebuah announcement saya kirim lewat POST admin dengan scheduled_at yang sudah lewat. Response admin-nya polos, hanya berisi payload announcement seperti biasa, tetapi statusnya sudah langsung published. Tiga pengujian lulus. Yang tidak lolos justru dugaan saya sendiri tentang cara sistem mencapai hasil itu.
Tebakannya: ada worker yang membalik status
Tebakan awal saya sederhana: pasti ada cron atau worker latar yang membaca scheduled_at, lalu menulis ulang status baris dari scheduled menjadi published begitu waktunya tiba. Model itu nyata dan dipakai beberapa CMS, sehingga saya sempat menyiapkan asumsi soal job beserta interval eksekusinya.
Asumsi itu tidak perlu. Kontrak yang dipakai API portal ini bersifat seperti WordPress: scheduled_at yang sudah lewat membuat announcement terhitung published sejak POST, hasil yang skenario uji ini buktikan sendiri. Nilai scheduled_at di masa depan membuatnya tetap tidak tampil di publik sampai waktunya. Menerbitkan konten pada akhirnya hanyalah pergantian status, bukan penulisan ulang konten, sehingga tidak ada yang perlu dibalik secara manual [4].
Yang belum terjawab dari riset ini: evaluasi itu terjadi saat insert atau saat baca. Spesifikasi eksternal yang saya baca menjelaskan keduanya mungkin, tanpa membuka kode implementasi target.
Tiga model yang selama ini disamakan
Frasa "kontrak ala WordPress" ternyata menyembunyikan setidaknya tiga pendekatan berbeda.
Pertama, filter saat baca. CMS dinamis seperti Directus menyaring konten pada saat query berjalan: sebuah item dianggap terbit jika date_published kurang dari atau sama dengan waktu sekarang. Tidak ada job apa pun di antaranya [5].
Kedua, polling saat tulis. Pada situs statis, Directus memakai Flow dengan trigger CRON yang menulis ulang status konten menjelang waktu tayang, karena halaman hasil build tidak bisa menyaring secara dinamis [6].
Ketiga, event timer saat tulis. WordPress memakai WP-Cron yang hanya berjalan saat halaman dimuat [1], lalu menjalankan publish_future_post untuk konten berstatus future [2]. WordPress menjadwalkan berdasarkan konversi get_gmt_from_date dari nilai tanggal lokal, bukan dari kolom GMT, sehingga perhitungannya tetap benar melewati perubahan daylight saving [8].
Ketiganya menghasilkan perilaku publik yang sama. Perbedaannya ada di lokasi keputusan diambil.
Lokasi itu penting saat ada yang meleset. Pada model event timer, konten yang jadwalnya terlewat berstatus future terlalu lama baru ditandai sebagai missed schedule [3]. Pada model filter saat baca, tidak ada yang bisa terlewat karena tidak ada yang dijadwalkan sama sekali. Pemilihan model menentukan jenis kegagalan yang harus dipantau.
Model yang dipilih hanyalah separuh persayaratan. Entri E2E ini juga mengunci urutan tampil: dua tanggal, dua peran. Listing rubrik agenda mengurutkan event_date secara descending, NULL diletakkan paling akhir, dengan limit 9 item, hasil yang lembar temuan pengujian ini catat. event_date di sini bukan tanggal terbit; kolom itu menentukan urutan tampil saja.
Pemisahan ini yang paling mudah dilanggar saat membangun CMS sendiri. Jika scheduled_at dipakai sekaligus sebagai kunci urutan, sebuah event yang dijadwalkan ulang akan ikut mengubah posisinya di daftar. Jadwal publikasi dan urutan tampil adalah dua keputusan berbeda, dan keduanya membutuhkan kolomnya masing-masing.
Urutan pembersihan datanya juga terkunci kontrak yang sama: trash dahulu, baru permanent delete. Permanent delete langsung tanpa trash menghasilkan 404 pada pengujian yang sama. Assert akhir pengujian memastikan tidak ada baris tersisa setelah cleanup, sehingga pengujian berikutnya selalu mulai dari kondisi kosong.
Setelah entri ini, saya memecah kolom tanggal di spesifikasi CMS yang saya tulis menjadi dua peran eksplisit: satu untuk kapan konten boleh terlihat, satu untuk di mana konten itu duduk di daftar. Sisanya, pemilihan model penjadwalan mana yang dipakai, bergantung pada apakah halaman dibangun ulang per deploy atau dirender per request.
Sources:
[1] WordPress Plugin Handbook: Cron
[2] check_and_publish_future_post() – WordPress Developer Resources
[3] WP_Posts_List_Table::column_date() – WordPress Developer Resources