Buna Basın: WPGraphQL ve Faust.js

WMR'den WordPress topluluğu podcast'i Press This'e hoş geldiniz. Her bölümde, topluluktan konuklar ve WordPress geliştiricilerinin karşılaştığı en büyük sorunların tartışmaları yer alır. Aşağıda, orijinal kaydın bir transkripsiyonu bulunmaktadır.

RedCircle tarafından desteklenmektedir

Doc Pop : WMR'de bir WordPress Topluluğu Podcast'i olan Press This'i dinliyorsunuz. Her hafta WordPress topluluğunun üyelerini ön plana çıkarıyoruz. Ben sunucunuzum, Doc Pop. WordPress topluluğunu WP Engine'deki rolüm ve podcast'ler yaptığım, karikatürler ve eğitim videoları çizdiğim TorqueMag.Io'daki katkılarım aracılığıyla destekliyorum. Kontrol et.

Red Circle, iTunes, Spotify'da Press This'e abone olabilir veya bölümleri doğrudan wmr.fm'den indirebilirsiniz.

Press This'in bu bölümünde Headless WordPress, GraphQL ve Faust.js hakkında konuşuyoruz. Bu araçlar birlikte nasıl kullanılabilir ve Başsız WordPress ile ne tür bir maliyet ilişkilendirilebilir. Bu konuyu derinlemesine incelemeye çalışacağız ve bugün bana katılan iki harika konuğum var, Denver, Colorado'da bulunan WP Engine'de baş yazılım mühendisi olan ve WPGraphQL'yi sürdürdüğü Jason Bahl var. . Ve Faust.js üzerinde çalışan bir mühendislik yöneticisi olan Chris Weigman'a sahibiz. Genelde bu gösterileri misafirlere WordPress köken hikayelerini sorarak başlatmak isterim, ancak burada işleri biraz değiştireyim dedim.

Jason, bize WPgraphQL'nin ne olduğunu ve wordPress Origin hikayesini anlatır mısın?

Jason Bahl: Ah evet, WPGraphQL, WordPress sitenize bir GraphQL API getiren ücretsiz bir açık kaynaklı WordPress eklentisidir ve GraphQL, grafik sorgulama dilidir. Böylece, geliştiricilerin grafik sorgulama dilini kullanarak WordPress'e girip içerik almalarına olanak tanır.

Ve eklenti ortaya çıktı, birkaç yıl önce bir gazetede çalışıyordum ve çok fazla içerik sendikasyonu yapıyorduk. ABD genelinde 54 site gibi bir ağımız vardı ve içeriği bir taraftan diğerine taşımamız gerekiyordu. Biliyorsunuz bir haber yayınlandığında farklı gazeteler diğer gazetelerin içeriklerine abone olabiliyordu.

Ve bu nedenle, çeşitli olaylar meydana geldiğinde, verileri bu ağ etrafında taşımamız gerekiyordu ve bu veri hareketinin çoğunu yapmak için WordPress REST API'sini kullanıyorduk. Ve teknik olarak bununla ilgili bazı sorunlar yaşıyorduk ve teknik olarak gerçek performans gibi, ama aynı zamanda geliştirici deneyimi. 2015'te Facebook tarafından açık kaynaklı olan gerçek grafik sorgulama dili GraphQL'yi öğrendim.

Böylece bu teknolojiyi buldum, biraz prototipleme yaptım, meslektaşlarıma sundum ve ardından iletişim sendikasyonumuzu REST'ten GraphQL'e taşıdık. Ve sonra JavaScript çerçevelerinin popüler hale geldiğini ve sunucudan sunucuya iletişimin birincil kullanım durumu olmadığı gibi GraphQL kullanmanın muhtemelen birincil kullanım durumu olacağını bilerek bir topluluk projesi olarak proje üzerinde çalışmaya devam ettim. İhtiyaçlarımızı çözdü, ancak onun için daha büyük bir vizyon gördüm, bu yüzden topluluk için açık kaynaklı bir proje olarak üzerinde çalışmaya devam ettim.

