Cara Memperbaiki Error “The Link You Followed Has Expired” di WordPress

Kesalahan "The link you followed has expired" di WordPress dipicu ketika unggahan file atau pengiriman formulir melebihi satu atau lebih batas runtime PHP — khususnya upload_max_filesize, post_max_size, max_execution_time, atau memory_limit. WordPress tidak dapat memulihkan diri dari penolakan sisi server ini, sehingga menampilkan pesan generik ini alih-alih kesalahan PHP yang spesifik.

Perbaikannya memerlukan peningkatan nilai direktif PHP tersebut melalui lapisan konfigurasi mana pun yang diekspos oleh lingkungan hosting Anda: php.ini, .htaccess, wp-config.php, atau antarmuka panel kontrol. Metode mana yang berhasil sepenuhnya bergantung pada tingkat akses server Anda — akses SSH root, cPanel terkelola, atau lingkungan shared yang terkunci masing-masing memerlukan pendekatan yang berbeda.

Mengapa Kesalahan Ini Sebenarnya Terjadi

Memahami akar penyebabnya mencegah Anda menerapkan perbaikan yang salah. Ketika WordPress memproses unggahan, browser mengirimkan permintaan POST multipart ke wp-admin/async-upload.php atau wp-admin/update.php. PHP mengevaluasi permintaan terhadap empat batas independen sebelum WordPress menjalankan satu baris kode aplikasi pun:

• upload_max_filesize — batas atas untuk setiap file yang diunggah
• post_max_size — batas atas untuk seluruh isi POST, yang harus *lebih besar* dari upload_max_filesize
• max_execution_time — maksimum detik waktu nyata yang boleh dijalankan oleh proses PHP
• memory_limit — RAM yang tersedia untuk proses PHP; pemrosesan gambar dan instalasi tema membutuhkan banyak memori

Jika salah satu dari batas ini dilanggar, PHP secara diam-diam menghentikan permintaan. WordPress menerima respons kosong atau tidak valid dan menampilkan "The link you followed has expired." Kesalahan ini bukan bug WordPress — ini adalah PHP yang menerapkan kebijakan server.

Pemicu umum dalam praktik:

• Menginstal tema premium (sering 5–30 MB) di shared host dengan batas unggahan default 2 MB
• Mengunggah file impor CSV produk WooCommerce
• Menginstal bundel plugin yang menyertakan aset bawaan
• Memulihkan situs dari arsip cadangan melalui dasbor WordPress
• Menjalankan skrip impor yang berjalan lama hingga mencapai batas waktu eksekusi

Tabel Referensi Cepat Direktif PHP

Aturan penting: post_max_size harus selalu diatur lebih tinggi dari upload_max_filesize. Jika Anda mengatur upload_max_filesize = 128M tetapi membiarkan post_max_size = 8M, unggahan akan tetap gagal karena batas isi POST tercapai lebih dulu.

Metode 1: Edit php.ini (Direkomendasikan untuk VPS dan Server Dedicated)

Ini adalah metode yang paling andal dan permanen. Di lingkungan VPS Hosting atau Dedicated Server di mana Anda memiliki akses root atau sudo, Anda mengontrol konfigurasi PHP secara langsung.

Temukan file php.ini yang aktif:

php --ini | grep "Loaded Configuration File"

Atau dari dalam situs WordPress, buat file sementara:

<?php phpinfo(); ?>

Cari baris Loaded Configuration File pada output, lalu segera hapus file tersebut setelahnya.

Edit direktif:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Setelah menyimpan, restart PHP-FPM atau Apache untuk menerapkan perubahan:

# For PHP-FPM (most common on modern stacks)
sudo systemctl restart php8.2-fpm

# For Apache with mod_php
sudo systemctl restart apache2

# For Nginx + PHP-FPM
sudo systemctl restart nginx php8.2-fpm

Verifikasi bahwa nilai baru telah berlaku:

php -r "echo ini_get('upload_max_filesize');"

Kasus khusus yang perlu diketahui: Pada server yang menjalankan beberapa versi PHP (pengaturan umum di cPanel), terdapat php.ini terpisah untuk setiap versi. Mengedit yang salah tidak akan berpengaruh. Konfirmasikan versi PHP mana yang digunakan WordPress sebelum mengedit.

Metode 2: Gunakan .htaccess (Shared Hosting Apache)

Jika Anda menggunakan shared hosting tanpa akses php.ini langsung, dan server Anda menjalankan Apache dengan mod_php atau suPHP, Anda dapat mengganti direktif PHP per direktori menggunakan .htaccess.

Akses direktori root WordPress Anda melalui FTP, SFTP, atau file manager hosting Anda. Buka .htaccess dan tambahkan blok berikut:

<IfModule mod_php.c>
    php_value upload_max_filesize 128M
    php_value post_max_size 256M
    php_value max_execution_time 300
    php_value max_input_time 300
    php_value memory_limit 256M
</IfModule>

Simpan dan unggah file, lalu uji unggahan Anda.

Peringatan penting:

