# PrestaShop 1.7’den 9’a: Symfony 6.4 ve yeniden yazılacak geçersiz kılmalar

> PrestaShop’ta 1.7’den doğrudan 9’a geçmek; Symfony 6.4’e, en az PHP 8.1’e ve tamamen Twig tabanlı bir yönetim paneline tek seferde geçmek demektir: göründüğünden daha ağır bir sıçrama.

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

## Doğrudan yanıt

> Her şeyden önce override/ klasörünün envanterini çıkarın: 9 sürümünde son legacy yönetim denetleyicileri kalmadı ve 1.7 için yazılmış bir override uyarı vermek yerine yüklenirken hata verir. Ayrıca en az PHP 7.4’ten PHP 8.1’e bir sıçrama hesaplayın; iki sürüm arasında ortak aralık yoktur, barındırma geçişten sonra değil önce hazır olmalıdır.

## 1.7 ile 9 arasında ne değişiyor

PrestaShop 1.7 ile 9 arasındaki fark artık yalnızca bir sürüm numarası meselesi değil, bir nesil değişikliğidir. PrestaShop 1.7 karma bir mimariye dayanır: yönetim panelinin bir kısmı ve bazı ön yüz denetleyicileri Symfony üzerinde, geri kalanı hâlâ saf Smarty ve legacy yönetim denetleyicileriyle çalışır. PrestaShop 9 bu son legacy denetleyicileri kaldırır: yönetim paneli artık tamamen Symfony denetleyicileri ve Twig şablonlama üzerine kuruludur; Symfony’nin kendisi de 6.4 LTS’e atlar, 1.7/8 tarafındaki çok daha eski sürüme karşı. PHP tarafında, 1.7 en son alt sürümünde 7.4’te tavan yaparken, 9 en az PHP 8.1 ister ve 8.2, 8.3, 8.4’ü destekler: iki uyumluluk aralığı arasında doğrudan örtüşme yoktur.

PrestaShop 9 ayrıca API Platform üzerine kurulu, OAuth kimlik doğrulamalı yeni bir yönetim API’si (Admin API) ekler. Tema tarafında, 9 Hummingbird temasını tanıtır, ama varsayılan tema çıkışta Classic kalır: 1.6’dan 1.7’ye geçişin aksine, zorunlu bir tema yeniden inşası söz konusu değildir.

Veritabanı yapısı geçilen her ana sürümde değişir; burada, tek işlemde veya iki aşamada yapılsın, autoupgrade’in güncelleme betiklerinin kapsaması gereken iki ana aşama vardır (1.7’den 8’e, ardından 8’den 9’a).

## Bu büyüklükte bir sürüm farkında neler bozulur

- Legacy bir Smarty yönetim denetleyicisine dayanan bir eklenti, 9’da o denetleyicinin artık olmadığını fark eder: çökmez, sadece kaybolur.
- 1.7 için yazılmış bir çekirdek metot override’ı, PHP 8.1’den beri gerekli dönüş tiplerini yok sayar: bir uyarı değil, ölümcül bir hata tetikler.
- Bir dizi veya karakter dizisine erişmek için süslü parantez söz dizimini ($array{0}) kullanan bir eklenti, PHP 8.1 veya üzerinde çalışmayı durdurur.
- Eski web servis API’sine göre geliştirilmiş bir entegrasyon, Admin API’nin OAuth kimlik doğrulaması için tasarlanmamıştır, gözden geçirilmesi gerekir.
- config.xml dosyasında yalnızca 8. sürüme kadar uyumluluk bildiren bir eklenti, 9 üzerinde kurulum sırasında reddedilir.

## Bu sıçramaya nasıl yaklaşıyorum

