OpenCart 3.0.x’ten 4.x’e yükseltme: gerçekçi bir kontrol listesi

Buna güncelleme değil, taşıma deyin

OpenCart 4, üzerine yeni bir boya çekilmiş bir ara sürüm değil. Dizin düzeni, sınıf yapısı, şablon yolları ve eklentilerin paketlenme biçimi aynı anda değişti. Yoğun bir 3.0.x mağazasını yerinde 4.x’e taşıyan güvenilir bir “yükselt” düğmesi yok; onu aramakla başlayan her proje kabullenmeden önce bir hafta sonunu kaybediyor. İşe yarayan yöntem sıkıcı olanı: canlı mağazanın yanına temiz bir OpenCart 4 kurulumu açmak, veriyi kendi kontrolünüzde oraya taşımak ve yeni yapı tam bir provadan sağ çıkmadan geçiş yapmamak.

4.0.x için asgari PHP

8.0

Tema şablon yolu

catalog/view/template/

Eklenti paket kökü

extension/<kod>/

Aşağıdaki liste, gerçek mağazalarda izlediğimiz sıra. Kabuk ve veritabanı erişiminiz, bozmakta serbest olduğunuz bir staging ortamınız ve savunabileceğiniz bir bakım pencereniz olduğunu varsayıyor.

Kaputun altında gerçekte ne değişti

Herhangi bir tahmin vermeden önce platformun kodunuza ne yaptığını bilin. İşi üreten değişiklikler bunlar:

• Her yerde namespace. Kontrolcü ve modeller artık Opencart\Catalog\Controller\Product\Product gibi, \Opencart\System\Engine\Controller’dan türeyen sınıflar. Özel dosyalar yamalanmaz, yeniden yazılır.
• Şablon yolları tema klasörünü kaybetti. catalog/view/theme/default/template/product/product.twig artık catalog/view/template/product/product.twig; temalar da kopyaladığınız klasörler yerine eklenti paketi olarak geliyor.
• Eklentiler tek bir yerde yaşıyor. admin/ ve catalog/ içine dağılmış dosyalar yerine her paket extension/<kod>/ dizinine sahip: kendi admin/, catalog/ ve system/ ağaçları artı bir install.json bildirimi.
• Rotalar paket adını taşıyor. extension/payment/bank_transfer olan ödeme yöntemi artık extension/opencart/payment/bank_transfer; bu da yazdığınız her sabit bağlantıyı, şablon çağrısını ve API isteğini sessizce bozar.
• config.php taşınabilir değil. OpenCart 4, DIR_OPENCART ve DIR_EXTENSION gibi sabitler ekliyor; 3.0.x dosyasını 4.x kurulumuna kopyalamak beyaz ekrana giden en kısa yollardan biri.
• Event API’si yer değiştirdi. 3.0.x’te model_extension_event üzerinden çağırdığınız şey 4.x’te model_setting_event.

İnsanların kaybedeceğini sandığı iki şey taşınmadan sağ çıkıyor. Admin klasörünün adını hâlâ değiştirebilirsiniz ve system/storage’ı hâlâ web kökünün dışında tutabilirsiniz. İkisi de config.php’deki birer sabit ve ikisi de sonraya bırakılan bir sıkılaştırma işi değil, ilk gün yapılacak iş.

<?php
// OpenCart 4 - admin/config.php, ad degistirmeden sonra onemli satirlar
define('DIR_OPENCART', '/home/store/public_html/');
define('DIR_APPLICATION', DIR_OPENCART . 'yonetim/');   // adi degistirilmis admin klasoru
define('DIR_EXTENSION', DIR_OPENCART . 'extension/');
define('DIR_STORAGE', '/home/store/storage/');          // web kokunun disinda

Takvimi eklentiler ve tema belirler

Platform tarafındaki taşıma öngörülebilir; eklenti listeniz değil. 3.0.x için yazılmış bir OCMOD yaması, 4.x’te artık var olmayan dosya yollarını, sınıf adlarını ve metot imzalarını arar; ya hiç uygulanmaz ya da yanlış yere uygulanır. Ticari her eklentinin üreticisinden 4.x sürümü gerekir ve bir kısmının böyle bir sürümü olmayacaktır. Bu, dördüncü haftada keşfedilecek bir sürpriz değil, ilk haftada verilecek bir iş kararıdır.