DP: Pekala, harika. Chris, bize Faust'un ne olduğu ve nasıl ortaya çıktığı hakkında benzer bir hikaye anlatabilir misin?

Chris Weigman: Elbette Faust, bu hafta itibariyle resmi olarak halka sunuldu, GraphQL kullanarak Başsız WordPress siteleri oluşturmak için halka açık çerçeveye yeniden yayınlandı. İyi geliştirme 2020'de başladı ve bu, WP Engine'in resmi olmayan bir projesiydi ve bu üçüncü büyük pivot.

Bunu DevRel'in bir uzantısı olarak başlatmışlardı, biraz daha resmi hale getirmeye başladılar ve GQty ve tamamen JavaScript, geliştirici önceliği zihniyeti denen bir şeye dönüştüler. Ve geçen yıl 1 Aralık'ta takımın başına geçtiğimde bunun hedef pazarımız olmadığını anladık.

WordPress geliştiricileri için geliştirmeliydik. Bu yüzden onu yeniden inşa etmeye başladık ve bu nihayet yakın zamanda yeniden piyasaya sürülebildi.

DP: Jason, yakın zamanda Faust.js'de yeni wpgraphql.com'u başlattığınızı tweet'lediniz. Önceki site, sanırım başsız WordPress'ti. Bize yaptığınız bu değişiklikten bahseder misiniz ve bilirsiniz, hangi iyileştirmelerden bahsediyorsunuz?

JB: Evet. Yani wpgraphql.com, yıllardır başıboş bir site. Bu yüzden birden fazla veri kaynağı kullanıyorum. Blog yazılarının tümü WordPress'te olduğu gibi, WordPress'te çok fazla içeriğim var.

Belgelerin bir kısmı WordPress'te de mevcuttur. Ve sonra GitHub deposundaki işaretleme dosyalarında bazı belgeler bulunur. Gatsby'yi en uzun süre, belki de üç yıldır kullanıyordum, özünde birden fazla kaynaktan veri çekebileceğiniz veri katmanına sahip bir JavaScript çerçevesi olan Gatsby'yi kullanıyordum.

Ben de bunu kullanıyordum, GitHub'dan veri çekiyor, WPGraphQL kullanarak WordPress'ten veri çekiyor ve bu verileri şablonlarımı oluşturmak için kullanmama izin veriyordu. Bu yüzden birkaç yıl boyunca bunu kullanıyordum. Veri katmanıyla ilgili bir şekilde kurtulmak istediğim pek çok acı noktası var.

Bu yüzden, Faust'un üzerine inşa edildiği Next'i kullanmak istedim. Bu başka bir JavaScript çerçevesi, ama sanırım pek çok eksik parça vardı. Sırada, bu JavaScript çerçevelerinin çoğu, ön uç çerçevelerinizin tüm yönlendirmeyi tanımlaması gerektiği fikrine sahip, değil mi? Ancak bir CMS kullanıyorsanız yönlendirmeyi CMS'niz tanımlar.

Ve böylece, ön ucunuzun bir şey hakkında bir görüşü olduğu ve arka ucunuzun farklı bir görüşü olduğu gibi, bu şeyleri iyi oynamanın birçok teknik sorunu var. Yani, çözmeye çalıştığım sorunlardan biri gibi, ön ucumun belirli bir URL'nin belirli bir şey olduğunu fark etmesini sağlamak ve ardından o şeyi temsil eden bir şablon oluşturmaktı.

Bir blog gönderisinin bir dokümandan veya kullanıcı arşivinden veya her neyse farklı bir şablonu olması gibi. Bu yüzden, ön ucumun CMS'ye bir URL gönderme, verileri geri alma, ancak hangi şablonun döndürüleceğini anlama yeteneğine sahip olmasını istedim. WordPress'te buna şablon hiyerarşisi denir. Ve Faust ekibi bu sorunu çözmeyi başardığında, ben de, evet, Faust'a geçiyorum dedim.

