WordPress Küçük Resim Üretmiyor: Imagick ve GD Kaynaklı Görsel Hataları

Medya kütüphanesine bir ürün fotoğrafı sürüklüyorsunuz. Mavi yükleme çubuğu sonuna kadar gidiyor, sonra kutucuk kırmızıya dönüyor ve şu cümleyi okuyorsunuz: "Görselin son işlemesi başarısız oldu; muhtemelen sunucu meşgul ya da yeterli kaynağa sahip değil. Daha küçük bir görsel yüklemeyi deneyin." Ya da daha sinsi bir hâlini yaşıyorsunuz: yükleme başarılı görünüyor, görsel medya kütüphanesinde duruyor, ama tema onu ana sayfada 6 MB'lık orijinal boyutuyla basıyor çünkü 150x150 ve 768x1024 sürümleri hiç üretilmemiş.

Bu iki belirtinin de kaynağı neredeyse her zaman aynı yerdedir: WordPress'in görselleri kırpmak ve yeniden boyutlandırmak için kullandığı PHP görüntü işleme kütüphanesi. WordPress kendi başına piksel işlemez; bu işi ya Imagick (ImageMagick'in PHP eklentisi) ya da GD kütüphanesine devreder. Bu iki eklentiden biri eksikse, sürümü uyumsuzsa, sunucu tarafında kısıtlanmışsa veya işlem sırasında bellek duvarına çarpıyorsa WordPress sessizce pes eder — ve size çoğu zaman gerçek nedeni söylemez.

Bu rehberde teşhisi tahminle değil ölçümle yapacağız. Önce sitenizde hangi kütüphanenin aktif olduğunu doğrulayacak, sonra bellek yetersizliğini, ImageMagick'in sunucu düzeyindeki policy.xml sınırlarını ve WebP/AVIF desteğini ayrı ayrı eleyeceğiz. Sorunun kaynağını bulup düzelttikten sonra da geriye kalan asıl işi yapacağız: geçmişte üretilememiş tüm küçük resimleri toplu olarak yeniden oluşturmak.

Sitenizde Hangi Görüntü Kütüphanesi Çalışıyor?#

Hiçbir şey denemeden önce bu soruyu cevaplayın. WordPress size cevabı doğrudan veriyor: yönetim panelinde Araçlar → Site Sağlığı → Bilgi sekmesini açın ve Medya İşleme bölümünü genişletin. Burada göreceğiniz satırlar teşhisin yarısıdır:

"Aktif düzenleyici" satırı WP_Image_Editor_GD diyorsa ve ImageMagick satırları boşsa, sunucunuzda Imagick kurulu değil demektir. Bu tek başına bir hata değildir — GD de küçük resim üretebilir — ama GD'nin bellek davranışı büyük JPEG'lerde çok daha savurgandır ve asıl sorun genellikle oradan çıkar.

Sunucuya SSH erişiminiz varsa aynı bilgiyi daha kesin biçimde doğrulayabilirsiniz:

# Hangi eklentiler yüklü?
php -m | grep -iE 'imagick|^gd$'

# GD'nin hangi formatları desteklediğini gör (WebP ve AVIF satırlarına dikkat)
php -r 'print_r(gd_info());'

# Sistemdeki ImageMagick sürümü ve derleme özellikleri
convert -version 2>/dev/null || magick -version

Önemli bir tuzak: php -m çıktısı komut satırı (CLI) PHP'sini gösterir. Sitenizi çalıştıran PHP-FPM havuzu bambaşka bir sürüm ve bambaşka bir eklenti listesi kullanıyor olabilir. Bu yüzden Site Sağlığı ekranı daha güvenilirdir — o, sitenin gerçekten kullandığı PHP'yi raporlar. İki çıktı çelişiyorsa web tarafını doğru kabul edin. Paylaşımlı barındırmada eklenti listesini panelden yönetiyorsanız cPanel PHP eklenti seçimi yazısındaki adımlarla imagick kutusunu işaretlemeniz yeterli olur.

