WordPress'te Mixed Content (Karışık İçerik) Sorunu

Yani sitenizdeki bir tema dosyası HTTP üzerinden çağrılıyorsa, ziyaretçi büyük ihtimalle bozuk bir tasarımla karşılaşır; çünkü Chrome ve Firefox bu CSS'i çoğu durumda hiç yüklemez. Pasif içerikte ise sayfa görünürde çalışmaya devam eder, fakat adres çubuğundaki kilit "bu sitede güvenli olmayan içerik var" uyarısına dönüşür. Arama motorları açısından da bu durum istenmeyen bir sinyaldir; çünkü tam HTTPS güvencesi veremeyen bir sayfa, güven gerektiren işlemlerde geri planda kalabilir.

WordPress'te En Sık Görülen Nedenler

Sorunun kaynağı neredeyse her zaman veritabanında ya da tema kodunda gömülü kalmış eski HTTP adresleridir. Pratikte şu noktalar öne çıkar:

• Sabit kodlanmış URL'ler: Yazı içeriğine elle eklenmiş, http:// ile başlayan görsel veya bağlantı adresleri.
• Tema ve eklenti varlıkları: wp_enqueue_script ya da wp_enqueue_style çağrılarında protokolü sabitlenmiş kaynaklar.
• Site Address ayarları: Ayarlar > Genel altındaki WordPress Adresi ve Site Adresi alanlarının hâlâ HTTP olarak kalması.
• Harici servisler: HTTP üzerinden çekilen reklam kodları, eski CDN bağlantıları veya gömülü harita/video içerikleri.
• Veritabanı kalıntıları: wp_postmeta ve wp_options içine serileştirilmiş (serialized) hâlde yazılmış eski adresler.

Sorunu Teşhis Etmek

Önce hangi kaynağın suçlu olduğunu net biçimde görmeniz gerekir. Tarayıcı geliştirici araçlarını (F12) açıp Console sekmesine bakın; "Mixed Content: The page at ... was loaded over HTTPS, but requested an insecure ..." şeklindeki satırlar size tam olarak hangi URL'in sorun çıkardığını söyler. Sunucu tarafında ise içeriği tarayarak da arama yapabilirsiniz:

wp search-replace 'http://siteadiniz.com' 'https://siteadiniz.com' \
  --all-tables --dry-run

# Hangi tablolarda kaç değişiklik olacağını gösterir, gerçek değişiklik yapmaz

WP-CLI'nin search-replace komutu, serileştirilmiş verileri bozmadan güncellediği için elle SQL sorgusu çalıştırmaya kıyasla çok daha güvenlidir. --dry-run ile önce ön izleme almanızı öneririm. Komut satırına erişiminiz yoksa, Better Search Replace gibi serialize uyumlu bir eklenti aynı işi panel üzerinden yapar; ancak elle UPDATE wp_posts SET post_content = REPLACE(...) türü ham SQL sorgularından uzak durun, çünkü bunlar serileştirilmiş dizilerdeki karakter uzunluğu bilgisini bozarak veriyi okunamaz hâle getirebilir.

Kalıcı Çözüm: Adresleri Toplu Güncelleme

Teşhisten emin olduktan sonra aynı komutu --dry-run olmadan çalıştırarak değişikliği uygulayabilirsiniz:

# Veritabanı yedeği aldıktan SONRA çalıştırın
wp db export yedek-$(date +%F).sql

wp search-replace 'http://siteadiniz.com' 'https://siteadiniz.com' \
  --all-tables --skip-columns=guid

guid sütununu atlamak önemlidir; bu alan RSS okuyucuları için kalıcı bir kimlik görevi gördüğünden değiştirmek beslemelerde tekrar bildirimlerine yol açabilir. İşlemden önce mutlaka tam bir yedek alın. Sağlam ve güncel bir SSL altyapısı için Bogahost SSL sertifikaları üzerinden doğru zincire sahip bir sertifika kullandığınızdan emin olun; eksik ara sertifika da kilit sorununu tetikleyebilir.

Sunucu Tarafında Yönlendirme ve Başlıklar

Veritabanını temizledikten sonra, gelen tüm HTTP isteklerini HTTPS'e yönlendirmek ve tarayıcıya "bu siteyi yalnızca HTTPS ile aç" demek isteriz. Apache/LiteSpeed ortamında .htaccess dosyasına şunu ekleyebilirsiniz:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
</IfModule>

Header always set Content-Security-Policy "upgrade-insecure-requests"

Buradaki upgrade-insecure-requests direktifi pratik bir kurtarıcıdır: tarayıcıya, sayfadaki HTTP kaynak isteklerini engellemeden önce sessizce HTTPS'e yükseltmesini söyler. Bu, kaynağı bulunamayan eski bir görsel için geçici bir tampon işlevi görür ama asıl temizliğin yerini tutmaz.

Tema ve Eklenti Kaynaklı Sorunlar

Eğer adresleri güncellemenize rağmen belirli bir dosya ısrarla HTTP üzerinden çağrılıyorsa, sorun kod içindedir. Tema veya eklenti dosyalarında protokolü sabitlenmiş çağrıları arayın. Doğrusu, protokolü hiç belirtmeden WordPress'in kendi fonksiyonlarına bırakmaktır:

// Yanlış: protokol sabitlenmiş
wp_enqueue_style( 'ana-stil', 'http://siteadiniz.com/style.css' );

// Doğru: WordPress doğru protokolü kendi üretir
wp_enqueue_style( 'ana-stil', get_stylesheet_uri() );

Yönetilen bir WordPress hosting ortamında genellikle SSL zorlaması ve yönlendirmeler hazır gelir, böylece bu ayarların çoğuyla tek tek uğraşmanız gerekmez.

Bogahost Önerisi: Veritabanında toplu değişiklik yapmadan önce mutlaka wp db export ile yedek alın ve değişiklikleri önce bir staging (deneme) kopyası üzerinde deneyin. Serileştirilmiş veriyi elle düzenlemek yerine her zaman WP-CLI veya Better Search Replace gibi serialize uyumlu araçları tercih edin.

Doğrulama ve Bakım

Temizlik sonrası işin bittiğine emin olmak için birkaç noktayı kontrol edin. Tarayıcı konsolunda hiçbir mixed content uyarısı kalmamalı. Why No Padlock benzeri çevrimiçi tarayıcılar veya curl -sI https://siteadiniz.com çıktısı, başlıkların ve yönlendirmenin doğru çalıştığını gösterir. Yeni içerik eklerken görselleri Medya Kütüphanesi üzerinden yüklemek, elle HTTP adresi girme riskini büyük ölçüde ortadan kaldırır.

Özetle

Karışık içerik, kötü niyetli bir hatadan çok, SSL geçişinin yarım kalmış bir kalıntısıdır. Veritabanındaki eski adresleri serialize uyumlu bir araçla güncellemek, sunucuda kalıcı 301 yönlendirmesi kurmak ve tema kodundaki sabit protokolleri ayıklamak çoğu durumda sorunu kökünden çözer. Bir kez düzgün kurduğunuzda kilit simgeniz kapanır ve hem ziyaretçi güveni hem de arama motoru görünürlüğü adına sağlam bir zemine oturursunuz.