Yükseltme öncesi eklenti denetimi: Magento 2'deki teknik borcu azaltın

Magento 2 sürüm yükseltmelerinin çoğu Adobe’nin çekirdek kodunda takılmaz. Asıl takıldıkları yer; 2022'den beri kimsenin güncellemediği bir ödeme modülü, temada değiştirilmiş bir çekirdek şablon ya da aynı sınıfı yeniden yazan üç eklentidir. Yeni sürüme taşıdığınız her üçüncü taraf modülün kontrol edilmesi, güncellenmesi veya yamalanması gerekir.

Sürüm yükseltmeden önce yapılan bir eklenti denetimi, bu belirsizliği her maddenin sorumlusu ve kararı belli bir listeye dönüştürür. Bu rehberde önerdiğimiz süreci adım adım anlatıyoruz: envanter, kullanım kontrolü, uyumluluk kontrolü, çakışma kontrolü ve son olarak kaldırma.

2.4.8 ve 2.4.9 yükseltmeleri neden daha riskli

Son iki sürüm de eklentilerin bağlı olduğu platform bileşenlerini değiştirdi:

• 2.4.8 (Nisan 2025) PHP 8.4 uyumluluğu getirdi, PHP 8.1 desteğini kaldırdı ve aramayı OpenSearch'e taşıdı; artık Elasticsearch ile uyumlu değil. Ayrıca bazı Laminas bağımlılıklarını başka bileşenlerle değiştirdi.
• 2.4.9 (Mayıs 2026) PHP 8.5 desteği getiriyor, PHP 8.2 ve 8.3 desteğini kaldırıyor. Adobe’nin sürüm notlarına göre Laminas MVC yerine yerel bir MVC yapısı, Zend_Cache yerine Symfony Cache bileşeni geliyor; WYSIWYG editörü de TinyMCE'den HugeRTE'ye geçiyor.

Bu kütüphaneleri doğrudan çağıran, kendi Elasticsearch adaptörünü içeren veya editörü özelleştiren her eklenti kontrol edilmeli. Destek süreleri de zamanı daraltıyor: Adobe’nin yaşam döngüsü politikasına göre 2.4.6'nın standart desteği 11 Ağustos 2026'da, 2.4.7'ninki ise 31 Mayıs 2027'de sona eriyor.

Adım 1: Eksiksiz bir modül envanteri çıkarın

Önce Magento'nun kurulu ve etkin gördüğü modülleri listeleyin:

bin/magento module:status --enabled  > modules-enabled.txt
bin/magento module:status --disabled > modules-disabled.txt

Ardından Composer'ın doğrudan kurduğu paketleri sürümleri ve açıklamalarıyla listeleyin:

composer show --direct
composer show --direct --format=json > composer-direct.json

Son olarak Composer dışında kalan kodu bulun:

