WordPress 7.1 Eş Zamanlı Düzenleme: Topluluk Testi Başladı

🇬🇧 English: Read this in English →

Yirmi yıllık deneyimden sonra hâlâ değişmeyen bir kalıp var: ekiplerin çalışma biçimini gerçekten değiştiren özellikler, sevkiyatı en zor olanlardır. WordPress’te eş zamanlı düzenleme tam ders kitabı örneği. 7.0 için hazır görünüyordu. Sürümden on iki gün önce geri çekildi. Şimdi 7.1 için yeniden masada — ve proje, sessiz bir beta yerine bence çok daha sağlıklı bir şey yapıyor: gerçek ekipleri, gerçek sunucularda, özelliği bilinçli olarak kırmaya davet ediyor.

Haber odaları, ajanslar ve aynı ürün sayfasına lansman günü on bir editörün dokunduğu bir kurumsal müşteri için editöryal akışlar kurdum. “Eş zamanlı düzenleme” üretimde ne anlama gelmeli, bu konuda görüşlerim net. Çoğu zaman aynı paragrafta iki imlecin yanıp sönmesi değildir. Varlık bilgisi, öneri kipi, sayfayı yenilediğinde kaybolmayan yorumlar ve altı ay sonra uyumluluk ekibine savunabileceğin bir denetim izi anlamına gelir. Bu duyuruyu da o gözle okuyorum.

WordPress üzerinde bir ajans ya da içerik ekibi yönetiyorsan önümüzdeki on hafta önemli. İşte tam olarak ne değişti ve ben yerinde olsam ne yapardım.

Gerçekten yeni olan ne

3 Haziran 2026’da çekirdek ekibi, annezazu, amykamala ve greenshady koordinasyonunda özellik geliştiricileriyle birlikte yürütülecek özel bir WordPress 7.1 eş zamanlı düzenleme topluluk testi programını duyurdu. Program, Make WordPress Slack’inde yeni açılan #collaborative-editing-outreach kanalında yürüyor ve 18 Ağustos 2026’daki prova sürümüne kadar tüm 7.1 geliştirme döngüsü boyunca açık kalacak. Sonuna kadar katılan gönüllülere test ekibi rozetleri veriliyor.

Altını çizmek istediğim kısım kapsam. Bu artık geliştirici-ve-kurumsal-müşteri çevresine kapalı bir test döngüsü değil. Ekip açıkça “farklı barındırma ortamlarına yayılmış erken benimseyenleri” istiyor: sivil toplum kuruluşları, küçük işletmeler, pazarlamacılar, tasarımcılar ve haber odaları. Barındırma ekibi de aynı gün eşleşen bir çağrı yayımladı: hostlardan, müşteri ortamlarında eş zamanlı düzenleme sorunlarını yüzeye çıkarmaya yardımcı olmaları ve müşterilerin katılım için Gutenberg eklentisinin son sürümünü çalıştırabildiğinden emin olmaları isteniyor.

Bu topluluk testinin neden önemli olduğunu hatırlatmak gerek: eş zamanlı düzenleme WordPress 7.0’dan, sürümden on iki gün önce 8 Mayıs’ta çıkarıldı. Matt Mullenweg gerekçe olarak yüzey alanı, yarış koşulları, sunucu yükü, bellek verimliliği ve fuzz testlerinde tekrar eden hataları saydı. Hiçbiri manşet yapacak çöküşler değil. Hepsi tam olarak, ancak gerçek editöryal ekipler gerçek barındırma ortamlarında özelliği kullanırken ortaya çıkan, düşük frekanslı ve yeniden üretilmesi zor sorunlar. Topluluk testi bu yüzden böyle kurgulanmış.

Takvim: 7.1 gönüllü çağrısında belirtilen plana göre Beta 1 15 Temmuz, Yayın Adayı 1 5 Ağustos, prova 18 Ağustos ve önerilen son sürüm tarihi 19 Ağustos 2026. Eş zamanlı düzenleme döngü boyunca çekirdeğe gömülmek yerine Gutenberg eklentisi üzerinden dağıtılıyor — ki bu doğru karar. Ekibin tüm sürümü tek bir özelliğe rehin vermeden iterasyon yapmasını sağlıyor.

İşin özü de 7.0 geri çekildiğinden bu yana yerinde durmamış. Gutenberg 23.3 sürüm notları, 7.0’da gemiye binen blok düzeyindeki not sisteminin (yani yorum altyapısının) artık eş zamanlı editörler arasında sayfa yenilemeye gerek kalmadan senkronize olduğunu ve önceki sürümlerin başına bela olan zincirleme bellek hatalarına karşı hata kurtarmanın sağlamlaştırıldığını doğruluyor. Borular açık şekilde iyileşiyor.

Bu filmi çok kullanıcılı oyunlarda gördüm

Şu “yarış koşulları, sunucu yükü, bellek verimliliği” listesine bakınca içimden bir gülümseme geçti, çünkü ben bu problemi kod tabanının başka bir çağında yaşadım. Multimedya döneminde çok kullanıcılı oyunlar kurdum — aynı sanal ortamda birden fazla insanın aynı anda hareket ettiği, aynı nesneye aynı anda dokunduğu türden. Ve orada öğrendiğim ilk acı gerçek şuydu: iki kullanıcı aynı anda aynı şeye uzandığında, “kim kazanır” sorusunun cevabını sunucu vermek zorunda. İstemciye bırakırsan ikisi de kendini haklı sanır, durum ikiye ayrılır ve ortaya kimsenin çözemediği bir hayalet nesne çıkar.

