# PrestaShop mağazası 500 hatası veya boş sayfa veriyor

> PrestaShop'ta boş bir sayfa veya 500 hatası tek başına bir şey söylemez: bu bir belirtidir, teşhis değil. Sorunun bir eklentiden, bir override'dan, veritabanından mı yoksa sunucudan mı kaynaklandığını anlamak için gerçek hata mesajlarını okumak gerekir.

- Source canonique : [https://allaux.fr/tr/prestashop/erreur-500](https://allaux.fr/tr/prestashop/erreur-500)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> config/defines.inc.php dosyasındaki _PS_MODE_DEV_ değerini true yapın: beyaz sayfanın yerini, hatalı dosya ve satır numarasıyla birlikte gerçek hata mesajı alır. Ayrıca var/logs/ (1.7, 8, 9) klasörünü ve barındırıcının PHP hata günlüğünü okuyun. Hata bir güncellemeden sonra çıktıysa var/cache klasörünü boşaltın ve geçersiz kalmış bir override’ı elemek için override/ klasörünü yeniden adlandırın.

## Ele aldığım durumlar

- Sitenin ön yüzü veya yönetim paneli yüklenirken tamamen boş ekran
- Bir eklenti veya PrestaShop güncellemesinin hemen ardından ortaya çıkan 500 hatası
- Yalnızca belirli sayfalarda görülen 500 hatası (ürün sayfası, sepet, sipariş)
- Barındırma sağlayıcısı değişiminden sonra "The file config/settings.inc.php is missing" mesajı
- Bir override dosyasında yapılan manuel değişiklik sonrası tetiklenen 500 hatası
- Yerelde çalışan ama üretim sunucusuna aktarılınca hata veren site

## Nasıl ilerliyorum

1. **Debug modunun etkinleştirilmesi** — Genel boş sayfa yerine PHP veya Smarty'nin gerçek hata mesajını görebilmek için config/defines.inc.php içinde _PS_MODE_DEV_ değerini true yapıyorum.
2. **Logların incelenmesi** — Sunucunun PHP loglarını (genellikle error_log veya Apache/Nginx logları içinde) ve PrestaShop 1.7/8'de Symfony hatalarını içeren var/logs/ klasörünü inceliyorum.
3. **Sorunlu bileşenin izole edilmesi** — Eklentileri ps_module tablosu veya FTP üzerinden tek tek devre dışı bırakıyor, core ile çakışan bir dosyayı tespit etmek için override/ klasörünün içeriğini kontrol ediyorum.
4. **Sunucu kontrolü** — PHP sürümünü, etkin uzantıları, memory_limit değerini ve var/cache, var/logs ile config üzerindeki yazma izinlerini kontrol ediyorum; bunlar barındırma değişikliği sonrasında sık görülen nedenlerdir.
5. **Düzeltme ve önbelleğin temizlenmesi** — Neden belirlendikten sonra ilgili dosyayı düzeltiyor veya sunucuyu yeniden yapılandırıyorum, ardından debug modunu tekrar false yapmadan önce var/cache/prod'u (1.6'da cache/smarty) temizliyorum.

## PrestaShop’ta boş sayfa: nerede göründüğü, nereden geldiğini söyler

Günlükleri okumadan önce bile boş sayfanın ya da 500 hatasının nerede oluştuğunu not edin. Bu, arama alanını yarıya indirir.

Hem mağaza hem yönetim paneli boş: arıza, PrestaShop ikisini ayırt etmeden önce oluşuyor. Yapılandırmaya bakın: barındırma firmasının değiştirdiği PHP sürümü, eksik bir app/config/parameters.php (1.7, 8, 9) ya da config/settings.inc.php (1.6), geçersiz bir .htaccess, eksik yazma izinleri.

Yalnızca yönetim paneli: çoğu zaman var/cache/ içinde önceki bir sürümden kalan önbellek ya da yönetim paneline bağlanan bir modül.

Yalnızca mağaza tarafı ya da tek bir sayfa: bir görüntüleme hook’una bağlı modül, bir tema dosyası ya da o sayfaya özgü bir veri.

Yalnızca sipariş adımında: yalnızca bu aşamada çağrılan ödeme ya da kargo modülü.

_PS_MODE_DEV_ açıkken sayfa hâlâ boşsa, hata PrestaShop yüklenmeden önce oluşuyor demektir: okunması gereken var/logs değil, sunucunun PHP hata günlüğüdür.

## En sık görülen hata mesajları ve işaret ettikleri

Cannot declare class … ya da Cannot redeclare class …: iki kez tanımlanmış ya da bir modül kaldırıldıktan sonra yerinde kalmış bir override. Sınıf dizinini silmek — 1.7 ve sonrasında var/cache/prod/class_index.php, 1.6’da cache/class_index.php — PrestaShop’u onu yeniden oluşturmaya zorlar.

Allowed memory size of … bytes exhausted: PHP bellek sınırına ulaşıldı; genellikle bir içe aktarma, küçük resimlerin yeniden oluşturulması ya da bir dizinleme sırasında.

Call to undefined function each() ya da create_function(): eski bir PHP sürümü için yazılmış bir modül. Bu fonksiyonlar PHP 8’de kaldırıldı; bkz. PrestaShop’u PHP 8’e geçirmek.

