WordPress Blocks API ile temel blokların supports ayarlarını değiştirin, özel stiller ekleyin ve variation kullanarak blok editörünü ihtiyacınıza göre düzenleyin.
Paragraf bloğunda kullanılmasını istemediğiniz bir ayar var ya da Görsel bloğuna sitenize özgü hazır bir görünüm eklemek istiyorsunuz. Böyle küçük ihtiyaçlarda mevcut bloğu kopyalayıp yeni bir blok geliştirmek işleri gereksiz yere büyütür. WordPress Blocks API, çekirdek blokların kayıt bilgilerine ve davranışlarına kontrollü biçimde müdahale etmeyi mümkün kılar.
Burada amaç WordPress çekirdek dosyalarını değiştirmek değil. core/paragraph, core/image veya core/button gibi mevcut blokların supports özellikleri sınırlandırılabilir, yeni stiller eklenebilir ve önceden hazırlanmış variation seçenekleri oluşturulabilir. WordPress blokları sunucu ve istemci tarafında ağırlıklı olarak block.json metadata yapısıyla kaydedildiği için genişletme işlemlerinde de bu kayıt sürecindeki API’lerden yararlanılır.
Blokların renk veya görünüm seçeneklerini değiştiriyorsanız sitenin diğer tasarım kararlarını da hesaba katmak gerekir. WordPress Karanlık Mod Nasıl Kurulur konusu, aynı blokların açık ve koyu renk düzenlerinde nasıl davranacağını planlarken bağlantılı bir örnektir. Özellikle renk kontrollerini kaldırmadan önce farklı görünüm senaryolarını kontrol etmek beklenmedik sonuçları önler.

WordPress Blocks API Nedir ve neyi değiştirebilir?
WordPress Blocks API, mevcut blokların kayıt özelliklerini, desteklediği editör kontrollerini, alternatif stillerini ve başlangıç varyasyonlarını değiştirmek veya genişletmek için kullanılan WordPress API’lerini kapsar. Küçük bir özelleştirme için yeni blok oluşturmak yerine çekirdek bloğun metadata, supports, style veya variation özellikleri hedeflenebilir.
İlk bakılacak yer çoğu zaman supports alanıdır.
Örneğin içerik editörlerinin Paragraf bloğunda margin kullanmasına izin verirken padding kontrolünü kaldırmak istediğinizi düşünün. block_type_metadata filtresi, block.json içinden gelen ham metadata henüz işlenmeden önce çalışır.
function site_paragraph_spacing( $metadata ) {
if ( 'core/paragraph' === $metadata['name'] ) {
$metadata['supports']['spacing'] = array(
'margin' => true,
'padding' => false,
);
}
return $metadata;
}
add_filter( 'block_type_metadata', 'site_paragraph_spacing' );
Bu işlem Paragraf bloğunu yeniden oluşturmaz. Yalnızca kayıt sırasında spacing davranışını değiştirir.
Ben WordPress Blocks API ile çalışırken önce bloğun mevcut supports yapısını kontrol ediyorum. Temmuz 2026’da güncellenen WordPress geliştirici belgelerinde de kayıt filtrelerinin kapsamı oldukça açık biçimde ayrılmış durumda. Daha önce yeni kontrol geliştirmeyi düşündüğünüz bir özellik, aslında blok metadata’sında bulunan ancak kapalı olan bir destek seçeneği çıkabiliyor.
register_block_type_args ne zaman işe yarar?
Bir başka seçenek register_block_type_args filtresidir. Bu filtre, blok sunucu tarafında resmi olarak kaydedilmeden hemen önce oluşan argüman dizisine erişir.
WordPress bunu sunucu tarafındaki en düşük seviyeli PHP kayıt filtresi olarak tanımlıyor. Burada verilen sunucu ayarları istemci tarafındaki karşılıklarına göre daha yüksek öncelikle aktarılıyor.
Örneğin Buton bloğunda kullanıcıların renkleri değiştirmesini istemiyorsanız:
function site_button_settings( $args, $block_type ) {
if ( 'core/button' === $block_type ) {
$args['supports']['color'] = array(
'text' => false,
'background' => false,
'link' => false,
);
}
return $args;
}
add_filter( 'register_block_type_args', 'site_button_settings', 10, 2 );
Kurumsal tasarım sistemlerinde bunun karşılığı oldukça nettir. Editöre sınırsız renk seçeneği vermek yerine tasarım kararları tema tarafından korunabilir.