Imagick ile GD Arasındaki Fark Neden Sorunu Belirliyor?#

WordPress, WP_Image_Editor adında soyut bir sınıf üzerinden çalışır ve bunun iki uygulaması vardır. Yükleme anında her ikisinin test() metodunu çağırır, dosyanın MIME tipini supports_mime_type() ile sorar ve şartları sağlayan ilk sınıfı seçer. Varsayılan sırada Imagick öndedir; yoksa GD devreye girer. İkisi de yoksa hiçbir alt boyut üretilmez ve orijinal dosya olduğu gibi kalır.

Buradaki kritik satır sondan bir öncekidir. GD sadece PHP'nin memory_limit değerine bakar; Imagick ise hem PHP belleğine hem de ImageMagick'in kendi kaynak politikasına tabidir. Yani "Imagick kurulu, o hâlde sorun çözülür" varsayımı yanlıştır — Imagick kurulu olduğu hâlde sunucu politikası yüzünden GD'den daha erken pes edebilir. Bu yüzden ikisini de ayrı ayrı test etmek gerekir.

Küçük Resimler Neden Hiç Oluşmuyor?#

WordPress her yüklemede kayıtlı boyut listesindeki her ölçü için ayrı bir dosya üretir: thumbnail, medium, medium_large, large, artı temanızın ve eklentilerinizin add_image_size() ile eklediği özel boyutlar. Yani tek bir yükleme aslında beş ilâ on beş ayrı işlemdir. Bunlardan biri hata verirse zincirin kalanı da kopabilir.

Gerçekten üretilip üretilmediklerini dosya sisteminden doğrulayın:

cd wp-content/uploads/2026/08

# Türev dosyalar (-150x150 gibi son ekli olanlar) kaç tane?
ls -1 | grep -E '\-[0-9]+x[0-9]+\.(jpg|jpeg|png|webp)$' | wc -l

# Hiç türevi olmayan orijinalleri listele
for f in *.jpg; do
  base="${f%.jpg}"
  count=$(ls "${base}"-*x*.jpg 2>/dev/null | wc -l)
  [ "$count" -eq 0 ] && echo "TUREV YOK: $f"
done

Çıktıda "TUREV YOK" satırları varsa küçük resim üretimi gerçekten çalışmıyor demektir. Hiç türev yoksa kütüphane sorunu, sadece bazı dosyalarda yoksa büyük ihtimalle bellek sorunu vardır — çünkü bellek duvarına yalnızca belirli bir çözünürlüğün üstündeki dosyalar çarpar. Bu ayrım teşhisi ikiye böler ve sonraki iki bölüm tam olarak bu iki dalı ele alır.

Görsel arayüzde de dolaylı bir kontrol vardır: medya kütüphanesinde bir görsele tıklayıp Görseli Düzenle ekranını açın. Kırpma ve döndürme düğmeleri çalışmıyor ya da ekran hata veriyorsa, WordPress hiçbir görüntü düzenleyici bulamıyor demektir. Görsellerin tarayıcıda hiç görünmemesi ise bambaşka bir konudur; onun için WordPress resimler görünmüyor yazısındaki 404/403 ayrımına bakın.

Post-Processing Hatası: WordPress'in Sessiz Bellek Duvarı#

WordPress 5.3 ile birlikte büyük görsellerin alt boyutları tek bir istekte değil, tarayıcının arka planda attığı ek AJAX istekleriyle üretiliyor. Aynı sürümde big_image_size_threshold filtresi geldi: uzun kenarı 2560 pikselden büyük her görsel önce bu ölçüye küçültülüyor, orijinal -scaled son ekiyle saklanıyor ve tüm türevler küçültülmüş kopyadan üretiliyor.