• Metode ini tidak berfungsi pada server yang menjalankan PHP-FPM, CGI, atau FastCGI. Pada stack tersebut, direktif php_value di .htaccess akan menyebabkan 500 Internal Server Error karena modul Apache yang menangani PHP bukan mod_php. Jika Anda melihat 500 setelah menyimpan, segera hapus baris-baris tersebut.
• Pada server Nginx, .htaccess diabaikan sepenuhnya. Gunakan php.ini atau file override pengguna php.ini sebagai gantinya.
• Beberapa host terkelola secara eksplisit menonaktifkan AllowOverride untuk direktif PHP, membuat metode ini tidak efektif bahkan di Apache.

Metode 3: Tambahkan Direktif ke wp-config.php

Metode ini menggunakan fungsi ini_set() PHP untuk mengganti direktif saat runtime. Metode ini berfungsi terlepas dari jenis web server, tetapi tunduk pada pembatasan open_basedir dan disable_functions host — beberapa host memblokir ini_set() karena alasan keamanan.

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

@ini_set( 'upload_max_size',    '128M' );
@ini_set( 'post_max_size',      '256M' );
@ini_set( 'max_execution_time', '300'  );
@ini_set( 'max_input_time',     '300'  );
@ini_set( 'memory_limit',       '256M' );

@ menekan kesalahan jika ini_set() dinonaktifkan, mencegah layar putih. Namun, jika host telah mengunci nilai-nilai ini di tingkat server menggunakan php_admin_value, panggilan ini_set() diabaikan secara diam-diam — nilai tidak akan berubah.

Cara memverifikasi bahwa ini benar-benar berhasil:

Instal plugin gratis Query Monitor dan periksa tab lingkungan PHP, atau tambahkan panggilan phpinfo() sementara. Jika nilai masih menampilkan batas lama, ini_set() sedang diganti di tingkat yang lebih tinggi dan Anda perlu menggunakan metode yang berbeda.

Metode 4: Sesuaikan Pengaturan PHP di cPanel

Untuk lingkungan hosting yang dikelola melalui cPanel — termasuk VPS dengan cPanel — Anda dapat memodifikasi batas PHP melalui antarmuka grafis tanpa menyentuh file apa pun.

Langkah-langkah:

1. Masuk ke cPanel.
2. Navigasi ke Software dan klik MultiPHP INI Editor.
3. Pilih document root situs WordPress Anda dari dropdown.
4. Temukan dan perbarui kolom berikut:

• upload_max_filesize → 128M
• post_max_size → 256M
• max_execution_time → 300
• memory_limit → 256M

1. Klik Apply.

Sebagai alternatif, gunakan Select PHP Version (PHP Selector) jika host Anda menggunakan CloudLinux. Di bawah tab Options, direktif yang sama tersedia sebagai slider atau kolom input.

Apa yang sebenarnya dilakukan cPanel di balik layar: Ini menulis file .user.ini (untuk PHP-FPM) atau memodifikasi .htaccess (untuk mod_php) di document root Anda. Jika Anda kemudian mengedit file-file tersebut secara manual, Anda mungkin menimpa perubahan cPanel — waspadai konflik ini.

Metode 5: Buat atau Edit File .user.ini (Lingkungan PHP-FPM)

Ini adalah metode yang paling sering diabaikan oleh tutorial, namun merupakan pendekatan yang tepat untuk PHP-FPM — yang merupakan handler PHP default di hampir setiap stack hosting modern, termasuk lingkungan berbasis Nginx.

Buat file bernama .user.ini di direktori root WordPress Anda dengan konten berikut:

upload_max_filesize = 128M
post_max_size = 256M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

Unggah ke direktori yang sama dengan wp-config.php. PHP-FPM memindai file .user.ini secara berkala — TTL cache dikontrol oleh user_ini.cache_ttl, yang defaultnya adalah 300 detik (5 menit). Perubahan tidak langsung berlaku. Jika Anda membutuhkan efek segera, restart PHP-FPM.

sudo systemctl restart php8.2-fpm

Catatan keamanan: File .user.ini tidak boleh dapat diakses melalui web. Tambahkan ini ke .htaccess jika Anda menggunakan Apache:

<Files ".user.ini">
    Require all denied
</Files>

Di Nginx, tambahkan blok location untuk menolak akses:

location ~ /.user.ini {
    deny all;
}

Metode 6: Hubungi Penyedia Hosting Anda

Jika tidak ada metode di atas yang menghasilkan perubahan pada nilai PHP yang Anda verifikasi dengan phpinfo() atau Query Monitor, host menerapkan batas di tingkat pool PHP-FPM atau melalui direktif php_admin_value dalam konfigurasi server — keduanya tidak dapat diganti oleh file yang dapat diakses pengguna mana pun.

Dalam hal ini, hubungi dukungan dan minta peningkatan spesifik. Berikan nama direktif yang tepat dan nilai target. Jika host menolak atau memberlakukan batas atas yang tidak memenuhi kebutuhan Anda, pertimbangkan untuk bermigrasi ke paket VPS Hosting di mana Anda sepenuhnya mengontrol konfigurasi PHP.