1. **Denetim ve yol kararı** — Eklentileri, denetleyici ve şablon override’larını ve mevcut web servis API’sini kullanan entegrasyonları listeliyorum, ardından işi nasıl böleceğime karar veriyorum. autoupgrade basamakları sırayla geçer, hiçbirini atlamaz: ara sürümlerin güncelleme betikleri her hâlükârda çalışır, tek soru bunların tek seferde mi akacağı yoksa özellikle legacy eklenti veya override varsa mağazayı kontrol etmek için 8’de durup durmayacağımdır.
2. **Bağımsız tam yedekleme** — Herhangi bir işlemden önce, autoupgrade’in iç yedeğine ek olarak tam bir SQL dökümü ve dosyaların tam kopyasını alıyorum; bunlar değiştirilecek sunucunun dışında saklanır.
3. **Mağazanın bir kopyası üzerinde geçiş** — Tüm prosedür, hedef PHP sürümü zaten devrede olan bir test ortamında tekrarlanır; böylece dönüş tipi hataları ve eksik denetleyiciler gerçek siteye dokunmadan önce ortaya çıkar.
4. **Geri dönüşü olmayan nokta: veritabanı betiklerinin çalıştırılması** — Şema güncelleme betikleri çalışmaya başladığında, temiz bir geri dönüş yalnızca dökümün geri yüklenmesiyle mümkündür. Bu adım yalnızca eklentiler ve override’lar test ortamında doğrulandıktan sonra başlatılır.
5. **Legacy denetleyicilerin ve eklentilerin yeniden yazılması** — Hâlâ Smarty üzerinde çalışan yönetim denetleyicileri ve bunlara bağımlı eklentiler, 9’un Symfony/Twig mimarisi için yeniden yazılır, sadece güncellenmez.
6. **Üretime geçiş** — Test sürümü onaylandıktan ve hedef PHP doğrulandıktan sonra, geçişi düşük trafikli bir zamana planlıyorum.

## Herhangi bir şeye dokunmadan önce ne yedekliyorum

> Tam bir SQL dökümü, dosyaların tam kopyası, sürümleriyle aktif eklentilerin listesi ve denetleyici veya şablon override’larının bir envanteri: en çok yeniden yazma işi gerektirenler bunlardır, sadece güncelleme değil.

## Sonradan nasıl doğruluyorum

Her aşamadan sonra eski ve yeni veritabanı arasında sipariş, müşteri ve ürün hacimlerini karşılaştırıyorum. Sipariş sürecini her ödeme yönteminde, yeniden yazılan denetleyicilerin her kullanıcı profili için doğru çalıştığını test ediyorum ve hiçbir API entegrasyonunun eski kimlik doğrulamasında takılı kalmadığından emin oluyorum. İlk günler PHP hata günlüğünü de izliyorum, özellikle nadiren kullanılan bir özellik devreye girdiğinde ortaya çıkan dönüş tipi hataları için.

## İlgili sayfalar

- **PrestaShop 1.7’den 8’e geçiş** — Eklenti ekosisteminiz hazır değilse, 9’u düşünmeden önceki ilk aşama. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8))
- **PrestaShop 8’den 9’a geçiş** — PHP 8 uyumluluğu zaten sağlandıktan sonraki ikinci aşama. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))
- **Geçiş sonrası uyumsuz eklentiler** — Sorunsuz çalışan bir eklentinin bir güncellemeden sonra neden çöktüğü veya kaybolduğu. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **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))

## FAQ

### 9’dan önce mutlaka 8. sürümden geçmem gerekir mi?

Zorunlu bir durak değil, hayır: autoupgrade basamakları sırayla geçer ve hiçbirini atlamaz, doğrudan 9’u hedefleseniz bile 8’in betikleri çalışır. Ancak fark büyüdükçe tek seferde çalıştırılan güncelleme betiği sayısı artar ve risk penceresi uzar. Mevcut eklenti ve override’ların durumuna göre 8’de durmanın riski azaltıp azaltmadığına karar veriyorum.

### Özel Smarty yönetim denetleyicilerim 9’da çalışmaya devam eder mi?

Hayır, oldukları gibi değil. PrestaShop 9, son legacy yönetim denetleyicilerini kaldırır: hâlâ Smarty üzerinde olan her yönetim paneli denetleyicisi, 9’un Symfony/Twig mimarisi için yeniden yazılmalıdır; kendiliğinden güncellenmez.

### Böyle bir sıçrama ne kadar sürer?

Basit bir 1.7’den 8’e güncellemeden daha uzun: denetim, legacy denetleyici yeniden yazımları ve kopya üzerinde testler, yönetim paneli kişiselleştirmesi olduğunda günler değil haftalar tutar.

### SEO’m etkilenir mi?

URL’ler ve sayfa yapısı korunursa, sürüm değişikliğinin kendisinden etkilenmez. İşlem boyunca, özellikle iki aşamada yürütülüyorsa, yönlendirmelere yakından dikkat ediyorum.