ls app/code/*/

Hepsini tek bir tabloda toplayın. Listeden Magento_* çekirdek modüllerini ve Adobe’nin pakete dahil ettiği modülleri çıkarın; ardından üretici, kurulu sürüm, güncel sürüm, kaynak (Composer veya app/code), iş tarafındaki sorumlu ve karar (koru, güncelle, değiştir veya kaldır) için sütunlar ekleyin.

Adım 2: Kullanılmayan ve terk edilmiş eklentileri bulun

Kullanılmayanlar

Devre dışı modüller işin en kolay kısmıdır. Bir modül aylardır kapalıysa ve kimse yokluğunu fark etmemişse, kaldırılmasını planlayın. Etkin modüllerde ise gerçekten kullanıldıklarına dair kanıt arayın:

• Özellik mağaza ön yüzünde veya günlük yönetim paneli işlerinde görünüyor mu? Mağazayı yöneten kişilere sorun.
• Veritabanı tablolarında yakın tarihli kayıtlar var mı?
• Cron görevi cron_schedule tablosunda görünüyor ve işe yarar bir iş yapıyor mu?
• Modül etkin olduğu hâlde özellik ayarlardan kapatılmış mı?

# Tables created by a vendor, with row counts
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name LIKE 'vendorprefix_%';

# Is the module's cron running?
SELECT job_code, status, MAX(executed_at)
FROM cron_schedule WHERE job_code LIKE 'vendorprefix_%'
GROUP BY job_code, status;

Terk edilmiş veya bakımı yapılmayanlar

composer outdated --direct
composer audit

composer outdated hangi paketlerin daha yeni sürümleri olduğunu gösterir ve terk edilmiş (abandoned) olarak işaretlenen paketleri belirtir. composer audit kurulu sürümleri bilinen güvenlik bildirimleriyle karşılaştırır. Her eklenti için üreticinin değişiklik kaydını (changelog) ve son sürümün tarihini de kontrol edin. Hedef PHP sürümünüzü destekleyen bir sürümü olmayan modül, değiştirilecekler listesine girer.

Adım 3: Hedef sürümle uyumluluğu kontrol edin

Composer kısıtlamaları

Hiçbir şeyi değiştirmeden önce yükseltmeyi neyin engellediğini Composer'a sorun:

composer why-not magento/product-community-edition 2.4.9
composer why-not php 8.4

Kodu aktif olarak değiştirdiğiniz yerel ve test (staging) ortamlarında magento/product-enterprise-edition (Adobe Commerce için). Çıktı, kısıtlamaları hedef sürümle çakışan tüm paketleri listeler. Bu liste, yükseltme için yapılacak işler listenizdir.

Upgrade Compatibility Tool (Adobe Commerce)

Adobe’nin Upgrade Compatibility Tool'u (UCT), bir kurulumdaki modülleri ve çekirdek kodu hedef sürüme göre analiz eder ve kritik sorunları, hataları ve uyarıları raporlar. Adobe’nin dokümantasyonuna göre araç yalnızca Adobe Commerce kurulumlarında kullanılabilir ve şu adresten kurulur: repo.magento.com:

composer create-project magento/upgrade-compatibility-tool uct --repository https://repo.magento.com
chmod +x ./uct/bin/uct

# Check custom code against a target version
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9

# Only show new problems introduced by the upgrade
./uct/bin/uct upgrade:check /var/www/magento -c 2.4.9 \
  --ignore-current-version-compatibility-issues --min-issue-level=error

# Find modified core files
./uct/bin/uct core:code:changes /var/www/magento /path/to/vanilla

Rapora güvenmeden önce UCT sürümünüzün, kontrol ettiğiniz hedef sürümü desteklediğinden emin olun.

PHP sürüm kontrolleri (Open Source ve Commerce)

Magento Open Source'ta veya UCT'ye ek olarak, üçüncü taraf kod üzerinde PHP_CodeSniffer ve PHPCompatibility standardıyla statik bir PHP uyumluluk taraması çalıştırın:

vendor/bin/phpcs -p --standard=PHPCompatibility \
  --runtime-set testVersion 8.4- app/code vendor/vendorname

Kurduğunuz PHPCompatibility sürümünün hedef PHP sürümünüz için sniff'leri içerdiğini kontrol edin. Statik taramalar çalışma anında ortaya çıkan sorunları yakalayamaz; bu yüzden mağazayı test ortamında, deprecation logları açıkken hedef PHP sürümüyle de çalıştırın.

PHP 8.4'e geçerken sık karşılaşılan bulgular arasında şu tür örtük nullable parametreler yer alır: function foo(Bar $bar = null); PHP 8.4 bu yazımı kullanımdan kaldırır (deprecated) ve yerine şunu önerir: ?Bar $bar = null. PHP 8.5 ise yeni kullanımdan kaldırmalar getirir; örneğin standart dışı tür dönüşümleri (integer) ve (boolean) ile null değerinin dizi anahtarı (offset) olarak kullanılması.

Adım 4: Plugin ve preference çakışmalarını bulun

Preference'lar bir çekirdek sınıfın yerini tamamen alır; bu yüzden aynı sınıf için yalnızca bir modülün preference'ı geçerli olur. Sık çalışan kod yollarındaki around plugin'ler birbirini bozabilir ve mağazayı yavaşlatabilir. Bunları listeleyin:

# Preferences declared by third-party code
grep -rn "<preference" app/code vendor/*/*/etc --include=di.xml | grep -v "vendor/magento"

# Full DI picture for a class that several modules touch
bin/magento dev:di:info "Magento\Checkout\Model\ShippingInformationManagement"

dev:di:info komutu; etkin preference'ı, constructor argümanlarını ve sınıftaki tüm plugin'leri türleriyle (before, after, around) gösterir. Birden fazla üreticiden preference alan çekirdek sınıfları ve birden fazla around plugin'i olan sınıfları işaretleyin. Yükseltmeden sonra ilk test etmeniz gereken yerler bunlardır.

Temanızda çekirdek dosyaları ezen şablon ve layout override'larını da arayın. Değiştirilmiş bir çekirdek şablon derlemeyi bozmaz, ancak yeni HTML yapısını, CSP nonce'larını veya güvenlik düzeltmelerini fark ettirmeden devre dışı bırakabilir.

Adım 5: Eklentileri çekirdek özelliklerle değiştirin

