WordPress Playground: Tarayıcıda tamamen çalışan WordPress
(developer.wordpress.org)- WordPress Playground, kurulum olmadan WordPress’i denemek ve öğrenmek için kullanılan bir çevrimiçi araçtır; bu sayfa bir ürün sitesi değil, resmi bir dokümantasyon merkezi olarak hizmet verir
- Dokümanlar Documentation, Blueprints, Developers ve API Reference olarak ayrılır; bunlar sırasıyla başlama yöntemlerini, JSON tabanlı yapılandırmayı, kod entegrasyonunu ve API referansını açıklar
- Kullanıcılar 5 dakika içinde yeni bir WordPress sitesi ayağa kaldırabilir, blokları, temaları ve eklentileri deneyebilir veya belirli WordPress/PHP sürümlerini test edebilir
- Geliştiriciler, amaca göre Query API, Blueprints API, JavaScript API arasından uygun yaklaşımı seçebilir ve Playground’u sıfır kurulumlu bir yerel geliştirme ortamı olarak kullanabilir
- Tarayıcı sandbox’ı içinde çalıştığı ve backend ile kimlik doğrulama bağımlılığı az olduğu için hızlı demo, prototip ve yapay zeka üretimli deney ortamları için uygundur
WordPress Playground dokümantasyon merkezi
- Resmi Playground web sitesi wordpress.org/playground/ adresine taşındı ve bu sayfa bir dokümantasyon giriş noktası olarak kullanılıyor
- WordPress Playground, WordPress’i denemek ve öğrenmek için bir çevrimiçi araçtır
- Dokümantasyon dört merkezden oluşur
- Documentation: WordPress Playground tanıtımı, başlangıç kılavuzu ve dokümantasyona giriş noktası
- Blueprints: Playground örneğini yapılandıran JSON dosyası dokümantasyonu
- Developers: Kod içinden Playground’un nasıl kullanılacağı
- API Reference: WordPress Playground’un sunduğu API’lerin tam referansı
Başlangıç ve geliştirme akışı
- İlk kez kullananlar, Quick Start Guide üzerinden yeni bir WordPress sitesi oluşturma, blok, tema ve eklenti test etme ya da belirli WordPress/PHP sürümlerini deneme işlemlerine hızlıca başlayabilir
- Playground web instance, https://playground.wordpress.net/ adresinde sunulan Playground örneğini ele alır
- About Playground sayfasında Playground’un güvenliği, kullanım biçimleri ve mevcut kısıtlamaları görülebilir
- Build, Test, Launch belgeleri üzerinden ürün geliştirme, doğrulama ve yayına alma süreçlerinde Playground’un nasıl kullanılabileceği incelenebilir
- Guides, adım adım anlatımları ve kullanım yöntemlerini bir araya getirir; Links and resources ise ilgili kaynakların derlemesidir
İlk adımlar ve API seçimi
- İlk adım olarak Start using WordPress Playground ile 5 dakika içinde başlanabilir ve demo site incelenebilir
- Geliştiriciler Get started for developing ile ilk uygulamalarını geliştirmeye başlayabilir
- Playground, sıfır kurulumlu bir local development environment olarak da kullanılabilir
- Güncel limitations ayrı bir dokümanda görülebilir
- Daha derine inmek için önce Playground APIs ve temel kavramlara bakılması önerilir
- Query API: Yalnızca sorgu parametreleriyle temel işlemleri gerçekleştirir
- Blueprints API: Basit bir JSON dosyası ile yüksek seviyede kontrol sağlar
- JavaScript API: npm paketindeki JavaScript istemcisiyle tam kontrol sunar
- Çalışma biçimi daha derinlemesine architecture dokümanında görülebilir
Katkı ve yapay zeka kullanımı
- WordPress Playground açık kaynaklı bir projedir; kod, tasarım, dokümantasyon ve triyaj katkılarını kabul eder
- Katkıda bulunmak isteyenler Contributors Handbook sayfasına başvurabilir
- Slack’teki
#playgroundkanalına katılınabilir; kayıt bilgileri WordPress Slack page üzerinde yer alır - Tüm katkıda bulunanlar Code of Conduct kurallarına uymalıdır
- Playground, yapay zeka kodlama ajanları ve yapay zeka tabanlı araçlarla birlikte kullanılmak üzere tasarlanmıştır
- WebAssembly üzerinde tamamen istemci tarafında çalışır, kimlik doğrulama ve backend gerektirmez, ayrıca tarayıcı sandbox’ının dışında kalıcı yan etkiler bırakmaz
- Using Playground with AI agents: Claude Code, Cursor, Gemini CLI, GitHub Copilot gibi araçlarda
wp-playgroundyeteneği kurularak komutların çalıştırılması sağlanabilir - AI-readable site index: Playground özellikleri, API’ler ve dokümantasyonun makine tarafından okunabilir
llms.txtözeti - AGENTS.md: Bu kod tabanına katkı sunan yapay zeka kodlama ajanları için yönergeler
- WordPress Playground, GNU General Public License version 2 veya daha sonraki sürüm koşullarıyla sunulan bir özgür yazılımdır; tam lisans metni LICENSE.md dosyasında yer alır
1 yorum
Hacker News yorumları
Düşük fiyatlı bir Android tablette Firefox’ta denedim; tepkiler anında değil ama makul bir bulut instance’ında ya da VPS’te tam LAMP stack çalıştırmaktan çok da farklı değil, bu yüzden epey şaşırtıcı.
Bunun içinde PHP yorumlayıcısının tamamı, WordPress kod tabanının binlerce satırı ve üstüne SQLite var. Buna rağmen yeterince kullanılabilir olması etkileyici.
Bunu çalışır hâle getirme biçimleri çok modern: PHP bir WebAssembly binary olarak çalışıyor, MySQL bir WordPress eklentisiyle SQLite ile değiştiriliyor ve web sunucusu JavaScript Service Worker olarak uygulanıyor.
WebAssembly PHP: https://wordpress.github.io/wordpress-playground/architectur...
Service Workers: https://wordpress.github.io/wordpress-playground/architectur...
“Playground; mobil cihazlar için not uygulamalarını, otomatik test ortamlarını ve sitelerde çalışan WooCommerce demolarını destekler” ifadesindeki son ikisini tamamen anlıyorum ama tarayıcı içinde WebAssembly ile PHP çalıştıran WordPress tabanlı bir mobil uygulama yapma fikri insanın başını döndürüyor.
WordPress, HN kitlesini belirgin biçimde ikiye ayırıyor. Bir taraf WordPress’i, geliştirici olmayanların kodlamayı düşünmeden asıl işlerine odaklanmasını sağlayan bir değer artırma aracı olarak görüyor; diğer taraf ise dağınık kod tabanından nefret edip gerçekte neredeyse kimsenin kullanmayacağı kusursuz biçimlendirilmiş, aşırı ölçeklenebilir koda takılıp kalıyor.
WordPress web’in yarısından fazlasını çalıştırıyor. En iyi teknoloji olmayabilir, hatta en kötü teknoloji de olabilir; ama birçok programcının sürekli kaçırdığı ders şu: sosisin nasıl yapıldığını kimse umursamaz.
Ama eski ve berbat bir WordPress sitesindeki üçüncü taraf SSO’yu yeni ve berbat bir WordPress sitesine taşıma işini ertelediğim için biraz içimi dökecek olursam, birinci grubun sosisin nasıl yapıldığını umursamasına gerek kalmasın diye bakım yapan üçüncü bir grup gerçekten var.
Yaklaşık 14 yıldır bu işleri yapıyorum; orta ölçekli bir üniversitenin yaklaşık 300 WordPress sitesini barındırdım, .gov siteleri de yaptım ve bakımını üstlendim, Gutenberg ekibinin yönü yüzünden birbirinden epey farklı 3 kalıp boyunca React tabanlı birkaç blok da geliştirdim. Sunucu dağıtımından IE6 için CSS düzeltmeye, var olmayan bir CMS’i kazıyıp binlerce sayfayı ve on binlerce görseli WordPress’e taşımaya, WP-CLI komutları yazmaya, multisite üzerinde takvim etkinliklerini zorla yaymaya çalışan koda kadar her şeyi yaptım.
Birilerinin sosisin nasıl yapıldığını bilmesi gerekiyor ve ben biliyorum. Bu yüzden WordPress’in ne kadar pamuk ipliğine bağlı bir çöp yığını olduğunu da biliyorum. Daha iyi araçlara ve anlaşılabilir veritabanlarına sahip, gerçekten kullanışlı kod tabanlarıyla da çalıştım; başka platformların da sorunları olduğunu biliyorum ama WordPress gerçekten kötü.
Bu yüzden ona sövmekten çekinmiyorum. Tamamen tükendim; işi bırakıp bir kamyonda yaşayıp müzik yapsam mı diye düşünecek hâldeyim. Berbat bir platform ve onu çalışır durumda tutmak için insanlar doğru düzgün para da ödemiyor. Sonunda koşullar yüzünden sürekli yanan bir bina gibi WordPress’e geri dönen insanlar var ve bu platforma yönelik kolektif nefretin gayet sağlam gerekçeleri var.
Elbette bu araçların sınırları ve kalite sorunları var; bazı kullanıcılar eninde sonunda bunlarla yüzleşiyor. Bunun kendisi sorun değil. Sorun, uzmanlardan bunun üstüne entegrasyon yapmalarının ya da bir şeyler inşa etmelerinin beklenmesiyle başlıyor. Web geliştiricisine gelen kişiler kalite beklentileri, kendilerine özgü sorunlar ve gereksinimlerle geliyor; WordPress mirası ise bu hedeflerin önüne o kadar çok tuzak ve engel koyuyor ki çoğu zaman kare çiviyi yuvarlak deliğe sokmaya dönüşüyor. Yaygın CRM ya da e-ticaret platformları için de benzer şeyler söylenebilir.
Aralık 2022’deki State of the Word keynote’unda bunu epey geniş şekilde ele almayı düşünmüştük: https://wordpress.tv/2023/01/04/matt-mullenweg-state-of-the-...
Bir mühendis olarak gerçekten çalıştığını görmek ve bunun için etkileşime girmesi gereken tüm katmanları düşünmek epey sarsıcıydı. 6 ay sonra HN’de gündem olduğunu görmek ilginç.
Koda biraz bakınca şu anda PHP’yi neredeyse hiç bilmediğimi de fark ettim ve bunun kalıcılık için “geleneksel” SQLite-over-OPFS yaklaşımını kullanmadığı anlaşılıyor. Biraz daha okuyunca Emscripten üzerinden kalıcı depolamanın hâlâ mümkün olup olmadığı bile belirsiz görünüyor. Sonunda https://github.com/WordPress/wordpress-playground/issues/19 bağlantısını buldum; bu da tarayıcı içindeki WordPress’te henüz kalıcılığın mümkün olmadığı anlamına geliyor gibi, üzücü.
Tamamen meraktan soruyorum: Veritabanını şimdilik bir kenara bırakırsak, bu WordPress’i Cloudflare Worker olarak çalıştırabileceğimiz anlamına mı geliyor? https://developers.cloudflare.com/workers/runtime-apis/webas...
Yine de bunu mümkün kılmak için hâlâ alan var gibi görünüyor; Cloudflare da sınırı artırabilir.
Yani çalışır hâle getirilebilir gibi.
Neredeyse statik olan birçok sitede WordPress’i sık kullanıyorum. Teknik olmayan kişilerin sürekli içerik eklemesine izin vermek için iyi; bu amaç için WordPress’e yakın bir alternatif yok.
Ancak kullanılan eklentileri dikkatle seçmek, uygun bir Cloudflare ön yüzü ayarlamak ve kullanıcıların dışarıdan basit görünen ama riskli şeyler yapmasını engellemek gerekiyor. WordPress nefretinin önemli bir kısmı, çok uzun zaman önce kullanmış olmaktan, WordPress’in karşılayamadığı gereksinimlere sahip olmaktan ya da miras olarak devralınmış durumlarda kalmaktan geliyor gibi.
Aslında WordPress’in suçu değil ama adını duyar duymaz hafif bir korkuyla irkilmemi değiştirmiyor.
PHP’yi WASM üzerinde çalıştıran bu Playground, genel web sitelerinin %95’inden çok daha hızlı tepki veriyor.
WordPress muhtemelen en yaygın kullanılan çok sayfalı uygulama çözümü; bu ise onu fiilen tek sayfalı bir uygulamaya dönüştürüyor. Üstelik sunucuya sürekli API isteği göndermesi gerekmediği için çoğu tek sayfalı uygulamadan da daha iyi performans gösteriyor.
Yazı/sayfa düzenleyici ve site düzenleyici gibi tek sayfalı uygulama bölümleri karmaşık React uygulamaları; bu demoda yerel geliştirme ortamından daha çevik hissettiriyor. Sunucuya gidip gelmeyi ortadan kaldırınca tek sayfalı uygulamaların ne kadar iyi olabileceğini güzel gösteriyor. Not: Automattic’te çalışıyorum ve bu deneyi izlemek gerçekten harikaydı.
WordPress’ü küçümsemeye gerek yok, ama geçmişi uzun ve sorunları da çok. Statik site üretimi ya da karmaşık barındırma olmadan kullanılabilecek modern, kendi kendine barındırılan bir alternatif olsa iyi olurdu
Kod tabanı iyi değil, üzerinde geliştirme yapmak eziyetli; tasarım yaklaşımı ve resmi mağazanın yönetimi de veritabanı tarafındaki karmaşayı ve riskleri engellemiyor. Yine de iki gün kurulum yapıp eklenti/tema için ayda 80 dolar harcama önerisini satmak, “Olur, önce en az iki ay geliştirme süresine ihtiyacımız var” demekten çok daha kolay.
Geliştirme işi gerekse bile WordPress geliştirme deneyimi olan birini bulmak kolay; doğrudan işe almak istemezseniz WordPress uzmanı ajanslar da bol. Yeni yükselen rakiplerin böyle bir ölçek avantajı yok. Eklenti ve tema yapısına sahip, genişletilebilir bir sistemi WordPress’ten çok daha iyi tasarlamak küçük bir iş değil, ama imkânsız da değil; dâhi bir ekip de gerektirmiyor. Ancak gerçek pazarda WordPress’i yerinden etme yolunda bu en kolay aşama
Sadece WordPress isteyen, başka hiçbir şeyi istemeyen müşterilerle herkes karşılaşmıştır. Temiz, yeni bir çözüm dağıtsanız bile müşterinin tekrar WordPress’e döndüğü çok olur. Karmaşık gereksinimleri başka bir framework ile yapılmış özel bir uygulamanın karşıladığı, içeriğin ise bir WordPress instance’ı ve connector’lar ile yönetildiği hibrit yaklaşımda değer gördüm
Ayrıca WordPress PHP API’si nesne yönelimi neredeyse hiç kullanmaz; çoğunlukla fonksiyonlar ve dizilerden oluşur. Bu yüzden çok temel programlama bilen kişiler bile kendi eklentilerini veya temalarını yapabildi
Şirketler uzun süre hayatta kalmış şeyleri sever; bunlar da tanım gereği çoğu zaman eski kafalıdır
Bu demonun arkasındaki teknoloji gerçekten harika. Gerçek zamanlı PHP hata/uyarı günlüklerini görebilmek isterdim; özellikle SQLite veritabanı yeniden yazımı da dahil olmak üzere bu simülatörün ne kadar eksiksiz olduğunu görmek istiyorum
Eklenti veya tema testi de çok kolay. Sadece
&plugin=plugin-slug-from-direklemek yeterli; slug WordPress.org URL’sindeki eklenti slug’ı ile eşleşirse otomatik olarak indirilip sandbox’a ekleniyor. Sandbox’ı yapılandıran tüm sorgu API’si dokümantasyonu burada: https://wordpress.github.io/wordpress-playground/query-api/Debug log’unu açmanın veya göstermenin mutlaka bir yolu olduğundan eminim. Öyle bir şey olmasaydı bunu geliştiremezlerdi