Güvenlik

WordPress Otomatik Güncelleme Yapılandırması Rehberi

14 Mayıs 2026 No comments yet
WordPress Otomatik Güncelleme Yapılandırması Rehberi kapak görseli

Kısa özet: WordPress otomatik güncellemeler doğru yapılandırıldığında çekirdek, eklenti ve tema güvenlik yamalarını siz haberdar olmadan uygular ve sitenizi gece yarısı çıkan kritik açıklara karşı korur. Yanlış yapılandırıldığında ise hatalı bir eklenti güncellemesi yüzünden sabah uyanıp sitenizi 500 hatasıyla bulabilirsiniz. Bu rehberde wp-config.php sabitleri, filtreler, WP-CLI komutları, Easy Updates Manager eklentisi ve staging stratejisi ile otomatik güncellemeleri kontrollü şekilde nasıl açacağınızı, hangileri için manuel akış kuracağınızı ve bir güncelleme bozulduğunda nasıl geri alacağınızı adım adım anlatıyoruz.

WordPress Otomatik Güncelleme Neden Önemli?

WordPress, dünya çapında web sitelerinin yaklaşık yüzde kırkını çalıştıran bir altyapıdır ve bu yaygınlık onu saldırganlar için cazip bir hedef yapar. Çekirdek, eklenti ve temalardaki güvenlik açıkları çoğunlukla CVE numarasıyla yayınlandıktan saatler sonra otomatik tarayıcılar tarafından sömürülmeye başlanır. Eğer site sahibi güncellemeyi manuel olarak günler sonra uygularsa, bu pencere boyunca site savunmasız kalır. Otomatik güncellemeler bu açığı sıfıra yakın bir süreye indirir.

Öte yandan otomatik güncelleme, “her şeyi açıp unutmak” olarak yapılandırıldığında ters tepebilir. Özellikle özel kodlanmış temalar, eski PHP sürümüne bağlı eklentiler veya WooCommerce gibi ödeme zinciri sıkı entegre sistemler, ana sürüm güncellemelerinde uyumsuzluk yaşayabilir. Doğru yaklaşım: güvenlik yamalarını otomatikleştirmek, ana sürüm sıçramalarını manuel onayda bırakmak ve her ihtimale karşı taze bir yedek garanti etmektir.

Otomatik güncellemelerin sağladığı faydalar

  • Sıfır gün açıklarına hızlı yanıt: 24 saat içinde yayınlanan kritik güvenlik yamaları site sahibi uyumadan önce uygulanır.
  • Yönetim yükünü azaltma: Çoklu site portföyü olan ajanslar veya freelance yöneticiler için manuel güncelleme rutini saatler tasarruf ettirir.
  • Tutarlılık: Tüm siteler benzer sürüm aralığında tutulur, bu da destek senaryolarını sadeleştirir.
  • Çeviri dosyalarının senkron kalması: Türkçe arayüz çevirileri her küçük sürümle birlikte tazelenir.

Otomatik güncellemenin riskleri

  • Hatalı bir eklenti sürümü canlı sitede beyaz ekran, 500 veya tasarım bozulmasına sebep olabilir.
  • WooCommerce gibi kritik sistemlerde ödeme akışı bir gece içinde kırılabilir.
  • Premium eklentilerin lisans doğrulaması sırasında otomatik güncelleme sessizce başarısız olabilir.
  • Yedek alınmadan önce güncelleme tetiklenirse hatadan geri dönüş zorlaşır.

WordPress Otomatik Güncelleme Türleri

WordPress yönetiminde otomatik güncellemeleri konuşurken dört ayrı kategoriyi birbirinden ayırmak gerekir. Her birinin varsayılan davranışı ve kontrol mekanizması farklıdır.

1. Çekirdek (core) küçük sürüm güncellemeleri

WordPress 3.7 sürümünden itibaren küçük (minor) çekirdek güncellemeleri varsayılan olarak otomatiktir. Örneğin 6.4.1 sürümünden 6.4.2 sürümüne geçiş arka planda kendi kendine yapılır. Bu güncellemeler ağırlıklı olarak güvenlik yamaları ve hata düzeltmeleri içerdiği için açık bırakılması güçlü tavsiye edilir.

