Log PHP 8 Berisik? Tiga Fungsi Lama Ini Biang Keroknya

Log pluginmu tiba-tiba penuh Deprecated, padahal fitur masih jalan? Biasanya bukan karena WordPress rusak. Seringnya, kode legacy masih memanggil strftime(), utf8_encode(), atau utf8_decode() setelah server naik ke PHP 8.1, 8.2, atau 8.3.

Kenapa Deprecated Ini Sering Muncul di Plugin WordPress Lama?

Banyak plugin lama lahir saat PHP 5.x masih umum. Saat itu, strftime() terasa praktis untuk format tanggal lokal, sementara utf8_encode() dan utf8_decode() sering dipakai sebagai “obat cepat” untuk teks aneh.

Namun, PHP modern makin ketat. Akibatnya, helper lama yang dulu aman sekarang memicu warning. Selain itu, warning ini sering muncul di admin screen, cron, import CSV, email template, dan integrasi API.

Kalau kamu maintain plugin legacy, fokusmu bukan cuma menghilangkan noise. Kamu juga perlu menjaga output tetap sama, terutama untuk user lintas locale.

Peta Cepat: Fungsi Lama, Pengganti Aman

• strftime() → IntlDateFormatter, atau wp_date() untuk konteks WordPress.
• utf8_encode() → mb_convert_encoding($text, 'UTF-8', 'ISO-8859-1').
• utf8_decode() → mb_convert_encoding($text, 'ISO-8859-1', 'UTF-8').
• Encoding tidak jelas → deteksi sumber data dulu, baru konversi.

Mengganti strftime() Tanpa Merusak Format Lokal

strftime() deprecated sejak PHP 8.1 karena bergantung pada locale sistem. Ini bikin hasil tanggal bisa beda antara laptop dev, shared hosting, dan container CI.

Untuk WordPress, pilihan paling ringan biasanya wp_date(). Fungsi ini mengikuti timezone situs dan cocok untuk format sederhana.

// Lama
$label = strftime('%d %B %Y', $timestamp);

// WordPress-friendly
$label = wp_date('d F Y', $timestamp);

Namun, kalau kamu butuh locale spesifik seperti id_ID, IntlDateFormatter lebih stabil. Dokumentasi resminya bisa kamu cek di PHP IntlDateFormatter.

$formatter = new IntlDateFormatter(
    'id_ID',
    IntlDateFormatter::LONG,
    IntlDateFormatter::NONE,
    wp_timezone_string(),
    IntlDateFormatter::GREGORIAN,
    'd MMMM yyyy'
);

$label = $formatter->format($timestamp);

Tip Praktis untuk Plugin Publik

Jangan langsung replace semua strftime() dengan pattern yang tampak mirip. Token format strftime dan date berbeda. Karena itu, buat mapping kecil untuk format yang pluginmu benar-benar pakai.

Dengan cara ini, kamu menghindari regresi diam-diam seperti bulan berubah angka, nama hari hilang, atau timezone meleset.

Mengganti utf8_encode() dan utf8_decode() dengan Benar

Bagian ini sering bikin bug halus. Banyak developer mengira utf8_encode() berarti “jadikan teks valid UTF-8”. Padahal, fungsi ini hanya mengonversi dari ISO-8859-1 ke UTF-8.

Jadi, kalau sumber datamu Windows-1252, Shift-JIS, atau sudah UTF-8, hasilnya bisa kacau. Karakter kutip pintar, simbol euro, dan aksen nama orang sering jadi korban.

// Lama
$name = utf8_encode($raw_name);

// Lebih eksplisit
$name = mb_convert_encoding($raw_name, 'UTF-8', 'ISO-8859-1');

Untuk arah sebaliknya:

// Lama
$legacy = utf8_decode($value);

// Lebih eksplisit
$legacy = mb_convert_encoding($value, 'ISO-8859-1', 'UTF-8');

Referensi deprecation bisa kamu lihat di dokumentasi resmi utf8_encode dan strftime.

Framework 3 Lapisan: Cari, Bungkus, Baru Ganti

Ini pendekatan yang lebih aman daripada “search and replace Jumat sore”. Pertama, cari semua pemakaian fungsi deprecated. Kedua, bungkus dengan helper internal. Ketiga, ganti implementasi helper sambil menambah test.

1. Cari Semua Titik Panggil

grep -R "strftime\|utf8_encode\|utf8_decode" wp-content/plugins/plugin-mu/

Setelah itu, kelompokkan berdasarkan konteks: tanggal UI, nama file, import CSV, API response, email, atau export.

2. Buat Helper Kompatibilitas

function pluginmu_to_utf8($value, $from = 'ISO-8859-1') {
    if (! is_string($value) || $value === '') {
        return $value;
    }

    return mb_convert_encoding($value, 'UTF-8', $from);
}

Helper membuat migrasi lebih terkendali. Selain itu, kamu bisa menambahkan fallback kalau extension mbstring belum aktif di server user.

3. Test Output, Bukan Sekadar Warning

Jangan cuma puas karena warning hilang. Test karakter nyata seperti José, François, €, dan nama bulan Indonesia.

Checklist Migrasi untuk Maintainer Plugin

• Audit semua strftime, utf8_encode, dan utf8_decode.
• Pilih wp_date() untuk format tanggal WordPress sederhana.
• Pakai IntlDateFormatter untuk locale spesifik.
• Tentukan charset sumber sebelum konversi encoding.
• Tambahkan PHPUnit test untuk karakter non-ASCII.
• Jalankan test matrix PHP 8.1, 8.2, 8.3, dan 8.4.
• Catat perubahan di changelog agar user tahu update ini fokus kompatibilitas.

Kalau kamu juga sedang membersihkan warning lain, baca panduan terkait: membersihkan dynamic property PHP 8.2, test matrix plugin WordPress untuk PHP 8.4, dan jalur aman upgrade PHP WordPress.

FAQ

Apakah strftime() langsung fatal di PHP 8?

Belum tentu. Di PHP 8.1, fungsi ini memicu deprecated warning. Namun, membiarkannya berarti kamu menunda masalah sampai versi PHP berikutnya atau konfigurasi error reporting lebih ketat.

Apakah wp_date() selalu cukup untuk mengganti strftime()?

Cukup untuk banyak format tanggal WordPress. Namun, kalau pluginmu butuh locale spesifik dan format kompleks, gunakan IntlDateFormatter.

Kenapa utf8_encode() berbahaya untuk migrasi cepat?

Karena fungsi ini mengasumsikan input ISO-8859-1. Jika inputmu bukan ISO-8859-1, hasil konversi bisa rusak walau warning hilang.

Haruskah plugin mewajibkan mbstring?

Idealnya iya untuk fitur encoding serius. Namun, jika target user memakai hosting lama, sediakan fallback iconv() dan tampilkan admin notice yang jelas.

Bersihkan Sekarang, Jangan Tunggu Hosting Memaksa

Deprecated warning bukan kosmetik. Ia adalah sinyal bahwa kode lama mulai keluar dari jalur aman PHP modern. Dengan mengganti PHP 8 deprecated functions secara terukur, pluginmu jadi lebih tenang di log, lebih mudah dites, dan lebih siap untuk rilis berikutnya.

Mau checklist teknis seperti ini langsung masuk inbox? Daftar newsletter Google kami di bawah, lalu simpan artikel ini untuk audit plugin berikutnya.