WordPress max_execution_time Süre Aşımı Hatası Nedir? Nasıl Çözülür?

Siteniz bir eklenti kuruyor, yedek alıyor ya da büyük bir içe aktarma yapıyor ve işlem yarıda "Maximum execution time exceeded" mesajıyla kesiliyor. Sorun çoğu zaman bozuk bir kod değil, PHP'nin bir betiğe tanıdığı süre sınırıdır. Bu rehberde hatanın nedenini, doğru çözüm yollarını ve sınırı artırmanın ne zaman yanlış olduğunu bulacaksınız.

max_execution_time Nedir?

max_execution_time, bir PHP betiğinin çalışmaya devam edebileceği en uzun süreyi saniye cinsinden belirleyen PHP yapılandırma ayarıdır. Betik bu süreyi aşarsa PHP işlemi sonlandırır ve WordPress'te "Fatal error: Maximum execution time of 30 seconds exceeded" benzeri bir hata görürsünüz.

Varsayılan değer PHP'de 30 saniyedir. Birçok hosting ortamı bu değeri 30, 60 veya 120 saniye olarak ayarlar. Komut satırından (CLI) çalışan PHP betiklerinde ise varsayılan değer 0'dır, yani süre sınırı yoktur. Bu yüzden aynı işlem SSH'tan sorunsuz çalışıp tarayıcıdan hata verebilir.

Ayarın amacı sunucuyu korumaktır. Sonsuz döngüye giren ya da takılan bir betik, işlemci ve bellek kaynaklarını sürekli tüketir. Süre sınırı bu durumda güvenlik sübabı görevi görür.

Hata Mesajı Nasıl Görünür?

WordPress'te bu sorun birkaç farklı biçimde ortaya çıkabilir. Hata ekranda açıkça yazılabileceği gibi, yalnızca beyaz ekran ya da 500 hatası olarak da görünebilir.

Kesin teşhis için hata günlüğüne bakmak gerekir. WordPress'te wp-config.php dosyasında WP_DEBUG ve WP_DEBUG_LOG seçeneklerini açarsanız hata wp-content/debug.log dosyasına yazılır.

Hatanın Sık Görülen Nedenleri

Hata çoğunlukla ağır bir işlemin sınırlı bir süreye sığmamasından kaynaklanır. Ancak bazen asıl sorun işlemin gereğinden uzun sürmesidir, yani sınır değil kod ya da kaynak yetersizliği sorunludur.

• Büyük tema veya eklenti kurulumları ve toplu güncellemeler
• Binlerce ürünün ya da yazının içe aktarılması (WooCommerce, XML/CSV)
• Tüm siteyi kapsayan yedekleme ve geri yükleme işlemleri
• Yavaş çalışan veya hatalı yazılmış eklentiler
• Yavaş yanıt veren harici API bağlantıları
• Optimize edilmemiş veritabanı sorguları
• Yetersiz CPU ve bellek nedeniyle yavaşlayan paylaşımlı sunucular

Bilgi: Süreyi artırmak belirtiyi giderir ama nedeni gidermez. Bir sayfa normalde 2 saniyede açılırken aniden 30 saniyeyi aşıyorsa, sınırı yükseltmeden önce sorunlu eklentiyi veya sorguyu araştırın.

max_execution_time Değeri Nasıl Artırılır?

Değeri artırmanın birkaç yolu vardır ve hangisinin çalışacağı hosting yapılandırmanıza bağlıdır. Genellikle önce panelden, olmazsa dosya tabanlı yöntemlerle denemek en pratik sıradır.

Hosting kontrol panelinden değiştirme

cPanel kullanıyorsanız MultiPHP INI Editor ya da PHP Seçenekleri bölümünden max_execution_time değerini düzenleyebilirsiniz. Plesk ve benzeri panellerde de PHP ayarları altında aynı seçenek bulunur. Bu yöntem en güvenli olanıdır, çünkü hatalı bir satır yazıp siteyi bozma riski taşımaz.