2. Çekirdek (core) ana sürüm güncellemeleri

Major (ana) güncellemeler ise varsayılan olarak otomatik değildir; örneğin 6.4 sürümünden 6.5 sürümüne geçiş manuel onay ister. Sebebi: ana sürümler API değişiklikleri, blok düzenleyici (Gutenberg) değişiklikleri veya eklenti uyumluluk kırılımları getirebilir. Bu seviyenin otomatikleştirilmesi yalnızca staging’de doğrulanmış senaryolar için tavsiye edilir.

3. Eklenti otomatik güncellemeleri

WordPress 5.5 sürümünden itibaren her eklenti için yönetici panelinden “Otomatik güncellemeleri etkinleştir” bağlantısı sunulur. Bu, eklenti başına granüler kontrol sağlar: güvendiğiniz, geniş kitle tarafından kullanılan eklentileri (örneğin Yoast SEO, Wordfence, Akismet) otomatikleştirip, kritik veya niş eklentileri manuel bırakabilirsiniz.

4. Tema otomatik güncellemeleri

Tema güncellemeleri de WordPress 5.5 ile birlikte tek tek otomatikleştirilebilir hale geldi. Ancak özel kodlanmış child tema kullanıyorsanız ya da temada manuel değişiklikler yaptıysanız, parent tema güncellemesinin sizin değişikliklerinizi nasıl etkileyeceğini düşünmeniz gerekir. Doğru pratik: child tema kullanmak ve parent tema güncellemelerini test edebilmek için staging ortamı tutmaktır.

wp-config.php ile Otomatik Güncellemeleri Yapılandırma

Otomatik güncelleme davranışı, en güçlü ve net şekilde wp-config.php dosyasındaki sabitlerle kontrol edilir. Bu dosya sitenin kök dizininde yer alır; düzenlemeden önce mutlaka yedeğini alın.

WP_AUTO_UPDATE_CORE sabiti

Çekirdek güncelleme davranışını tek satırda belirleyen ana sabittir:

// Tüm çekirdek güncellemeleri (minor + major + development) otomatik
define( 'WP_AUTO_UPDATE_CORE', true );

// Sadece küçük güvenlik güncellemelerini otomatikleştir (önerilen)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Tüm çekirdek otomatik güncellemeleri devre dışı bırak
define( 'WP_AUTO_UPDATE_CORE', false );

Önerilen değer 'minor'‘dur. Bu seçenek küçük güvenlik yamalarını otomatik uygular ama ana sürüm sıçramalarında size karar yetkisi bırakır. Eğer kurumsal bir SLA imzaladıysanız ve geceden gündüze bir değişikliğin sorumluluğunu üstlenmek istemiyorsanız false tercih edilebilir; ancak bu durumda manuel güncelleme disiplini şarttır.

AUTOMATIC_UPDATER_DISABLED sabiti

Eğer barındırma sağlayıcınız zaten çekirdek güncellemelerini sunucu seviyesinde yönetiyorsa veya tüm güncellemeleri tamamen WordPress dışında bir araçla (örneğin Composer + bedrock) yönetiyorsanız, WordPress’in tüm otomatik güncelleme mekanizmasını şu sabitle kapatabilirsiniz:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Bu sabit hem çekirdek, hem eklenti, hem de tema otomatik güncellemelerini kapatır. Dikkat: bu, “ben güncellemeleri tamamen başka bir araçla yönetiyorum” anlamına gelir; aksi halde site uzun süre savunmasız kalabilir.

Dosya sistemine yazma yetkisi

Otomatik güncellemelerin çalışabilmesi için WordPress’in sitenin kök dizinine ve wp-content klasörüne yazabilmesi gerekir. wp-config.php‘de aşağıdaki sabit varsa otomatik güncellemeler genelde başarısız olur:

define( 'DISALLOW_FILE_MODS', true );

Eğer otomatik güncellemeleri kullanacaksanız bu satırı silin veya false yapın. Dosya izinleri için klasörlerin 755, dosyaların 644 olması beklenir. wp-config.php dosyasının 600 veya 640 izniyle saklanması önerilir.

Filtreler ile Granüler Kontrol