"Post-processing" hatası tam olarak bu arka plan isteğinin PHP tarafında ölmesidir. Ekrandaki mesaj "sunucu meşgul olabilir" der ama gerçek sebep neredeyse her zaman bellektir. Matematiği basittir: bir JPEG diskte sıkıştırılmıştır, ancak işlenmek için piksel piksel RAM'e açılır. Kaba hesap genişlik × yükseklik × 4 bayt:

Diskte 5 MB olan bir telefon fotoğrafı işlem sırasında rahatlıkla 250 MB isteyebilir. Üstelik -scaled küçültmesi de bir işlemdir; yani orijinali RAM'e açmadan küçültemezsiniz. Duvar tam burada çıkar.

WordPress'in yönetim panelinde kullandığı bellek tavanı WP_MAX_MEMORY_LIMIT sabitidir ve varsayılanı 256 MB'dır. Ancak bu sabit, PHP'nin kendi memory_limit değerinden büyük olamaz — PHP 128 MB'ta ise WordPress'in 256 yazması hiçbir şey değiştirmez. İkisini birlikte yükseltin:

// wp-config.php icinde, "That's all, stop editing!" satirindan ONCE
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

; php.ini veya cPanel'de MultiPHP INI Editor
memory_limit = 512M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

Değişiklikten sonra PHP-FPM'i yeniden başlatmayı unutmayın; aksi hâlde eski değer havuzda yaşamaya devam eder. Bellek sınırlarının hangi katmanda hangisini ezdiğini PHP memory_limit yazısında ayrıntılı bulabilirsiniz; hatanın klasik metin hâliyle karşılaşıyorsanız allowed memory size exhausted hatası yazısı da doğrudan konuyla ilgilidir.

Teyit için hata günlüğüne bakın — tahmin etmeyin:

tail -n 50 wp-content/debug.log
grep -i 'allowed memory size' /var/log/php-fpm/error.log

Allowed memory size of X bytes exhausted satırını gördüğünüz anda teşhis kesinleşmiştir. Görmüyorsanız sorun bellek değildir ve bir sonraki bölüme geçin.

ImageMagick policy.xml: Sunucunun Söylemediği Sınır#

Imagick kurulu, bellek bol, ama hâlâ büyük dosyalar işlenmiyorsa suçlu neredeyse kesin olarak ImageMagick'in kendi güvenlik politikasıdır. Bu dosya, bir zamanlar ciddi güvenlik açıklarına yol açan kod çözücüleri (PDF, PostScript, MSL, MVG) kapatmak için sunucularda oldukça sıkı ayarlanır — ve bu sıkılaştırma sırasında bellek, alan ve boyut limitleri de sık sık gereğinden düşük bırakılır.

Aktif limitleri okuyun:

# Su an gecerli kaynak limitleri
identify -list resource

# Politika dosyasinin yeri surume gore degisir
ls -l /etc/ImageMagick-6/policy.xml /etc/ImageMagick-7/policy.xml 2>/dev/null

# Hangi politikalar dayatiliyor?
identify -list policy

identify -list resource çıktısında Memory, Map, Area, Width, Height ve Disk satırlarını göreceksiniz. Width değeri örneğin 16KP ise 16.000 pikselden geniş bir görsel hiç işlenmez; Area düşükse toplam piksel sayısı sınırı devreye girer. Tipik bir üretim yapılandırması şöyle görünür:

<policymap>
  <policy domain="resource" name="memory" value="512MiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <policy domain="resource" name="area" value="256MP"/>
  <policy domain="resource" name="disk" value="2GiB"/>
  <policy domain="resource" name="width" value="32KP"/>
  <policy domain="resource" name="height" value="32KP"/>
  <policy domain="coder" rights="none" pattern="PS"/>
  <policy domain="coder" rights="none" pattern="PDF"/>
</policymap>