Bazı eklentiler, Magento'da o dönem eksik olan ve sonradan çekirdeğe eklenen özellikleri karşılamak için satın alındı. Kontrol etmeye değer tipik örnekler:

Değiştirme otomatik olmaz: özellikleri karşılaştırmanız, verileri taşımanız ve kullanıcıları yeniden eğitmeniz gerekir. Ama çıkardığınız her modül, gelecekteki her sürüm yükseltmesinde bir bağımlılık daha az demektir.

Adım 6: Eklentileri güvenli şekilde kaldırın

1. Yedek alın (veritabanı ve kod).
2. Önce test ortamında devre dışı bırakın ve eksiksiz bir regresyon testi yapın: ödeme sayfası, ödemeler, yönetim panelinden sipariş oluşturma, içe aktarımlar ve entegrasyonlar.
3. Saklamanız gereken verileri kontrol edin; örneğin modülün kaydettiği özel nitelikler, sipariş alanları veya müşteri verileri.
4. Kodu kaldırın. Composer ile kurulan modüller için:

bin/magento maintenance:enable
bin/magento module:disable Vendor_Module
composer remove vendor/module-package
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento maintenance:disable

Alternatif olarak bin/magento module:uninstall Vendor_Module --backup-db komutu, composer remove işlemini sizin yerinize yapar ve --remove-data’yla birlikte kullanıldığında modülün kendi kaldırma rutinini de çalıştırır. Bu yöntem yalnızca Composer ile kurulan modüllerde işe yarar. app/code’daki modüller içinse önce bunları devre dışı bırakın, dizini silin, ardından şunu çalıştırın: setup:upgrade.

5. Kalıntıları temizleyin ama dikkatli olun: sahipsiz tablolar, core_config_data kayıtları ve EAV nitelikleri. Verileri yalnızca iş tarafındaki sorumlu onay verdikten sonra silin.
6. Canlı ortama alın ; platform yükseltmesinden önce ve ayrı bir yayın olarak. Böylece sorunların kaynağını birbirinden ayırt edebilirsiniz.

Sıkça sorulan sorular

Upgrade Compatibility Tool, Magento Open Source için kullanılabilir mi?

Hayır. Adobe’nin dokümantasyonuna göre Upgrade Compatibility Tool yalnızca Adobe Commerce kurulumlarında kullanılabilir. Open Source projeleri Composer’ın why-not, PHPCompatibility taramalarını ve test ortamında bir deneme yükseltmesini bir arada kullanabilir.

Kullanılmayan bir eklentiyi devre dışı mı bırakmalıyım, yoksa kaldırmalı mıyım?

Kaldırın. Devre dışı bir modül kod tabanınızda durmaya devam eder, Composer kısıtlamalarıyla yine çakışabilir ve bağımlılıkları değiştiğinde yine güncelleme gerektirir.

Bir eklenti denetimi ne kadar sürer?

Kaç üçüncü taraf modül kullandığınıza ve bunların ne kadar iyi belgelendiğine bağlıdır. Envanterin kendisi yukarıdaki komutlarla hızlıca çıkarılır. Asıl zaman, iş tarafıyla yapılan kullanım kontrollerine ve alternatiflerin test edilmesine harcanır.

PHP ve Magento 2'yi aynı anda yükseltebilir miyiz?

Yükseltme yolunuz için desteklenen kombinasyonları kontrol edin. 2.4.8 canlı kullanım için PHP 8.3 veya 8.4 gerektirir; 2.4.9 ise PHP 8.5'i tam olarak destekler, PHP 8.4'e yalnızca yükseltme sürecinde izin verir. Birçok ekip önce her iki sürümün de desteklediği bir PHP sürümünde hedef Magento sürümüne geçer, ardından PHP'yi ayrı bir adımda yükseltir.

Kaynaklar

• Adobe Commerce 2.4.8 sürüm notları
• Adobe Commerce 2.4.9 sürüm notları
• Adobe Experience League: Yayınlanan sürümler
• Adobe Experience League: Yazılım yaşam döngüsü politikası
• Adobe Experience League: Upgrade Compatibility Tool'a genel bakış
• Adobe Experience League: Upgrade Compatibility Tool'u çalıştırma
• Adobe Experience League: bin/magento CLI başvuru kılavuzu
• Adobe Experience League: Modülleri kaldırma
• Adobe Developer: Dependency injection yapılandırması
• PHP kılavuzu: PHP 8.4'te kullanımdan kaldırılan özellikler
• PHP kılavuzu: PHP 8.5'te kullanımdan kaldırılan özellikler