Cara Memperbaiki Error max_execution_time di WordPress

Kesalahan max_execution_time di WordPress terjadi ketika skrip PHP melampaui durasi eksekusi maksimum yang dikonfigurasi di tingkat server. PHP menghentikan skrip dan mengembalikan fatal error, yang ditampilkan WordPress sebagai layar putih, pemberitahuan timeout, atau pesan eksplisit "Maximum execution time exceeded".

Secara default, sebagian besar lingkungan shared hosting memberlakukan batas 30 detik. Operasi seperti mengimpor CSV produk WooCommerce, menjalankan backup seluruh situs, atau menginstal bundel plugin besar dapat dengan mudah melampaui batas ini. Menaikkan batas — melalui php.ini, .htaccess, wp-config.php, atau lapisan plugin WordPress — menyelesaikan kesalahan tanpa mengorbankan stabilitas server jika dilakukan dengan benar.

Memahami Mengapa Batas Ini Ada dan Kapan Menjadi Masalah

Direktif max_execution_time PHP adalah mekanisme perlindungan sumber daya, bukan pembatasan sembarangan. Ini mencegah skrip yang tidak terkendali memonopoli waktu CPU pada kumpulan proses bersama, yang sangat penting pada infrastruktur multi-tenant.

Batas ini menjadi hambatan nyata dalam skenario berikut:

• Impor atau ekspor database besar melalui phpMyAdmin atau WP-CLI yang memproses ribuan baris
• Instalasi plugin atau tema yang mengekstrak arsip melebihi 50 MB
• Operasi massal WooCommerce — pembaruan harga, sinkronisasi inventaris, ekspor pesanan
• Migrasi seluruh situs menggunakan alat seperti Duplicator atau All-in-One WP Migration
• Cron job terjadwal yang mengumpulkan data dari API eksternal
• Plugin optimasi gambar yang memproses ratusan unggahan yang belum dioptimalkan dalam satu batch

Nuansa penting yang diabaikan sebagian besar panduan: max_execution_time mengukur waktu CPU yang dikonsumsi oleh proses PHP, bukan waktu nyata. Pada server yang sangat sibuk, sebuah skrip dapat berjalan selama 90 detik waktu nyata sambil hanya mengonsumsi 28 detik waktu CPU dan tidak pernah memicu batas. Sebaliknya, loop yang intensif CPU mencapai batas lebih cepat dari yang diharapkan. Perbedaan ini penting saat mendiagnosis timeout yang tidak konsisten.

Cara Memverifikasi Nilai max_execution_time Anda Saat Ini

Sebelum mengubah apa pun, konfirmasi batas yang aktif. Buat file sementara di root WordPress Anda — jangan pernah biarkan dapat diakses publik setelah pengujian:

<?php
phpinfo();

Unggah sebagai phpinfo-test.php, kunjungi https://yourdomain.com/phpinfo-test.php, dan cari max_execution_time di output. Hapus file segera setelah memeriksa.

Atau, gunakan WP-CLI dari SSH:

wp eval 'echo ini_get("max_execution_time");'

Ini mengembalikan nilai yang saat ini aktif untuk permintaan WordPress, yang mungkin berbeda dari php.ini global server jika override per-direktori sudah ada.

Metode 1: Edit File php.ini (Paling Andal)

Memodifikasi php.ini adalah metode paling otoritatif karena menetapkan direktif di tingkat interpreter PHP, tidak menimpa apa pun dan tidak ditimpa oleh apa pun di bawahnya dalam hierarki konfigurasi — kecuali panggilan ini_set() berikutnya menggantikannya saat runtime.

Langkah 1: Temukan File php.ini yang Benar

Di sinilah sebagian besar administrator membuat kesalahan. PHP dapat memuat beberapa file .ini tergantung pada SAPI (Server API) yang digunakan:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — digunakan oleh WP-CLI dan cron job
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — digunakan oleh stack Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — digunakan oleh Apache dengan modul PHP

Mengedit php.ini CLI akan memperbaiki timeout WP-CLI tetapi tidak akan memengaruhi permintaan yang dipicu browser. Selalu identifikasi SAPI yang benar terlebih dahulu:

php -i | grep "Loaded Configuration File"

Untuk permintaan web, periksa output phpinfo() di bawah Loaded Configuration File.

Langkah 2: Edit atau Buat php.ini di Web Root

