# Bir güncelleme eklentiyi bozduğunda ya da değişikliklerinizi sildiğinde

> Eklenti çalışıyordu, önerilen güncellemeyi kabul ettiniz ve o zamandan beri çalışmıyor — ya da çalışıyor ama sizin için yapılan uyarlamalar kayboldu. Bu şanssızlık değildir: bir ana sürüm değişikliği eklentinin yapılandırmasını, tablolarını ve dosyalarını yeniden yazar; bu geçiş, ömrünün en kırılgan anıdır.

- Source canonique : [https://allaux.fr/tr/modules/module-casse-apres-une-mise-a-jour](https://allaux.fr/tr/modules/module-casse-apres-une-mise-a-jour)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Doğrudan yanıt

> Güncellemeyi yeniden başlatmayın: yarım kalmış bir yükseltme betiğini tekrar çalıştırmak veritabanının durumunu daha da bozar. Önce gerçek hatayı var/logs/ (1.7, 8, 9) klasöründe ya da sunucunun PHP günlüğünde okuyun; eksik metot veya sütun adıyla belirtilir. Ardından modülün ps_configuration satırlarını güncelleme öncesi alınan yedekle karşılaştırın.

## Bir eklenti güncellemesi gerçekte ne yapar

Bir eklentiyi güncellemek yalnızca dosyaları değiştirmek değildir. PrestaShop'ta da WordPress'te de iyi yazılmış bir eklenti bu sırada bir yükseltme yordamı çalıştırır: veritabanına sütun ekleyebilir, yapılandırma anahtarlarını yeniden adlandırabilir, eski ayarları yeni bir biçime taşıyabilir ya da başka görüntüleme noktalarına bağlanabilir.

Üç şey ters gidebilir. Yordam yarı yolda kesilir ve veritabanı, eklentinin okuyamadığı bir ara duruma düşer. Eski ayarlar aktarılmaz ve eklenti varsayılan değerleriyle yeniden başlar; bu da hiçbir şey yapmıyormuş izlenimi verir. Ya da yeni sürüm sizinkinden yüksek bir PHP veya platform sürümü ister ve yüklenirken sessizce başarısız olur.

En kafa karıştırıcı durum, eklentinin çalışıyor görünmesine karşın ayarlarının yalnızca bir bölümünün sağ kalmasıdır. Yalnızca kaybolmuş bir yapılandırmanın olduğu yerde hata ararsınız.

## Ne yapmalı ve hangi sırayla

1. **Güncellemeyi art arda yeniden başlatmayın** — Yarı yolda başarısız olmuş bir yükseltme yordamını yeniden çalıştırmak, zaten yapılmış işlemleri tekrarladığı için veritabanının durumunu ağırlaştırabilir. Bir ara durum onarılır, üç kez tekrarlanmış bir durum çok daha zor onarılır.
2. **Sunucunun hata günlüğünü okuyun** — Karşılanmayan bir sürüm koşulu, eksik bir yöntem ya da var olmayan bir sütun orada adıyla görünür. Uyumsuzluğu kaybolmuş ayardan ayıran budur.
3. **Yapılandırmayı önce ve sonra karşılaştırın** — Önceki bir yedeğiniz varsa eklentinin yapılandırma değerleri oradadır ve karşılaştırılabilir. Tam açıklama çoğu zaman oradadır.
4. **Mümkünse önceki sürüme dönün** — Sürüm düşürmek yalnızca veritabanı yükseltmeyle değişmediyse güvenlidir. Aksi hâlde tam bir site yedeğini geri yüklemek, güvenilir tek geri dönüş yoludur.

## Geri dönüş bakışımlı değildir

> Bir eklentinin eski dosyalarını geri koymak, güncellemenin veritabanında yaptığı değişiklikleri geri almaz. Yeni bir yapıyı okuyan eski bir eklenti, ilkinden farklı hatalar üretir ve bir sorun yerine iki sorunla kalırsınız. Bu yüzden dosya ve veritabanını birlikte kapsayan tam yedek önceden alınır, sonradan değil.

## Ödeme ve kargo eklentilerinin özel durumu

Bunlar ayrı bir ilgiyi hak eder, çünkü arızaları ana sayfada değil sipariş akışının son adımında, yani satışı yitirdiğiniz yerde görünür. Yeni bir ana sürüm, eklentinin sağlayıcıdan gelen bildirimleri alma biçimini sıkça değiştirir ve bu bildirimler mağazanızda değil, sağlayıcıda kayıtlı bir adrese ulaşır. Güncelleme bu adresi değiştiriyorsa iki tarafta da güncellenmesi gerekir.

Bir ödeme eklentisinin her güncellemesinden sonra üretim koşullarında baştan sona gerçek bir sipariş verir ve siparişin doğru durumla oluştuğunu denetlerim. Bir şeyi kanıtlayan tek deneme budur.

## Öteki sonuç: değişikliklerinizi silen güncelleme

Ters belirti de vardır ve çoğu zaman öncekiyle karıştırılır: eklenti bozulmamıştır, yalnızca eski hâline dönmüştür. Güncelleme, eklentinin dosyalarını yeni sürümdekilerle değiştirir. Karşılaştırmaz, birleştirmez, üzerine yazar. Eklenti klasörünün içine yazılmış her şey uyarısız ve izsiz kaybolur. İmzası tanıdıktır: yılda iki kez, her zaman bir bakım işleminden sonra kaybolan ve aradaki süre uzun olduğu için kimsenin güncellemeyle ilişkilendirmediği özel bir işlev.

İkinci etkisi daha sinsidir: değişiklik ayakta kaldığı sürece güncellemeleri fiilen engeller. Kimse onu yeniden yitirmek istemediği için eklenti eski bir sürümde kalır, uyumsuzlukları biriktirir ve güncellemenin kaçınılmaz olduğu gün, yukarıda anlatılan arızanın tam olarak daha kötüsünü üretir.

Bir eklenti hiçbir genişletme noktası bildirmiyor ve çıktısını geçersiz kılınabilir bir şablondan geçirmeden kuruyorsa zarif bir çözüm yoktur; tersini düşündürmektense bunu söylemeyi yeğlerim. Geriye tercih sırasıyla üç seçenek kalır: eklentinin yayıncısından bir genişletme noktası eklemesini istemek, bedelsizdir ve bazen kabul edilir; eklentiyi başka bir adla çoğaltıp kendi eklentiniz olarak sahiplenmek, güncellemelerinden vazgeçtiğinizi ve bakımcısı hâline geldiğinizi bilerek; ya da değişikliği belgelenmiş bir yama olarak ayrı tutup her güncellemeden sonra yeniden uygulamak. Yapmadığım şey: bir eklentiyi değiştirip hiçbir şey söylememek. Altı ay sonra birinin güncelleyeceği bir kodun içindeki belgelenmemiş bir değişiklik, sonraki kişi için bir tuzaktır; o kişi ben olduğumda bile.

## Bir eklentiyi değiştirmeden uyarlamanın dört yolu

- **Öngörülmüş genişletme noktalarını kullanmak** — Birçok eklenti kendi bağlantı noktalarını bildirir. Düzgün yazılmış bir üçüncü taraf eklenti, tek satırına dokunulmadan dışarıdan tamamlanabilir.
- **Şablonu tema üzerinden geçersiz kılmak** — PrestaShop'ta bir tema, bir eklentinin şablonunun kendi sürümünü sunabilir. WooCommerce'de eşdeğer mekanizma alt temadaki özel bir klasörden geçer. Değişiklik böylece eklentide değil temada yaşar. ([/guides/creer-theme-enfant-wordpress](/guides/creer-theme-enfant-wordpress))
- **Küçük bir tamamlayıcı eklenti yazmak** — Özgün eklentiden sonra bağlanıp sonucunu değiştiren özel bir eklenti. Değişiklik yalnızca görüntüyü değil davranışı ilgilendirdiğinde en temiz çözüm budur. ([/guides/override-ou-module-prestashop](/guides/override-ou-module-prestashop))
- **Çeviri sistemini kullanmak** — Değişiklik yalnızca bir metni ilgilendiriyorsa, bunun için var olan ve güncellemelerden sağ çıkan platform çeviri sisteminden geçer.

## Değiştirmeden önce lisansın ne dediğini denetleyin

> Bazı ticari eklenti lisansları değişikliği yasaklar ve izinsiz bir değişiklik, tam ihtiyacınız olduğu anda desteği kesebilir. Bunu denetlemek beş dakika sürer ve bir arıza gününde kötü sürprizi önler.

## İlgili sayfalar

- **Bir eklentiyi üretimden önce denemek** — Sorunu bütünüyle önlemenin yolu: önce bir kopyada güncellemek. ([/modules/tester-un-module-avant-la-production](/modules/tester-un-module-avant-la-production))
- **Müdahaleden önce mağazayı yedeklemek** — Geri dönüşü mümkün kılan yedek: dosyalar ve veritabanı birlikte. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))
- **Güncellemeden sonra kaybolan ödeme yöntemi** — Ödeme eklentisinin sipariş akışında artık görünmediği özel durum. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Başarısız güncellemeden sonra geri yükleme** — WordPress ve WooCommerce tarafındaki toparlanma yordamı. ([/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee](/wordpress-woocommerce/mise-a-jour/restaurer-apres-mise-a-jour-ratee))
- **Özel bir eklentiyi zaman içinde sürdürmek** — Sizin için yazılan bir eklentinin, değiştirilmeden uyarlanabilir kalacak biçimde nasıl tasarlandığı. ([/modules/maintenir-un-module-dans-le-temps](/modules/maintenir-un-module-dans-le-temps))

