WordPress’te max_execution_time Hatası Nasıl Düzeltilir

WordPress’teki max_execution_time hatası, bir PHP betiğinin sunucu düzeyinde yapılandırılmış maksimum yürütme süresini aşması durumunda ortaya çıkar. PHP betiği sonlandırır ve ölümcül bir hata döndürür; WordPress bunu beyaz ekran, zaman aşımı bildirimi veya açık bir "Maximum execution time exceeded" mesajı olarak gösterir.

Varsayılan olarak, çoğu paylaşımlı barındırma ortamı 30 saniyelik bir sınır uygular. WooCommerce ürün CSV’si içe aktarma, tam site yedekleme veya büyük bir eklenti paketi yükleme gibi işlemler bu sınırı kolayca aşabilir. Sınırı yükseltmek — php.ini, .htaccess, wp-config.php veya WordPress eklenti katmanı aracılığıyla — doğru yapıldığında sunucu kararlılığından ödün vermeden hatayı çözer.

Sınırın Neden Var Olduğunu ve Ne Zaman Sorun Haline Geldiğini Anlamak

PHP’nin max_execution_time yönergesi, keyfi bir kısıtlama değil, bir kaynak koruma mekanizmasıdır. Özellikle çok kiracılı altyapılarda kritik öneme sahip olan paylaşımlı bir işlem havuzunda kontrolden çıkmış bir betiğin CPU süresini tekeline almasını engeller.

Sınır şu senaryolarda gerçek bir engel haline gelir:

• phpMyAdmin veya WP-CLI aracılığıyla binlerce satırı işleyen büyük veritabanı içe/dışa aktarmaları
• 50 MB’ı aşan arşivleri açan eklenti veya tema yüklemeleri
• Fiyat güncellemeleri, stok senkronizasyonları, sipariş dışa aktarmaları gibi WooCommerce toplu işlemleri
• Duplicator veya All-in-One WP Migration gibi araçlar kullanan tam site göçleri
• Harici API’lerden veri toplayan zamanlanmış cron görevleri
• Tek bir toplu işlemde yüzlerce optimize edilmemiş yüklemeyi işleyen görsel optimizasyon eklentileri

Çoğu kılavuzun atladığı kritik bir nüans: max_execution_time, gerçek zamanlı süreyi değil, PHP işlemi tarafından tüketilen CPU süresini ölçer. Yoğun yüklü bir sunucuda, bir betik yalnızca 28 saniyelik CPU süresi tüketerek 90 gerçek saniye boyunca çalışabilir ve sınırı hiç tetiklemeyebilir. Öte yandan, CPU yoğun bir döngü sınıra beklenenden daha hızlı ulaşır. Bu ayrım, aralıklı zaman aşımlarını teşhis ederken önem taşır.

Mevcut max_execution_time Değerinizi Nasıl Doğrularsınız

Herhangi bir şeyi değiştirmeden önce aktif sınırı onaylayın. WordPress kök dizininizde geçici bir dosya oluşturun — test sonrasında asla herkese açık bırakmayın:

<?php
phpinfo();

phpinfo-test.php olarak yükleyin, https://yourdomain.com/phpinfo-test.php adresini ziyaret edin ve çıktıda max_execution_time ifadesini arayın. Kontrol ettikten hemen sonra dosyayı silin.

Alternatif olarak SSH üzerinden WP-CLI kullanın:

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

Bu, WordPress istekleri için şu anda aktif olan değeri döndürür; dizin başına geçersiz kılma zaten mevcutsa sunucunun global php.ini değerinden farklı olabilir.

Yöntem 1: php.ini Dosyasını Düzenleyin (En Güvenilir)

php.ini dosyasını değiştirmek en yetkili yöntemdir; çünkü yönergeyi PHP yorumlayıcı düzeyinde ayarlar, yapılandırma hiyerarşisinde altındaki hiçbir şeyi geçersiz kılmaz ve altındaki hiçbir şey tarafından geçersiz kılınmaz — çalışma zamanında sonraki bir ini_set() çağrısı onu aşmadığı sürece.

