Bir güncelleme çıkıyor. "Hadi yükleyelim, güvenlik yaması var" diyorsun. Dosyaları atıyorsun, sayfayı yeniliyorsun ve aylarca uğraştığın vitrin bir anda fabrika ayarlarına dönüyor. Renkler gitmiş, özel ürün kartı yok, ödeme adımındaki güven ibareleri silinmiş. İlk tepki hep aynı: "Güncelleme tasarımı bozdu."
Oysa güncelleme hiçbir şeyi bozmadı. Sadece kendi dosyalarını kendi yerine yazdı. Senin özelleştirmelerin o dosyaların içinde yaşıyordu, dolayısıyla üzerine yazıldı. Bu, bir epin satış scripti ile çalışan hemen her satıcının en az bir kez yaşadığı ve genelde yanlış teşhis ettiği bir olaydır. Doğru teşhis şu: sorun güncellemede değil, özelleştirmeyi nereye koyduğunda. Bu yazıda o "nereye" sorusunun cevabını, dosya dosya, ritüel ritüel konuşacağız.
Güncelleme sonrası tasarımın bozulmasını "kötü şans" sanıyorsun
Şansla ilgisi yok. Bir sürüm paketi, içinde yer alan her dosyayı hedefteki eşiyle değiştirir. Eğer ürün kartı şablonunu doğrudan açıp içine kendi HTML'ini yazdıysan, o dosya paketin içinde olduğu an değişimin kurbanı olur. Paket senin neyi değiştirdiğini bilemez, bilmek zorunda da değildir.
Bu yüzden profesyonel kurulumlarda tek bir kural geçerlidir: güncellemenin dokunduğu hiçbir dosyaya kalıcı bir şey yazma. Yazacağın her şey, güncellemenin görmediği ayrı bir yerde durmalı ve çalışma anında çekirdeğin üstüne binmeli. Buna override katmanı diyoruz ve iyi bir e-pin satış yazılımı bunu mimarisinde hazır sunar.
Çekirdek dosyaya dokunmanın bedeli ilk güncellemede ödenir
Çekirdeğe müdahale, ilk gün hiçbir maliyet üretmez. Hatta hızlı görünür: dosyayı açtın, satırı değiştirdin, oldu. Bedel ertelenmiştir. Üç ay sonra bir ödeme sağlayıcısı protokolünü değiştirir, sürüm çıkar, sen güncellemek zorunda kalırsın. O anda iki kötü seçenek arasında sıkışırsın: ya güncellemeyi atlayıp güvenlik açığıyla yaşarsın, ya güncelleyip tasarımı baştan yaparsın.
Üçüncü ve doğru seçenek, o kararı hiç vermek zorunda kalmamaktır. Değişikliklerini baştan doğru yere koyarsan, güncelleme bir korku anı değil, sıradan bir bakım işi olur. Satıcı olarak hedefin, güncellemeyi rutine dönüştürmek; heyecan verici bir olay olmaktan çıkarmaktır.
Child tema / override katmanı denilen şey tam olarak nedir?
Fikir sade: şablon yükleyici bir dosyayı ararken önce senin dizinine bakar, orada bulursa onu kullanır, bulamazsa çekirdeğe düşer. Yani tema/ozel/urun-karti.php varsa o çalışır; yoksa tema/varsayilan/urun-karti.php devreye girer. Sen sadece değiştirmek istediğin parçanın kopyasını kendi dizinine alırsın, gerisine dokunmazsın.
Bunun en güzel yanı bakım yükünün küçük kalmasıdır. Beş dosyayı özelleştirdiysen, güncellemeden sonra kontrol etmen gereken beş dosya vardır; iki yüz değil. Stil tarafında da aynı mantık geçerli: çekirdek stil dosyasını düzenlemek yerine kendi ek dosyanı en sonda yükler, yalnızca ezmek istediğin seçicileri yazarsın. Bir dijital ürün satış yazılımı değerlendirirken "özel dosyalarımı nereye koyacağım?" sorusunun net bir cevabı yoksa, ilerideki bakım maliyetini satın alıyorsun demektir.
| Özelleştirme yeri | Güncellemede durumu | Bakım yükü | Önerilir mi |
|---|---|---|---|
| Çekirdek şablon dosyası | Üzerine yazılır | Her sürümde tekrar iş | Hayır |
| Çekirdek stil dosyası | Üzerine yazılır | Yüksek | Hayır |
| Özel tema dizini (override) | Korunur | Sadece değişen dosyalar | Evet |
| Ek stil dosyası (en son yüklenen) | Korunur | Çok düşük | Evet |
| Panel üzerinden ayar/alan | Korunur | Yok | Evet, ilk tercih |
| Veritabanına gömülü HTML | Korunur ama izlenemez | Orta, riskli | Sınırlı |
Neden herkes yedeği alır da geri dönüşü test etmez?
Yedek almak bir alışkanlık haline gelmiş, güzel. Ama yedek almak yeterli değil; yedeği geri yükleyebildiğini bilmek gerekiyor. Sahada gördüğümüz en acı senaryo şudur: güncelleme kötü gitmiş, satıcı yedeğe dönmek istiyor, dosya yedeği var ama veritabanı yedeği o günün sabahına ait değil. Ya da tam tersi.
Doğrusu şöyle: dosya ve veritabanı yedeğini aynı anda al, ikisini aynı etikete yaz, sonra boş bir alt dizinde geri yüklemeyi bir kez dene. On beş dakikalık bu prova, ilk krizde saatler kazandırır. Geri dönüş provası yapmayan bir yedek, yedek değil; teselli belgesidir.
Güncelleme sonrası bozulmaların kaynak dağılımı
- Çekirdek şablona doğrudan müdahale 50%
- Stil dosyasının içine yazılan yamalar 25%
- Eski önbellek ve derlenmiş şablonlar 17%
- Sunucu/PHP sürüm uyuşmazlığı 8%
Güncelleme öncesi 20 dakikalık ritüel
Sıralama önemli. Önce özelleştirdiğin dosyaların listesini çıkar; bu listeyi bir metin dosyasında güncel tutmak en iyi alışkanlıktır. Sonra dosya ve veritabanı yedeğini eşzamanlı al. Ardından güncellemeyi mümkünse bir test kopyasında dene; canlıda değil. Test kopyasında sepetten ödemeye kadar tek bir sipariş geçir, kod teslimini gözle doğrula.
Canlıya geçerken bakım modunu aç, paketi yükle, önbelleği ve derlenmiş şablonları temizle, sonra bakım modunu kapat. Son adım en çok atlananıdır: güncellemeden sonra gerçek bir test siparişi geç. Sayfa açılıyor diye her şey çalışıyor demek değildir; kritik olan kodun müşteriye ulaşmasıdır.
Özel dosyalarının en başına tek satır yorum düş: neyi, neden, hangi tarihte değiştirdin. Altı ay sonra o satır, yarım saatlik hatırlama çabasını saniyeye indirir.
Özelleştirmeyi kalıcı kılan dosya düzeni
İdeal düzen üç kovadan oluşur. Birinci kova panel ayarlarıdır: logo, renk, iletişim bilgisi, güven ibareleri, banka hesapları. Bunlar veritabanında yaşar ve hiçbir güncelleme onlara dokunmaz. İkinci kova override şablonlarıdır: yalnızca gerçekten farklı görünmesi gereken parçalar. Üçüncü kova ek stil ve betik dosyalarıdır: çekirdeğin üstüne binen, kendi adıyla duran, kısa ve okunabilir dosyalar.
Pinova bu üç kovayı ayrı tuttuğu için güncelleme paketi yalnızca çekirdeğe dokunur. Panel ayarların, özel şablonların ve ek stilin yerinde kalır. Bir e-pin scripti ile uzun yıllar çalışacaksan, aradığın şey en gösterişli tema değil; güncellenebilirliğini kaybetmeyen bir düzendir.
| Güncelleme kontrol listesi | Zaman | Atlanırsa ne olur |
|---|---|---|
| Özel dosya listesini güncelle | 2 dk | Neyi kontrol edeceğini bilemezsin |
| Dosya + veritabanı yedeği (eş etiketli) | 5 dk | Geri dönüş tutarsız olur |
| Test kopyasında dene | 6 dk | Hatayı müşteri bulur |
| Bakım modunu aç | 10 sn | Yarım işlem siparişi oluşur |
| Önbellek ve derlenmiş şablonları temizle | 1 dk | Eski tasarım görünmeye devam eder |
| Gerçek test siparişi geç | 4 dk | Teslim kırılır, farkı sabah anlarsın |
| Sonucu not et | 1 dk | Aynı hatayı ikinci kez yaparsın |
Güncellemeyi korku anı olmaktan çıkar
Pinova'nın override katmanı sayesinde tasarımını bir kez yapar, sürümleri gönül rahatlığıyla geçersin. Lisansını al, düzeni doğru kur.
Daha önce çekirdeğe müdahale ettim, şimdi ne yapmalıyım?
Panik yapma. Değiştirdiğin dosyaları tespit et, farkları not al, sonra aynı değişiklikleri override dizinine taşı ve çekirdeği orijinal haline döndür. Bir kerelik iştir, bir daha tekrarlamazsın.
Önbelleği temizlemezsem ne olur?
Yeni şablonlar yüklenmiş olsa bile ziyaretçi eski derlenmiş çıktıyı görür. Bu genelde "güncelleme çalışmadı" yanılgısının kaynağıdır; oysa yalnızca eski çıktı sunulmaktadır.
Her güncellemeyi hemen yüklemek zorunda mıyım?
Güvenlik ve ödeme protokolü güncellemelerini geciktirmemek gerekir. Görsel ve özellik güncellemelerini ise yoğun satış saatleri dışında, hafta içi sabah gibi sakin bir zamana alabilirsin.
Özelleştirmelerimi panelden yapsam daha mı iyi?
Kesinlikle. Panelden yapılabilen hiçbir şeyi koda yazma. Panel ayarları veritabanında yaşadığı için güncellemeden hiç etkilenmez ve geri almak tek tıktır.
Kalıcı tasarım, yetenekli bir tasarımcının değil; doğru dosya düzeninin eseridir. Özelleştirmeyi güncellemenin göremediği katmana taşıdığın gün, sürüm notlarını korkmadan okumaya başlarsın. Bu katmanın panelde ve dosya yapısında nasıl durduğunu görmek istersen canlı demo ile tema ayarlarını incele, ardından özellikler bölümünde güncelleme akışının nasıl yönetildiğine bak.