Pada shared hosting di mana Anda tidak memiliki akses root, Anda dapat menempatkan php.ini tingkat pengguna di direktori root situs Anda (public_html). Akses melalui cPanel File Manager, FTP, atau SSH:

nano ~/public_html/php.ini

Tambahkan atau perbarui direktif:

max_execution_time = 300

300 detik (5 menit) sudah cukup untuk sebagian besar operasi. Untuk migrasi yang sangat besar, pertimbangkan 600 detik untuk sementara, lalu kembalikan setelah tugas selesai.

Langkah 3: Verifikasi Perubahan Berlaku

Setelah menyimpan, jalankan kembali pemeriksaan phpinfo() atau perintah WP-CLI dari sebelumnya. Jika nilai belum berubah, host Anda mungkin memberlakukan batas keras melalui max_execution_time di php.ini tingkat server yang menggantikan file tingkat pengguna Anda. Dalam hal ini, lanjutkan ke Metode 4.

Langkah 4: Restart PHP-FPM (VPS dan Server Dedicated)

Pada VPS atau server dedicated di mana Anda mengontrol lingkungan, restart PHP-FPM diperlukan agar perubahan diterapkan pada permintaan web:

sudo systemctl restart php8.2-fpm

Ganti php8.2-fpm dengan versi PHP yang terinstal. Apache dengan mod_php memerlukan reload Apache sebagai gantinya:

sudo systemctl reload apache2

Metode 2: Edit File .htaccess (Khusus Apache)

Metode .htaccess bekerja secara eksklusif pada server Apache di mana AllowOverride mengizinkan direktif konfigurasi PHP. Metode ini tidak bekerja pada Nginx, LiteSpeed dengan konfigurasi tertentu, atau stack apa pun di mana PHP berjalan sebagai FastCGI/FPM dengan AllowOverride None.

Langkah 1: Tampilkan dan Akses File .htaccess

File .htaccess tersembunyi secara default. Di cPanel File Manager, klik Settings di sudut kanan atas dan aktifkan Show Hidden Files (dotfiles). File ini berada di public_html.

Melalui SSH:

nano ~/public_html/.htaccess

Langkah 2: Tambahkan Direktif PHP

Sisipkan baris berikut. Posisi penting — tempatkan di luar blok <IfModule> mana pun untuk memastikan berlaku secara global:

php_value max_execution_time 300

Jika server Anda menjalankan PHP-FPM (dapat diidentifikasi dengan PHP/x.x.x (fpm-fcgi) di phpinfo()), direktif ini akan menyebabkan 500 Internal Server Error karena php_value tidak valid dalam konteks tersebut. Gunakan php_admin_value hanya jika host secara eksplisit mengizinkannya, atau beralih ke Metode 1.

Langkah 3: Uji untuk Error 500

Setelah menyimpan, segera muat halaman beranda Anda. Error 500 berarti direktif tidak kompatibel dengan konfigurasi server Anda. Hapus baris tersebut dan gunakan metode alternatif.

Metode 3: Edit wp-config.php Menggunakan set_time_limit()

Fungsi set_time_limit() mereset timer eksekusi dari titik dipanggil. Ini adalah panggilan runtime PHP, bukan direktif konfigurasi, yang berarti bekerja terlepas dari apakah server mengizinkan override php.ini atau .htaccess — selama daftar disable_functions PHP tidak menyertakannya.

Langkah 1: Temukan wp-config.php

File ini berada di root instalasi WordPress, satu level di atas public_html pada beberapa konfigurasi server, atau langsung di dalamnya pada konfigurasi lain.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Langkah 2: Tambahkan Direktif

Buka wp-config.php dan tambahkan baris berikut sebelum komentar /* That's all, stop editing! Happy publishing. */:

set_time_limit(300);

Memanggil set_time_limit(0) menonaktifkan batas sepenuhnya untuk permintaan tersebut. Gunakan ini hanya sebagai tindakan diagnostik sementara — tidak pernah dalam produksi — karena menghilangkan jaring pengaman terhadap infinite loop.

Catatan penting: set_time_limit() hanya memengaruhi eksekusi skrip saat ini. Ini tidak mengubah konfigurasi PHP di seluruh server. Jika plugin secara internal menjalankan subprocess atau membuat permintaan HTTP yang memblokir, subprocess tersebut tidak tercakup oleh panggilan ini.

Metode 4: Gunakan Plugin WordPress

