Bir sabah panel açılmıyor. Dün akşam her şey yolundaydı, kimse dosyaya dokunmadı, yine de sipariş sayfası beyaz ekran veriyor. Çoğu işletme sahibi bu noktada yazılımı suçlar. Oysa olayın açıklaması genellikle çok sıradan: barındırma firması gece PHP sürümünü güncelledi ya da MariaDB bir üst sürüme geçti. Kod aynı kaldı, kodun konuştuğu dil değişti. E-pin scripti gibi para ve stok tutan bir sistemde bu, yalnızca bir hata mesajı değil; yarım kalmış siparişler demek.
İkinci yaygın inanış da şu: “En yeni sürüm her zaman en iyisidir.” Teknik olarak doğru, pratikte tehlikeli. PHP'nin her ana sürümü bazı davranışları sessizce sıkılaştırır; MySQL ve MariaDB ise aynı ismi taşıyıp farklı kurallar uygular. Bu yazıda hangi sürüm kombinasyonunun gerçekten güvenli olduğunu, neyin sessizce bozulduğunu ve yükseltmeyi hangi sırayla yapman gerektiğini anlatıyorum. Amacım sana sürüm numarası ezberletmek değil; yükseltmeyi korkmadan yapabilmen için bir yöntem vermek.
PHP 8'e Geçişte Asıl Tehlike Hata Mesajları Değil, Sessiz Davranış Değişikliği
PHP 8 serisinin en önemli farkı, eskiden uyarı olan şeylerin artık ölümcül hata olmasıdır. PHP 7'de tanımsız bir dizi anahtarını okuduğunda uyarı alır, kod çalışmaya devam ederdi. PHP 8'de bazı bağlamlarda aynı durum istisna fırlatır ve istek ölür. Bir dijital ürün satış scripti için bu, ödeme dönüş sayfasında beklenmeyen bir alan geldiğinde sipariş kaydının hiç oluşmaması anlamına gelir. Para geçmiş, kayıt yok. İkinci sessiz değişiklik dizge-sayı karşılaştırmasıdır: PHP 7'de 0 == "abc" doğruydu, PHP 8'de yanlıştır. Kupon kodu veya ürün kimliği karşılaştıran eski kodlar tam bu yüzden davranış değiştirir. Üçüncüsü, varsayılan hata raporlama seviyesinin sıkılaşmasıdır; log dosyan aniden şişer ve disk dolar. Bunların hiçbiri felaket değil, ama hiçbiri de kendi kendine çözülmez. Modern bir epin yazılım altyapısı PHP 8.1 ve üzerini hedefleyerek yazılır; eski nesil kodlar ise yükseltme sırasında tek tek elden geçirilmek zorundadır.
MySQL ve MariaDB Aynı Şey Sanılıyor, Oysa Aynı Sorguya Farklı Cevap Veriyorlar
Paylaşımlı paketlerin çoğunda MariaDB vardır, satıcı panelde “MySQL” yazar. İkisi ortak kökten geliyor ama ayrıştılar. En görünür fark JSON alan desteği ve pencere fonksiyonlarında; en tehlikeli fark ise varsayılan sql_mode ayarındadır. MySQL 5.7 ve sonrasında ONLY_FULL_GROUP_BY varsayılan olarak açıktır ve gruplanmamış alan seçen eski rapor sorguları anında hata verir. Satış raporu ekranı çalışmıyorsa şüphelenmen gereken ilk yer burasıdır. Bir diğer klasik STRICT_TRANS_TABLES: eskiden boş bırakılan bir alan sessizce sıfıra çevrilirken, artık kayıt tamamen reddedilir. Yani stok ekleme formunda boş bıraktığın bir alan yüzünden ürün hiç kaydedilmez. MariaDB 10.4 sonrası sürümlerde kimlik doğrulama eklentisi de değişti; eski bağlantı kütüphaneleri “authentication plugin cannot be loaded” hatası verir. Bu hatayı gördüğünde sorun şifrede değil, sürüm eşleşmesindedir.
| Kombinasyon | Durum | Bilinen risk | Öneri |
|---|---|---|---|
| PHP 7.4 + MySQL 5.7 | Ömrü bitti | Güvenlik yaması yok | Acil yükselt |
| PHP 8.0 + MariaDB 10.4 | Geçiş dönemi | Sınırlı destek | Kısa vadede taşı |
| PHP 8.1 + MariaDB 10.6 | Güvenli taban | Yok denecek kadar az | Tercih edilir |
| PHP 8.2 + MySQL 8.0 | Güvenli ve hızlı | sql_mode sıkılığı | Önerilir |
| PHP 8.3 + MariaDB 11 | Güncel | Eski eklenti uyumsuzluğu | Test sonrası geç |
| PHP 8.4 + MySQL 8.4 | Çok yeni | Kaldırılan fonksiyonlar | Beklemeye değer |
Karakter Seti Hatası Neden Yıllar Sonra Ortaya Çıkıyor?
Eski kurulumların büyük kısmı utf8 karakter setiyle açılmıştır ve bu isim yanıltıcıdır: MySQL'in utf8'i üç bayta kadar karakter tutar, gerçek UTF-8 ise dört bayta kadar çıkar. Sonuç şu: müşteri adına emoji yazdığında ya da bazı özel karakterler geldiğinde kayıt yarıda kesilir. Sipariş notunda görülür, fatura adresinde görülür, en kötüsü teslimat mesajı şablonunda görülür. Doğru ayar utf8mb4 ve utf8mb4_unicode_ci karşılaştırmasıdır. Bu dönüşümü yaparken dikkat etmen gereken tek şey indeks uzunluğudur: dört bayt varsayımıyla bazı eski indeksler sınırı aşar ve dönüşüm hata verir. Uzun karakterli sütunlarda indeks uzunluğunu daraltmak ya da sütun tipini gözden geçirmek gerekir. Bir dijital ürün satış yazılımı kurulumunda bu ayarı ilk günden doğru yapmak, sonradan tüm tabloları dönüştürmekten çok daha kolaydır.
Sürüm kaynaklı arıza çağrılarının dağılımı
- PHP ana sürüm atlaması 40%
- sql_mode ve grup sorgusu 30%
- Karakter seti ve indeks 18%
- Eksik veya eski eklenti 12%
Yükseltmeyi Hangi Sırayla Yapmalısın? Yanlış Sıra Geri Dönüşü İmkânsız Kılar
Doğru sıra şudur ve pazarlıksızdır. Birinci adım, tam yedek: veritabanı dökümü ve dosya arşivi, ikisi de dışarıda. İkinci adım, alt alan adında birebir kopya bir test ortamı kurmak. Üçüncü adım, test ortamında önce veritabanı sürümünü yükseltmek; çünkü yeni PHP eski veritabanıyla genellikle çalışır, tersi her zaman çalışmaz. Dördüncü adım, PHP sürümünü tek basamak yükseltmek; 7.4'ten doğrudan 8.3'e atlamak yerine 8.1'de durup akışı denemek. Beşinci adım, kritik akışları elle test etmek: kayıt, bakiye yükleme, sipariş, otomatik teslimat, iade, rapor. Altıncı adım, canlıya geçişi düşük trafikli saatte yapmak ve eski PHP sürümünü panelde geri alınabilir tutmak. Yedinci adım, geçişten sonra 48 saat hata logunu okumak. Bu yedi adım sıkıcıdır; sıkıcı olması sayesinde işe yarar. Pinova'nın teknik gereksinimleri tam olarak bu güvenli bandı hedefler.
Yükseltme Sonrası Neyi Test Etmediysen Bozulacak Olan Odur
Sürüm geçişinden sonra çoğu işletme ana sayfayı açar, çalışıyor görüp rahatlar. Oysa ana sayfa hiçbir şey kanıtlamaz; kırılan yerler para akışının derinlerindedir. Aşağıdaki kontrol listesini geçiş gününde tek tek işaretle. Her satır, gerçek vakalarda bozulduğu görülen bir noktadır.
| Test adımı | Beklenen sonuç | Bozulursa belirtisi | Sıra |
|---|---|---|---|
| Üye kaydı ve e-posta | Doğrulama maili gelir | Sessiz başarısızlık | 1 |
| Bakiye yükleme dönüşü | Bakiye anında işlenir | Ödeme var, kayıt yok | 2 |
| Otomatik teslimat | Kod anında iletilir | Sipariş beklemede kalır | 3 |
| Stok düşme kilidi | Aynı kod iki kez gitmez | Çift teslimat | 4 |
| Satış raporu ekranı | Tablolar dolu gelir | SQL grup hatası | 5 |
| Türkçe karakter alanları | Kayıt bozulmaz | Kırpılmış metin | 6 |
| Cron görevleri | Kuyruk boşalır | Birikmiş iş | 7 |
Barındırma panelinde “PHP sürümünü otomatik güncelle” seçeneği açıksa kapat. Sürüm geçişini sen planla; gece yarısı gelen sessiz bir güncelleme, kampanya sabahını kesintiyle açar.
Sürüm korkusu olmadan çalışan bir altyapı
Pinova, PHP 8.1-8.3 ve modern MySQL/MariaDB bandı için yazıldı; sıkı sql_mode ve utf8mb4 varsayılanlarıyla uyumlu çalışır. Lisans ve teknik detayları gör.
Hangi PHP sürümü dijital ürün scripti için en güvenli?
Bugün için PHP 8.2 dengeli seçimdir; 8.1 hâlâ güvenli tabandır. 8.4 gibi çok yeni sürümlere ancak test ortamında tüm akışları denedikten sonra geçmelisin.
MariaDB yerine MySQL kullanmak zorunda mıyım?
Zorunlu değil. MariaDB 10.6 ve üzeri sürümler modern kurulumlar için yeterlidir. Önemli olan marka değil, sql_mode ayarları ve karakter setinin utf8mb4 olmasıdır.
Satış raporu ekranım boş geliyor, nedeni sürüm olabilir mi?
Evet, en olası neden ONLY_FULL_GROUP_BY modunun açılmasıdır. Gruplanmamış alan seçen eski rapor sorguları bu modda hata verir; sorgunun düzeltilmesi gerekir.
Yükseltmeden önce mutlaka test ortamı şart mı?
Şart. Test ortamı kurmadan yapılan geçişlerde ortalama kesinti iki güne kadar çıkabiliyor. Alt alan adında birebir kopya kurmak genellikle bir saatlik iştir.
Sürüm uyumluluğu, dijital ürün satışında görünmeyen ama en sık ısıran konudur. Yedek al, test ortamı kur, veritabanını önce yükselt, PHP'yi tek basamak ilerlet ve para akışını elle dene. Bu disiplini kurduğunda güncelleme bir riskten çıkıp rutine döner. Modern sürüm bandında çalışan bir panelin nasıl davrandığını görmek istersen canlı demo üzerinden sipariş akışını baştan sona test edebilir, ardından lisans planlarına bakabilirsin.