Yani, evet, PHP teması gibi temel WordPress'te var olan bazı kavramları alıp başsız olarak kullanabiliyorum, böylece React'in faydalarını ve ön uçta kullanmak istediğim JavaScript'i şablon olarak kullanabilirim. site, ancak yine de WordPress dünyasından tanıdık kavramlar.

DP: Chris, Faust'un bazı değişikliklere uğradığından bahsediyordun. Neydi o değişiklikler? Biliyorsun, Jason onlardan bahsediyordu. Bu gelişmeyi mümkün kılan değişikliklerden bazıları nelerdi?

CW: Her zaman WPGraphQL'ye odaklanır. Asıl sorun olan diğer her şeydi. Örneğin, Faust'un son ana sürümü, kağıt üzerinde kulağa gerçekten harika gelen GQty adlı GraphQL ile etkileşim kurmak için altında bir kitaplık kullandı. O zamanki Faust ekibinden gelen fikir, soyutlayalım, insanların bu karmaşık sorguları nasıl oluşturacaklarını bilmelerine gerek olmaması gerektiğidir.

Bu çerçeve sizin için bunu soyutlamalıdır. WordPress verilerinin tüm karmaşıklığı nedeniyle pratikte gerçekten iyi görünen kağıt üzerinde. Tek bir gönderi türünün bile çok fazla varyasyonu olabilir. Belki bunu kategoriyle karıştırıyorsun, belki de tüm farklı şeyler. GQty, ona güç sağlayamadı.

Üstüne üstlük, GQty sürümüyle oluşturulduğunda, Jason'ın bahsettiği yönlendirme sorununa gerçekten hiç dikkat edilmemişti. Yönlendirmeyi kim yönetir? WordPress, yönlendirmesini içeriğin ne olduğuna göre ele almak ister, bu bir içerik yönetim sistemidir, bu nedenle tüm yönlendirme ve WordPress büyük ölçüde içerik tabanlıdır.

Next.js bir ön uç çerçevesidir, bu nedenle tüm yönlendirmeler buna dayalıdır, yönlendirmenin nasıl temel aldığı konusunda tamamen farklı bir paradigmadır. /Blog on Next ne olabilir, bir blog içeriğiyle hiçbir ilgisi olmayabilir. Bir dizi şablona gidiyor. Bir blog oluşturabilen uygulamanın bir parçası olacak.

WordPress'te /Blog çok iyi bir anlama gelebilirken, bunların tümü blog gönderileridir. Ve bu paradigmayı oluştururken, WordPress'i çok sağlam bir ön uç veya kafasız yetenekli bir CMS yapmak istiyorsanız, bu yönlendirme ile uğraşmak zorunda kaldık. Bunu yaptığımızda başka bir değişiklik, GQty sürümünde söylediğim gibi, amacımız, bunun WP Engine olduğunu anlayana kadar asil görünen WordPress'i kullanmak zorunda kalan JavaScript geliştiricileriydi.

Yıllardır WordPress üzerine inşa etmiş ajanslarla uğraşıyoruz ve şimdi çeşitli nedenlerle (daha sonra ele alabileceğimiz) kafasız bir şeye doğru ilerliyorlar. WordPress geliştirmeyi nasıl yapacaklarını biliyorlar. WordPress şablon yönlendirmelerinin nasıl çalıştığını ve şablonların nasıl çalıştığını anlarlar, bunun gibi şeyler.

GraphQL'nin WordPress geliştiricileri tarafından daha kolay kullanılabilmesi için bu özellikleri öne çıkarmamız gerekiyor. Faust'un buradaki amacı da buydu. Şablon hiyerarşisi, WordPress'in yaptığını basitçe yeniden oluşturur. Şimdi, Next'in yönlendirmesini kullanmak istiyorsanız, uygulamada onu geçersiz kılmanın yolları var, böylece hiçbir şey kaybetmezsiniz.

Ancak WordPress'leri gerçek bir içerik yönetim sistemi olarak kullanan ve içeriği içerik yönetimiyle yönlendirebilen kişiler için, o zaman Faust bunu sizin için çok daha iyi halledecek mi? bu mantıklı mı?

