WordPress 7.0.1 Bakim Surumu: 7.1 Oncesi 31 Hata Duzeltmesi

🇬🇧 English: Read this in English →

Bakım sürümleri, WordPress’in sektör basınının hiç yazmadığı ama benim en çok önemsediğim tarafıdır. Yeni özellik yok, tanıtım turu yok, pazarlama söylemi yok — sadece son büyük sürümün önümüzdeki üç ay boyunca yayında kalmaya güvenli olup olmadığını belirleyen sessiz temizlik geçişi. Açık konuşayım: bir ajansın olgunluğunu, en son hangi parlak özelliği kurduğundan çok, bu tür sürümleri nasıl karşıladığından anlarım.

WordPress 7.0.1, 9 Temmuz 2026’da, Aaron Jorbin’in üç hafta önce yayımladığı takvime dakikası dakikasına uydu. Çekirdek ve Blok Düzenleyici genelinde otuz bir hata düzeltmesi. Yeni API yok. Kendi müşteri sitelerimde şu ana kadar üretebildiğim davranış değişikliği yok. Zaten mesele de bu.

Bu sürüm, WordPress 7.1 Beta 1’in trunk dalını sabitleyeceği 15 Temmuz’dan yalnızca altı gün önce çıkıyor. Bu yazıyı gelecek haftaya bırakmamanın asıl nedeni de bu. Siten 7.1 döngüsü açıldığında hâlâ 7.0.0 üzerindeyse, aynı pencerede iki geçişi üst üste bindirmiş olursun. Önce 7.0.1’i al.

Gerçekte ne değişti

WordPress 7.0.1, Aaron Jorbin, Brian Haas, Carlos Bravo ve Estela Rueda’nın yönettiği kısa döngülü bir bakım sürümü. wordpress.org/news üzerindeki resmi duyuru 9 Temmuz 2026 tarihli. Sürüm, “çekirdek ve blok düzenleyici genelinde otuz bir hatayı, blok düzenleyici, e-posta ve klasik temalar dahil WordPress’in birden fazla alanını etkileyen sorunlar için” düzeltiyor. Bu ifade, doğrudan 7.0.1 belge sayfasından alındı.

Değişiklik seti şekli önemli. Blok Düzenleyici tarafındaki düzeltmelerin tamamı tek bir eşzamanlama işlemi altında toplanıyor (changeset 62610). Bu, tam olarak Haziran sonunda yayımlanan “Gutenberg Kodunun WordPress Develop’a Eşzamanlama Kuralları” yazısının anlattığı disiplin — Gutenberg tarafı için minör başına tek toplu commit, çekirdek tarafı için ayrı Trac biletleri. Bu disiplinin log’da temiz göründüğü ilk bakım sürümü bu.

Çekirdek tarafındaki düzeltmeler az sayıda bileşen etrafında toplanıyor — Ortam (Ortam Kitaplığı arama çubuğu konumu, spinner hizalaması, görsel düzenleme ekranında ölçek/kırpma alanı uyuşmazlığı), Editör yöneticisi (Blok Görünürlüğü’nün “her yerde gizle” davranışı, artık kalan Gutenberg varlık dosyaları, görsel düzenleme ekranındaki Ölçekle düğmesi), inline CSS içinde background-image: url() için wp_kses()‘in sertleştirilmesi, wp_get_attachment_image_src fonksiyonunda PHP 8.5 dizi erişim hatası, ve bir dizi yönetici arayüzü gerilemesi (mobil form öğeleri, kalabalıklaşan Yayımla düğmeleri, Network başlık logosu). Kanonik liste 1 Temmuz’daki RC1 duyurusu; bilet türüne göre filtrelersen çekirdek tarafının on üç bilette, Gutenberg eşzamanlamasının ise toplamı otuz bire çıkardığı görülür.

Yokluğuyla dikkat çeken iki şey var: güvenlik düzeltmesi yok (bu bir güvenlik sürümü değil), veritabanı güncellemesi yok. Jorbin’in 18 Haziran’da yayımladığı takvim 1 Temmuz için RC1, 9 Temmuz için genel sürüm diyordu — iki tarih de gününde tutturuldu.

WordPress ve WooCommerce insanları için neden önemli

WordPress 7.0, 20 Mayıs 2026’da çıktı. İlk bakım sürümüne yedi hafta, modern bir majör için uzun tarafta — 6.8 ilk noktayı üç haftanın altında almıştı. 7.0’ın bu kadar sürmesinin sebebi tembellik değil; sürüm ekibi yarım kalmış Gutenberg dallarını kararlı bir bakım sürümüne sokmayı reddetti. Aslında sağlıklı okuma bu: gerçek zamanlı işbirliği (RTC) döngü ortasında geri çekildi, React 19 yükseltmesi geri alındı, ekip bakımı bu iki büyük olayın tozu dağılana kadar bekletti.

Ajans işi için pratik sonuçlar dar ama gerçek. Inline CSS’te background-image: url() için wp_kses() düzeltmesi, kahraman arka planları veya dinamik galeri kapakları için satır içi stil yazan tema ve eklentilerin varsa önemli — 7.0.0 sonrası bazıları temizlenip atılıyordu. PHP 8.5 wp_get_attachment_image_src düzeltmesi, staging veya üretimi PHP 8.5’e taşıdıysan kritik; 8.5’teki dizi erişim sıkılaştırması yıllardır uyuyan gizli bir hatayı yüzeye çıkardı. Ve Blok Görünürlüğü düzeltmesi, birkaç blok kütüphanesinin blokları role veya bağlama göre kapatmak için güvendiği “her yerde gizle” davranışını geri getiriyor.

