Magento Modül Geliştirme: Magento 2’de Özel Modül Ne Zaman Gerekir?

Magento modül geliştirme, platformu işinize göre şekillendirmenin en güçlü yoludur; ama her ihtiyaç için özel modül yazmak doğru değildir. Bazen hazır bir eklenti yeterlidir, bazen yalnızca bir ayar değişikliği işi çözer, bazen de gerçekten size özel bir modül gerekir. Bu yazıda Magento’da modülün ne olduğunu, hazır eklenti ile özel modül arasında nasıl karar verileceğini, iyi bir modülün nasıl geliştirildiğini ve bir Magento geliştirici ekibiyle çalışırken nelere dikkat etmeniz gerektiğini anlatıyoruz. Projenize özel geliştirme için Magento modül geliştirme sayfamızdan bize ulaşabilirsiniz.

Magento’yu henüz seçme aşamasındaysanız önce e-ticaret yazılımı nasıl seçilir yazımızdaki kriterlere göz atmanızı öneririz.

Magento’da modül nedir?

Magento’nun kendisi de modüllerden oluşur: katalog, sepet, ödeme, müşteri, CMS ve diğerleri ayrı modüllerdir. Bir modül, belirli bir işi yapan PHP sınıflarını, yapılandırma dosyalarını, veritabanı şemasını ve gerekiyorsa şablon ve stil dosyalarını bir arada tutan pakettir. Magento eklentisi (extension) dediğimiz şey de aslında bir veya birkaç modülden oluşur.

Modüler yapının en önemli avantajı, çekirdek koda dokunmadan davranış değiştirebilmektir. Magento; plugin (interceptor), observer (olay dinleyici), preference ve dependency injection gibi mekanizmalarla bir modülün başka bir modülün davranışını değiştirmesine izin verir. Çekirdek dosyaları doğrudan değiştirmek ise ilk sürüm güncellemesinde tüm değişikliklerin kaybolması demektir.

Bir Magento custom module’un yapısı

Bir özel modül genellikle app/code/Firma/ModulAdi klasöründe veya Composer paketi olarak vendor klasöründe bulunur. Tipik klasör yapısı şöyledir:

• registration.php: Modülü Magento’ya tanıtır.
• etc/module.xml: Modülün adını ve bağımlı olduğu modülleri tanımlar.
• composer.json: Paket bilgisi ve bağımlılıklar; modülün Composer ile kurulabilmesini sağlar.
• etc/di.xml: Dependency injection, plugin ve preference tanımları.
• etc/events.xml: Observer tanımları.
• etc/db_schema.xml: Bildirime dayalı (declarative) veritabanı şeması.
• etc/adminhtml/system.xml: Yönetim panelindeki yapılandırma alanları.
• Model, Api, Plugin, Observer, Controller klasörleri: İş mantığı.
• view/frontend ve view/adminhtml: Şablonlar, düzen (layout) dosyaları, JavaScript ve stiller.
• i18n: Çeviri dosyaları (ör. tr_TR.csv).
• Test: Birim ve entegrasyon testleri.

Bu yapı, iyi yazılmış bir modülün okunabilir, test edilebilir ve güncellenebilir olmasını sağlar. Bir teklif alırken geliştiricinin bu standartlara uyup uymadığını sormak, kalite hakkında hızlı bir fikir verir.

Hazır Magento eklenti mi, özel modül mü?

İhtiyaç ortaya çıktığında şu sırayla düşünmek çoğu zaman en ekonomik yoldur:

1. Magento’nun kendi özellikleri yetiyor mu? Sepet fiyat kuralları, müşteri grupları, özellik setleri, Page Builder ve çoklu mağaza ayarları pek çok ihtiyacı kod yazmadan karşılar.
2. Güvenilir bir hazır eklenti var mı? Ödeme, kargo, arama, SEO, pazaryeri gibi yaygın ihtiyaçlar için genellikle hazır çözümler bulunur.
3. Hazır eklenti küçük bir uyarlamayla işi görüyor mu? Eklentiyi değiştirmek yerine onun üzerine küçük bir uyarlama modülü yazmak, güncellemeleri korur.
4. Hiçbiri yetmiyorsa: Özel modül geliştirin.

Üç örnek ihtiyaç ve doğru çözüm