DP : Evet. Kesinlikle. Biliyor musun, bence burası kısa bir ara vermek için iyi bir yer. Chris Weigman ve Jason Bahl'ın yer aldığı bir WordPress Community podcast'i olan Press This'i dinliyorsunuz. WordPress ve başsız hakkında konuşmak için geri döneceğiz. Bizi izlemeye devam edin.

DP: Press This ile geri döndük. Ve biliyorsun, Chris, o aradan hemen önce bir şeyden bahsettin, gittikçe daha fazla şirketin kafasızlaştığından bahsettin ve WP Engine'in durumun böyle olduğunu gösteren pek çok araştırma yaptığını biliyorum. Headless'ın kesinlikle bir şey olarak bir üne sahip olduğunu merak ediyorum, bence girişim, headless'ı düşündüğümde doğru mu düşünüyorum? Başsız olmak bu mu? Bu sadece kurumsal bir araç mı yoksa daha fazla sitenin kullanacağı bir araç mı?

CW: Evet ve hayır. Büyük ölçüde kafasız, özellikle şu anda WordPress ile, içerdiği karmaşıklık, muhtemelen ihtiyacınız olanı oluşturan tam bir ekibiniz olduğu anlamına gelir.

Bu, WordPress'i kutudan çıkar çıkmaz kullanan biri değil, sadece kişisel blogunuzu istiyorsunuz. Bunu yapabilir, ancak bunu yapabilmek için şimdiye kadar çok daha ağır bir kaldırma. Contentful ile aynı, diğer tüm CMS'lerle aynı. Basit bir şey istiyorsanız, bilirsiniz, yıllardır web'de olan içerik türü, başsız bir şey, muhtemelen şu ana kadar uğraşmak istediğinizden daha fazla iş olacaktır.

Kesinlikle kurumsal mı? Bak, hayır. Gatsby yıllardır bu sorun üzerinde çalışıyor. Daha sonra başka bir podcast'iniz var, Doc with Mastodon. Birkaç yıldır dahil olduğum bir topluluk. Bu konudaki çoğu insan, özellikle Gatsby olmak üzere başsız CMS'lerin varyasyonlarını kullanıyor, ancak Hugo var. Çok tabandan gelen her türden farklı, bu tür teknoloji var.

Böylece, tabandan gelen kullanıcılarla ve ağır siteler için kurumsal kullanıcılarla son bulursunuz, oysa WordPress geleneksel olarak aradaki herkesle birlikte düşüyor gibi görünüyor. Bir Gatsby kullanıcısının yapabileceği gibi işaretleme dosyaları ve kodlarla uğraşmak istemeyen kişidir, ya da bilirsiniz, Gatsby zaten kutudan çıkar.

Ama aynı zamanda kişisel markasını veya kişisel blogunu oluşturan 10 kişilik bir ekibe sahip biri de değil. Bu, WordPress'i ortadan kaldırır ve her iki uca da çok kolay bir şekilde genişletir. Artık GraphQL arasında kolayca derleme yapabilirsiniz, tüm verilere sahipsiniz ve bu verileri işlemek için sürekli büyüyen bir dizi yola sahipsiniz.

Ve Faust, bunu ve bir ay yerine bir günde inşa edebileceğiniz bir şeyi kullanmayı çok daha kolay hale getiriyor.

DP: Jason, Chris senin düşünceni duymak istediğim bir şeyden bahsetti, bunun benim gibi küçük ekipler, küçük blogcular için pek iyi olmadığını duydum, ki bu kesinlikle mantıklı, kafasız bir WordPress'e ihtiyacım yok ama şöyle , Sanırım merak ettiğim şey, başsız WordPress'in bana daha pahalıya mal olması mı, çünkü bir iOS cihazına ve bir WordPress cihazına sahip olmak zorunda kalacağım? Daha pahalı mı yoksa bir şekilde daha uygun maliyetli mi?

