Drupal — Güncelleme öncesi hazırlık nasıl yapılır?
Çekirdek, tema, modül veya eklenti güncellemesinden önce güvenli hazırlık süreci. Module, theme, configuration ve cache katmanları kontrollü yönetilmelidir.
Çekirdek, tema, modül veya eklenti güncellemesinden önce güvenli hazırlık süreci. Bu rehber Drupal kullanan yeni başlayanların da takip edebileceği şekilde hazırlanmıştır. Amaç, işlemi ezbere yapmak yerine hangi adımın neden gerekli olduğunu anlamak ve hata oluştuğunda geri dönebileceğin güvenli bir yol bırakmaktır.
BU REHBERDE NE YAPACAĞIZ?
Güncelleme sırasında veri kaybı ve uyumsuzluk riskini azaltacağız. Drupal ortamında değişikliklerin panel, uygulama ve sunucu katmanlarını birlikte etkileyebileceğini unutma. Bu nedenle önce mevcut durumu kaydedecek, ardından kontrollü değişiklik yapacak ve son aşamada sonucu bağımsız olarak doğrulayacağız.
İŞLEME BAŞLAMADAN ÖNCE
Drupal codebase, sites/default/files ve veritabanı için güncel ve geri yüklenebilir bir yedek bulunduğunu doğrula. Yedeğin yalnızca oluşturulmuş olması yeterli değildir; dosyanın açılabildiğini ve veritabanı yedeğinin bozuk olmadığını kontrol etmek gerekir.
Drupal admin ve sunucu erişimi erişiminin çalıştığını doğrula. Yönetici hesabı, SSH/SFTP veya hosting paneli erişimi kaybolursa işlem yarıda kalabilir.
Mevcut sürüm, PHP sürümü, aktif eklenti/modül bilgileri ve kritik ayarları not et. Sorun çıkarsa hangi noktaya geri döneceğini bilmek işin yarısını çözer.
sites/default/settings.php ve Drupal configuration konumunu veya ilgili ayar ekranını belirle. Canlı sistemde rastgele dosya değiştirmek yerine hangi yapılandırmanın gerçekten kullanıldığını teyit et.
Yoğun trafikli bir sitede işlem yapıyorsan bakım penceresi planla. Ödeme, üyelik, form veya sipariş akışı varsa gerçek kullanıcı verisinin kaybolmayacağı bir yöntem kullan.
Şifre, API anahtarı, veritabanı parolası ve özel anahtar gibi hassas bilgileri ekran görüntüsüne, ticket metnine veya herkese açık loglara koyma.
ADIM ADIM UYGULAMA
1. Mevcut durumu ölç. Drupal Recent log messages ile PHP/web server log kayıtlarında son hataları kontrol et; tarayıcı geliştirici araçlarında 4xx/5xx isteklerini ve yüklenmeyen kaynakları not al.
2. Yedek noktasını oluştur. Dosya ve veritabanını birlikte yedekle; yalnızca birini almak uygulamayı tutarlı biçimde geri getirmeye yetmeyebilir.
3. Değişikliği en küçük parçaya böl. sürüm notu, PHP gereksinimi ve bağımlılık uyumluluğunu kontrol etme işlemini tek seferde çok sayıda ayarı değiştirerek değil, kontrol edilebilir adımlarla uygula.
4. sites/default/settings.php ve Drupal configuration üzerinde gerekli ayarı yaparken eski değeri bir yere not et. Değişiklikten sonra cache veya servis yeniden yüklemesi gerekiyorsa yalnızca ilgili servisi hedefle.
5. Uygulama katmanını kontrol et. Drupal yönetim ekranı açılıyor mu, oturum açma çalışıyor mu, ana sayfa ve kritik alt sayfalar doğru cevap veriyor mu test et.
6. Veri katmanını kontrol et. Veritabanı kullanan yapılarda bağlantı, karakter seti, tablo erişimi ve yazma işlemlerinin beklendiği gibi çalıştığını doğrula.
7. HTTPS, yönlendirme ve alan adı davranışını kontrol et. www/non-www veya http/https arasında sonsuz döngü oluşmadığından emin ol.
8. E-posta, cron, webhook, ödeme veya dış API kullanan bir proje ise arka plandaki bu akışları da test et. Ana sayfanın açılması tek başına sağlıklı sistem anlamına gelmez.
9. Tarayıcı ve uygulama cache’lerini temizle. CDN kullanıyorsan yalnızca gereken dosyaları purge et; tüm cache’i gereksiz yere sürekli boşaltmak performansı düşürebilir.
10. Son olarak farklı bir cihaz veya gizli pencere üzerinden testi tekrarla. Yönetici oturumundaki cache/cookie durumu gerçek ziyaretçinin gördüğünden farklı olabilir.
DOĞRULAMA KONTROL LİSTESİ
güncelleme öncesi alınan yedeğin geri yüklenebilir olduğunu doğrula
Ana sayfa, giriş sayfası ve en az iki iç URL HTTP 200 dönüyor mu kontrol et.
Form gönderimi, dosya yükleme veya kayıt oluşturma gibi yazma gerektiren bir işlemi test et.
Mobil görünümde bozuk CSS/JS, mixed content veya yönlendirme problemi olmadığını kontrol et.
Drupal Recent log messages ile PHP/web server log içinde işlem sonrasında yeni ve tekrarlayan kritik hata oluşup oluşmadığını incele.
Kaynak kullanımı belirgin arttıysa CPU, RAM, disk I/O ve PHP worker sayısını karşılaştır.
YAYGIN HATALAR VE ÇÖZÜMLERİ
1. 500 Internal Server Error: İlk olarak Drupal Recent log messages ile PHP/web server log kaydındaki en erken gerçek hata satırını bul. PHP syntax, eksik extension, yanlış izin, hatalı rewrite veya uyumsuz sürüm en sık nedenlerdir.
2. 404 veya sayfa bulunamadı: Document root, permalink/rewrite kuralı, route cache ve yanlış yönlendirme ihtimallerini kontrol et. Dosya gerçekten varsa web sunucusunun o klasörü yayınladığını doğrula.
3. Veritabanı bağlantı hatası: Host, port, veritabanı adı, kullanıcı, parola ve kullanıcı yetkilerini ayrı ayrı doğrula. Uygulama cache’inde eski bağlantı bilgisi kalmış olabilir.
4. Değişiklik görünmüyor: Tarayıcı cache’i, uygulama cache’i, opcode cache ve CDN katmanlarından hangisinin aktif olduğunu belirle. Hepsini rastgele temizlemek yerine ilgili katmanı hedefle.
5. İşlem sonrası giriş yapılamıyor: Session/cookie domaini, HTTPS zorlaması, saat farkı, cache ve kullanıcı rol/yetkilerini kontrol et.
6. Desteklenmeyen PHP veya bağımlılık sürümü güncelleme sonrası siteyi açılmaz hale getirebilir. Bu durumda son yaptığın değişikliği geri al, servisi veya uygulamayı yeniden test et ve ancak temel akış düzeldikten sonra sonraki adıma geç.
GÜVENLİK NOTLARI
Yönetici erişimini güçlü ve benzersiz parola ile koru; mümkün olan sistemlerde iki aşamalı doğrulamayı etkinleştir.
sites/default/settings.php ve Drupal configuration dosyasında parola veya anahtar varsa web üzerinden indirilemeyecek konum/izin kullan. Repository içine gerçek production secret koyma.
Dosya izinlerini sorunu çözmek için 777 yapmak kalıcı çözüm değildir. Web sunucusu kullanıcısı, sahiplik ve minimum gerekli izin mantığıyla ilerle.
Güncellemesi bitmiş eklenti, tema, modül veya çekirdek sürümünü canlıda tutma. Kullanmadığın bileşenleri yalnızca pasif bırakmak yerine yedeğini aldıktan sonra kaldırmayı değerlendir.
Yönetim ve API uç noktalarında brute-force, rate limit, CSRF, yetkilendirme ve log takibi gibi kontrolleri ihmal etme.
PERFORMANS İÇİN İPUÇLARI
Önce ölç, sonra optimize et. Sayfa üretim süresi, veritabanı sorguları, büyük dosyalar ve dış API çağrıları birbirinden farklı darboğazlardır.
Statik dosyalarda tarayıcı cache’i ve CDN, dinamik uygulamada doğru page/object cache stratejisi kullan. Sepet, hesap ve ödeme gibi kişiye özel sayfaları yanlışlıkla cache’leme.
Görselleri uygun boyutta ve modern formatta sun. Kullanılmayan büyük JS/CSS paketleri ve üçüncü taraf scriptler gerçek kullanıcı hızını ciddi etkileyebilir.
Veritabanında indeks, gereksiz autoload/config kayıtları, büyüyen log/session tabloları ve uzun süren sorguları düzenli kontrol et.
GERİ DÖNÜŞ PLANI
İşlem beklenen sonucu vermiyorsa panikle art arda yeni değişiklik yapma. Önce son değişikliği geri al. Sorun devam ederse dosya ve veritabanını aynı yedek zamanına döndür. DNS veya CDN değişikliği yaptıysan eski kayıtların TTL nedeniyle bir süre görülebileceğini hesaba kat. Geri dönüşten sonra Drupal Recent log messages ile PHP/web server log kayıtlarını tekrar incele ve neden-sonuç ilişkisini netleştirmeden aynı işlemi tekrarlama.
SIK SORULAN SORULAR
Soru: Drupal üzerinde bu işlemi canlı sitede yapabilir miyim?
Cevap: Küçük ve geri alınabilir ayarlar canlıda yapılabilir; çekirdek güncelleme, taşıma, veritabanı değişikliği veya büyük yapılandırmalar için staging ve yedek yaklaşımı daha güvenlidir.
Soru: Değişiklikten sonra ne kadar beklemeliyim?
Cevap: Uygulama ayarları genellikle anında etkili olur. DNS/CDN/SSL zincirindeki bazı değişiklikler TTL, cache veya sertifika doğrulaması nedeniyle daha uzun sürebilir.
Soru: Hata mesajını gizlemek mi yoksa debug açmak mı doğru?
Cevap: Canlıda ziyaretçiye ayrıntılı hata göstermemelisin. Ayrıntılı kayıtları güvenli log dosyasında tutup yalnızca yetkili kullanıcıların erişebileceği şekilde incelemelisin.
Soru: Destek talebi açarken hangi bilgileri vermeliyim?
Cevap: Domain, hata saati, tekrar adımları, ilgili ekran/URL, ilk gerçek log hatası ve son yaptığın değişikliği yaz. Şifre ve API anahtarı gönderme.
SON KONTROL
Drupal için Güncelleme öncesi hazırlık nasıl yapılır? işlemi, yalnızca ekranda hata görünmemesiyle tamamlanmış sayılmaz. güncelleme öncesi alınan yedeğin geri yüklenebilir olduğunu doğrula Ayrıca log, yedek, güvenlik ve arka plan görevleri birlikte kontrol edildiğinde değişikliğin gerçekten sağlıklı olduğu söylenebilir.