SQLSTATE[42S02]: Base table or view not found: bir geçişten, yarıda kalan bir SQL içe aktarmasından ya da düzgün kaldırılmamış bir modülden sonra eksik bir tablo.

Link to database cannot be established: yapılandırma dosyasında hatalı veritabanı bilgileri ya da erişilemeyen bir MySQL sunucusu. Bkz. veritabanı bağlantı hatası.

var/cache ya da var/logs üzerinde Permission denied: kaybolan yazma izinleri; FTP aktarımından ya da barındırma değişikliğinden sonra sık görülür.

## En sık görülen nedenler

PrestaShop'ta 500 hatası nadiren rastlantısaldır. En sık karşılaştığım durumlar:

Sınıfın yeniden tanımlanmasına yol açan, hatalı yazılmış veya override/ ile bir eklenti arasında yinelenmiş bir override dosyası.

Barındırma sağlayıcısında yapılan bir PHP sürüm yükseltmesi sonrası ortaya çıkan uyumsuzluk (örneğin PHP 8'de kaldırılmış bir fonksiyonu kullanan bir eklenti).

FTP ile dosya aktarımından sonra var/cache, var/logs veya config üzerinde eksik yazma izinleri.

PrestaShop çalışmaya başlamadan önce yönlendirmeyi bozan, bozulmuş bir .htaccess dosyası veya geçersiz bir yeniden yazma kuralı.

Bir geçiş veya yarıda kalan SQL içe aktarma sonrası veritabanında eksik veya bozulmuş bir tablo.

1.6 sürümünde, boş sayfa genellikle bir tema güncellemesinden sonra temizlenmemiş derleme önbelleğindeki (cache/smarty/compile) bir Smarty hatasını gizler.

## Siparişleriniz kaybolmaz

> 500 hatası görüntülemeyi engeller, veritabanını silmez. Zaten kaydedilmiş siparişler olduğu gibi kalır; gerçek risk, geçmişi kaybetmek değil, kesinti süresince satış kaybetmektir.

## config/defines.inc.php

```
define('_PS_MODE_DEV_', true);
```

## İlgili sayfalar

- **PrestaShop hata ayıklama modunu açmak** — Sürüme göre izlenecek adımlar ve ardından nasıl kapatılacağı. ([/guides/activer-mode-debug-prestashop](/guides/activer-mode-debug-prestashop))
- **PrestaShop hata günlüklerini okumak** — Günlüklerin nerede olduğu ve önemli satırın nasıl bulunacağı. ([/guides/lire-logs-erreurs-prestashop](/guides/lire-logs-erreurs-prestashop))
- **Ürün sayfası kaydedilemiyor** — Hata yalnızca yönetim panelinde bir ürün kaydedilirken çıkıyorsa. ([/prestashop/problemes/fiche-produit-enregistrement-echoue](/prestashop/problemes/fiche-produit-enregistrement-echoue))
- **Kurulmayı reddeden modül** — Kurulum hatası, kaybolan modül: dosya ve veritabanı tarafındaki nedenler. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))
- **Güncellemeden sonra kaybolan ödeme yöntemi** — Arıza yalnızca sipariş sürecinde görülüyorsa. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Tekrar eden hatalar: onarmak mı, yeniden yapmak mı?** — Eski bir sürümde her düzeltme yenisini doğuruyorsa. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Siparişlerimi veya müşterilerimi kaybetme riskim var mı?

Hayır. 500 hatası sayfaların görüntülenmesini engeller ama veritabanı sağlam kalır: verilmiş siparişler, müşteri hesapları ve katalog etkilenmez. Duran şey PHP çalıştırma katmanıdır, veri saklama değil.

### Hangi erişimleri sağlamam gerekiyor?

FTP veya SSH erişimi, veritabanı erişimi (phpMyAdmin veya doğrudan bilgiler) ve mümkünse PHP yapılandırmasını kontrol edebilmem için barındırma sağlayıcısının müşteri panelinde erişim.

### Teşhis ne kadar sürer?

Çoğu durumda, debug modunu etkinleştirmek ve logları okumak, nedeni ilk çalışma oturumunda belirlemek için yeterlidir. Bu, sunucu erişimi hazır olduğunda aynı gün içinde çözülen türden bir engeldir; düzeltmenin kendisi ise neyin bozuk olduğuna bağlıdır.

### Hata düzeltildikten sonra tekrar ortaya çıkabilir mi?

Kararsız bir üçüncü taraf eklentiden kaynaklanıyorsa, evet, bir sonraki otomatik güncellemede. Bunun tekrarlanmasını önlemek için hassas eklentilerin güncellemelerini kilitleyebilirim.

### Tam bir yedekten yeniden mi başlamak gerekir?

Nadiren. Bir yedeği geri yüklemek, o tarihten sonraki siparişlerin ve değişikliklerin kaybolmasına neden olur. Genellikle sorunlu dosyayı veya yapılandırmayı doğrudan düzeltiyorum.

### PrestaShop mağazam neden hiçbir mesaj olmadan boş sayfa gösteriyor?

Çünkü PrestaShop canlı ortamda hataları gizler: _PS_MODE_DEV_ false olduğu sürece ayrıntı gösterilmez. Bir deneme süresince true yapın. Sayfa buna rağmen boş kalıyorsa hata PrestaShop yüklenmeden önce oluşuyordur — PHP sürümü, .htaccess, yapılandırma dosyası — ve onu sunucunun hata günlüğünde bulursunuz.