## FAQ

### Eklenti güncellemelerini reddetmeli miyim?

Hayır. Güncellenmeyen bir eklenti sonunda platformla uyumsuz hâle gelir ve bilinen açıklar taşıyabilir. Kaçınılması gereken, yedeksiz ve önceden denenmeden doğrudan üretime uygulanan güncellemedir.

### Eklenti güncellemeden beri veritabanı hatası veriyor

Bu, yarıda kesilmiş bir yükseltme yordamının imzasıdır: beklenen bir sütun ya da tablo yoktur. Çözüm, eksik göçü tamamlamaktır; eklentiyi yeniden kurmak değil, çünkü bu mevcut verileri yitirir.

### Ayarlarım kayboldu, geri alınabilir mi?

Eski anahtarlarıyla hâlâ veritabanındaysa ya da önceki bir yedekte duruyorsa çoğu zaman evet. Bu, eklentinin kendisini düzeltmekten ayrı bir veri kurtarma işidir.

### Kurmadan önce yeni sürümün uyumlu olduğunu nasıl anlarım?

Eklentinin tanıtımı gerektirdiği platform ve PHP sürümlerini belirtir; eklentiyle birlikte gelen tanım dosyası da bunları içerir. İkisi çelişirse geçerli olan, teslim edilen dosyadır.

### Değişikliklerimin silindiğini nasıl anlarım?

Eklentinin dosyalarını yayımlanmış sürümle karşılaştırarak: farklar hemen göze çarpar. Sürüm denetimi olmayan bir sitede tek yol budur ve değişiklikleri eklentinin dışına koymamın nedeni de budur.

### Temadaki şablon geçersiz kılması gerçekten sağ kalır mı?

Eklenti güncellemelerinden sağ çıkar, evet. Ancak eklenti veri yapısını değiştirirse geçersiz kılınmış şablon doğru şeyi göstermeyi bırakabilir: eklentinin her ana sürüm değişikliğinden sonra yeniden denetlenmesi gerekir.