Daha ince ayar isteyenler için WordPress filtreleri ana mekanizmadır. Bu kodları bir mu-plugin (must-use plugin) içine veya child tema functions.php dosyasına ekleyebilirsiniz. Önerilen pratik: wp-content/mu-plugins/auto-update-policy.php adında yeni bir dosya açıp aşağıdaki politikaları oraya yazmaktır; çünkü mu-plugins’ler tema değişikliğinden bağımsız çalışır.

Ana sürüm çekirdek güncellemelerini açma/kapatma

// Ana sürüm güncellemelerini aç
add_filter( 'allow_major_auto_core_updates', '__return_true' );

// Küçük sürüm güncellemelerini aç (zaten varsayılan)
add_filter( 'allow_minor_auto_core_updates', '__return_true' );

// Geliştirme (nightly) çekirdek güncellemelerini aç
add_filter( 'allow_dev_auto_core_updates', '__return_false' );

Tüm eklentileri otomatik güncellenecek şekilde işaretleme

add_filter( 'auto_update_plugin', '__return_true' );

Bu filtre tüm eklentileri otomatik güncellemeye alır. Genelde önerilmez; bunun yerine yöneticipanelinden eklenti başına işaretlemek daha güvenlidir. Tersini istiyorsanız:

add_filter( 'auto_update_plugin', '__return_false' );

Belirli eklentileri hariç tutma

Tümünü açık bırakırken sadece WooCommerce veya kendi özel eklentinizi hariç tutmak istiyorsanız:

add_filter( 'auto_update_plugin', function( $update, $item ) {
    $haric = array( 'woocommerce', 'kendi-ozel-eklentim' );
    if ( in_array( $item->slug, $haric, true ) ) {
        return false;
    }
    return true;
}, 10, 2 );

Tema güncelleme politikası

Tema için de aynı yapı geçerlidir:

add_filter( 'auto_update_theme', '__return_true' );

Child tema kullanmadığınız sürece bu filtreyi açmak risklidir çünkü manuel olarak parent temaya yapılmış her özelleştirme güncellemeyle silinir.

Çeviri dosyası güncellemeleri

Türkçe siteler için çeviri dosyalarının otomatik güncellenmesi şiddetle tavsiye edilir; varsayılan olarak açıktır.

add_filter( 'auto_update_translation', '__return_true' );

WP-CLI ile Otomatik Güncelleme Yönetimi

Sunucuya SSH erişiminiz varsa WP-CLI, otomatik güncellemeleri yönetmenin en hızlı yoludur. Tipik komutlar:

# Tüm eklentilerin otomatik güncelleme durumunu listele
wp plugin auto-updates status --all

# Belirli bir eklenti için otomatik güncellemeyi aç
wp plugin auto-updates enable yoast-seo

# Otomatik güncellemeyi kapat
wp plugin auto-updates disable woocommerce

# Tüm temaların otomatik güncellemesini aç
wp theme auto-updates enable --all

# Mevcut güncellemeleri (otomatik veya manuel) hemen uygula
wp plugin update --all
wp theme update --all
wp core update

Bir cron job içinde WP-CLI ile haftalık güncelleme + yedek alma akışını birleştirebilirsiniz. Örnek bir gece yarısı senaryosu:

# /etc/cron.d/wp-haftalik-bakim
0 3 * * 0 www-data /usr/local/bin/wp --path=/var/www/site db export /yedek/db-$(date +\%F).sql && /usr/local/bin/wp --path=/var/www/site plugin update --all

Bu kurulumda her pazar gecesi 03:00’te önce veritabanı yedeği alınır, sonra eklenti güncellemeleri uygulanır. Yedek olmadan otomatik güncelleme yapmamak temel kural olmalı.

Easy Updates Manager Eklentisiyle Yönetim

Kod yazmak istemeyen site sahipleri için Easy Updates Manager eklentisi WordPress deposunda ücretsiz olarak sunulur. Eklenti kurulduğunda yönetici menüsünde “Updates Options” sekmesi açılır ve aşağıdaki seçenekleri arayüz üzerinden sunar:

  • Tüm güncellemeleri açma/kapatma (master switch)
  • Çekirdek major/minor/dev güncellemeleri ayrı ayrı kontrol
  • Tüm eklentileri otomatik güncelle veya seçimli
  • Tema güncelleme politikası
  • Çeviri otomatik güncellemeleri
  • Güncelleme e-posta bildirimi alıcılarını yapılandırma
  • Log: hangi güncellemenin ne zaman uygulandığının kaydı