Adım 1: Doğru php.ini Dosyasını Bulun

Çoğu yöneticinin hata yaptığı yer burasıdır. PHP, kullanılan SAPI’ye (Sunucu API’si) bağlı olarak birden fazla .ini dosyası yükleyebilir:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — WP-CLI ve cron görevleri tarafından kullanılır
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — Nginx + PHP-FPM yapılandırmaları tarafından kullanılır
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — PHP modülüyle Apache tarafından kullanılır

CLI php.ini dosyasını düzenlemek WP-CLI zaman aşımlarını düzeltir ancak tarayıcı tarafından tetiklenen istekleri etkilemez. Her zaman önce doğru SAPI’yi belirleyin:

php -i | grep "Loaded Configuration File"

Web istekleri için Loaded Configuration File altındaki phpinfo() çıktısını kontrol edin.

Adım 2: Web Kök Dizininde php.ini Dosyasını Düzenleyin veya Oluşturun

Root erişiminizin olmadığı paylaşımlı barındırmada, sitenizin kök dizinine (public_html) kullanıcı düzeyinde bir php.ini yerleştirebilirsiniz. cPanel Dosya Yöneticisi, FTP veya SSH aracılığıyla erişin:

nano ~/public_html/php.ini

Yönergeyi ekleyin veya güncelleyin:

max_execution_time = 300

300 saniye (5 dakika) çoğu işlem için yeterlidir. Son derece büyük göçler için geçici olarak 600 saniye düşünün, ardından görev tamamlandıktan sonra geri alın.

Adım 3: Değişikliğin Geçerli Olduğunu Doğrulayın

Kaydettikten sonra phpinfo() kontrolünü veya daha önceki WP-CLI komutunu yeniden çalıştırın. Değer değişmediyse, barındırıcınız kullanıcı düzeyindeki dosyanızı geçersiz kılan sunucu düzeyinde bir php.ini içindeki max_execution_time aracılığıyla sabit bir sınır uygulayabilir. Bu durumda Yöntem 4’e geçin.

Adım 4: PHP-FPM’yi Yeniden Başlatın (VPS ve Özel Sunucular)

Ortamı kontrol ettiğiniz bir VPS veya özel sunucuda, değişikliğin web isteklerine yayılması için PHP-FPM yeniden başlatması gereklidir:

sudo systemctl restart php8.2-fpm

php8.2-fpm ifadesini kurulu PHP sürümünüzle değiştirin. mod_php ile Apache bunun yerine Apache yeniden yüklemesi gerektirir:

sudo systemctl reload apache2

Yöntem 2: .htaccess Dosyasını Düzenleyin (Yalnızca Apache)

.htaccess yöntemi yalnızca AllowOverride PHP yapılandırma yönergelerine izin verdiği Apache sunucularında çalışır. Nginx’te, belirli yapılandırmalara sahip LiteSpeed’de veya PHP’nin AllowOverride None ile FastCGI/FPM olarak çalıştığı herhangi bir yapıda çalışmaz.

Adım 1: .htaccess Dosyasını Gösterin ve Erişin

.htaccess dosyası varsayılan olarak gizlidir. cPanel Dosya Yöneticisi’nde sağ üst köşedeki Ayarlar‘a tıklayın ve Gizli Dosyaları Göster (dotfiles) seçeneğini etkinleştirin. Dosya public_html konumundadır.

SSH aracılığıyla:

nano ~/public_html/.htaccess

Adım 2: PHP Yönergesini Ekleyin

Aşağıdaki satırı ekleyin. Konum önemlidir — global olarak uygulandığından emin olmak için herhangi bir <IfModule> bloğunun dışına yerleştirin:

php_value max_execution_time 300

Sunucunuz PHP-FPM çalıştırıyorsa (phpinfo() içinde PHP/x.x.x (fpm-fcgi) ile tanımlanabilir), bu yönerge 500 Internal Server Error‘a neden olur; çünkü php_value bu bağlamda geçerli değildir. php_admin_value yalnızca barındırıcı buna açıkça izin veriyorsa kullanın, aksi takdirde Yöntem 1’e geçin.