Mendiagnosis Batas Mana yang Sebenarnya Memicu Kesalahan

Daripada menebak-nebak, gunakan langkah diagnostik ini sebelum menerapkan perbaikan apa pun:

Periksa batas PHP saat ini dari baris perintah:

php -r "echo 'upload_max_filesize: ' . ini_get('upload_max_filesize') . PHP_EOL;
echo 'post_max_size: ' . ini_get('post_max_size') . PHP_EOL;
echo 'max_execution_time: ' . ini_get('max_execution_time') . PHP_EOL;
echo 'memory_limit: ' . ini_get('memory_limit') . PHP_EOL;"

Periksa log kesalahan PHP untuk kegagalan yang sebenarnya:

tail -n 50 /var/log/php/error.log
# or
tail -n 50 /var/log/apache2/error.log

Cari baris yang mengandung Allowed memory size, Maximum execution time, atau POST Content-Length. Pesan spesifik memberi tahu Anda dengan tepat direktif mana yang perlu ditargetkan.

Periksa ukuran file yang Anda unggah terhadap upload_max_filesize saat ini. Jika file berukuran 45 MB dan batasnya adalah 64 MB, batas unggahan bukan masalahnya — lihat post_max_size atau memory_limit sebagai gantinya.

Memilih Metode yang Tepat: Matriks Keputusan

Daftar Periksa Teknis Utama Sebelum Menganggap Masalah Terselesaikan

• post_max_size diatur lebih tinggi dari upload_max_filesize — ini adalah miskonfigurasi yang paling umum
• Perubahan telah diverifikasi dengan phpinfo() atau php -r "echo ini_get(...)" — bukan hanya diasumsikan
• PHP-FPM di-restart jika .user.ini atau php.ini diedit secara langsung
• .user.ini atau php.ini yang diedit sesuai dengan versi PHP yang sebenarnya melayani situs WordPress
• memory_limit minimal 256M jika Anda menginstal tema besar atau menjalankan operasi yang banyak menggunakan gambar
• Log kesalahan telah diperiksa untuk mengonfirmasi batas spesifik mana yang menyebabkan penghentian
• Jika menggunakan paket Shared Web Hosting, batas atas host telah dikonfirmasi — beberapa penyedia membatasi upload_max_filesize pada 64M terlepas dari pengaturan pengguna
• Setelah memperbaiki kesalahan unggahan, verifikasi bahwa SSL Certificates Anda valid jika Anda mengakses wp-admin melalui HTTPS, karena kesalahan mixed-content atau sertifikat dapat menghasilkan kegagalan redirect yang tampak serupa

FAQ

Mengapa kesalahan muncul meskipun saya sudah meningkatkan upload_max_filesize di .htaccess?

Server kemungkinan menjalankan PHP melalui FastCGI atau PHP-FPM daripada mod_php. Direktif php_value di .htaccess hanya diproses oleh handler mod_php Apache. Pada stack PHP-FPM, gunakan file .user.ini di direktori root WordPress sebagai gantinya.

Apa perbedaan antara upload_max_filesize dan post_max_size, dan mengapa keduanya penting?

upload_max_filesize membatasi ukuran setiap file individual dalam unggahan multipart. post_max_size membatasi total ukuran seluruh isi permintaan POST, yang mencakup data file ditambah kolom formulir dan batas. Jika post_max_size lebih kecil dari upload_max_filesize, batas isi POST tercapai lebih dulu dan PHP membuang seluruh permintaan sebelum WordPress dapat mengevaluasi ukuran file.

Panggilan ini_set() saya di wp-config.php diabaikan. Mengapa?

Host menggunakan php_admin_value dalam konfigurasi pool PHP-FPM atau blok virtual host Apache. php_admin_value menetapkan direktif sebagai hanya-baca dari perspektif aplikasi — panggilan ini_set() untuk direktif tersebut diabaikan secara diam-diam. Hanya penyedia hosting yang dapat mengubah nilai yang ditetapkan dengan cara ini.

Bagaimana cara memverifikasi bahwa perubahan konfigurasi PHP saya benar-benar berlaku?

Buat file sementara di root WordPress Anda yang berisi <?php phpinfo(); ?>, akses melalui browser, dan cari nama direktif. Kolom Local Value menampilkan nilai efektif untuk direktori tersebut. Hapus file segera setelah memeriksa — membiarkan output phpinfo() dapat diakses publik merupakan risiko keamanan.

Apakah kesalahan ini bisa disebabkan oleh sesuatu selain batas unggahan PHP?

Ya. Kedaluwarsa nonce WordPress dapat menghasilkan pesan yang sama. Nonce WordPress valid selama 24 jam secara default. Jika pengguna membuka halaman unggahan plugin, membiarkannya tidak aktif selama lebih dari 24 jam, lalu mengirimkan formulir, validasi nonce gagal dan WordPress menampilkan "The link you followed has expired." Dalam hal ini, cukup menyegarkan halaman akan menghasilkan nonce baru dan unggahan berjalan normal — tidak diperlukan perubahan konfigurasi PHP.