Çoklu site (multisite) kurulumlarında ağ yöneticisi tüm alt siteler için tek bir politika belirleyebilir. Multisite, ajanslar için son derece pratik bir merkezi yönetim katmanı sağlar.

Hangi eklenti için Easy Updates Manager?

Easy Updates Manager’a alternatif olarak Companion Auto Update, WP Updates Notifier ve ManageWP gibi çözümler bulunur. ManageWP daha ziyade çoklu site portföyü yöneten ajanslar için, tek bir panelden onlarca siteyi tek tıklamayla güncellemek isteyenlere uygundur ve uzaktan güncelleme öncesi otomatik yedek alma özelliği vardır.

Staging Ortamında Güncellemeyi Test Etme

Sürekli olarak söylediğimiz şey: canlı sitede ana sürüm güncellemesi denemek profesyonel pratik değildir. Staging ortamı, sitenizin birebir kopyasının ayrı bir alt alan adında (genelde staging.siteadi.com) çalıştırıldığı test ortamıdır.

Staging kurma yolları

  • Barındırma paneli özelliği: Birçok yönetilen WordPress hosting sağlayıcısı tek tıkla staging klonu oluşturur. Önce buna bakın.
  • WP Staging eklentisi: Ücretsiz sürümü mevcut, alt klasörde bir kopya oluşturur.
  • Manuel klon: Veritabanı dump + dosya kopyası + wp-config.php düzenleme. Üst düzey kontrol için iyidir, ama 15-20 dakika sürer.

Doğrulama checklist’i

Staging’de güncelleme yaptıktan sonra şunları test edin:

  1. Ana sayfa hatasız yükleniyor mu?
  2. Yönetici paneline giriş yapabiliyor musunuz?
  3. Blok düzenleyici (Gutenberg) hatasız çalışıyor mu?
  4. WooCommerce kullanıyorsanız: sepete ürün ekleme + ödeme adımı sorunsuz mu?
  5. İletişim formu mail gönderebiliyor mu?
  6. JavaScript konsolunda kırmızı hata var mı? (Tarayıcı F12)
  7. Sunucu error log son 10 dakika içinde yeni hata kayıtladı mı?

Bu adımlar yeşille geçtiyse aynı güncellemeyi canlıya uygulayabilirsiniz; geçmediyse problemi staging’de izole edip çözmek, canlı sitenin yayında kalmasını sağlar.

Yedekleme + Otomatik Güncelleme: Doğru Sıralama

Otomatik güncellemenin tüm potansiyel hasarını sıfırlayan en güçlü güvenlik ağı: her güncelleme öncesi taze bir yedek. WordPress bunu çekirdek güncellemeleri için kısmen yapar (eski sürümün dosyalarını kısa süreliğine saklar) ama eklenti ve tema güncellemeleri için yapmaz. Doğru yaklaşım:

  • UpdraftPlus, BlogVault veya Solid Backups gibi bir eklentiyle haftalık tam yedek + günlük artımlı yedek planlayın.
  • Yedekleri ASLA aynı sunucuda saklamayın; Amazon S3, Google Drive veya Backblaze B2 gibi harici bir uzak depoya gönderin.
  • Otomatik güncelleme planınızı haftalık yedek planının hemen ardına yerleştirin. Örnek: pazar 02:00 yedek, 03:00 güncelleme.
  • Yedekten geri yükleme prosedürünü ayda bir staging’de prova edin. Sadece yedek almak yetmez; geri yükleyebildiğinizi doğrulamış olmanız gerekir.

Otomatik Güncelleme Sonrası İzleme

Güncelleme uygulandıktan sonra sitenin sessiz sedasız kırılıp kırılmadığını öğrenmek için izleme şarttır. İzlemenin üç katmanı vardır:

1. Uptime monitoring

UptimeRobot, Better Uptime veya Pingdom gibi ücretsiz/ücretli servislerle siteyi her 1-5 dakikada bir kontrol ettirin. Site 500, 502 veya zaman aşımı (timeout) hatası verirse anında Slack/SMS bildirimi alın. Bu, çoğunlukla güncelleme sonrası ilk uyarı kanalıdır.