Yarış koşulu dediğin şey tam olarak buydu: iki olay milisaniye farkla geldiğinde sıralamanın sonucu değiştirmesi. O zaman elimizde ne fuzz testi vardı ne de düzgün bir profil aracı; hataları oyunu saatlerce oynatıp durumun ne zaman bozulduğunu izleyerek yakalardık — bugün WordPress’in “gerçek ekipleri gerçek sunuculara koyalım” demesinin ilkel atası. Çünkü bu sınıf hata laboratuvarda çıkmaz. Ancak yeterince kullanıcı, yeterince gerçek bir yükle aynı anda aynı yere bastığında ortaya çıkar. WordPress 7.0’ı geri çektiren sorunların üretimden önce staging’de görünmemesinin nedeni de bu. Yirmi yıl önce oyunlarda öğrendiğim ders, bugün blok editöründe birebir aynı: eş zamanlılık, gerçek eş zamanlı yükle test edilmeden kanıtlanmış sayılmaz.

WordPress ve WooCommerce dünyası için neden önemli

Kendin dışında biri için WordPress sitesi yönetiyorsan, bu, editöryal maliyet yapını en doğrudan etkileyen özellik. Çok-editörlü akışlar için bugünün sanatı bir yığın: gönderi kilitleme, üçüncü taraf yorum eklentisi, özel bir revizyon karşılaştırma aracı ve kimin neyi düzenleyeceğini koordine eden bir Slack akışı. Bu yığın çalışıyor. Ama insan dikkati cinsinden pahalı. İki editör 4.000 kelimelik bir ürün sayfasında çarpıştığında, biri emeğini kaybediyor, diğeri özür e-postasını yazıyor.

Yerel eş zamanlı düzenleme hesabı değiştiriyor. Hedef Google Docs olduğu için değil — değil — ama içerik canlıya çıktıktan sonra önemli olan şeylerde WordPress zaten kazanıyor: yönlendirmeler, slug geçmişi, revizyon saklama, rol granülaritesi, eklenti ekosistemi, yönetişim. Bu yığının üstüne eş zamanlı yazımı eklemek, büyük editöryal ekiplerin içeriği hâlâ başka bir yerde taslaklayıp WordPress’e yapıştırmasının son meşru gerekçesini ortadan kaldırıyor. Ölçekte içerik operasyonu yöneten herkes için anlamlı bir kazanç.

WooCommerce mağazaları için resim daha dar ama gerçek. Ürün sayfaları, kategori açıklamaları, açılış sayfaları, kampanya içerikleri — bir metin yazarı ile bir merchandiser’ın aynı kaydı aynı saatte düzenlemesi gereken her şey. Bugün bu akış elektronik tablolarda ya da kimsenin sevmediği ayrı bir içerik yönetim sisteminde yaşıyor. 7.1 eş zamanlı düzenlemenin yeterince kararlı bir sürümünü getirebilirse, bu iş SEO’nun, analitiğin ve yönlendirmelerin zaten yaşadığı WordPress’in içine geri dönebilir.

Hostlar ve ajanslar için mesaj daha açık: proje senden katılımı açıkça istiyor. Eş zamanlı düzenleme, motorun altında uzun süreli bağlantı, sunucu tarafı durum ve ani trafik desenleri demek. 7.0’ı geri çektiren sorunlar — yarış koşulları, yük altında bellek verimliliği — tam olarak bir paylaşımlı barındırma müşterisinin, herhangi bir staging ortamından önce yüzeye çıkaracağı türden sorunlar. Birkaç müşteri sitesini teste vermek ucuz. Aynı arıza modunu üretimde, lansmandan sonra keşfetmek değil.

Yerinde olsam ne yapardım (ve ne yapmazdım)

Öncelik sırasıyla üç şey.

Bir, ekibi üç kişiden büyük herhangi bir müşteri için WordPress’te editöryal akış yönetiyorsan, bu hafta #collaborative-editing-outreach Slack kanalına katıl ve bir staging sitesinde Gutenberg eklentisinin son sürümünü kurup Ayarlar > Yazma‘dan eş zamanlı düzenlemeyi aç. Her hatayı bulmak zorunda değilsin. Editörlerinin Google Docs’u kullandığı şekilde kullan ve neyin kırıldığını raporla. Tüm beklenti bu.

İki, üretimde henüz açma. Gutenberg 23.3’teki sağlamlaştırmalara rağmen bu, 7.1 gerçekten yayınlanana ve muhtemelen ilk bir-iki yama sürümüne kadar özellik eklentisi bölgesidir. Doğru kalıp: üretimle aynı barındırma planı, aynı ön bellek katmanı ve aynı editör ekibiyle çalışan bir staging ortamı. Pazarlama metnini değil, akışı test et.

Üç, mevcut çok-editörlü yığınından göçü şimdiden planla. Yerel eş zamanlı düzenleme temiz şekilde inerse hangi üçüncü taraf araçları emekliye ayıracağını denetle: gönderi kilitleme eklentisi, harici yorum aracı, çoğaltılmış Docs-taslağı akışı. Bazıları yerini koruyacak — uyumluluk denetimine bağlı yorumlar farklı bir hayvan. Çoğu korumayacak. Hangisinin hangisi olduğunu 7.1 yayınlanmadan bilmek, Eylül’de bir çeyrek aceleci entegrasyon işinden kurtarır.

Yapmayacağım şey: 7.0 geri çektiği için eş zamanlı düzenlemeyi silmem. Geri çekme gerekçeleri dürüst, teknik ve görünürdü. Olgun projelerin canlı altyapıya dokunan özellikleri sevk etme biçimi tam olarak budur. Önümüzdeki sekiz hafta bunun iyi inip inmeyeceğine karar verecek — ve kapalı bir betadan farklı olarak, proje, özelliği desteklemek zorunda kalacak insanları açıkça bu kararın parçası olmaya çağırıyor. Daveti kabul et.