Bagi pengguna yang lebih memilih untuk tidak mengedit file server secara langsung, beberapa plugin mengekspos nilai konfigurasi PHP melalui antarmuka admin WordPress. Pendekatan ini cocok untuk pemilik situs non-teknis pada hosting terkelola.

Opsi yang direkomendasikan:

• WP Maximum Execution Time Exceeded — secara khusus menargetkan kesalahan ini dan mencoba beberapa metode override
• PHP Settings — menyediakan tampilan dashboard direktif PHP aktif dan memungkinkan override aman di mana host mengizinkan

Untuk menginstal: navigasikan ke Plugins > Add New di dashboard WordPress, cari nama plugin, instal, dan aktifkan. Ikuti halaman pengaturan plugin untuk menetapkan waktu eksekusi yang diinginkan.

Keterbatasan: Plugin hanya dapat memanggil set_time_limit() atau ini_set() saat runtime. Jika host telah mengunci max_execution_time melalui pembatasan open_basedir atau konfigurasi server yang dikodekan keras, plugin akan gagal meningkatkan batas tanpa pemberitahuan. Selalu verifikasi perubahan menggunakan phpinfo() setelah mengaktifkan.

Metode 5: Hubungi Penyedia Hosting Anda

Jika tidak ada metode di atas yang menghasilkan perubahan terverifikasi dalam output phpinfo(), batas diberlakukan di tingkat server oleh host Anda. Ini umum pada paket shared hosting tingkat dasar di mana penyedia menetapkan batas keras untuk melindungi sumber daya bersama.

Saat menghubungi dukungan, berikan:

• Pesan kesalahan yang tepat dan tindakan WordPress yang memicunya
• Nilai max_execution_time saat ini dari phpinfo()
• Nilai yang Anda butuhkan (misalnya, 300 detik) dan alasannya (misalnya, impor WooCommerce besar)

Host terpercaya akan menyesuaikan batas untuk akun Anda atau mengarahkan Anda ke opsi panel kontrol (seperti pemilih PHP di cPanel) di mana Anda dapat mengonfigurasinya sendiri.

Perbandingan Semua Lima Metode

Mendiagnosis Timeout Persisten Setelah Menaikkan Batas

Jika Anda telah mengonfirmasi batas baru aktif di phpinfo() tetapi kesalahan tetap ada, kemungkinan hambatannya bukan max_execution_time. Pertimbangkan penyebab alternatif berikut:

Direktif timeout FastCGI atau Nginx — Nginx memiliki direktif fastcgi_read_timeout-nya sendiri, terpisah dari PHP:

fastcgi_read_timeout 300;

Ini harus diatur di blok server Nginx dan memerlukan reload Nginx.

Direktif TimeOut Apache — Timeout koneksi Apache sendiri dapat menghentikan permintaan sebelum batas PHP tercapai:

TimeOut 300

request_terminate_timeout PHP-FPM — Dalam konfigurasi pool PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf), direktif ini secara independen mematikan proses worker:

request_terminate_timeout = 300

wait_timeout dan interactive_timeout MySQL — Kueri database yang berjalan lama dapat menyebabkan koneksi MySQL terputus di tengah eksekusi, yang ditampilkan PHP sebagai kegagalan skrip bukan kesalahan database. Periksa dengan:

SHOW VARIABLES LIKE '%timeout%';

Timeout tingkat WooCommerce atau plugin — Beberapa plugin mengimplementasikan logika timeout internal mereka sendiri menggunakan set_time_limit() PHP dengan nilai yang lebih rendah, yang mereset penghitung dan dapat menimpa konfigurasi Anda.

Pertimbangan Performa dan Praktik Terbaik

Menaikkan max_execution_time adalah perbaikan yang ditargetkan, bukan solusi arsitektur permanen. Jika operasi tertentu secara rutin melebihi 30–60 detik, proses yang mendasarinya harus dioptimalkan atau direstrukturisasi:

• Pemrosesan batch: Pecah impor besar menjadi potongan lebih kecil menggunakan chunking berbasis AJAX (seperti yang dilakukan WP All Import secara native) daripada memproses semuanya dalam satu permintaan HTTP
• Pemrosesan latar belakang: Gunakan WP-Cron atau antrean tugas yang tepat (Action Scheduler, digunakan oleh WooCommerce) untuk memindahkan pekerjaan yang berjalan lama dari siklus hidup permintaan web
• WP-CLI untuk operasi massal: Eksekusi CLI tidak tunduk pada timeout server web dan merupakan alat yang tepat untuk impor database, operasi search-replace, dan pemrosesan media massal
• Optimalkan kueri lambat: Gunakan plugin Query Monitor untuk mengidentifikasi kueri database yang mengonsumsi waktu eksekusi yang tidak proporsional
• Tingkatkan tier hosting: Jika beban kerja Anda secara konsisten memerlukan waktu eksekusi yang diperpanjang, VPS dengan cPanel memberi Anda kontrol penuh atas konfigurasi PHP dan sumber daya dedicated yang tidak bersaing dengan tenant lain