Adım 3: 500 Hatalarını Test Edin

Kaydettikten sonra hemen ana sayfanızı yükleyin. 500 hatası, yönergenin sunucu yapılandırmanızla uyumsuz olduğu anlamına gelir. Satırı kaldırın ve alternatif bir yöntem kullanın.

Yöntem 3: set_time_limit() Kullanarak wp-config.php’yi Düzenleyin

set_time_limit() işlevi, çağrıldığı noktadan itibaren yürütme zamanlayıcısını sıfırlar. Bu bir PHP çalışma zamanı çağrısıdır, yapılandırma yönergesi değildir; yani PHP’nin disable_functions listesi onu içermediği sürece sunucunun php.ini veya .htaccess geçersiz kılmalarına izin verip vermediğinden bağımsız olarak çalışır.

Adım 1: wp-config.php Dosyasını Bulun

Dosya, WordPress kurulum kök dizininde bulunur; bazı sunucu yapılandırmalarında public_html dizininin bir üst seviyesinde, diğerlerinde ise doğrudan içinde yer alır.

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

Adım 2: Yönergeyi Ekleyin

wp-config.php dosyasını açın ve aşağıdaki satırı /* That's all, stop editing! Happy publishing. */ yorumundan önce ekleyin:

set_time_limit(300);

set_time_limit(0) çağrısı, söz konusu istek için sınırı tamamen devre dışı bırakır. Bunu yalnızca geçici bir tanılama önlemi olarak kullanın — asla üretim ortamında kullanmayın — çünkü sonsuz döngülere karşı güvenlik ağını kaldırır.

Önemli uyarı: set_time_limit() yalnızca mevcut betik yürütmesini etkiler. Sunucu genelindeki PHP yapılandırmasını değiştirmez. Bir eklenti dahili olarak bir alt işlem oluşturursa veya engelleyici bir HTTP isteği yaparsa, bu alt işlem bu çağrı kapsamında değildir.

Yöntem 4: WordPress Eklentisi Kullanın

Sunucu dosyalarını doğrudan düzenlemeyi tercih etmeyen kullanıcılar için, çeşitli eklentiler PHP yapılandırma değerlerini WordPress yönetici arayüzü üzerinden sunar. Bu yaklaşım, yönetilen barındırmadaki teknik olmayan site sahipleri için uygundur.

Önerilen seçenekler:

• WP Maximum Execution Time Exceeded — özellikle bu hatayı hedefler ve birden fazla geçersiz kılma yöntemi dener
• PHP Settings — aktif PHP yönergelerinin bir kontrol paneli görünümünü sağlar ve barındırıcının izin verdiği durumlarda güvenli geçersiz kılmalara olanak tanır

Yüklemek için: WordPress kontrol panelinde Eklentiler > Yeni Ekle bölümüne gidin, eklenti adını arayın, yükleyin ve etkinleştirin. İstediğiniz yürütme süresini ayarlamak için eklentinin ayarlar sayfasını takip edin.

Sınırlama: Eklentiler yalnızca çalışma zamanında set_time_limit() veya ini_set() çağırabilir. Barındırıcı max_execution_time değerini open_basedir kısıtlamaları veya sabit kodlanmış bir sunucu yapılandırması aracılığıyla kilitlemiş ise eklenti sınırı artırmada sessizce başarısız olur. Etkinleştirdikten sonra her zaman phpinfo() kullanarak değişikliği doğrulayın.

Yöntem 5: Barındırıcınızla İletişime Geçin

Yukarıdaki yöntemlerin hiçbiri phpinfo() çıktısında doğrulanmış bir değişiklik üretmiyorsa, sınır barındırıcınız tarafından sunucu düzeyinde uygulanıyordur. Bu durum, sağlayıcının paylaşılan kaynakları korumak için sabit bir tavan belirlediği giriş seviyesi paylaşımlı barındırma planlarında yaygındır.

Destek ile iletişime geçerken şunları sağlayın:

• Tam hata mesajı ve onu tetikleyen WordPress eylemi
• phpinfo() çıktısındaki mevcut max_execution_time değeri
• İhtiyaç duyduğunuz değer (örn. 300 saniye) ve nedeni (örn. büyük WooCommerce içe aktarması)