Temada da hikâye aynı. Journal 3, OpenCart 3.x için üretildi; OpenCart 4 hattı kendi lisansı ve kendi ayar deposu olan ayrı bir ürün. Yani ana sayfa düzenini dışa aktarmayı değil, yeniden kurmayı bütçeleyin. Fiyat vermeden önce envanteri yönetim ekranından değil, veritabanından çıkarın:

-- Canli 3.0.x magazasinda calistirin
SELECT type, code FROM oc_extension ORDER BY type, code;

SELECT extension_install_id, filename, status
FROM oc_extension_install ORDER BY filename;

-- Hangi eklenti ayarlari gercekten acik
SELECT code, `key`, value FROM oc_setting
WHERE `key` LIKE '%\_status' AND value = '1' ORDER BY code;

4.x’te oc_extension tablosuna, etkin her eklentiyi geldiği pakete bağlayan bir extension_install_id sütunu eklendi. Küçük bir değişiklik ama pratik sonucu var: kurulu paket listesiyle etkin eklenti listesi birbirini tutmayabiliyor. Bir eklenti temiz şekilde yeniden kurulmuyorsa ikisine de SQL’den bakın.

PHP 8 bir onay kutusu değil

OpenCart 4.0.x, PHP 8.0 veya üstünü istiyor. PHP 7.x’e göre yazılmış özel kod olduğu gibi taşınmaz; çünkü 8.0, uzun süre hoş görülen bir dizi özensizliği ölümcül hataya çevirdi. En sık karşılaştığımız kırılmalar, kabaca sıklık sırasıyla:

• Dahili bir fonksiyonun string beklediği yere null geçmek — trim(null) ve htmlspecialchars(null) artık uyarı üretiyor ve farklı davranıyor.
• Kaldırılan fonksiyonlar: create_function() ve each() yok; ikisi de eski OpenCart eklentilerinde yaygındı.
• $string{0} biçimindeki süslü parantezli string erişimi artık sözdizimi hatası; tek bir eski dosya bütün isteği düşürür.
• Dahili fonksiyonlarda sıkılaşan argüman tipleri sessizce false dönmek yerine TypeError fırlatıyor.
• Tanımsız dizi anahtarları ve tanımsız özellikler logu dolduran uyarılara dönüştü — gürültülü, ama her biri birinin ertelediği gerçek bir hata.

Tarih sözü vermeden önce taramayı mekanik olarak yapın ve gerçekten yayına alacağınız PHP sürümüyle çalıştırın:

# Her ozel dosyayi hedef surumle sozdizimi kontrolunden gecir
find . -name '*.php' -not -path './vendor/*' -print0 \
  | xargs -0 -n1 php8.1 -l | grep -v 'No syntax errors'

# Daha derini: PHP_CodeSniffer ile uyumluluk taramasi
phpcs -p . --standard=PHPCompatibility \
  --runtime-set testVersion 8.1 --extensions=php

Veriyi taşımak

OpenCart 4’ü temiz kurun, sonra veriyi tablo tablo getirin. 3.0.x dökümünü 4.x kurulumuna geri yüklemek işe yaramaz: birkaç tablonun şekli değişti, değişmeyenler ise yalnızca kendi şemasının yanında anlam taşıyan id’lere bağlı. Herkesin takıldığı tablo oc_seo_url. 3.0.x’te product_id=42 gibi tek bir query sütunu tutuyor; 4.x’te bu key ve value olarak ikiye ayrılıyor, yanına da bir sort_order geliyor.

-- 3.0.x -> 4.x: SEO anahtarlarini yeni sekle donustur
INSERT INTO oc4.oc_seo_url (store_id, language_id, `key`, `value`, keyword, sort_order)
SELECT store_id,
       language_id,
       SUBSTRING_INDEX(query, '=', 1),
       SUBSTRING_INDEX(query, '=', -1),
       keyword,
       0
FROM oc3.oc_seo_url
WHERE query LIKE '%=%';

Taşımaya güvenmeden önce elle kontrol edilecek üç şey daha var:

• Parolalar. İki taraftaki şemayı SHOW COLUMNS FROM oc_customer LIKE 'salt'; ile karşılaştırın — eski mağazada hâlâ salt sütunu varsa sessiz bir kopyalama yerine parola sıfırlama e-postası planlayın.
• Sipariş durumları. Varsayılanlar (1 Pending, 2 Processing, 3 Shipped, 5 Complete, 7 Canceled) yalnızca varsayılan. İki mağazada da oc_order_status’ü okuyun ve id eşleşmesini bilerek kurun; özellikle durumları yazan bir ERP veya kargo entegrasyonu varsa.
• Terk edilmiş siparişler. oc_order içinde order_status_id = 0 olan satırlar satış değil, onaylanmamış sepettir. Geçmiş için taşıyabilirsiniz, ama bir rapora ya da ERP beslemesine asla girmesinler.

Prova, sırasıyla

Mağazayı ayakta tutan kısım burası. Geçiş tarihini belirlemeden önce bu sırayı staging üzerinde en az bir kez baştan sona işletin:

1. 1Canlı mağazanın tam dosya ve veritabanı dökümünü alın ve geri yüklemenin başka bir yerde çalıştığını kanıtlayın. Test edilmemiş yedek yedek değil, söylentidir.
2. 2Bir staging alt alan adına OpenCart 4’ü temiz kurun; HTTP kimlik doğrulaması ve noindex başlığının arkasına alın ki asla taranamasın.
3. 3Katalog, müşteri ve siparişleri taşıyın; sonra iki tarafta da satır sayın — ürün, açıklama, kategori, sipariş, sipariş ürünü — ve her farkı hesaba katın.
4. 4Yalnızca tutmaya karar verdiğiniz 4.x eklentilerini, teker teker kurun ve her birinden sonra mağaza yüzünü kontrol edin.
5. 5Temayı yeniden kurun ve mağazayı telefondan dolaşın: ana sayfa, kategori, filtreli kategori, ürün, sepet, ödeme, hesap.
6. 6Canlıdaki her ödeme yöntemiyle sandbox modunda tam bir test siparişi geçin ve dönüş çağrısının beklediğiniz sipariş durumunu yazdığını doğrulayın.
7. 7Fatura, kargo ve ERP entegrasyonlarını staging’e yöneltin ve içinden gerçekçi bir günlük trafiği geçirin.
8. 8SEO URL’lerini canlı siteyle karşılaştırın ve değişen her şey için 301 haritası çıkarın — sıralamalar düştükten sonra değil, açılıştan önce.
9. 9Bütün işlem e-postalarını, iletişim formunu ve cron görevlerini kontrol edin; eski sunucuda sessizce çalışan özel görevler dahil.
10. 10DNS el değiştirmeden önce kategori ve arama sayfalarını zirve trafik seviyesinde yük testine sokun.

Geçiş ve kullanmak istemeyeceğiniz geri dönüş

DNS TTL’ini bir gün önceden düşürün. Dondurma penceresinde eski mağazayı bakım moduna alın, farkı taşıyın — prova dökümünden bu yana oluşan sipariş, müşteri ve yorumlar — ve sonra geçin. 3.0.x yapısını en az bir hafta boyunca çalışır ve iç bir alan adından erişilebilir tutun; fazladan sunucunun maliyeti, o sunucunun olmamasının maliyetinin yanında hiçbir şey.

Geri dönüş eşiklerini başlamadan önce yazılı olarak anlaşın ki gecenin ikisinde kimse tartışmak zorunda kalmasın. Bizimkiler genelde şunlar: ödeme tamamlama oranı otuz dakika boyunca normalin altında kalırsa, ödeme dönüş çağrıları düşerse, yönetim panelinden sipariş işlenemiyorsa veya ERP beslemesi durursa. Biri bile gerçekleşirse geri dönersiniz — taşıma önümüzdeki hafta sonu hâlâ orada olacak.

Ne zaman bize yazın

Mağazanız ciddi bir sipariş hacmi taşıyorsa ya da eklenti envanterinde artık kimsenin tanımadığı satırlar varsa, plana ikinci bir çift göz ucuz bir sigortadır. Lansman ücretiyle saatlik 10 $ + KDV üzerinden çalışırız, iş başlamadan önce saati yazılı olarak veririz ve ilk mesajları Pazartesi–Cumartesi 09:00–22:00 arasında iki saat içinde yanıtlarız. Eklenti listesini ve mevcut PHP sürümünü gönderin — ilk okuma için bu yeterli.