5 puan yazan GN⁺ 2023-07-15 | 1 yorum | WhatsApp'ta paylaş
  • 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

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
  • 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-playground yeteneğ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

 
GN⁺ 2023-07-15
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.

    • WordPress performansının düşük ve yüksek donanımda pek değişmediğini hep hissetmişimdir. Sonuçta darboğaz WordPress’in kendisi gibi görünüyor.
  • 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.

  • “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.

    • Grup gibi küçük bir yardımcı site yaparken buna tamamen katılıyorum. Ucuz bir hosting’e kabaca koyup Google Calendar entegrasyonu bozulmadan grubun dağılmasını ummak yeterli.
      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.
    • WordPress, yukarıda söz edilen birinci grup için harika. Onu Excel, FileMaker, Visual Basic gibi yazılımı demokratikleştiren ve herkes için erişilebilir kılan araçlara benzer görüyorum.
      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.
    • Kendimi ciddi bir yazılım mühendisi olarak görüyorum ama şirket web sitesi için WordPress kullanıyorum.
    • Mesele “kusursuz biçimlendirilmiş ve aşırı ölçeklenebilir kod”a kaçmak değil; belki de mevcut kusurlu kod tabanı üzerinde çalışmayı bırakıp kusursuz olacak yeni bir projeye başlamak.
    • Bu ayrım daha çok yeni nesil full-stack JavaScript geliştiricileri ile PHP + MySQL üzerinden öğrenenler arasındaki farka benziyor.
  • 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ç.

    • Şimdiye kadar “sunucu tarafı” uygulama olarak görülen şeyleri tarayıcı içinde çalıştırma fikri ilgimi çektiği için çok heyecan verici. Özellikle SQLite’ı gerçek bir üründe çalıştırmanın ilk örneği gibi göründüğü için daha da ilginç; daha önce sadece oyuncak demolar görmüştüm.
      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ü.
    • Sunum iyiydi. Merak edenler için Wordpress Playground 48:33’ten itibaren tanıtılıyor.
  • 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...

  • 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.

    • Bende ikinci ve üçüncü durumun, ayrıca headless CMS + özel kodun çok daha iyi olacağı bir projede müşterinin WordPress’te ısrar etmesinin birleşimi böyle oldu.
      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.

    • Buradaki en harika nokta, sunucuya gidip gelmeleri inanılmaz ölçüde azaltması. Tüm veritabanı çağrıları ve varlık istekleri istemcide gerçekleşiyor. Elbette birkaç saniyelik yükleme süresini göze almak gerekiyor.
      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

    • Her rakibin çok zorlu bir tavuk-yumurta sorununu aşması gerekiyor. WordPress’te neredeyse her şeyi yapan eklentiler var ve genelde ücretli destek de alınabildiği için ondan kaçınmak zor
      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
    • İşlevsel olarak kusursuz pek çok alternatif var, ama WordPress’in gerçek değer önerisi eklenti ekosistemi, geliştirici havuzu ve kullanıcı desteği
      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
    • WordPress’in bugün başarılı olmasının nedeni, yıllar boyunca diğer CMS’ler API’lerini sürekli kırarken WordPress’in genel olarak kararlılığını koruması ve bunun sayesinde dev bir eklenti ekosisteminin büyümesi
      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
    • Geliştiricilerin birlikte çalışmak istediği CMS ile şirketlerin kullanmak istediği CMS farklıdır. İkincisine girmek için, birincisinden uzaklaştıran çok sayıda pratik seçim yapmak gerekir
      Şirketler uzun süre hayatta kalmış şeyleri sever; bunlar da tanım gereği çoğu zaman eski kafalıdır
    • Burada: https://github.com/Qbix/Platform
  • 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-dir eklemek 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