PHP dosyasından editördeki blok hücrelerine uzanan tek bağlantı çizgisini gösteren soyut diyagram

WordPress 7.0 ile basit, sunucu taraflı bloklar artık yalnızca PHP ile kaydedilebiliyorblock.json dosyasına ve JavaScript kaydına gerek kalmadan. Bu, mevcut React/JS blok geliştirme yöntemini ortadan kaldırmıyor; register_block_type() içine eklenen yeni autoRegister bayrağıyla, düşük etkileşimli bloklar için tek bir PHP fonksiyonu yeterli hale geliyor.

Ne Değişti: register_block_type() ve autoRegister Bayrağı

Değişiklik, 3 Mart 2026 tarihli resmi Core dev notunda duyuruldu ve WordPress 7.0 ile birlikte geldi. Yeni yöntemde register_block_type() fonksiyonuna metadata’yı doğrudan bir dizi (array) olarak veriyorsunuz; supports.autoRegister değeri true olduğunda WordPress, editörde blok için gereken JavaScript’i kendisi üretiyor.

function ns_register_php_only_block() {
	register_block_type(
		'ns/example',
		array(
			'title'      => __( 'Example Block', 'ns' ),
			'attributes' => array(
				'count' => array(
					'type'    => 'integer',
					'default' => 0,
				),
			),
			'render_callback' => function ( $attributes ) {
				return sprintf(
					'<p>%s: %d</p>',
					esc_html__( 'Count', 'ns' ),
					(int) $attributes['count']
				);
			},
			'supports' => array(
				'autoRegister' => true,
			),
		)
	);
}
add_action( 'init', 'ns_register_php_only_block' );

Bu kod parçası tek başına yeterli: block.json dosyası yok, webpack/wp-scripts build adımı yok, ayrı bir JS dosyası yok. WordPress, attributes tanımına bakarak Inspector panelinde otomatik kontroller (metin kutusu, sayı girişi, açma/kapama, açılır liste) oluşturuyor.

Eski Yöntem Neden Bu Kadar Ağırdı: block.json + Çift Kayıt

Klasik blok kaydında bile en basit blok için üç ayrı parça gerekiyordu: metadata’yı tanımlayan bir block.json, onu okuyan bir PHP register_block_type() çağrısı ve editördeki edit/save bileşenlerini tanımlayan bir JavaScript dosyası. Resmi Block Editor Handbook, en iyi pratiğin bloğu hem sunucuda hem istemcide kaydetmek olduğunu vurguluyor — yani JS kaydı olmadan editör deneyimi eksik kalıyor.

// block.json
{
	"apiVersion": 3,
	"name": "ns/example",
	"title": "Example Block",
	"attributes": {
		"count": { "type": "integer", "default": 0 }
	}
}

// PHP: register_block_type( __DIR__ . '/build' );

// src/index.js
import { registerBlockType } from '@wordpress/blocks';
import metadata from './block.json';
import Edit from './edit';
import save from './save';

registerBlockType( metadata.name, {
	edit: Edit,
	save,
} );

Bu üçlü yapı zengin, etkileşimli bloklar için hâlâ doğru yaklaşım. Ama sadece birkaç metin alanı gösteren, sunucu taraflı basit bir blok için bu kadar altyapı kurmak gereksiz bir maliyetti — autoRegister tam olarak bu boşluğu dolduruyor.

register_block_type() Çağrısının Anatomisi

attributes dizisinde tanımladığınız her alan, editörde otomatik bir kontrole dönüşüyor — ama bu otomasyonun sınırı var. Yalnızca dört temel tip destekleniyor: string, integer, boolean ve enum (açılır liste için sabit string değerleri). array veya object gibi karmaşık tipler, autoRegister ile otomatik bir kontrole dönüşmüyor.

supports.autoRegister => true ise, WordPress bu bloğu bir JavaScript global’i üzerinden editöre bildiriyor; ayrı bir registerBlockType() çağrısı yazmanıza gerek kalmıyor. Editör, bloğu önizlerken ServerSideRender bileşenini kullanıyor.

render_callback Nasıl Çalışır

render_callback hem editördeki önizlemeyi hem de cephedeki (frontend) çıktıyı üreten tek fonksiyon. Inspector panelinde bir attribute değiştirdiğinizde, editör WordPress REST API’sine bir istek atıyor, bu istek render_callback‘i çalıştırıyor ve dönen HTML önizlemede güncelleniyor. Ayrı bir save fonksiyonu veya derlenmiş JS çıktısı yok — kaynak tek: PHP.

Sınırlamalar: Nerede Duruyor