Kaynak limitlerini yükseltirken coder satırlarına dokunmayın; PDF ve PostScript kod çözücülerinin kapalı kalması gerçek bir güvenlik önlemidir ve bir web sitesinin görsel üretimiyle ilgisi yoktur. Sadece resource satırlarını düzenleyin, ardından PHP-FPM'i yeniden başlatın. Paylaşımlı barındırmadaysanız bu dosyayı düzenleme yetkiniz olmaz; o durumda destek ekibine "ImageMagick policy.xml içindeki memory ve area limitleri düşük" diye somut bir talep açmak, "görseller yüklenmiyor" demekten çok daha hızlı sonuç verir.

Imagick Kurulu Ama WordPress Kullanmıyor: Düzenleyiciyi Zorlamak#

Bazen doğru cevap Imagick'i onarmak değil, geçici olarak GD'ye geçmektir — özellikle Imagick sürümü ile PHP sürümü arasında bilinen bir uyumsuzluk varsa. WordPress bunun için wp_image_editors filtresini sunar ve dizideki sıra önceliği belirler:

// GD'yi one al (Imagick sorun cikariyorsa gecici cozum)
add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

// Tam tersi: Imagick'i zorla (GD buyuk dosyalarda oluyorsa)
add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_Imagick', 'WP_Image_Editor_GD' );
} );

Bu kodu temanın functions.php dosyasına değil, wp-content/mu-plugins/gorsel-duzenleyici.php gibi bir mu-plugin dosyasına koyun; böylece tema güncellemesinde silinmez. Tema dosyalarını tercih ediyorsanız mutlaka bir child tema kullanın.

Ardından Site Sağlığı ekranına dönüp "Aktif düzenleyici" satırının gerçekten değiştiğini doğrulayın. Değişmediyse zorladığınız sınıfın test() metodu başarısız oluyor demektir — yani o kütüphane sunucuda kullanılabilir durumda değildir.

Belirtiden nedene hızlı bir karar tablosu:

WebP ve AVIF Desteği Neden Ayrı Bir Sorun?#

Küçük resim üretimi çalışıyor ama .webp dosyaları yüklenmiyorsa, kütüphane var demektir; eksik olan o formatın desteğidir. GD, PHP derlenirken WebP desteği eklenmediyse .webp dosyalarını okuyamaz; gd_info() çıktısında WebP Support değerinin true olması gerekir. Imagick tarafında da aynı şey geçerlidir: ImageMagick libwebp olmadan derlendiyse desteklenen format listesinde WEBP hiç görünmez.

WordPress 5.8'den beri WebP dosyaları çekirdek tarafından yüklenip düzenlenebiliyor; AVIF desteği ise WordPress 6.5 ile geldi. Ancak dikkat edilmesi gereken bir nokta var: WordPress varsayılan olarak yüklediğiniz JPEG'leri WebP'ye çevirmez. Alt boyutların hangi formatta üretileceğini image_editor_output_format filtresi belirler ve varsayılanı boştur, yani "girdiyle aynı format".

// Yuklenen JPEG ve PNG'lerin ALT BOYUTLARINI WebP olarak uret
add_filter( 'image_editor_output_format', function ( $formats ) {
    $formats['image/jpeg'] = 'image/webp';
    $formats['image/png']  = 'image/webp';
    return $formats;
} );

Bu filtreyi açmadan önce iki şeyi doğrulayın: kütüphane WebP yazabiliyor olmalı ve önbellek/CDN katmanınız yeni uzantıyı doğru servis etmeli. Format seçiminin kalite ve boyut karşılaştırmasını WebP formatına dönüştürme yazısında bulabilirsiniz.

Eksik Boyutları Toplu Olarak Yeniden Üretmek#

Kütüphane sorununu çözdüğünüzde geçmiş kendiliğinden düzelmez. Sorun devam ettiği süre boyunca yüklenen tüm görsellerin türevleri hâlâ eksiktir ve tema her birinde orijinal dosyayı basmaya devam eder. Bunları toplu üretmek son adımdır.

WP-CLI erişiminiz varsa en temiz yol budur:

# ONCE yedek alin: veritabani + uploads klasoru
wp db export yedek-$(date +%F).sql
tar -czf uploads-yedek-$(date +%F).tar.gz wp-content/uploads

