Güncelle Butonuna Basmadan Önce Kimsenin Sana Söylemediği 11 Kontrol: Dijital Ürün Satış Scriptini Çökertmeden Sürüm Atlamanın Gizli Sırası

Çoğu bayi güncellemeyi bir dosya kopyalama işi sanır. Panele girer, "yeni sürüm çıkmış" uyarısını görür, güncelle der ve kahvesini içmeye devam eder. Sonra bir müşteri mesaj atar: "Ödeme yaptım, kod gelmedi." Ardından ikinci, üçüncü mesaj. Meğer güncelleme sırasında ödeme bildirim dosyasının izinleri değişmiş, sipariş otomatik teslimata düşmemiş. İşin acı tarafı şu: o an kaybettiğin şey birkaç sipariş değil, bir daha geri gelmeyecek müşterinin güveni.

Gerçek şu ki bir e-pin scripti güncellemesi neredeyse hiçbir zaman dosya işi değildir. Veritabanı şeması değişir, ayar anahtarları yeniden adlandırılır, şablon dosyaları üzerine yazılır, tedarikçi API sürümü terk edilir. Bu yazıda sana yıllardır sahada tekrarlanan hataların damıtılmış hâlini vereceğim: güncelle butonuna dokunmadan önce sırayla geçmen gereken kontroller, hangi riskin hangi sonucu doğurduğu ve bakım penceresini ne zaman açman gerektiği. Bunu bir kez alışkanlığa çevirdiğinde güncelleme, korkulan bir olay olmaktan çıkıp sıradan bir bakım işine dönüşür.

Neden bir dijital ürün satış scripti güncellemesi "dosya kopyalama" değildir?

Bir dijital ürün satış scripti üç ayrı katmanda yaşar: dosyalar, veritabanı ve çalışma zamanı ortamı. Güncelleme paketleri genelde birincisini taşır, ikincisine migrasyon uygular, üçüncüsünü ise varsayar. Sorun tam burada doğar. Sende PHP sürümü farklıdır, bir eklenti kapalıdır, dosya sahipliği web sunucusu kullanıcısında değildir. Paket kendi dünyasında doğru çalışır, senin sunucunda yarım kalır. Yarım kalan bir migrasyon, hiç başlamamış migrasyondan daha tehlikelidir; çünkü veritabanın artık ne eski ne yeni sürüme uyar.

Bu yüzden güncellemeye hazırlığın ilk adımı envanter çıkarmaktır. Hangi PHP sürümünde çalışıyorsun, hangi uzantılar açık, cron görevleri hangi kullanıcı ile koşuyor, ödeme bildirim adresleri hangi dosyaya bakıyor? Bunları bir metin dosyasına yazmak on dakika alır ve arıza ânında seni saatlerce tahmin yürütmekten kurtarır. Profesyonel bir e-pin satış yazılımı kurulumunda bu envanter, sunucunun kimlik kartıdır.

Yedeğin var mı, yoksa geri dönebildiğin yedeğin mi var?

Sahada gördüğüm en yaygın yanılgı: "Yedek alıyorum, sorun yok." Sorunu şöyle netleştireyim. Yedek almak bir dosya üretmektir; kurtarma ise o dosyadan çalışan bir sistem çıkarabilmektir. İkisi arasında test edilmemiş bir uçurum vardır. Hosting panelinin gece aldığı yedek, veritabanını ürün tablolarındaki büyük BLOB alanları yüzünden yarıda kesmiş olabilir. Ya da yedeğin var ama dosya yedeğinde .env benzeri yapılandırma dışarıda bırakılmıştır.

Kural basit: güncellemeden hemen önce elle, kendi kontrolünde bir yedek al. Veritabanı dökümünü indir, boyutunu kontrol et, dosyanın sonunda tabloların kapanış satırlarının bulunduğuna bak. Dosya arşivini indir ve yerelde aç. Yedeği indirmediysen yedeğin yok sayılır; çünkü sunucu tarafında oluşan bir sorun yedeğini de birlikte götürebilir.

Staging kurmadan güncelleme yapmak neden gişeyi açıkken tavanı sökmektir?

Staging, aynı sunucuda bir alt alan adı ve ayrı bir veritabanından fazlası değildir. Maliyeti neredeyse sıfır, getirisi ise güncelleme korkusunun tamamen bitmesidir. Canlı verinin bir kopyasını alır, yeni sürümü orada çalıştırır ve sipariş akışını uçtan uca denersin: ürün sayfasına gir, sepete ekle, ödeme adımına geç, test modunda tamamlat, teslimat kaydının oluştuğunu gör.

