Çoğu e-pin satıcısı, hosting panelindeki PHP sürüm menüsünü bir tercih ayarı sanır. "7.4'ten 8.2'ye geçtim, site açıldı, sorun yok" diye düşünür. Oysa bir e-pin satış scripti açılış sayfasından çok daha fazlasıdır: arka planda çalışan kod havuzu sorguları, ödeme bildirimi karşılayan webhook dosyaları, bayi API'si, otomatik teslimat kuyruğu, fatura üretici ve cron görevleri var. Bunların hiçbiri ana sayfa açıldığında test edilmez. Site açılır, sen rahatlarsın, üç saat sonra bir müşteri "ödemem gitti ama kod gelmedi" diye yazar.
İşin sinsi tarafı şu: PHP yükseltmeleri çoğu zaman beyaz ekran vermez. Uyarı seviyesini düşürmüş bir kurulumda hata ekrana basılmaz, sipariş kaydı yarım kalır, e-posta gönderimi sessizce başarısız olur. Yani yükseltmenin bedelini teknik bir hata mesajıyla değil, iade taleplerinle ve düşen güveninle ödersin. Bu yazıda bir dijital ürün satış scripti PHP yükseltmesinde tam olarak nerelerden çatlar, hangi kırılma sessizdir ve hangi sırayla ilerlersen tek bir siparişi bile kaybetmezsin sorusunun cevabı var.
Neden hosting firması "yükselt" der ama sonucunu üstlenmez?
Barındırma sağlayıcısının PHP 7.4 gibi destek dışı sürümleri kapatmak için gerçek bir gerekçesi var: güvenlik yamaları bitmiştir, sunucuda tek bir eski sürüm bile tüm makineyi riskli hale getirir. Bu yüzden sana "sürümünüzü güncelleyin" e-postası gelir. Ama o e-posta senin e-pin yazılımının hangi fonksiyonları kullandığını bilmez. Sağlayıcı altyapıyı yönetir, uygulama uyumluluğu senin sorumluluğundadır.
Bu ayrımı bilmek pratikte şunu değiştirir: yükseltmeyi sağlayıcının verdiği son tarihte panik içinde değil, kendi belirlediğin sakin bir gecede yaparsın. Aradaki fark, yedeğini alıp almamak, staging kurup kurmamak ve ödeme bildirimlerini test edip etmemektir. Destek dışı sürümde kalmak da çözüm değil; yalnızca riski güvenlikten tarafa kaydırır. Doğru cevap "yükseltmemek" değil, kontrollü yükseltmek.
Gerçek katil hangisi: mysqli'nin sessizce konuşmaya başlaması
PHP 8.1 ile birlikte mysqli sürücüsünün varsayılan hata davranışı değişti. Eskiden başarısız bir sorgu false döndürüp sessizce geçiyordu; artık varsayılan olarak istisna fırlatıyor. Eski kodun "sorgu başarısızsa zaten kontrol ederim" mantığıyla yazıldığı her yerde bu durum ölümcül hataya dönüşür. Özellikle kod havuzundan stok düşen, sipariş durumunu güncelleyen ve bayi bakiyesini işleyen fonksiyonlar bu kalıba çok yatkındır.
İkinci sessiz katil, PHP 8.0'daki string-sayı karşılaştırma değişikliğidir. Artık "abc" == 0 ifadesi false döner. Kulağa doğru geliyor, ama eski bir e-pin scripti sipariş durumunu, kupon kodunu veya ürün tipini gevşek karşılaştırmayla kontrol ediyorsa mantık bir gecede tersine döner. Bir durum kontrolü yanlış tarafa düşer ve ödenmemiş sipariş teslim edilmiş gibi işlenir. Bu tür hata log'a hiç düşmez, çünkü teknik olarak hata değil; yanlış karardır.
| PHP sürümü | Kritik değişiklik | E-pin işine yansıması | Risk |
|---|---|---|---|
| 8.0 | Gevşek karşılaştırma kuralları, each() ve create_function() kaldırıldı | Sipariş durumu ve kupon mantığı ters karar verir | Yüksek / sessiz |
| 8.1 | mysqli varsayılan olarak istisna fırlatır, örtük nullable uyarısı | Stok düşme ve bakiye güncelleme ölümcül hataya düşer | Çok yüksek |
| 8.2 | Dinamik özellik kullanımı ve ${} dizge sözdizimi kullanımdan kaldırıldı | Eski şablon motoru ve model sınıfları uyarı seliyle yavaşlar | Orta |
| 8.3 | Sabit ve tip katılığı artışı, bazı uyarılar hataya yükseldi | Özel eklentiler ve eski ödeme SDK'ları kırılır | Orta |
| 8.4 | Örtük nullable parametreler kullanımdan kaldırıldı | Yıllar önce yazılmış yardımcı fonksiyonlar uyarı üretir | Düşük / gürültülü |
Lisanslı script'in şifrelenmişse yükseltme tek tıkla imkânsız olur
Ticari bir dijital ürün satış yazılımı genellikle kaynak kodu koruma katmanıyla dağıtılır. Bu katmanın sunucuda çalışması için PHP'nin tam sürümüyle eşleşen bir yükleyici uzantısı gerekir. Sen PHP'yi 8.2'ye çektiğinde yükleyici hâlâ 7.4 için derlenmişse script açılmaz; "site can't be reached" değil, doğrudan anlamsız bir 500 hatası alırsın ve kodun içine bakıp sebebi bulamazsın çünkü dosyalar okunabilir değildir.
Buradaki ders, yükseltme sırasının ters olması gerektiğidir: önce yazılım sağlayıcının hedef PHP sürümünü desteklediğini doğrula, sonra sunucudaki yükleyici uzantısını güncelle, en son PHP sürümünü değiştir. Bu üç adımı ters sırada yaparsan site kapalı kalır. Şifrelenmemiş, açık kaynaklı bir epin yazılım kurulumunda bu risk yoktur ama onun yerine kendi yazdığın eklentilerin uyumu senin üzerinde kalır.
PHP yükseltmesinde ilk kırılan bileşenler
- Veritabanı katmanı 45%
- Ödeme ve bayi API entegrasyonları 25%
- Şablon ve tema dosyaları 20%
- Cron ve e-posta gönderimi 10%
Ödeme bildirimleri neden ana sayfadan sonra test edilmeli?
Yükseltme sonrası çoğu satıcı ana sayfaya, ürün sayfasına ve sepete bakar; hepsi çalışıyorsa işi bitmiş sayar. Ama ödeme sağlayıcısının senin sunucuna gönderdiği bildirim isteği tamamen farklı bir kod yolunu tetikler: imza doğrulama, şifreleme fonksiyonları, JSON çözümleme ve sipariş güncelleme. Eski SSL ve şifreleme fonksiyonlarının bir kısmı yeni sürümlerde kullanımdan kaldırıldığı için imza doğrulama sessizce başarısız olabilir.
Sonuç en kötü senaryodur: para tahsil edilir, bildirim reddedilir, sipariş "beklemede" kalır ve otomatik teslimat tetiklenmez. Müşteri ödediği kodu almaz. Bu yüzden yükseltmeden sonra yapılacak ilk test göz testi değil, gerçek bir kuruşluk sipariş testidir. Aynı şey bayi API'si, stok senkronizasyonu ve fatura PDF üretimi için de geçerlidir.
Geçici olarak tüm uyarıları dosyaya yazdır, ekrana asla basma. Böylece kullanıcı hiçbir şey görmezken sen kırılan her satırı elinde tutarsın.
Geri dönüş planı olmayan yükseltme, yükseltme değil kumardır
Doğru sıra şudur: tam yedek al (dosya ve veritabanı ayrı ayrı), alt alan adında kopya bir kurulum aç, PHP'yi yalnızca o kopyada yükselt, hata log'unu izle, sipariş akışını baştan sona dene, sonra canlıya geç. Bu iş bir gecelik değildir ama iki saatlik bir hazırlık, üç günlük iade yazışmasından kısadır.
Ayrıca sürüm atlamayı sevme. 7.4'ten doğrudan 8.3'e gitmek yerine 8.1'e çık, bir hafta izle, sonra devam et. Her ara durakta log'u okursun ve hangi değişikliğin neyi kırdığını net bilirsin. Bakımı yapılan, düzenli sürüm notu yayımlayan bir e-pin satış yazılımı kullanıyorsan bu iş çok daha kolaydır: sağlayıcı zaten uyumluluğu senin yerine test etmiştir.
| Kontrol adımı | Ne zaman | Başarı ölçütü |
|---|---|---|
| Dosya ve veritabanı yedeği | Yükseltmeden önce | Yedek indirilip ayrı diskte doğrulandı |
| Yazılım sürüm notu kontrolü | Yükseltmeden önce | Hedef PHP sürümü resmen destekli |
| Kod koruma yükleyicisi güncellemesi | PHP değişiminden hemen önce | Uzantı sürümü PHP ile eşleşiyor |
| Staging kurulumda test | Canlıya geçmeden | Log'da ölümcül hata yok |
| Kuruşluk gerçek sipariş | Yükseltmeden 5 dk sonra | Ödeme bildirimi geldi, teslimat yapıldı |
| Cron ve e-posta denetimi | İlk 24 saat | Zamanlanmış görevler hatasız koştu |
| Hata log'u incelemesi | İlk 72 saat | Uyarı sayısı sıfıra yakın |
Yükseltme korkusu olmayan bir altyapıya geç
Pinova, güncel PHP sürümleriyle test edilerek dağıtılan lisanslı bir e-pin ve dijital ürün satış yönetim yazılımıdır. Uyum kontrolünü sen değil, yazılım üstlenir.
PHP sürümünü yükseltmezsem ne olur?
Destek dışı sürümler güvenlik yaması almaz. Bilinen bir açık üzerinden sunucuna sızılması hâlinde kod havuzun ve müşteri verin risk altına girer. Yükseltmemek kalıcı bir çözüm değil, ertelenmiş bir risktir.
Yükseltmeden sonra site açılıyor ama siparişler beklemede kalıyor, sebebi ne olabilir?
Neredeyse her zaman ödeme bildirimi karşılayan dosyadaki imza doğrulama veya veritabanı güncelleme adımıdır. Hata log'unu açıp bildirim isteğinin geldiği zaman damgasına bak; ölümcül hata satırını orada bulursun.
PHP sürümünü geri alabilir miyim?
Çoğu barındırma panelinde evet, birkaç dakika sürer. Ancak yükseltme sırasında veritabanına yazılmış bozuk kayıtlar geri gelmez; bu yüzden yedek almadan yükseltme yapılmaz.
Kendi yazdığım eklentiler yükseltmeden sonra çalışmazsa ne yaparım?
Önce hepsini devre dışı bırakıp scriptin temiz hâlde çalıştığını doğrula, sonra tek tek aç. Kırılanı böyle izole edersin; hepsini birlikte açıp sebebi aramak saatler kaybettirir.
PHP yükseltmesi, altyapısı düzgün kurulmuş bir sistemde sıkıcı bir bakım işidir; eski ve bakımsız bir kurulumda ise gece yarısı krizidir. Aradaki farkı belirleyen şey senin teknik bilgin değil, kullandığın yazılımın güncel sürümlerle test edilip edilmediğidir. Hangi tarafta olduğunu görmek istiyorsan özellik listesine ve fiyatlandırmaya göz at, ardından canlı demo üzerinden panelde gezinip sipariş akışını kendi gözünle dene.