# Sadece EKSIK olan boyutlari uret (mevcut dosyalara dokunmaz)
wp media regenerate --only-missing --yes

# Tek bir boyutu hedefle (yeni bir add_image_size ekledikten sonra)
wp media regenerate --image_size=thumbnail --yes

# Belirli ID'ler - buyuk kutuphaneleri parca parca islemek icin
wp media regenerate 1200 1201 1202 --yes

--only-missing bayrağı burada önemlidir: var olan türevleri yeniden yazmaz, yalnızca eksik olanları üretir. Bu hem çok daha hızlıdır hem de daha önce elle optimize ettiğiniz dosyaların üzerine yazma riskini ortadan kaldırır.

Birkaç bin görselli bir kütüphanede işlem saatler sürebilir ve SSH oturumunuz kopabilir. Uzun süren işi oturumdan bağımsız hâle getirin:

nohup wp media regenerate --only-missing --yes > regen.log 2>&1 &
tail -f regen.log

WP-CLI erişiminiz yoksa aynı işi yönetim panelinden yapan Regenerate Thumbnails gibi eklentiler vardır. Bunları kullanırken tarayıcı sekmesini açık tutmanız gerekir ve max_execution_time düşükse işlem yarıda kesilir; geçici olarak 300 saniyeye çekmek işi kolaylaştırır. Bittiğinde eklentiyi devre dışı bırakın.

Son bir kontrol: yeniden üretim bittikten sonra tarayıcının ağ sekmesinde görselin gerçekten -768x432.jpg gibi bir türevle yüklendiğini doğrulayın. Hâlâ orijinal dosya çağrılıyorsa sorun kütüphanede değil, temanın the_post_thumbnail() çağrısındadır. Görsel ağırlığını kalıcı düşürmenin bütün resmi için WordPress görsel optimizasyonu yazısına göz atın.

Aynı Sorunu Yeniden Yaşamamak İçin#

Tekrarı engelleyen üç alışkanlık var. Birincisi, fotoğraf makinesinden çıkan dosyaları doğrudan yüklememek: uzun kenarı 2560 pikselin altına indirilmiş bir görsel -scaled adımını tamamen atlar ve bellek riskini sıfıra yakın hâle getirir.

İkincisi, PHP sürümünü her yükselttiğinizde Site Sağlığı ekranındaki Medya İşleme bölümüne geri dönmek; sürüm değişimi eklenti listesini sıfırlayabilir ve Imagick sessizce kaybolabilir.

Üçüncüsü, yeni bir tema veya add_image_size() kullanan bir eklenti kurduğunuzda wp media regenerate --only-missing komutunu bir kez çalıştırmak. Aksi hâlde yeni boyut yalnızca o günden sonra yüklenen görsellerde var olur, eski içerikte sessizce eksik kalır.

Sıkça Sorulan Sorular#

Imagick mi GD mi kullanmalıyım?#

Mümkünse Imagick. Bellek yönetimi daha akıllıdır, disk önbelleğine taşabildiği için büyük dosyalarda daha az patlar ve yeniden boyutlandırma kalitesi gözle görülür biçimde daha iyidir. Ancak Imagick'in kurulu olması tek başına yetmez: sunucudaki policy.xml kaynak limitleri düşükse GD'den bile daha erken pes edebilir. Imagick'i kurun, sonra limitlerin makul olduğunu doğrulayın.

Post-processing hatası alıyorum ama sunucumda bolca bellek var. Neden?#

Sunucunun toplam RAM'i ile PHP'nin tek bir isteğe ayırdığı bellek farklı şeylerdir. 32 GB RAM'li bir makinede bile PHP memory_limit 128 MB ise, 24 megapiksellik bir fotoğrafın işlenmesi o sınıra çarpar ve süreç sonlandırılır. wp-config.php içindeki WP_MAX_MEMORY_LIMIT de PHP'nin sınırından büyük olamaz; ikisini birlikte yükseltip PHP-FPM'i yeniden başlatmanız gerekir.