Staging'de test ederken kendini kandırmanın klasik yolu yalnızca ana sayfaya bakmaktır. Ana sayfa her zaman açılır. Kritik olan, paranın ve kodun dokunduğu yollardır. Bir epin yazılım kurulumunda bu yollar dörttür: sepet, ödeme dönüşü, stok düşümü, sipariş bildirimi. Dördü staging'de yeşil yanmadıysa canlıya dokunmaya hazır değilsin.

Özelleştirmelerini listelemediysen güncelleme onları sessizce siler

Zamanla her işletme scriptine dokunur. Bir şablona WhatsApp butonu eklersin, bir sınıfa özel indirim kuralı yazarsın, faturaya kendi ibaresini basarsın. Bu dokunuşlar tek tek küçüktür ama toplamı senin işini rakiplerinden ayıran şeydir. Güncelleme paketi ise senin dokunduğun dosyanın orijinal hâlini geri koyar ve o fark bir gecede buharlaşır.

Çözüm, özelleştirmeleri güncellemeden korunan alanlara taşımaktır: çocuk tema dizini, ayrı bir eklenti dosyası, veritabanındaki ayar kaydı. Bunu yapamadığın durumda en azından bir değişiklik günlüğü tut: hangi dosyanın kaçıncı satırında ne yaptığını yaz. Güncelleme sonrası o listeyi elden geçirmek yirmi dakika sürer; hafızadan yeniden keşfetmek ise günler.

Entegrasyonlar: ödeme, tedarikçi API'si ve mail kuyruğu aynı anda kırılabilir

Bir e-pin satış scripti tek başına ayakta duran bir yazılım değildir; dışarıya bağlı üç can damarı vardır. Ödeme sağlayıcısı sana bildirim gönderir, tedarikçi API'si kodu verir, mail servisi müşteriye ulaştırır. Güncelleme bu üç bağlantının hepsinin yapılandırmasına dokunabilir. En sinsi senaryo şudur: ödeme çalışır, kod çekilir, ama mail kuyruğu yeni sürümde farklı bir gönderim yöntemine geçtiği için müşteri hiçbir şey almaz. Panelde her şey "tamamlandı" yazar.

Bu yüzden güncelleme sonrası doğrulama, panelde yeşil tik saymak değil, uçtan uca bir gerçek sipariş geçirmektir. Kendi kartınla en düşük fiyatlı ürünü satın al, mailin gelmesini bekle, kodu görüntüle. Beş dakikalık bu tatbikat, günlerce süren "acaba çalışıyor mu" tedirginliğini bitirir. Pinova gibi bütünleşik bir dijital ürün satış yazılımı kullanıyorsan bu adımları tek bir test siparişi akışıyla yürütebilirsin.

Bakım penceresini hangi saate koymalısın?

Dijital ürün satışında trafik akşam saatlerinde ve hafta sonlarında zirve yapar. Buna karşılık çoğu işletme sahibi güncellemeyi kendine en uygun olan akşam saatinde yapar; yani tam da en pahalı saatte. Doğru pencere, kendi panelindeki saatlik sipariş dağılımını açıp en düşük hacimli üç saati bulmaktır. Çoğu e-pin yazılımı kurulumunda bu aralık sabaha karşı 04.00-07.00'ye denk gelir.

Pencereyi belirledikten sonra yapman gereken son şey iletişimdir. Site üstüne kısa bir bilgi şeridi koy, sosyal hesaplarından "bakım nedeniyle 20 dakika kapalı" duyurusu yap. Müşteri, haber verilen bir kesintiyi sorun saymaz; haber verilmeyen iki dakikayı ise güven kaybı olarak yazar. Bu yaklaşımı benimseyen işletmeler için güncelleme, aylık rutin bir işlem hâline gelir.

Bu on bir maddeyi bir kez kağıda dökersen her güncelleme aynı ritimle akar: yedek, staging, prova, pencere, doğrulama. Kendi kurulumunda bu akışın nasıl göründüğünü merak ediyorsan Pinova'nın canlı demo ortamında sipariş, teslimat ve ayar ekranlarını kendin gezebilir, güncelleme öncesi kontrol listeni bu ekranlara bakarak çıkarabilirsin.