2. Sunucu error log inceleme

Apache veya Nginx error log dosyaları, PHP fatal hatalarının ilk yansıdığı yerdir. WordPress’in kendi debug log dosyasını da etkinleştirin:

// wp-config.php içine
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // /wp-content/debug.log içine yazar
define( 'WP_DEBUG_DISPLAY', false ); // canlıda ekrana yazma
@ini_set( 'display_errors', 0 );

Güncelleme sonrası ilk 24 saatte tail -f wp-content/debug.log komutuyla canlı izleme yapabilirsiniz.

3. Görsel doğrulama

Manuel olarak ya da Visualping, Hexowatch veya ghost-inspector gibi servislerle anasayfa ve önemli iç sayfalar için ekran görüntüsü karşılaştırması kurun. Tasarımı bozan bir CSS güncellemesi 200 HTTP durum kodu döndürür, dolayısıyla uptime monitor’ün gözünden kaçar; ancak görsel diff yakalar.

Hatalı Bir Güncellemeyi Geri Alma (Rollback)

Otomatik güncelleme bir eklentiyi bozduysa hızla geri almak için iki ana yol vardır.

WP Rollback eklentisiyle eski sürüme dönmek

Ücretsiz WP Rollback eklentisi, WordPress.org deposundaki herhangi bir eklenti veya temayı tek tıkla daha eski bir sürüme döndürür. Kurulumdan sonra Eklentiler listesinde her satıra “Rollback” bağlantısı eklenir.

Yedekten geri yüklemek

Eğer eklenti premium ise veya WP Rollback işe yaramıyorsa, en son yedeği (tercihen güncelleme öncesinden) UpdraftPlus üzerinden “Restore” butonuyla geri yükleyin. Geri yükleme öncesinde mevcut hasarlı dosyaları indirip ayrı bir klasörde saklayın; vendor desteğine gönderebilirsiniz.

Sadece tek bir eklentiyi geri almak

SSH varsa, WP-CLI ile hedeflenmiş geri alma çok hızlıdır:

# Mevcut eklentiyi sil
wp plugin deactivate kotu-eklenti
wp plugin delete kotu-eklenti

# Belirli sürümü kurup aktif et
wp plugin install kotu-eklenti --version=2.4.1 --activate

Tüm WordPress’i topyekun düşürmek yerine bu hedefli müdahale 30 saniye içinde siteyi tekrar ayağa kaldırır.

Sorun Giderme Checklist’i

Otomatik güncellemelerin beklendiği gibi çalışmadığı durumlarda sırasıyla kontrol edin:

  1. WordPress sürümü 3.7 veya üzeri mi? Çok eski siteler otomatik güncellemeyi desteklemez.
  2. wp-config.php içinde DISALLOW_FILE_MODS veya AUTOMATIC_UPDATER_DISABLED ayarı true mu? Bu sabitler otomatik güncellemeleri durdurur.
  3. Dosya izinleri doğru mu? Klasörler 755, dosyalar 644 olmalı; sunucudaki Web kullanıcısı (örneğin www-data) bunlara yazabilmeli.
  4. wp-cron çalışıyor mu? WordPress otomatik güncellemeleri cron üzerinden tetikler. Eğer wp-cron devre dışı veya kırıksa otomatik güncellemeler de çalışmaz. wp cron event list ile zamanlanmış görevleri listeleyin.
  5. Sunucu PHP sürümü destekleniyor mu? WordPress son sürümleri PHP 7.4 üzerini ister; daha eski PHP’de güncellemeler başarısız olabilir.
  6. Disk dolu mu? Yetersiz disk alanı güncelleme dosyalarının inilmesini engeller. df -h ile kontrol edin.
  7. WordPress.org bağlantısı engellenmiş mi? Bazı güvenlik duvarları api.wordpress.org alan adını engelleyebilir. curl -I https://api.wordpress.org/core/version-check/1.7/ ile test edin.
  8. Güvenlik eklentisi mod_security veya benzeri kural sıkıyor mu? Wordfence/Sucuri bazı kuralları WP REST API çağrılarını engelleyebilir.
  9. Premium eklenti lisansı geçerli mi? Lisans süresi dolduysa eklenti güncellemeyi reddeder.

