# PrestaShop 1.7’den 8’e: PHP 8 ve TypeScript yönetim paneli

> PrestaShop’ta bugün en sık karşılaşılan güncelleme: PHP 8 uyumluluğu, TypeScript’e taşınan yönetim paneli JavaScript’i ve herhangi bir şeye dokunmadan önce tek tek kontrol edilmesi gereken eklentiler.

- Source canonique : [https://allaux.fr/tr/prestashop/migration/1-7-vers-8](https://allaux.fr/tr/prestashop/migration/1-7-vers-8)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Bunu iki ayrı iş olarak ele alın: önce 8 sürümüne yükseltme, sonra PHP 8’e geçiş. Başlamadan önce her modülün config.xml dosyasındaki üst uyumluluk sınırını ve ana sınıfındaki $ps_versions_compliancy özelliğini okuyun: 1.7’de donmuş bir modül güncellemeden sonra soluk kalır. Yönetim panelinin JavaScript’i TypeScript’e geçtiği için özel yönetim betiklerinizi de gözden geçirin.

## 1.7 ile 8 arasında gerçekte ne değişiyor

Teknik açıdan, 1.7’den 8’e geçiş, 1.6’dan 1.7’ye geçişten daha az köklüdür: Smarty/Symfony karma mimarisi ve Classic teması yerinde kalır. Gerçekten değişen PHP uyumluluğudur: PrestaShop 8 en az PHP 7.2.5 ister, çıkışından itibaren PHP 8.0 ve 8.1’i destekler, ardından Eylül 2024’te yayımlanan 8.2 sürümünden itibaren PHP 8.2’yi destekler. Hiçbir 1.7.x sürümü PHP 8 altında çalışmaz, Smarty anında çöker: bu yüzden 8’e geçiş, neredeyse her zaman, PHP sürümünü PrestaShop ile aynı anda yükseltmeyi gerektirir; bu da olası kırılma noktalarını artırır.

Yönetim paneli tarafında daha az göze çarpan ama gerçek bir değişiklik: yönetim paneli JavaScript’i 8.0’dan itibaren TypeScript’e taşınır, 1.7 için geliştirilmiş override’lar veya betikler artık aynı şekilde devreye girmez. Çekirdeğin birçok metodu da artık bir dönüş tipi bildirir; PHP 8.1’in bir sonucudur: bu imzaya uymayan bir override, basit bir uyarı değil, ölümcül bir hata tetikler.

Veritabanı yapısı da her ana sürümde değişir: yeni tablolar, yeniden adlandırılmış sütunlar. Ham bir SQL dökümünü olduğu gibi yeni bir 8 kurulumuna geri yüklemek güvenilir değildir; ilgili güncelleme betiklerini autoupgrade çalıştırır.

## Sorun çıkaran eklentiler ve işlevler

- PHP 8.1’e geçtikten sonra yönetim paneli ilk erişimde, override edilmiş bir metotta eksik dönüş tipine bağlı ölümcül bir hata veriyor.
- 1.7’de kurulu bir eklenti, config.xml dosyasında 8. sürümle uyumluluk bildirilmediği için güncellemeden sonra bulunamıyor veya devre dışı görünüyor.
- Özel bir eklenti hâlâ süslü parantezli dizi/karakter dizisi erişim söz dizimini ($array{0}) kullanıyor; bu, PHP 8’de kaldırıldığı için sayfa bir söz dizimi hatasıyla çöküyor.
- Özel bir yönetim paneli betiği veya override, JavaScript’ten TypeScript’e geçiş nedeniyle artık çalışmıyor.
- Bir eklentinin eski sürümde sabit kalmış $ps_versions_compliancy özelliği, kod değişiklik gerektirmeden çalışacak olsa bile etkinleştirmeyi engelliyor.

## Bu geçişi nasıl yürütüyorum

1. **PHP ve eklenti denetimi** — Mevcut ve hedef PHP sürümünü kontrol ediyorum, kurulu eklentileri config.xml ve $ps_versions_compliancy’deki uyumluluk bildirimleriyle listeliyorum.
2. **Bağımsız tam yedekleme** — Autoupgrade’in kendi iç yedeğine ek olarak bir veritabanı dökümü ve dosyaların tam kopyasını alıyorum.
3. **Mağazanın bir kopyası üzerinde geçiş** — Autoupgrade önce bir test ortamında çalışır: dosya ve veritabanı yedeği, ardından şema güncelleme betikleri.
4. **Geri dönüşü olmayan nokta: veritabanı güncellemesi** — Veritabanı güncelleme betikleri çalışmaya başladıktan sonra, geri dönmek artık dosyaları geri almakla olmuyor: sadece dökümün geri yüklenmesi temiz bir geri dönüş sağlar. Bu adımı yalnızca dosyalar ve eklentiler hazır olduğunda başlatıyorum.
5. **Eklenti ve override düzeltmeleri** — Eski bir uyumluluk bildirimi veya PHP 8’de kaldırılan süslü parantez söz dizimi yüzünden engellenen eklentileri güncelliyor veya değiştiriyorum, TypeScript’ten etkilenen override’ları uyarlıyorum.
6. **Üretime geçiş** — Test sürümü onaylandıktan sonra, siparişlere etkiyi sınırlamak için PHP dahil geçişi düşük trafikli bir zamana planlıyorum.

## Herhangi bir şeye dokunmadan önce ne yedekliyorum

> Veritabanının tam bir SQL dökümü (yalnızca /autoupgrade/backup içindeki autoupgrade’in otomatik yedeği değil), sitenin tüm dosyalarının tam kopyası ve aktif eklentilerin sürümleriyle listesi. Yedekler değiştirilecek sunucunun dışında saklanır.

## Geçiş sonrasında hiçbir şeyin kaybolmadığını nasıl doğruluyorum

Hiçbir şeyin kaybolmadığından emin olmak için eski ve yeni veritabanı arasında sipariş, müşteri ve ürün sayılarını karşılaştırıyorum. Sipariş sürecini her aktif ödeme yönteminde, ön yüzdeki temel sayfaları (ana sayfa, kategori, ürün) ve yönetim paneline erişimi test ediyorum. İlk saatlerde PHP hata günlüğünü de kontrol ediyorum: dönüş tipi eksik override’lar genellikle orada ortaya çıkar.

## İlgili sayfalar

- **Geçiş öncesi kontrol listesi** — Bir geçişe başlamadan önce kontrol edilmesi ve yedeklenmesi gerekenler. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Geçiş sonrası uyumsuz eklentiler** — Sorunsuz çalışan bir eklentinin bir güncellemeden sonra neden çöktüğü veya kaybolduğu ve uyumluluğun önceden nasıl kontrol edileceği. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **PrestaShop’u PHP 8’e geçirmek** — PrestaShop sürümünden bağımsız olarak, barındırma tarafındaki PHP sürümü değişikliğinin ne anlama geldiği. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **PrestaShop 8’den 9’a geçiş** — Mağaza 8. sürümde stabilize edildikten sonraki mantıklı bir sonraki adım. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))

## FAQ

### 8’e geçmeden önce en son 1.7.8 alt sürümünde olmam gerekir mi?

Kesin bir zorunluluk değil, ama autoupgrade için en çok test edilmiş kurulum bu: güncellemeden önce 1.7 kurulumunuzun durumunu kontrol ediyorum, gerekirse mağazayı en son 1.7 alt sürümüne getiriyorum.

### Yeni yönetim panelindeki TypeScript, yönetim paneline özel yaptığım kişiselleştirmeleri bozar mı?

Sadece yönetim paneline özel JavaScript betikleriniz veya override’larınız varsa. Standart yönetim paneli davranışı etkilenmez; uyarlanması gereken özel koddur.

### 1.7’den 8’e geçiş ne kadar sürer?

Esas olarak eklenti sayısına ve özel override sayısına bağlıdır. Az eklentisi ve standart teması olan bir mağaza birkaç günde geçirilebilir; daha ağır bir kişiselleştirme daha uzun sürer.

### Geçişten önce barındırmamın değişmesi gerekir mi?

Genellikle evet. Barındırmanın sunduğu PHP sürümünü PrestaShop 8’in gerektirdikleriyle karşılaştırıyorum; mevcut değilse, bu değişikliği güncellemeden önce bildiriyorum.