autoRegister, mevcut istemci taraflı blok paradigmasının yerini almak için tasarlanmadı; düşük karmaşıklıklı, sunucu taraflı bloklar için bir kısayol. Üç sınırlama özellikle önemli:

  • InnerBlocks desteklenmiyor. Gutenberg ekibinden Miguel Fonseca, ilgili tartışmada bunun için “net bir vizyon olmadığını” belirtti — yani PHP-only bir blok, içine başka blok kabul edemiyor.
  • Attribute tipleri sınırlı. Sadece string, integer, boolean ve enum otomatik kontrole dönüşüyor; array/object gibi karmaşık veri yapıları desteklenmiyor.
  • postId aktarımında bilinen bir hata var. uses_context ile postId talep ettiğinizde değer yalnızca ilk render’da doluyor; editördeki sonraki REST çağrılarında boş geliyor (Trac ticket #65331 olarak kabul edilmiş bir hata).

Ne Zaman PHP-only, Ne Zaman Klasik JS Blok

Kararı tek bir soruya indirgemek mümkün: Blok, iç içe blok yapısı veya canlı/interaktif bir editör deneyimi gerektiriyor mu? Gerektirmiyorsa — örneğin bir widget veya shortcode’u bloğa taşıyorsanız, ya da sadece birkaç sabit alanla sunucu taraflı içerik gösteriyorsanız — autoRegister daha az kod ve sıfır build adımıyla aynı işi görüyor.

WordPress 7.0 mu, 7.1 mi? Karıştırmayın

PHP-only blok kaydı WordPress 7.0’ın bir özelliği — Core dev notu Mart 2026’da yayınlandı ve autoRegister bayrağı o sürümle geldi. Bunu, 19 Ağustos 2026’da yayınlanan WordPress 7.1 “Mary Lou” ile karıştırmayın: 7.1, Playlist ve Tabs gibi yeni bloklar, tarayıcıda medya işleme ve simge (icon) kaydı için yeni fonksiyonlar getirdi, ama block registration mekanizmasını değiştirmedi. Siteniz zaten 7.1’e güncellendiyse autoRegister bayrağı orada da çalışmaya devam ediyor; bu bir 7.0-only özellik değil, 7.0’da eklenip sonraki sürümlerde de duran bir API.

7.1 sürecini daha yakından takip ettiyseniz 7.1 RC1 yazımızdaki uyumluluk notları da işinize yarayabilir.

Sıkça Sorulan Sorular

WordPress’te PHP ile blok nasıl kaydedilir?

register_block_type() fonksiyonuna blok adını ve bir metadata dizisini (title, attributes, render_callback) doğrudan veriyorsunuz; dizinin supports anahtarına 'autoRegister' => true ekleyip init hook’unda çağırdığınızda blok, block.json veya JavaScript olmadan editörde görünür.

block.json dosyası hâlâ zorunlu mu?

Hayır, autoRegister yöntemiyle zorunlu değil. Ancak zengin, istemci taraflı etkileşim isteyen bloklar için block.json + register_block_type() + registerBlockType() üçlüsü hâlâ önerilen, daha yetenekli yöntem.

PHP-only bloklar InnerBlocks destekliyor mu?

Hayır. Gutenberg ekibi, autoRegister ile kaydedilen bloklarda InnerBlocks için şu an net bir plan olmadığını belirtti. İç içe blok yapısına ihtiyacınız varsa klasik JS/React yöntemini kullanmanız gerekiyor.

autoRegister bayrağı hangi WordPress sürümünde geldi?

WordPress 7.0 ile geldi (Core dev notu: Mart 2026). 19 Ağustos 2026’da yayınlanan WordPress 7.1 “Mary Lou” bu özelliği değiştirmedi, üstüne yeni blok ve medya işleme özellikleri ekledi.

autoRegister ile kaydedilen bir bloğu sonradan JS blok yapabilir miyim?

Evet, ama otomatik bir geçiş yok. block.json oluşturup registerBlockType() ile client-side kaydı eklemeniz, gerekirse InnerBlocks veya karmaşık attribute’lar için edit/save bileşenlerini yeniden yazmanız gerekir.

Sonuç

autoRegister, WordPress’in blok geliştirmeyi PHP-only geliştiriciler için de erişilebilir kılma çabasının bir parçası — Abilities API gibi diğer 2026 geliştirmeleriyle aynı yönde ilerliyor: WordPress çekirdeğini JavaScript build zincirine bağımlı olmadan genişletmek. Basit, sunucu taraflı bloklarınız için bugün deneyebilirsiniz; InnerBlocks veya zengin etkileşim gerektiren bloklar için klasik yöntem hâlâ yerinde duruyor. Sitenizde resmi tarayıcı eklentisiyle blok sınırlarını görünür kılıp yeni PHP-only bloklarınızı editörde test edebilirsiniz.

Aytaç Özdalgıç

Hakkında

Aytaç Özdalgıç

Full Stack Designer — Grafik Tasarım Yöneticisi, KJ Power

UX odaklı tasarım kararlarını yazılım mimarisiyle ilişkilendirerek sürdürülebilir dijital sistemler kurguluyorum. 20 yıla yakın kariyerimde, kullanıcı araştırmasından frontend’e uzanan uçtan uca ürün geliştirme süreçlerinde çalıştım.

Hakkımda daha fazlası →

Bir Yorum Yazın

Aytaç Özdalgıç sitesinden daha fazla şey keşfedin

Okumaya devam etmek ve tüm arşive erişim kazanmak için hemen abone olun.

Okumaya Devam Edin