Sık Sorulan Sorular (SSS)

Otomatik güncellemeler sitemi bozarsa kim sorumlu?

Hukuki sorumluluk hâlâ site sahibindedir. Bu yüzden yedek + staging + izleme üçlüsü pazarlık dışıdır. Otomatik güncellemeleri açmadan önce bu üçünün hazır olduğundan emin olun.

Tüm eklentileri otomatik güncellemek güvenli mi?

Hayır. WooCommerce, ödeme ağ geçidi eklentileri (Iyzico, PayTR, Stripe), büyük form eklentileri (Gravity Forms) ve özel kodlanmış eklentiler manuel güncelleme listesinde tutulmalıdır. Bu eklentilerin major sürümleri kritik veri akışını etkileyebilir.

Otomatik güncelleme sonrası site açılmıyor, ne yapayım?

Önce yönetici paneline FTP veya hosting dosya yöneticisinden girip wp-content/plugins klasörü adını plugins-eski olarak değiştirin. Bu işlem tüm eklentileri tek seferde devre dışı bırakır. Site açıldığında plugins-eski içindeki klasörleri teker teker geri taşıyın; hatalı olanı bulunca silin veya rollback yapın.

WP-CLI yoksa otomatik güncelleme kontrolünü nasıl yapabilirim?

Easy Updates Manager eklentisi tüm WP-CLI işlevini grafiksel arayüzde sunar. Veya hosting panelinizdeki “WordPress Manager” özelliğini kullanabilirsiniz.

WordPress çoklu site (multisite) için otomatik güncelleme farklı mı çalışır?

Network admin seviyesinde tek bir politika belirlenir; alt siteler ayrı ayrı yönetilmez. wp-config.php sabitleri tüm ağ için geçerlidir.

“Failed to connect to FTP Server” hatası alıyorum, neden?

WordPress doğrudan dosya sistemine yazamıyor ve FTP detayı istiyor. Çözüm: wp-config.php dosyasına define( 'FS_METHOD', 'direct' ); ekleyin. Bu, WordPress’in dosyalara doğrudan PHP üzerinden yazmasını sağlar, FTP olmadan.

Eklenti otomatik güncellemesi sonrası “There has been a critical error” mesajı görüyorum, ne yapmalıyım?

Bu mesaj PHP fatal hatasıdır. WP_DEBUG_LOG aktifse wp-content/debug.log dosyasında tam hata izini bulursunuz. Genelde yeni eklenti sürümü kullanmadığınız bir PHP fonksiyonu (örneğin PHP 8.1 öncesi sürümlerde tanımlı olmayan) çağırıyordur. PHP sürümünüzü hosting panelinden yükseltmek veya eklentiyi rollback yapmak çözer.

Önerilen Otomatik Güncelleme Politikası (Hızlı Şablon)

Tek bir blog veya kurumsal kurumsal site için pragmatik bir politika önerimiz:

  • Çekirdek küçük güncellemeleri: Otomatik (varsayılan)
  • Çekirdek ana güncellemeleri: Manuel — yeni sürüm çıktıktan en az 2 hafta sonra, staging’de test edip uygula
  • Çeviri dosyaları: Otomatik
  • Ücretsiz, çok kullanıcılı eklentiler (Yoast, Wordfence, Akismet): Otomatik
  • WooCommerce ve ödeme ağ geçitleri: Manuel, staging’de doğrulanır
  • Özel kodlanmış eklentiler: Manuel, geliştirici onayı sonrası
  • Parent tema: Child tema kullanıyorsanız otomatik; kullanmıyorsanız manuel
  • Yedek: Günlük artımlı + haftalık tam, harici depoda
  • İzleme: UptimeRobot 5 dakikada bir + Slack bildirimi

Bu şablon yıllarca onlarca müşteri sitesinde sınanmış, gece yarısı krizini en aza indiren denge noktasıdır.

Kaynak Önerileri

Otomatik Güncellemeleri Devre Dışı Bırakmanız Gereken Durumlar