php.ini ile değiştirme

Sunucuya erişiminiz varsa ya da hosting php.ini dosyasına izin veriyorsa şu satırı ekleyin veya güncelleyin:

max_execution_time = 300

Değişikliğin ardından PHP-FPM veya web sunucusunun yeniden başlatılması gerekebilir. Paylaşımlı hostingde ise yeni ayar çoğunlukla birkaç dakika içinde devreye girer.

.user.ini ile değiştirme

PHP'yi CGI/FastCGI ya da PHP-FPM ile çalıştıran ortamlarda site dizinine .user.ini dosyası oluşturup aynı satırı yazabilirsiniz:

max_execution_time = 300

.htaccess ile değiştirme

Apache ve mod_php kullanılan ortamlarda .htaccess dosyasına şu satır eklenebilir:

php_value max_execution_time 300

Uyarı: PHP, FastCGI veya PHP-FPM olarak çalışıyorsa bu satır 500 hatasına yol açar. Düzenlemeden önce .htaccess dosyasının yedeğini alın.

wp-config.php veya PHP kodu ile değiştirme

Bazı durumlarda süreyi betik içinden de belirleyebilirsiniz. wp-config.php dosyasında "Hepsi bu kadar" satırından önce şunu ekleyin:

set_time_limit(300);

Bu yöntem, sunucu set_time_limit fonksiyonunu devre dışı bırakmamışsa ve güvenli mod benzeri kısıtlamalar yoksa işe yarar. Hosting tarafında kısıtlama varsa değişiklik sessizce yok sayılabilir.

Yöntemlerin Karşılaştırması

Değişikliğin Uygulandığını Doğrulama

Ayarı değiştirdikten sonra gerçekten devreye girip girmediğini kontrol edin. Birçok kullanıcı dosyayı düzenleyip sonucu test etmeden hatanın sürdüğünü düşünür.

1. WordPress panelinde Araçlar > Site Sağlığı > Bilgi > Sunucu bölümünü açın.
2. "PHP zaman sınırı" satırındaki değeri okuyun.
3. Değer hâlâ eskiyse başka bir yöntemi deneyin veya hosting desteğiyle iletişime geçin.

Alternatif olarak geçici bir PHP dosyasına phpinfo() yazarak max_execution_time değerini görebilirsiniz. Bu dosyayı işiniz bitince mutlaka silin, çünkü sunucu bilgilerini herkese açık bırakır.

Hangi Değer Doğru?

Her sorunun çözümü 300 saniye ya da 0 değildir. Değer, yapacağınız işlemin gerçek ihtiyacına göre seçilmelidir.

İpucu: Yüksek değeri kalıcı bırakmak yerine işlem bitince eski haline döndürün. Süresiz çalışan bir betik, trafik yoğunluğunda sunucu kaynaklarını tüketebilir.

Değeri 0 (sınırsız) yapmak da önerilmez. Takılan bir betik ancak sunucu müdahalesiyle durdurulabilir ve bu durum sitenin tamamını yavaşlatabilir.

Süre Artırmak Yetmediğinde Yapılacaklar

Değeri yükselttiğiniz halde hata sürüyorsa sorun başka bir katmanda olabilir. Web sunucusu ve proxy katmanlarının da kendi zaman aşımı değerleri vardır ve bunlar PHP ayarından bağımsız çalışır.

• Web sunucusu zaman aşımı: Apache'de Timeout, Nginx'te fastcgi_read_timeout değerleri PHP süresinden kısaysa işlem yine kesilir.
• PHP-FPM: request_terminate_timeout ayarı betiği bağımsız olarak sonlandırabilir.
• Bellek sınırı: memory_limit dolduğunda farklı bir hata alırsınız, ancak yavaşlama süre aşımına dönüşebilir.
• Eklenti çakışması: Eklentileri tek tek devre dışı bırakarak sorunlu olanı bulun.
• Önbellek ve nesne önbelleği: Tekrarlanan ağır sorguları azaltır.