Aşağıdaki örnekler gerçek müşteri vakaları değil; karar mantığını göstermek için seçilmiş tipik durumlardır.

• “Belirli bir tutarın üzerinde kargo bedava olsun.” Bu ihtiyaç için kod gerekmez. Magento’nun ücretsiz kargo yöntemi veya sepet fiyat kuralı ile panelden ayarlanır.
• “Ürün sayfasında tahmini teslim tarihi gösterelim.” Hazır eklentiler bulunur. Ancak teslim süreniz depoya ve kargo firmasına göre değişiyorsa, eklentinin üzerine küçük bir uyarlama modülü gerekebilir.
• “Bayiler kendi cari bakiyelerini görsün ve bakiyeyle sipariş versin.” Bu, ERP’deki cari hesaplara bağlı, size özel bir süreçtir. Özel modül ve entegrasyon geliştirmek doğru yoldur.

Bu basit ayrım, gereksiz geliştirme maliyetini önlemenin en etkili yoludur. Geliştirme ekibinizden her talep için önce “bunu ayarla yapabilir miyiz?” sorusunun cevabını isteyin.

Magento modül geliştirme ne zaman gerekir?

Deneyimlerimize göre özel modül ihtiyacı en çok şu durumlarda ortaya çıkar:

Size özel entegrasyonlar

ERP, muhasebe, depo yönetimi veya kendi iç sistemlerinizle bağlantı genellikle özel geliştirme gerektirir. Hazır entegrasyon eklentileri standart senaryoları kapsar; ama ürün ve fiyat yapınız, stok mantığınız veya sipariş akışınız farklıysa uyarlama kaçınılmazdır. Pazaryeri tarafını pazaryeri entegrasyonu nedir yazımızda anlattık.

Özel fiyatlandırma ve sipariş kuralları

Ölçüye göre hesaplanan fiyatlar, bayi bazlı özel iskontolar, minimum sipariş kuralları veya karmaşık kampanya mantıkları standart kurallarla çözülemiyorsa özel modül gerekir.

Türkiye’ye özgü ihtiyaçlar

Yerel adres yapısı, e-fatura ve e-arşiv akışı, belirli kargo firmalarıyla özel anlaşmalar veya yerel ödeme kuruluşlarıyla özel senaryolar için hazır eklentiler her zaman yeterli olmaz.

Yönetim panelinde operasyon kolaylığı

Sipariş hazırlama, toplu işlem, özel raporlar veya ekip içi onay akışları gibi operasyonel ihtiyaçlar, panelde küçük ama çok zaman kazandıran özel ekranlarla çözülebilir.

Hazır eklentinin performans veya güvenlik sorunu

Bir eklenti siteyi yavaşlatıyor, güncellemeleri engelliyor veya güvenlik açığı yaratıyorsa, ihtiyacınız olan küçük kısmını yeniden yazmak çoğu zaman daha sağlıklıdır.

İyi bir Magento modülü nasıl geliştirilir?

• Çekirdeğe dokunmayın: Değişiklikler plugin, observer ve dependency injection ile yapılmalı; çekirdek veya eklenti dosyaları doğrudan düzenlenmemelidir.
• Servis sözleşmeleri kullanın: Api klasöründeki arayüzler, modülün diğer sistemlerle güvenli şekilde konuşmasını sağlar.
• Bildirime dayalı şema: Veritabanı değişiklikleri db_schema.xml ile tanımlanmalı, el ile SQL çalıştırılmamalıdır.
• Yapılandırılabilirlik: Değişebilecek değerler kodun içine gömülmek yerine panelden ayarlanabilmelidir.
• Önbellek dostu: Vitrine eklenen bloklar tam sayfa önbelleğini bozmamalıdır.
• Kodlama standartları: Magento Coding Standard ile otomatik kontrol, kalitenin ölçülebilir bir göstergesidir.
• Testler: Kritik iş mantığı için birim ve entegrasyon testleri yazılmalıdır.
• Sürüm kontrolü ve dokümantasyon: Kod Git’te tutulmalı, kurulum ve yapılandırma adımları yazılı olmalıdır.

Modül geliştirmede güvenlik

Özel modüller, sitenizin saldırı yüzeyinin bir parçasıdır. Özellikle dış sistemlerden veri alan, dosya yükleyen veya yönetim paneline yeni ekranlar ekleyen modüllerde şu kurallar önemlidir:

• Kullanıcıdan veya dış sistemden gelen her veri doğrulanmalı ve çıktıda kaçış (escape) uygulanmalıdır.
• Panel ekranları Magento’nun yetki sistemi (ACL) ile korunmalı; her yönetici her ekranı görmemelidir.
• Formlarda Magento’nun form anahtarı (CSRF koruması) kullanılmalıdır.
• API anahtarları ve parolalar kodun içine yazılmamalı, şifreli yapılandırma alanlarında tutulmalıdır.
• Veritabanı sorguları Magento’nun veri erişim katmanı üzerinden yapılmalı, ham SQL birleştirmesinden kaçınılmalıdır.

Sık yapılan hatalar

• Çekirdek dosyaları değiştirmek: İlk güncellemede tüm değişiklikler kaybolur.
• Aynı işi yapan birden fazla eklenti kurmak: Çakışmalar ve beklenmedik hatalar ortaya çıkar.
• Kapsamı yazılı hale getirmemek: Beklenti ile teslim edilen iş arasında fark oluşur.
• Test ortamı olmadan geliştirmek: Hatalar doğrudan müşterilerinize yansır.
• Kaynak kodu teslim almamak: Geliştiriciyle yollarınız ayrıldığında modülü kimse sürdüremez.

Magento eklentisi seçerken nelere dikkat etmeli?

Hazır eklenti yolunu seçtiyseniz şu kontrolleri yapın:

1. Sürüm uyumu: Eklenti kullandığınız Magento sürümüyle ve PHP sürümüyle uyumlu mu? Ekim 2026 itibarıyla güncel sürüm 2.4.9 ve test edilen PHP sürümü 8.5’tir.
2. Güncelleme geçmişi: Son güncelleme ne zaman yapılmış? Uzun süredir güncellenmeyen eklentiler risklidir.
3. Kaynak ve satıcı: Adobe Commerce Marketplace’te yayınlanan eklentiler bir inceleme sürecinden geçer; yine de kodu kurulumdan önce incelemek iyi bir pratiktir.
4. Tema uyumu: Hyvä gibi alternatif bir tema kullanıyorsanız eklentinin bu temayla uyumlu olup olmadığını sorun.
5. Destek ve lisans: Yıllık destek yenilemesi var mı, kaç alan adında kullanılabilir?
6. Test ortamında deneme: Hiçbir eklentiyi doğrudan canlı siteye kurmayın.

Özel modül projesi nasıl yürütülür?

1. İhtiyaç tanımı: İş süreci, kullanıcılar, girdiler ve beklenen çıktılar yazıya dökülür.
2. Teknik analiz: Mevcut özellikler ve eklentiler değerlendirilir, çözüm yaklaşımı belirlenir.
3. Kapsam ve tahmin: Neyin yapılıp neyin yapılmayacağı netleştirilir.
4. Geliştirme: Kod sürüm kontrolünde, test ortamında geliştirilir.
5. Test ve kabul: İş ekibi gerçek senaryolarla test eder.
6. Yayın ve izleme: Canlıya alınır, hata kayıtları ve performans izlenir.
7. Bakım: Magento sürüm güncellemelerinde modülün uyumu kontrol edilir.

Vitrin tarafında modül: tema ile birlikte düşünün

Ziyaretçinin gördüğü bir özellik ekleyen modüller (ör. ürün sayfasında hesaplayıcı, özel filtre, kampanya bandı) temayla doğrudan ilişkilidir. Luma tabanlı bir temada çalışan arayüz kodu, Hyvä temasında çoğu zaman yeniden yazılmalıdır; çünkü iki tema farklı JavaScript yaklaşımları kullanır. Bu yüzden vitrine dokunan bir modül planlarken hangi temada çalışacağını baştan belirtin. İş mantığını (fiyat hesabı, veri) modülün arka tarafında, görünümü ise temaya uygun ayrı bir katmanda tutmak, ileride tema değiştirdiğinizde yalnızca görünüm kısmının yenilenmesini sağlar.

Bir Magento geliştirici veya ekip seçerken

Özel modül, sitenizin uzun vadede bakımını yapacak kişilerin okuyabileceği kalitede olmalıdır. Geliştirici veya ekip seçerken şu soruları sorun:

• Kod kimin mülkiyetinde olacak, kaynak kod ve Git erişimi size verilecek mi?
• Kodlama standartları ve testler uygulanıyor mu?
• Sürüm güncellemelerinde modül uyumu nasıl sağlanacak?
• Daha önce benzer kapsamda hangi işleri yaptılar (referansları kendiniz doğrulayın)?
• Dokümantasyon teslim edilecek mi?

Unvanlardan çok iş yapış biçimine bakın: Kod incelemesi, test ortamı ve sürüm kontrolü olmayan bir süreçte yazılan modül, ilk güncellemede başınızı ağrıtır.

Teslimden sonra: bakım ve dokümantasyon

Bir modülün yaşam döngüsü teslimle bitmez. Magento her yeni sürümde PHP sürümünü, kütüphaneleri ve bazı iç yapıları günceller; özel modüllerin bu değişikliklere uyumlu kalması gerekir. Örneğin 2.4.9 ile birlikte test edilen PHP sürümü 8.5 oldu. Daha eski PHP sürümleri için yazılmış kodlar güncelleme sırasında uyarı veya hata verebilir. Bu yüzden her modül için kısa bir teknik doküman (ne yapar, hangi ayarları vardır, hangi modüllere bağlıdır, nasıl test edilir) hazırlanmalı ve sürüm güncellemesi planına dahil edilmelidir. Dokümanı olan bir modülü yeni bir geliştiricinin devralması çok daha kolaydır.

Maliyeti ne belirler?

Özel modül maliyeti; iş mantığının karmaşıklığına, entegre olunacak sistemlerin sayısına ve dokümantasyon kalitesine, vitrinde arayüz gerekip gerekmediğine, test kapsamına ve sonrasındaki bakım ihtiyacına göre değişir. Teklifleri karşılaştırırken aynı kapsamı tarif ettiklerinden ve bakım maliyetinin ayrıca belirtildiğinden emin olun. Genel maliyet çerçevesi için e-ticaret sitesi fiyatları yazımıza bakabilirsiniz.

Sonuç

Magento modül geliştirme, doğru kullanıldığında platformu işinize tam uyan bir sisteme dönüştürür. Ancak önce Magento’nun kendi özelliklerini, ardından güvenilir hazır eklentileri değerlendirin; özel modülü, gerçekten size özel bir süreç olduğunda tercih edin. Her durumda çekirdeğe dokunmayan, test edilmiş ve belgelenmiş kod uzun vadede en ucuz çözümdür.

Özel modül veya eklenti uyarlaması ihtiyacınızı değerlendirmek için Magento geliştirme sayfamızı inceleyin. Ekibinizin Magento yapısını öğrenmesi için birebir Magento 2 eğitimi de veriyoruz.

Sık Sorulan Sorular

Magento extension ile modül aynı şey mi?

Pratikte büyük ölçüde evet. Magento eklentisi (extension) bir veya birkaç modülden oluşan pakettir. Modül, belirli bir işi yapan kod, yapılandırma ve şablon dosyalarını bir arada tutan temel birimdir.

Magento custom module ne zaman gerekir?

Magento'nun kendi özellikleri ve güvenilir hazır eklentiler ihtiyacınızı karşılamıyorsa özel modül gerekir. En sık örnekler size özel ERP entegrasyonları, karmaşık fiyat ve sipariş kuralları, Türkiye'ye özgü süreçler ve operasyonel panel ekranlarıdır.

Hazır Magento eklentisini değiştirmek doğru mu?

Eklenti dosyalarını doğrudan değiştirmek, eklentinin bir sonraki güncellemesinde değişikliklerin kaybolmasına yol açar. Doğru yöntem, eklentinin üzerine plugin veya preference kullanan küçük bir uyarlama modülü yazmaktır.

Özel modül sürüm güncellemelerinde sorun çıkarır mı?

Çekirdeğe dokunmadan, servis sözleşmeleri ve standart mekanizmalarla yazılmış modüller güncellemelerde genellikle az sorun çıkarır. Yine de her sürüm güncellemesinde modülün test ortamında denenmesi gerekir.

Magento eklentisi seçerken nelere bakmalıyım?

Magento ve PHP sürüm uyumu, son güncelleme tarihi, satıcının güvenilirliği, kullandığınız temayla uyum, destek ve lisans koşulları başlıca kriterlerdir. Her eklentiyi önce test ortamında deneyin.