Bazı durumlarda otomatik güncellemeler tamamen kapatılmalıdır. Bu kararı bilinçli vermek için aşağıdaki senaryoları gözden geçirin.

Composer veya Bedrock altyapısı

Eğer siteniz Roots Bedrock veya Composer tabanlı bir WordPress kurulumuysa, eklenti ve çekirdek bağımlılıkları composer.json üzerinden yönetilir. Bu durumda WordPress’in dosya sistemine yazıp bağımsız güncelleme yapması versiyon disiplinini bozar. AUTOMATIC_UPDATER_DISABLED ve DISALLOW_FILE_MODS sabitlerinin her ikisini de true yapın.

Git tabanlı dağıtım (CI/CD)

Eklenti ve tema dosyalarını Git deposunda tutuyorsanız, sunucuda otomatik güncelleme yapılması Git ile sunucu arasındaki tutarlılığı bozar. Bir sonraki git pull komutunda eski sürümler geri gelir veya merge conflict oluşur. CI/CD akışı varken otomatik güncellemeleri kapatın; tüm güncellemeleri geliştirme ortamında yapın, test edin, push edin, dağıtın.

Sertifikasyon gerektiren projeler

PCI-DSS, HIPAA veya KVKK uyumluluğu kapsamında dış denetimi olan projelerde her sürüm değişikliği değişiklik yönetimi sürecinden geçmek zorundadır. Bu durumda otomatik güncellemeler regülasyon ihlali sayılabilir. Manuel ve dokümante edilmiş bir güncelleme süreci şarttır.

WordPress.com VIP veya Yönetilen Kurumsal Hosting

WordPress VIP, WP Engine, Pantheon ve Kinsta gibi kurumsal yönetilen hostingler kendi güncelleme akışlarını çalıştırır. Bu durumlarda WordPress içi otomatik güncellemeler ya zaten devre dışı bırakılmıştır ya da yönetim arayüzü üzerinden yapılır. Müdahale etmeyin.

Çoklu Site Portföyü İçin Merkezi Yönetim

10 veya daha fazla WordPress sitesi yönetiyorsanız tek tek panele girip güncellemeleri yönetmek pratik değildir. Bu noktada merkezi yönetim panelleri devreye girer.

MainWP, ManageWP, InfiniteWP karşılaştırması

Bu üç çözüm de aynı işi yapar: tek bir panelden onlarca WordPress sitesini görüntüler, güncelleme durumlarını listeler, tek tıkla toplu güncelleme uygular, yedek alır ve uptime izler. Tercih kriterleri:

  • MainWP: Tamamen ücretsiz açık kaynak çekirdek; eklenti uzantılarıyla genişler. Site sayısı sınırsız. Kendi sunucunuzda barındırılır.
  • ManageWP: Bulut tabanlı, profesyonel arayüz. İlk 5 ücretsiz, sonrası ücretli. Otomatik güncelleme öncesi otomatik yedek özelliği güçlü.
  • InfiniteWP: Self-hosted, MainWP’ye benzer. Ek tek seferlik lisans satın alma modeli.

Ajans modeli için MainWP veya ManageWP, kişisel portföy için MainWP en mantıklı seçimdir. Hepsi otomatik güncelleme öncesi yedek alma akışını destekler.

Sonuç

WordPress’te otomatik güncellemeler, doğru yapılandırıldığında siteyi sıfır gün açıklarına karşı koruyan, yanlış yapılandırıldığında ise gece yarısı krizine sebep olan iki yüzü keskin bir kılıçtır. Püf noktası: küçük güvenlik güncellemelerini otomatikleştir, ana sürüm sıçramalarını manuel onayda bırak, her şeyin altına yedek + staging + izleme ağını ser. Bu üç parçayı kurduktan sonra yöneticipanelinde her eklenti için “otomatik güncellemeyi aç” bağlantısına basmak risksiz hale gelir. Bu rehberdeki sabitleri, filtreleri ve WP-CLI komutlarını kullanarak kendi sitenizin profiline uyan bir politika çıkarın; kurum SLA’sına ve teknik kapasitenize göre dengeyi ayarlayın. Düzenli güncelleme uygulayan siteler, açıklara karşı en hızlı kapanan ve aynı zamanda en hızlı toparlanan sitelerdir.

Related posts