# Özel bir PrestaShop eklentisinin geliştirilmesi

> Piyasadaki hiçbir eklenti bir iş ihtiyacını tam olarak karşılamadığında, PrestaShop'un kaynak koduna doğrudan değişiklik yapma cazibesi doğar. Bu, bir sonraki güncellemede her şeyi kaybetmenin garantisidir. Özel bir eklenti bu tuzağı önler.

- Source canonique : [https://allaux.fr/tr/prestashop/module-sur-mesure](https://allaux.fr/tr/prestashop/module-sur-mesure)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Çekirdek dosyalarına dokunmayın: bir modül oluşturun, install() metodunun içinde registerHook() ile ihtiyaca karşılık gelen hook’a bağlayın ve sürüm aralığını config.xml içinde bildirin. Bir fiyat kuralı için bu genellikle actionCartSave ya da ürün gösterim hook’udur; bir senkronizasyon için actionValidateOrder. Özel tablolar install() içinde Db::getInstance() ile oluşturulur.

## Bu tür bir talebi tetikleyen durumlar

- İşinize özgü, mevcut eklentilerde bulunmayan bir fiyat veya indirim hesaplaması
- PrestaShop ile bir iç araç arasında senkronizasyon (ERP, kasa, yönetim yazılımı)
- Özel alanlar veya kurallar içeren bir sipariş formu
- Belirli iş kriterlerine bağlı ürün gösterimi (stok, müşteri rolü, satış kanalı)
- Şu anda core dosyalarını doğrudan değiştirerek yapılan ve her güncellemede kaybolan değişiklikler

## Core'u değiştirmek yerine neden bir eklenti kullanmalı

PrestaShop, bir hook sistemi etrafında inşa edilmiştir: kodun içindeki bağlantı noktaları (displayHeader, actionValidateOrder, actionProductUpdate ve yüzlerce diğeri) sayesinde bir eklenti, orijinal dosyalara dokunmadan kod çalıştırmak için registerHook() ile bunlara bağlanabilir. Güncellemelerden sonra ayakta kalan bir değişiklikle ilk composer update'te veya bir sonraki sürümde bozulan bir değişiklik arasındaki fark budur.

İyi yapılandırılmış bir PrestaShop eklentisi, yapılandırmasını bir config.xml dosyasında bildirir, ana sınıfı Module'den türetilir ve install() metodu hem hook kaydını hem de gerekirse Db::getInstance() üzerinden özel tabloların oluşturulmasını yönetir. Bir yönetim ekranı eklemek gerektiğinde, mevcut arayüzü kopyalamak yerine, yönetim paneliyle tutarlı kalmak için native admin denetleyicilerini kullanıyorum.

İhtiyaca göre, değiştirilecek davranışı hiçbir hook karşılamadığında bir override da kullanıyorum, ama bunu gerçekten alternatif olmadığı durumlar için saklıyorum; çünkü kötü yönetilen bir override, güncelleme sonrası 500 hatasının en sık görülen nedenlerinden biridir.

## Bir eklentiyi nasıl inşa ediyorum

1. **İhtiyacın çerçevelenmesi** — Eklentinin tam olarak ne yapması gerektiğini, hangi ekranlarla, hangi verilerle ve mevcut sistemle hangi etkileşimlerle çalışacağını netleştiriyorum.
2. **Hook seçimi** — Sipariş, ürün veya müşteri yaşam döngüsünün doğru anında, gereksiz yük oluşturmadan devreye girmek için en uygun hook'ları belirliyorum.
3. **Geliştirme ve testler** — Üretime almadan önce, temsili veri setleriyle bir test ortamında geliştirme yapıyorum.
4. **Kısa dokümantasyon** — Gerekirse başka bir geliştiricinin projeyi devralabilmesi için, eklentinin ne yaptığına ve nasıl yapılandırılacağına dair asgari bir dokümantasyon bırakıyorum.

## Eklenti size aittir

> Geliştirilen eklentinin kaynak kodu teslim edilir ve belgelenir; çalışmaya devam etmesi için müdahaleme bağımlı değildir. Gerekirse başka bir geliştiriciyle geliştirmeye devam etme özgürlüğünüz saklıdır.

## ChatGPT Ads dönüşüm takibi

- **PrestaShop için ChatGPT Ads modülü** — Tekilleştirilmiş OpenAI pikseli ve Conversions API, siparişe kadar korunan oppref, onaya uygun: geliştiren ve kuran benim. ([/prestashop/module-chatgpt-ads](/prestashop/module-chatgpt-ads))

## Bir modülü yapay zekâ asistanıyla yönetilebilir kılmak

- **PrestaShop MCP** — Modüllerinizin işlevlerini resmî sunucuda veya özel bir MCP modülünde MCP aracı olarak sunmak. ([/prestashop/mcp](/prestashop/mcp))

## FAQ

### Özel bir eklenti PrestaShop güncellemelerine dayanıklı olur mu?

Amaç tam olarak bu: core'da değişiklik yapmak yerine native hook'lar kullanılarak, eklenti güncellemeden sonra da çalışmaya devam eder. Büyük sürüm yükseltmelerinde bir uyumluluk kontrolü yine de faydalıdır.

### Bir eklentinin geliştirilmesi ne kadar sürer?

Basit bir özellik için birkaç günden, dış bir sistemle karmaşık bir entegrasyon için birkaç haftaya kadar değişir. İhtiyacı çerçeveledikten sonra kesin bir tahmin veriyorum.

### Eklentiyi yayına alınmadan önce görebilir miyim?

Evet, geliştirme, üretime almadan önce inceleyip onaylayabileceğiniz bir test ortamında yapılır.

### Teslimattan sonra ihtiyaçlarım değişirse ne olur?

Kod okunabilir ve belgeli kaldığı, gizli bir bağımlılık içermediği için eklenti daha sonra benim veya başka bir geliştirici tarafından geliştirilmeye devam edilebilir.

### Küçük bir değişiklik için bile eklenti gerekir mi?

Her zaman değil. Çok küçük ve tek seferlik bir değişiklik için hedefli bir override yeterli olabilir. İş mantığı önemli hâle geldiğinde veya zamanla gelişmesi beklendiğinde eklenti anlamlı olur.