Saygın barındırıcılar ya hesabınız için sınırı ayarlar ya da bunu kendiniz yapılandırabileceğiniz bir kontrol paneli seçeneğine (cPanel’deki PHP seçici gibi) sizi yönlendirir.

Beş Yöntemin Karşılaştırması

Sınırı Artırdıktan Sonra Devam Eden Zaman Aşımlarını Teşhis Etme

phpinfo() çıktısında yeni sınırın aktif olduğunu onayladıysanız ancak hata devam ediyorsa, darboğaz muhtemelen max_execution_time değildir. Şu alternatif nedenleri göz önünde bulundurun:

FastCGI veya Nginx zaman aşımı yönergeleri — Nginx’in PHP’den bağımsız kendi fastcgi_read_timeout yönergesi vardır:

fastcgi_read_timeout 300;

Bu, Nginx sunucu bloğunda ayarlanmalı ve Nginx yeniden yüklemesi gerektirir.

Apache TimeOut yönergesi — Apache’nin kendi bağlantı zaman aşımı, PHP sınırına ulaşılmadan önce bir isteği sonlandırabilir:

TimeOut 300

PHP-FPM request_terminate_timeout — PHP-FPM havuz yapılandırmasında (/etc/php/8.x/fpm/pool.d/www.conf), bu yönerge bağımsız olarak çalışan işlemleri sonlandırır:

request_terminate_timeout = 300

MySQL wait_timeout ve interactive_timeout — Uzun süren veritabanı sorguları, yürütme ortasında MySQL bağlantısının düşmesine neden olabilir; PHP bunu veritabanı hatası yerine betik hatası olarak gösterir. Şununla kontrol edin:

SHOW VARIABLES LIKE '%timeout%';

WooCommerce veya eklenti düzeyinde zaman aşımları — Bazı eklentiler, PHP’nin set_time_limit() işlevini daha düşük bir değerle kullanarak kendi dahili zaman aşımı mantıklarını uygular; bu sayacı sıfırlar ve yapılandırmanızı geçersiz kılabilir.

Performans Değerlendirmeleri ve En İyi Uygulamalar

max_execution_time değerini artırmak, kalıcı bir mimari çözüm değil, hedefe yönelik bir düzeltmedir. Belirli bir işlem rutin olarak 30–60 saniyeyi aşıyorsa, temel süreç optimize edilmeli veya yeniden yapılandırılmalıdır:

• Toplu işleme: Her şeyi tek bir HTTP isteğinde işlemek yerine, WP All Import’un yerel olarak yaptığı gibi AJAX tabanlı parçalama kullanarak büyük içe aktarmaları daha küçük parçalara bölün
• Arka plan işleme: Uzun süren işleri web isteği yaşam döngüsünden çıkarmak için WP-Cron veya uygun bir görev kuyruğu (WooCommerce tarafından kullanılan Action Scheduler) kullanın
• Toplu işlemler için WP-CLI: CLI yürütmesi web sunucusu zaman aşımlarına tabi değildir ve veritabanı içe aktarmaları, arama-değiştirme işlemleri ve toplu medya işleme için doğru araçtır
• Yavaş sorguları optimize edin: Orantısız yürütme süresi tüketen veritabanı sorgularını belirlemek için Query Monitor eklentisini kullanın
• Barındırma katmanını yükseltin: İş yükünüz sürekli olarak uzatılmış yürütme süreleri gerektiriyorsa, cPanel’li VPS size PHP yapılandırması üzerinde tam kontrol ve diğer kiracılarla rekabet etmeyen özel kaynaklar sağlar

Yapay zeka destekli ürün önerileri veya büyük ölçekli görsel işleme hatları gibi yüksek hesaplama gerektiren iş yükleri için, GPU barındırma yoğun hesaplamayı tamamen PHP katmanından devreder.

Pratik Karar Kontrol Listesi

Herhangi bir düzeltme uygulamadan önce ve sonra bu kontrol listesini kullanın:

• Değişiklik yapmadan önce phpinfo() veya WP-CLI aracılığıyla mevcut max_execution_time değerini onaylayın
• Bir yöntem seçmeden önce sunucu yapılandırmanızı belirleyin (Apache + mod_php, Apache + FPM, Nginx + FPM)
• Aynı anda yalnızca bir yöntem uygulayın — php.ini, .htaccess ve wp-config.php değişikliklerini aynı anda yığmak hata ayıklamayı imkânsız hale getirir
• Bir değişiklik uyguladıktan sonra phpinfo() çıktısında aktif değeri yeniden doğrulayın — değişikliğin işe yaradığını varsaymayın
• Yalnızca ana sayfayı yükleyerek değil, orijinal başarısız eylemi yeniden üreterek test edin
• Hata çözüldüyse, temel işlemin orijinal sınır içinde çalışacak şekilde optimize edilip edilemeyeceğini değerlendirin
• Tek seferlik görev tamamlandıktan sonra geçici sınır artışlarını (örn. set_time_limit(0)) geri almak için takvim hatırlatıcısı ayarlayın
• Paylaşımlı barındırmada, barındırıcının planınız için izin verilen maksimum değer olarak onayladığı şeyi belgeleyin
• PHP sınırının yükseltildiğini onayladıktan sonra zaman aşımları devam ederse, Nginx fastcgi_read_timeout, Apache TimeOut ve PHP-FPM request_terminate_timeout değerlerini bağımsız olarak denetleyin

SSS

WordPress’te max_execution_time için ayarlanacak en güvenli değer nedir?

300 saniye (5 dakika), büyük eklenti yüklemeleri, WooCommerce içe aktarmaları ve tema güncellemeleri dahil olmak üzere kaynak yoğun WordPress işlemlerinin büyük çoğunluğunu kapsar. 600 saniyenin üzerindeki değerler geçici olarak değerlendirilmeli ve belirli görev tamamlandıktan sonra geri alınmalıdır.

php.ini dosyasını düzenledikten sonra max_execution_time değişikliğim neden phpinfo() çıktısında görünmüyor?

Büyük olasılıkla yanlış php.ini dosyasını düzenliyorsunuzdur. PHP, CLI, Apache mod_php ve PHP-FPM için farklı yapılandırma dosyaları yükler. CLI için php -i | grep "Loaded Configuration File" komutunu çalıştırın ve web istekleri için doğru dosyayı belirlemek amacıyla tarayıcıdan erişilebilen bir phpinfo() sayfasındaki Loaded Configuration File satırını kontrol edin.

max_execution_time değerini artırmak sunucumdaki tüm kullanıcıları etkiler mi?

Paylaşımlı bir sunucuda, web kök dizininizdeki kullanıcı düzeyinde bir php.ini dosyasını düzenlemek yalnızca hesabınızı etkiler. Global sunucu php.ini dosyasını düzenlemek (root erişimi gerektirir) o sunucudaki tüm PHP işlemlerini etkiler. Özel sunucuda global yapılandırmayı kontrol eder ve bunun etkisinden tamamen sorumlu olursunuz.

.htaccess yöntemi Nginx sunucusunda çalışır mı?

Hayır. .htaccess dosyası Apache’ye özgü bir mekanizmadır. Nginx, .htaccess dosyalarını işlemez. Nginx + PHP-FPM yapılandırmalarında, SSH erişimi gerektiren PHP-FPM havuz yapılandırmasını veya sunucu düzeyindeki php.ini dosyasını düzenlemeniz gerekir.

Bir WordPress eklentisi max_execution_time değerini kalıcı olarak artırabilir mi?

Hayır. Eklentiler PHP çalışma zamanı içinde yürütülür ve yalnızca mevcut isteği etkileyen set_time_limit() veya ini_set() çağırabilir. php.ini dosyasına yazamaz veya istekler arasında yapılandırma değişikliklerini kalıcı hale getiremezler. Kalıcı bir artış için sunucu düzeyinde php.ini, .htaccess veya bir PHP-FPM havuz yapılandırma dosyasını değiştirmeniz gerekir.