JB: Muhtemelen ne ürettiğinize bağlı, sanırım. İOS'tan bahsettiğiniz gibi yapıyorsanız, yerel bir mobil uygulama yapıyorsanız, bununla ilgili maliyetler olduğu açıktır ve WordPress'ten veri kullanıyorsanız bunu yapmanın gerçekten iyi bir yolu yoktur, diğer Başsız yapmaktansa, çünkü bilirsiniz, yerel bir uygulama php'yi işlemez, bu yüzden bunu kafasızca yapmanız gerekir.

Ancak, şu anda geleneksel WordPress'te web için oluşturuyorsanız, gidip bir tema bulabilir, ücretsiz bir tema bilirsiniz veya bir pazarda bir tema bulabilir, indirebilir, yükleyebilirsiniz ve siz de yarışlara kapalı. Çoğu insan onu bir şekilde özelleştirecek.

Bu nedenle, bunu ister kendiniz yapıyor olun, ister bir başkası yapıyor olsun, genellikle geliştirici maliyetine sahip olacaksınız. Başsız WordPress ile geleneksel PHP temasından farklı olan şeylerden biri, örneğin, yeni wpgraphql.com'u başlattığımda, Gatsby siteme güç veren aynı WordPress örneğini kullanabildim.

Verileri alıyorum, veriler dışarı çıkıyor ve Gatsby sitesine giriyordu, CMS'de içerik yayınlamaya devam ederken aynı zamanda bunun için bir sonraki önyüzümü geliştirebildim. Geleneksel WordPress geliştirmede, sitenizi genellikle bir hazırlama ortamı gibi taşımanız gerekir.

Bu ortamda yeni bir tema etkinleştirin, temanızı orada oluşturun, içerik oluşturucularınıza "Hey, bugün içerik yayınlayamazsınız çünkü taşınacağız ve sonra biz'" dediğiniz bir tür içeriğin donma dönemiyle başa çıkın. Yeni WordPress örneğini, canlı örneği ayarlayacağız." Ve sonra orada oturum açmalı ve içeriğinizi doğru yapmaya başlamalısınız.

Başsız WordPress, gerçek WordPress örneğimde hiçbir şeyi bozmadan sitemi tamamen farklı bir ön uç yığınında yeniden oluşturabildim, bu veri ve sunumun ayrılması, değil mi? Böylece, yarın bir sonraki sıcak teknolojiyi keşfetmek istersem, sanki Next yerine Svelte'ye bakabilirmişim gibi gidebilirim ve WordPress'te hiçbir şeyi değiştirmek zorunda kalmam.

Yani bazı durumlarda aslında daha ucuz olabilir çünkü başka bir sunucuyu döndürme, ekibinizin içerik yazmayı bırakmasını sağlama ve ardından farklı bir WordPress örneğine geçme ve ardından orada yayınlamaya başlama, Delta geçişleri yapma, bunun gibi şeyler, bunun da bir maliyeti var.

İlginç olan başka bir şey de, JavaScript ekosisteminin gerçekten nakliye yapıyor olmasıdır. Kanımca, başsız hareket etmenin ortak motivasyonlarından biri, bileşen tabanlı mimarilerdir. Ayrıca, React ve VUE ekosisteminde, bileşenleri projeler arasında yeniden kullanmanıza izin veren her türden bileşen kitaplığı vardır.

Ve böylece ajanslar, projelerde kullandıkları ortak bileşenleri oluşturabilir ve bunları merkezi bir yerde güncelleyebilir, ancak daha sonra birden fazla projeye kurabilirler. WordPress ile bu o kadar kolay değil çünkü PHP şablon parçalarınız ve WordPress genellikle ait oldukları projeyle çok sıkı bir şekilde birleşiyor.

Headless ile bu bileşenlere sahip bir MPM paketine sahip olabilirsiniz ve birden çok proje bu paketi güncelleyebilir ve aynı anda daha az çabayla fayda sağlayabilir. Bu yüzden şu anda, muhtemelen daha maliyetli ve daha fazla iş olduğunu söyleyebilirim, ancak yakın zamana kadar var olmayan Faust gibi araçların, başsız inşa etmek için gereken genel çabayı azalttığını düşünüyorum.

Ve bence çok da uzak olmayan bir gelecekte, başsız inşa etmek, başsız yapmaktan daha ucuz olabilir.