Aynı bloğa yeni görünüm nasıl eklenir?
Bloğun çalışma biçimini değiştirmeyecekseniz Supports API’ye müdahale etmek şart değildir. Bazen gereken şey yalnızca ikinci bir görünüm seçeneğidir.
WordPress Blocks API içinde Block Styles bunun için kullanılır. register_block_style() mevcut bir bloğa yeni stil kaydeder ve seçildiğinde blok sarmalayıcısına is-style-{isim} sınıfını ekler. PHP tarafındaki kayıt fonksiyonu inline_style, style_handle ve style_data gibi özellikleri destekler.
Görsel bloğu için basit bir örnek:
function site_image_styles() {
register_block_style(
'core/image',
array(
'name' => 'soft-corners',
'label' => 'Yumuşak Köşe',
'inline_style' => '
.wp-block-image.is-style-soft-corners img {
border-radius: 18px;
}
',
)
);
}
add_action( 'init', 'site_image_styles' );
CSS birkaç satırı aşacaksa ayrı stil dosyası kullanmak kodu daha rahat yönetilebilir tutar.
Burada küçük bir ayrıntı var: PHP ile çalışan unregister_block_style() yalnızca sunucu tarafında PHP ile kaydedilmiş stilleri kaldırabilir. JavaScript ile kayıt edilmiş bir stil JavaScript tarafında kaldırılmalıdır. WordPress’in güncel Block Styles belgeleri bu ayrımı özellikle belirtiyor.
Style ile variation arasındaki fark nedir?
Bu iki kavram sık karışıyor.
Style, aynı bloğun görünümünü değiştirir. Variation ise mevcut bloğu belirli başlangıç özellikleri veya iç bloklarla hazır hale getirir. WordPress’in Embed bloğundaki farklı servis seçenekleri bu yapının bilinen örneklerinden biridir.
Örneğin Group bloğunu editörlerin her seferinde aynı flex düzenine çevirmesini istemiyorsanız variation hazırlanabilir:
wp.blocks.registerBlockVariation(
'core/group',
{
name: 'content-row',
title: 'İçerik Satırı',
attributes: {
layout: {
type: 'flex'
}
},
scope: [ 'inserter' ]
}
);
JavaScript ile oluşturulan variation dosyası editörde enqueue_block_editor_assets üzerinden yüklenebilir. Mayıs 2026’da güncellenen WordPress tema belgeleri de bu yükleme yöntemini kullanıyor.
2026 itibarıyla variation yalnızca JavaScript seçeneği de değil. get_block_type_variations filtresiyle PHP üzerinden dinamik variation kayıtları oluşturulabiliyor. Bu özellikle variation değerleri yazı türü veya taxonomy gibi WordPress verilerine bağlı olacaksa kullanışlıdır.

WordPress Blocks API kullanırken nerede durmak gerekir?
Bir ayarı kapatmak için önce supports yapısına bakın. Kayıt bilgisinin kendisi değişecekse metadata filtreleri değerlendirilebilir. Görünüm farkı gerekiyorsa Block Styles, aynı bloğun hazır bir başlangıç sürümü isteniyorsa variation daha temiz kalır.
WordPress Blocks API kullanmanın avantajı tam da burada ortaya çıkıyor. Küçük ihtiyaç için yüzlerce satırlık yeni blok üretmek yerine WordPress’in mevcut kayıt mekanizmasını kullanırsınız.
Bu değişiklikler editörde geniş etki oluşturabileceğinden kodu canlı sisteme geçirmeden önce test ortamında denemek daha güvenlidir. Özellikle bir filtreyi yalnızca hedef core/* bloğuna uyguladığınızdan emin olun.
Blok editörü veya WordPress yapılandırmasında teknik desteğe ihtiyaç duyulduğunda 11858, 2011 yılından bu yana Türkiye genelinde milyonlarca kullanıcıya 7/24 profesyonel teknik destek sunuyor. Bilgisayar, akıllı TV, sosyal medya ve modem dahil farklı alanlarda çalışan ekip gerektiğinde TeamViewer ve AnyDesk üzerinden lisanslı uzaktan bağlantı sağlıyor. Hizmet dakika bazlı şeffaf ücretlendirmeyle yürütülüyor; yüzde 95 memnuniyet oranı ve 500.000’den fazla başarılı işlem tecrübesi bulunuyor.
Blok davranışları site genelinde standardize edildiğinde aynı yapıların farklı dil sürümlerinde nasıl kullanılacağı da ayrı bir tasarım kararına dönüşür. WordPress Blok Temalarını Çok Dilli Hale Getirme konusu bu noktada devam edebileceğiniz bağlantılı bir alandır. Stil isimleri, editörde görünen etiketler ve özel variation başlıkları kullanıyorsanız çeviri yapısını da geliştirme sırasında hesaba katmak gerekir.
WordPress Blocks API için doğru yaklaşım, mümkün olan her bloğu değiştirmek değil, ihtiyacı en küçük müdahaleyle çözmektir. Çekirdek blok zaten yapmak istediğiniz işin yüzde 90’ını karşılıyorsa kalan yüzde 10 için yeni blok geliştirmek çoğu zaman gereksizdir. Siz hangi temel WordPress bloğunun davranışını değiştirmek istiyorsunuz? Yorumlarda paylaşabilirsiniz.