Küçük resimleri yeniden üretmek eski görsellerimi bozar mı?#

--only-missing bayrağıyla çalıştırdığınızda hayır; bu mod yalnızca eksik türevleri üretir, mevcut dosyalara dokunmaz. Bayraksız çalıştırdığınızda ise tüm türevler orijinalden yeniden üretilir. Daha önce bir sıkıştırma eklentisiyle optimize ettiyseniz o kazanç silinir ve yeniden optimize etmeniz gerekir. Her iki durumda da işlemden önce uploads klasörünün ve veritabanının yedeğini alın.

Site Sağlığı Imagick'i öneriyor ama hostingimde kuramıyorum, ne yapmalıyım?#

Paylaşımlı barındırmada eklenti listesi genellikle panelden yönetilir; cPanel kullanıyorsanız PHP eklenti seçimi ekranından imagick kutusunu işaretlemeyi deneyin. Seçenek yoksa destek ekibine talep açın. Kuramadığınız durumda site çalışmaya devam eder, çünkü GD de küçük resim üretir. Yalnızca görselleri 2560 pikselin altına indirmeye ve PDF gibi Imagick gerektiren dosyaları medya kütüphanesinde işlemeye çalışmamaya dikkat edin.

WordPress yüklediğim JPEG'leri neden otomatik WebP yapmıyor?#

Çünkü çekirdek varsayılanı böyle değildir. WordPress 5.8'den beri WebP dosyalarını yükleyip düzenleyebilir, ama yüklediğiniz bir JPEG'in alt boyutlarını yine JPEG olarak üretir. Dönüşümü istiyorsanız image_editor_output_format filtresini kullanmanız ya da bu işi yapan bir görsel optimizasyon eklentisi kurmanız gerekir. Filtreyi açmadan önce kütüphanenizin WebP yazabildiğini doğrulayın.

Yükleme sırasında HTTP hatası alıyorum, bu da aynı sorun mu?#

Aynı aileden ama farklı bir dal. Genel HTTP hatası mesajı bellek yetersizliğinden de gelebilir, ancak upload_max_filesize ve post_max_size gibi yükleme limitlerinden, güvenlik duvarı kurallarından ya da geçici klasör izinlerinden de kaynaklanabilir. Ayrımı hata günlüğü yapar: allowed memory size satırı görüyorsanız bellek, görmüyorsanız önce limitlere ve dosya izinlerine bakın.

Türevler üretiliyor ama tema hâlâ orijinal dosyayı basıyor?#

Bu artık bir kütüphane sorunu değil, tema veya eklenti sorunudur. Tarayıcının ağ sekmesinde çağrılan dosya adına bakın: -768x432.jpg gibi bir son ek yoksa tema görseli full boyutuyla çağırıyor ya da bir sayfa oluşturucu görseli sabit URL olarak gömüyor olabilir. Çözüm görsel işleme katmanında değil, şablonun istediği boyut adındadır.

Kapanış#

Eksik küçük resim sorunu, görünürde tek bir hata mesajının arkasında birbirinden bağımsız beş nedeni saklar: kütüphanenin hiç olmaması, yanlış kütüphanenin seçilmesi, PHP belleğinin yetmemesi, ImageMagick politikasının kısıtlaması ve formatın desteklenmemesi. Bunları tahminle değil sırayla eleyin — Site Sağlığı ekranı, hata günlüğü ve identify -list resource çıktısı birkaç dakikada doğru dalı gösterir.

Kaynağı düzelttikten sonra wp media regenerate --only-missing komutunu çalıştırmayı ihmal etmeyin; onsuz sorun "bugünden itibaren" çözülmüş, geçmiş içeriğinizde ise olduğu gibi kalmış olur. Bol bellek ve güncel PHP eklentilerinin garanti edildiği bir barındırma zemininde aynı sorunun tekrar etme ihtimali baştan düşer.