DP: Chris, başsız WordPress'in maliyetleri açısından hangi ajansların düşünmesi gerekebileceğine eklemek istediğin bir şey var mıydı?

CW: Bence Jason tam olarak çiviyi kafasına vurdu.

Ve bu, WPGraphQL ile ilgili sevdiğim bir şey, ekibimin WordPress'i bu yönde genişletmek için çalışması, çalışma başlığımız React Gutenberg Bridge, ancak bu WordPress'te de bir sorun. Bu bileşenleri nasıl yeniden kullanırsınız? Sadece bileşen kelimesini kullanmak istemiyorum çünkü JavaScript tarafında geçerli olduğu gibi WordPress tarafında geçerli değil, değil mi?

Ancak, başsız veya başka bir şekilde WordPress ile kodu projeler arasında nasıl yeniden kullanırız ve başsız bunu sağlar. Ancak, ortalama bir blog yazarının sadece yemek bloglarından çıkmaya çalıştığını, muhtemelen bununla kendilerinin ilgilenmediğini söylemenin güvenli olduğunu düşünüyorum. Bu daha çok bir ajans sorunu. Bu daha fazla maliyet mi?

Belki, belki değil, ama maliyet bunun neresinde diye konuştuğumuzda işler karmaşıklaşıyor. Çünkü verileri nasıl kullanmak istediğinizin farklı türleri var.

DP: Evet, kesinlikle. Biliyorsun, gazete geçmişi olan, Twin Cities'de Weeklys'de ve Nashville'de çalışan Jason, 56 gazetene bir gün boyunca yayın yapmamalarını söylemenin nasıl bir şey olacağını hayal edebiliyorum.

Bugün haber yok, çünkü siteyi güncelliyoruz.

JB: Evet. Yani o dönemlerden geçtik değil mi? Orada işe alındığımda WordPress kullanmıyorlardı ve bu yüzden işimin bir parçası onları başka bir sistemden WordPress'e geçirmekti. Bu yüzden, kesinlikle öyle günler oldu ki, pekala, WordPress gününde yayına giriyor. Yaptığın şeyi bırak. Sağ.

Yani kesinlikle böyle dönemler oldu ya da biz de o sorunla uğraşmak zorunda kaldık, tamam, dün gece gece yarısına kadar eski sistemde yayın yapıyorlardı ama bundan iki gün önce WordPress'i kullanıma hazır hale getirdik. Şimdi bir Delta geçişi gibi yapmalıyız ve tüm verilerin hala senkronize edildiğinden emin olmalıyız, böylece, bilirsiniz, bu süreçlerin kesinlikle teknik ve insani maliyeti vardır.

DP: Evet. Ve ayrıca çok şey olduğunu düşünüyorum, hala WordPress kullandığınızda, bu maliyet tasarrufunu elde edebileceğiniz o ekosisteme hala sahip oluyorsunuz. SEO araçlarını oluşturmak zorunda değilsiniz.

Yoast SEO eklentisini veya her neyse onu kullanabilirsiniz. Bir Headless sitesi olsanız bile, çoğu eklentinin öne bakmadıkları sürece çalışacağını varsayıyorum.

JB: Evet. Bu aslında ilginç bir şey. Böylece yeni Faust, bir eklenti mimarisiyle oluşturulmuştur. Kutudan çıktığı gibi, bir istemciyle gelecek, Apollo istemcisini kullanıyor, böylece WPGraphQL'den veri alabilirsiniz, WordPress verilerinizi alabilirsiniz, ancak eklentiler oluşturabilirsiniz, böylece, diyelim ki, sizin gibi yaptınız Bahsedilen, WordPress sitenize Yoast SEO yükleyin.

Bir Yoast Eklentisi ekleyebilirsiniz. Henüz yok, ama yakında olabilir. Faust için ön uçta bu verilerle ne yapacağını bilen bir Yoast eklentisi ekleyebilirsiniz, değil mi? Böylece insanlar için yetenek olacak, bazılarını biz üretebilir ve destekleyebiliriz, ancak bazılarında topluluk, şeylerin Faust tarafı için de eklentiler üretebilir ve destekleyebilir, böylece siz sadece bir kod satırıyla bu eklentiyi ekleyebilirsiniz. başsız kullanıcı arabiriminiz için Yoast gibi işlevler elde edin.