WooCommerce siteleri için bu haftaki güncelleme özel bir anlam taşıyor. WooCommerce 11.0, 28 Temmuz’da geliyor ve ürün nesnesi önbelleklemesi ile Action Scheduler 4.0.0 çıkışı, WordPress çekirdeğinin sıcak kod yolunu etkileyecek. Bu değişikliğe log’da on dört çözülmemiş regresyon barındıran 7.0.0 üzerinde girmek yerine 7.0.1 üzerinde girmek, ölçülebilir biçimde daha güvenli. Kanıtlaması da ucuz: 7.0.1 bir bakım sürümü olduğundan çoğu mağaza için beş dakikalık staging geçişi yeterli.

7.1 takvimi ikinci baskı unsuru. Beta 1, 15 Temmuz’da trunk’ı sabitliyor. RC1, 5 Ağustos. Genel sürüm 19 Ağustos. Eklenti veya tema uyumluluğunu 7.1’e karşı test ediyorsan, bilinen hatalarla dolu bir 7.0.0 tabanı yerine temiz bir 7.0.1 tabanına karşı test etmek istersin. Aksi hâlde regresyonun senden mi 7.1’den mi 7.0.0’dan mı geldiğini ayırt edemezsin.

Ne yapardım (ya da yapmazdım)

Bu hafta 7.0.0 üzerinde olan her siteyi 7.0.1’e geçir. Düzgün yönetilen bir ajans için bu on beş dakikalık bir iş: staging’i çek, güncellemeyi çalıştır, site editörünü ve bir iki yönetici ekranını gez, hata log’unda PHP uyarısı ara, üretime al. Veritabanı güncellemesi yok, veri geçiş yolu yok, eklenti uyumluluk matrisi yok.

Site minör sürümleri otomatik güncelliyorsa (varsayılan böyle) iş zaten tamamdır — 7.0.1 arka planda otomatik güncellemeyi destekliyor ve mağazaların çoğu 9 Temmuz’dan sonraki yirmi dört saat içinde sürümü çekmiştir. Araçlar → Site Sağlığı → Bilgi → WordPress altından doğrula ve yoluna devam et. Gerçekten müdahale etmesi gerekenler, otomatik güncellemeyi bilinçli olarak kapatmış olanlar ve bu siteler tam olarak ciddi bir staging geçişi yapılması gereken sitelerdir.

Yapmayacağım şey ise 7.0.1’i atlayıp 15 Temmuz’da Beta 1 gelince doğrudan 7.1’e sıçramak. Beta üretim değildir. Her sürüm döngüsünde birkaç ekibin bakım sürümünü “nasılsa bir sonraki majörü bekleriz” diye atladığını görüyorum — ve her döngüde en az biri, Temmuz’da 7.0.1’de yakalayabileceği bir regresyonu üretime yolluyor. Bedavaya gelen kolaylığı reddetme.

Aynı şekilde 7.1 Beta 1’i hiçbir üretim WooCommerce mağazasında çalıştırmam. WooCommerce 11.0, 7.1 genel sürümünden üç hafta önce, 28 Temmuz’da geliyor ve sorumlu sıralama şu: bugün 7.0.1, 28 Temmuz’da (kendi staging geçişinden sonra) WooCommerce 11.0, 19 Ağustos veya sonrasında saha rehberi yayımlandıktan sonra WordPress 7.1. Adım atlamak, adımların tasarruf ettirdiğinden fazlasına mal olur.

Bakım sürümünü atlamanın gerçek maliyeti

Bir noktayı biraz açmak istiyorum, çünkü “sadece bakım sürümü, sonra hallederim” cümlesini yıllardır aynı sonla biterken izliyorum. Bir bakım sürümünü atladığında hemen bir şey patlamaz; risk gecikmeli gelir. Aradan iki ay geçer, majör sürüm çıkar, bir eklenti güncellenir, ve tam o hafta bir regresyon üretimde başını kaldırır. O an tek bir şeyi ayıklaman gerekir; oysa elinde üst üste binmiş üç değişken vardır: atladığın bakım sürümü, yeni majör ve eklenti güncellemesi. Hangisi kırdı belli değildir, ve bu belirsizlik seni saatlerce meşgul eder.

Bunun ilacı çok sıkıcı ve tam da bu yüzden işe yarıyor: değişkenleri asla üst üste bindirme. Her sürümü kendi penceresinde, kendi staging geçişinden geçirerek al, bir şey kırılırsa neyin kırdığını tek değişkenle ayıklayabil. Filo yöneten bir ajanssan bunu bir kişisel disiplin değil, yazılı bir prosedür yap — kim ne zaman hangi siteyi güncelledi, log tutulsun. Otuz yıldır aynı dersi öğreniyorum: sistemleri ayakta tutan kahramanlık anları değil, kimsenin övmediği bu sıkıcı sıralı disiplin.

7.0.1’in başlıktan daha sessiz bir sinyali var. Gutenberg eşzamanlama disiplini tutuyor. Sürüm ekibi takvim yayımlıyor ve takvime uyuyor. 7.0 döngüsü iki büyük geri çekilmeyi (RTC ve React 19) bakım kadansını bozmadan sindirdi. Bu, WordPress yönetişim katmanının tam da yapması gerekeni yapması — ve üç yıl sonra hâlâ çalışması gereken işler için WordPress’i önermeye devam etmemin sebebi.