Büyük içe aktarmalarda işlemi parçalara bölmek, süreyi uzatmaktan daha kalıcı çözümdür. CSV dosyasını küçük gruplara ayırmak ya da WP-CLI ile komut satırından çalışmak, tarayıcı kaynaklı süre sınırlarını büyük oranda ortadan kaldırır.

Kalıcı Önlemler

Hatayı yalnızca bir kez çözmek yerine tekrarını önlemek için birkaç alışkanlık edinmek yeterlidir. Bunlar hem hızı hem kararlılığı iyileştirir.

1. PHP sürümünü güncel ve desteklenen bir sürümde tutun.
2. Kullanmadığınız eklenti ve temaları kaldırın.
3. Veritabanını düzenli olarak temizleyin ve optimize edin.
4. Sayfa ve nesne önbelleği kullanın.
5. Zamanlanmış görevleri (cron) yoğun saatlerin dışına planlayın.
6. Kaynak ihtiyacınız büyüdüyse paylaşımlı hostingden VPS veya özel sunucuya geçmeyi değerlendirin.

Kaynaklar yetersizse ayar değişikliği geçici rahatlama sağlar. Trafiği ve işlem yükü artan siteler için kaynakları size ayrılmış bir sunucu ortamı, süre sınırlarını kendiniz yönetebileceğiniz için daha esnektir.

Netlen ile Çalışırken Dikkat Edilecekler

Netlen İnternet Hizmetleri üzerinde barındırılan bir WordPress sitesinde PHP ayarlarını genellikle hosting panelinden yönetebilirsiniz. Ayarın değişmediğini ya da farklı bir sınırla karşılaştığınızı fark ederseniz, teknik destek ekibine hata günlüğünden bir satır ve işlem yaptığınız zamanı iletmek teşhisi hızlandırır.

Ağır bir içe aktarma ya da düzenli yedekleme gibi sürekli yüksek süre gerektiren işleriniz varsa, paketinizin kaynaklarının bu işe yetip yetmediğini de birlikte değerlendirmek mantıklıdır.

Sık Sorulan Sorular

max_execution_time varsayılan değeri kaçtır?

PHP'de varsayılan değer 30 saniyedir. Komut satırında çalışan betiklerde ise 0 olarak gelir, yani süre sınırı uygulanmaz. Hosting sağlayıcıları bu değeri paketlerine göre farklı belirleyebilir.

max_execution_time ile memory_limit arasındaki fark nedir?

max_execution_time bir betiğin ne kadar süre çalışabileceğini, memory_limit ise ne kadar bellek kullanabileceğini sınırlar. İkisi bağımsız ayarlardır ancak biri diğerini etkileyebilir. Bellek yetersizliği işlemi yavaşlatıp süre aşımına yol açabilir.

Değeri 0 yapmak güvenli midir?

Değeri 0 yapmak süre sınırını kaldırır, bu yüzden önerilmez. Takılan ya da sonsuz döngüye giren bir betik sunucu kaynaklarını sürekli tüketebilir. Gerekiyorsa yalnızca işlem süresince geçici olarak yüksek bir değer verin.

Ayarı değiştirdim ama hata devam ediyor, neden?

Değişiklik uygulanmamış olabilir ya da web sunucusu veya PHP-FPM düzeyinde ayrı bir zaman aşımı sınırı bulunabilir. Site Sağlığı ekranından geçerli değeri kontrol edin. Değer doğruysa Nginx veya Apache zaman aşımı ayarlarına ve hata günlüklerine bakın.

WordPress'te hata günlüğünü nasıl açarım?

wp-config.php dosyasında WP_DEBUG ve WP_DEBUG_LOG sabitlerini true yapın. Hatalar wp-content/debug.log dosyasına yazılır. Canlı sitede WP_DEBUG_DISPLAY değerini false yaparak hataların ziyaretçilere gösterilmesini engelleyin.