Bu, başka hiçbir başsız ön ucun gerçekten Faust'un ona yaklaştığı şekilde bir konsepte sahip olduğunu düşünmediğim bir şey. Bu yüzden eklentinin, WordPress geliştiricileri için tanıdık olan başka bir şey olduğunu düşünüyorum. WordPress'ten tanıdık kavramlar getiriyor, ancak modern JavaScript ön uç yığınıyla köprü kuruyor.

DP: burası, Press This'de son bir mola için iyi bir yer ve geri döndüğümüzde, Chris Weigman ve Jason Bahl ile görüşmemizi bitireceğiz. Bizi izlemeye devam edin.

DP: Bir WordPress Topluluğu podcast'i olan Press This'i dinliyorsunuz. Ben sunucunuzum, Doc Pop. Bugün WPGraphQL, Faust ve başsız WordPress sitenizi nasıl güçlendirebileceğiniz hakkında konuşuyoruz. Aradan hemen önce, Faust ve eklentiler hakkında konuşuyorduk ve ben size bazı rastgele sorular soracağım ve burada herhangi bir iyi yanıt olup olmadığına bakacağım.

Ama Chris, Faust ile ilgili herhangi bir potansiyel olup olmadığını merak ediyorum, bunun başsız bir platform olduğunu biliyorum, ancak en azından sizi bir şekilde kurmanızı sağlayan bir WordPress Faust teması gibi herhangi bir potansiyel var mı? işte ihtiyacınız olan eklentiler ve işte kutudan çıkan her şey.

CW: Kesinlikle. Aslında, zaten bizde var. Yerel ile çok yoğun bir şekilde çalıştığı için Blueprints olarak adlandırıyoruz. Çoğu insan, WP Engine gibi bir platformda başlatmadan önce bu şeyler üzerinde bir çeşit ince ayar yapacak. Bu yüzden Local'in Blueprints adını ödünç aldık.

Yeni Faust için, temelde tam bir portföy teması olan Portföy adında bir tane var ve ajansların kullanabileceği çok boş bir yapı iskelesi üzerinde çalışıyoruz. İşleri bir kez kavradığınızda, muhtemelen her şeyi kendiniz özelleştirmek isteyeceksiniz. Yani bir iskele en iyi proje uygulamaları olacaktır, onu döndürün ve sonra onunla kendi işlerinizi yapabilirsiniz.

Uzun vadede başsız bir tema mağazası olan Blueprints hakkında çok konuştuk. İnsan gücümüz yok, bu yüzden bu biraz uzakta, ama bu kesinlikle düşündüğümüz, düşündüğümüz ve gerçekleşmesini istediğimiz bir şey.

DP: Evet, bunu düşünmek harika. Bu, içine girilmesi gereken tamamen farklı bir ekosistem.

Ve biliyorsun, Jason, seninle daha önce röportaj yaptım ve eminim bu soru her zaman geliyor, ama ne zaman WPGraphQL hakkında bir şey duysam, bunun REST API'nin yaptığına çok benzediğini düşünüyorum. Aslında bu, REST API'nin yaptığından çok daha güçlü gibi görünüyor ve REST API çekirdeğin bir parçası ve merak ediyorum, WPGraphQL'nin WordPress Çekirdeğinin bir parçası olması gerektiğini düşünüyor musunuz?

JB: Belki bir gün. Henüz orada olduğumuzu sanmıyorum. WordPress Core'da işler birleştiğinde, muhtemelen Gutenberg hariç, yenilik durur. Örneğin, REST API'si, sanırım 2016'dan beri var olan insanlara işaret ettiğim bir hata var. Yani, işler çekirdeğe girdiğinde, web'in yüzde 40'ına ayarlanmış bir özellik ekliyorsunuz ve bu nedenle, değişiklik yapmak çok daha yavaş yapılmalıdır, burada bu bir eklentiyse, insanların dahil etmek istedikleri sürümü seçmelerine izin verebilirsiniz ve projeleri için hangi sürümün en iyi çalıştığını seçebilecekleri için çok daha hızlı yineleyebilirsiniz.