Untuk beban kerja komputasi tinggi seperti rekomendasi produk berbasis AI atau pipeline pemrosesan gambar skala besar, GPU hosting memindahkan komputasi intensif sepenuhnya dari lapisan PHP.

Daftar Periksa Keputusan Praktis

Gunakan daftar periksa ini sebelum dan sesudah menerapkan perbaikan apa pun:

• Konfirmasi nilai max_execution_time saat ini melalui phpinfo() atau WP-CLI sebelum membuat perubahan
• Identifikasi stack server Anda (Apache + mod_php, Apache + FPM, Nginx + FPM) sebelum memilih metode
• Terapkan hanya satu metode pada satu waktu — menumpuk perubahan php.ini, .htaccess, dan wp-config.php secara bersamaan membuat debugging tidak mungkin dilakukan
• Setelah menerapkan perubahan, verifikasi ulang nilai aktif di phpinfo() — jangan asumsikan perubahan berhasil
• Uji dengan mereproduksi tindakan yang gagal sebelumnya, bukan hanya dengan memuat halaman beranda
• Jika kesalahan teratasi, pertimbangkan apakah operasi yang mendasarinya dapat dioptimalkan untuk berjalan dalam batas asli
• Atur pengingat kalender untuk mengembalikan peningkatan batas sementara (misalnya, set_time_limit(0)) setelah tugas satu kali selesai
• Pada shared hosting, dokumentasikan apa yang dikonfirmasi host sebagai nilai maksimum yang diizinkan untuk paket Anda
• Jika timeout tetap ada setelah mengonfirmasi batas PHP dinaikkan, audit fastcgi_read_timeout Nginx, TimeOut Apache, dan request_terminate_timeout PHP-FPM secara independen

FAQ

Berapa nilai paling aman untuk diatur pada max_execution_time di WordPress?

300 detik (5 menit) mencakup sebagian besar operasi WordPress yang intensif sumber daya termasuk instalasi plugin besar, impor WooCommerce, dan pembaruan tema. Nilai di atas 600 detik harus diperlakukan sebagai sementara dan dikembalikan setelah tugas tertentu selesai.

Mengapa perubahan max_execution_time saya tidak muncul di phpinfo() setelah mengedit php.ini?

Anda kemungkinan besar mengedit file php.ini yang salah. PHP memuat file konfigurasi yang berbeda untuk CLI, Apache mod_php, dan PHP-FPM. Jalankan php -i | grep "Loaded Configuration File" untuk CLI dan periksa baris Loaded Configuration File di halaman phpinfo() yang dapat diakses browser untuk mengidentifikasi file yang benar untuk permintaan web.

Apakah menaikkan max_execution_time memengaruhi semua pengguna di server saya?

Pada server bersama, mengedit php.ini tingkat pengguna di web root Anda hanya memengaruhi akun Anda. Mengedit php.ini server global (yang memerlukan akses root) memengaruhi semua proses PHP di server tersebut. Pada server dedicated, Anda mengontrol konfigurasi global dan bertanggung jawab penuh atas dampaknya.

Apakah metode .htaccess bekerja pada server Nginx?

Tidak. File .htaccess adalah mekanisme khusus Apache. Nginx tidak memproses file .htaccess. Pada stack Nginx + PHP-FPM, Anda harus mengedit konfigurasi pool PHP-FPM atau php.ini tingkat server, keduanya memerlukan akses SSH.

Bisakah plugin WordPress secara permanen meningkatkan max_execution_time?

Tidak. Plugin dieksekusi dalam runtime PHP dan hanya dapat memanggil set_time_limit() atau ini_set(), yang hanya memengaruhi permintaan saat ini. Plugin tidak dapat menulis ke php.ini atau mempertahankan perubahan konfigurasi lintas permintaan. Untuk peningkatan permanen, Anda harus memodifikasi php.ini, .htaccess, atau file konfigurasi pool PHP-FPM di tingkat server.