Çekirdekte, çekirdeği güncellerseniz ve bu, büyük değişiklikleri içeriyorsa, web'in yüzde 40'ını bozmuş olabilirsiniz. Yani GraphQL bir özelliktir, WordPress ile de hiçbir ilgisi yoktur.

Sağ. Ve böylece GraphQL spesifikasyonu hala gelişiyor. Ve bu gelişmeye devam ettikçe, GraphQL spesifikasyonunun en son ve en iyisine ayak uydurmak istiyoruz. Diyelim ki, bugün WPGraphQL'yi Core ile birleştirirsek ve GraphQL gelişmeye devam ederse, WordPress, dünyanın geri kalanı 2030 sürümünde veya her neyse, GraphQL'in 2022 sürümünde takılıp kalır. Bana göre, bir noktada WPCLI'nin X işini yapmanın resmi yolu gibi tanınmasının mantıklı olabileceğini düşünüyorum.

Sanki WordPress için kendi CLI istemcinizi oluşturabilirsiniz, ancak topluluk tarafından WPCLI'nin resmi bir şey olduğu kabul ediliyor. WordPress Core'un bir parçası değildir, ancak WordPress Vakfı ve WordPress topluluğunun çoğu tarafından resmi bir şey olarak kabul edilmektedir. Bu nedenle, bir noktada bir WPGraphQL'nin bu şekilde tanınması güzel olabilir, örneğin, başsız WordPress yapacaksanız, bu şekilde yapın.

Hala bir eklenti olarak kalacak. Bu benim düşüncem. GraphQL'nin mükemmel hissettirdiği ve gerçekten tekrarlanmadığı bir zaman olabilir ve belki o zaman bunu düşünürüz. Ancak şu anda GraphQL spesifikasyonuna, API'nin önemli değişikliklere sahip olmasına neden olacak şeyler geliyor.

Bu yüzden bunu bir eklenti olarak yapmak benim için hala mantıklı.

DP: Doğru. Ve evet, WPCLI'den bahsettiniz ve ben unutup duruyorum, onlar sanki çekirdeğin bir parçasıymış gibi hissediyorlar. Ne hissettiriyorsa, resmi gibi. Yani evet, sanki, oh evet, bu bağımsız bir şey gibi, tıpkı şu anda WPGraphQL gibi.

Bu iyi bir benzetme. O yüzden burada bitireceğim. İkinizle de sohbet etmek gerçekten harikaydı. Dinleyiciler ikinizden birini takip etmekle ilgileniyorsa, @JasonBahl ve @ChrisWeigman'ı takip edebilirsiniz. Yapabilirsek Twitter tanıtıcılarını gösteri açıklamasına koyacağız. WMR'de bir WordPress Topluluğu podcast'i olan Press This'i dinliyorsunuz.

Gelecek haftaki bölümde, Automatic'de ürün irtibat sorumlusu olan Anne McCarthy, site Düzenleme ve 6.1'deki değişiklikler ve 6.2'de neler olacağı hakkında konuşacak. Press This'i dinlediğiniz için tekrar teşekkürler.

Torque dergisi ile yaşadığım maceraları @thetorquemag Twitter üzerinden takip edebilir veya her gün buna benzer eğitimler, videolar ve röportajlar eklediğimiztorquemag.io'ya gidebilirsiniz. Torkmag.io'ya göz atın veya bizi Twitter'da takip edin. Press This'e Red Circle, iTunes, Spotify üzerinden abone olabilir veya her hafta doğrudan wmr.fm'den indirebilirsiniz. Ben sunucunuzum Doctor Popular WP Engine'deki rolüm aracılığıyla WordPress topluluğunu destekliyorum. Ve her hafta Press This'te topluluk üyelerini öne çıkarmayı seviyorum.