Başsız WordPress Ne Zaman ve Ne Zaman Kullanılmamalı

Headless WordPress, özellikle son birkaç aydır geliştiriciler ve barındırma şirketlerinden giderek daha fazla ilgi görüyor. WP Engine'in Atlas barındırma hizmetini başlatmasıyla ve sitelerinin ön ucunu güçlendirmek için Javascript çerçevelerini tercih eden daha fazla geliştiriciyle, başsız WordPress her iki dünyanın da en iyisini sunuyor gibi görünüyor: modern bir teknoloji yığını seçme esnekliği ile arka uçta tanıdık bir editoryal deneyim ön uçta.

Ancak, başsız WordPress'in tüm faydalarına rağmen, kesinlikle bazı dezavantajları da vardır. Her barındırma ortamı, başsız WordPress'i yerel olarak işlemek için ayarlanmamıştır, bu nedenle daha geleneksel bir WordPress kurulumuna alışkınsanız, barındırma konusunda yaratıcı olmanız gerekebilir.

Ek olarak, ön uç ve arka uç ayrı olduğundan, normalde dahil edilen bazı WordPress parçalarının yeniden oluşturulması veya en azından yeniden tasarlanması gerekir.

Bu yazıda, başsız WordPress'in gerçekten parladığı bazı kullanım durumlarının yanı sıra daha geleneksel bir WordPress kurulumuna bağlı kalmak isteyebileceğiniz bazı durumlara göz atacağız. Ve sonunda, umarım bir sonraki projeniz için başsız WordPress'in iyi bir seçenek olup olmadığı konusunda size daha iyi bir fikir verir. Hadi dalalım.

Başsız WordPress Nedir?

Geleneksel bir WordPress kurulumu, hem editörler hem de içerik oluşturucular için arka uç sağlayan ve aynı zamanda web sitesinin ön uçta iyi görünmesini sağlamak için şablonu ve diğer her şeyi sunan bir sunucuda çalışırken, başsız WordPress, ne zaman ön uç olduğunu açıklamak için kullanılan bir terimdir. ve bir WordPress sitesini oluşturan arka uç ayrılır.

Bu, geleneksel WordPress arka uç deneyimi aynı olsa da, WordPress'in herhangi bir şablon veya temayla ilgili içerik sunmaktan sorumlu olmadığı anlamına gelir.

Başsız bir kurulumda, WordPress sitenin tüm içeriğini API uç noktaları (genellikle WordPress REST API veya WP GraphQL) aracılığıyla verir. Bu API uç noktaları, içeriğin görüntülenmesinden tamamen sorumlu olan ayrı bir ön uç tarafından tüketilir.

Çoğu durumda bu, popüler Javascript çerçevelerinden biri, bir mobil uygulama, Alexa veya Google Home tarafından desteklenen bir konuşma uygulaması veya API aracılığıyla içerik tüketebilen hemen hemen her arayüz ile bir araya getirilmiş bir sitedir. Bunun nasıl görünebileceğini görmek için aşağıdaki WPCasts videosuna bir göz atın.

Bu, içeriğin nasıl sunulabileceği konusunda başsız bir WordPress sitesini çok daha esnek hale getirir. Geleneksel bir WordPress kurulumuyla, büyük ölçüde tema tarafından kontrol edilen çıktıya kilitlenirsiniz, ancak başsız olarak, aynı içeriğin çıktısını alabilir ve sunum, platform tarafından kontrol edildiğinden, son kullanıcılarınıza birçok farklı şekilde sunulmasını sağlayabilirsiniz. sonuçta API uç noktalarını tüketir.

Headless WordPress'in Faydaları

Başsız WordPress popülaritesini artırmaya devam ediyor çünkü bazı geliştirici ve içerik ekipleri için başsız bir kurulumun kesinlikle bazı güçlü faydaları var.

Farklı takımlar en iyi yaptıkları şeyi yapabilir

Bazı kuruluşlar, hatta geliştiricileri istihdam eden yazılım işletmeleri bile, pazarlama departmanı pazarlama sitesi için WordPress'i kullanmak istese de, bunun mevcut geliştiricilerinin becerileriyle örtüşmediğini ve bu işi bir ajansa veya bir serbest çalışana dış kaynak kullandığını görüyorlar. kim daha WordPress merkezli.

Bununla birlikte, başsız bir WordPress kurulumuyla, dahili geliştiriciler, sitenin ön ucunu geliştirmek için istedikleri ön uç çerçevesini kullanmayı seçebilir ve WordPress ile hiçbir deneyimleri olmasa bile mevcut becerilerini kullanabilirler.

WordPress'e özgü çalışma daha sonra dış kaynaklı olabilir ve API aracılığıyla kurum içi ön uç ile bağlanabilir, bu da siteyi geliştirme maliyetinden potansiyel olarak tasarruf sağlamanın yanı sıra kurum içi tüm marka ve şirkete özel bilgilerin ön uçta ortaya çıkmasına izin verir. Aksi takdirde çeviride kaybolan bir şeyin olabileceği sitenin.

Editoryal, aşina oldukları WordPress'i kullanabilir

WordPress düzenleme deneyimine zaten aşina olan bir editör ekibiniz veya içerik oluşturucularınız varsa (WordPress'in daha fazla pazar payı almasıyla giderek daha yaygın hale geliyor), kullanıcı arabiriminizin güncel kalmasına izin vermek arasında karar vermek zorunda değilsiniz. en son teknolojilerle ve içerik oluşturma ekibine aşina oldukları bir deneyim vererek.

İçerik oluşturucular, başsız bir WordPress kurulumu kullanarak, aşina oldukları WordPress deneyiminde içerik üretmeye devam edebilirken, geliştirme ekibi en rahat oldukları ön uç teknolojilerini kullanmakta özgürdür.

Arka uç API'leri farklı platformlara güç sağlayabilir

WordPress'in yalnızca ön uç şablonları sunmak yerine API uç noktalarına güç sağladığı başsız bir kurulumla çalışırken, bu uç noktaların içeriği yalnızca bir web sitesi dışındaki arabirimlere gönderme esnekliğine sahipsiniz.

İçeriğinizi web'e çıkaran aynı API uç noktaları, mobil uygulamaları da çalıştırabilir, basılı bir yayına güç sağlayan başka bir CMS ile arayüz oluşturabilir, Alexa veya Google Home ile bir ses uygulamasının içerik sağlayıcısı olabilir ve çok daha fazlasını yapabilir.

Pek çok arayüz API'leri tüketecek şekilde ayarlandığından, WordPress'i başsız bir uygulama olarak kullanmak, WordPress'te zaten yazdığınız içeriği nerede kullanabileceğiniz ve yeniden kullanabileceğiniz olanakları gerçekten genişletiyor.

Headless WordPress'in Dezavantajları

Başsız bir WordPress kurulumunun bazı faydaları olsa da, kesinlikle herkes için değildir. Daha geleneksel bir WordPress deneyimine alışkınsanız ve yukarıdaki durumlardan herhangi birine uymuyorsanız, atlamadan önce göz önünde bulundurmak isteyeceğiniz olası dezavantajlardan bazıları burada.

Eklentiler her zaman çalışmıyor

Çoğu insan, WordPress ve WordPress ekosistemi hakkında, siteniz için ek işlevlere ihtiyacınız varsa, bu işlevi sağlayan bir eklenti arayabileceğiniz, yükleyebileceğiniz ve genellikle herhangi bir kod veya yapılandırma gerektirmeden "işe yaradığı" izlenimine sahiptir.

Bununla birlikte, başsız bir WordPress kurulumuyla, birçok eklenti, işlevlerini API aracılığıyla sağlamaları gerektiğinin mutlaka farkında olmadıklarından, kutudan çıktığı gibi çalışmaz. Bazı eklentiler için bu tür bir davranış mümkün bile değildir.

Örneğin, içeriği çeşitli sosyal ağlarda daha kolay paylaşılabilir hale getirmek için tek gönderi sayfasının en üstüne sosyal paylaşım bağlantıları ekleyen bir eklentiyi ele alalım. Normal bir WordPress kurulumuyla, bu eklenti etkinleştirilebilir ve sosyal paylaşım simgeleri otomatik olarak veya bir kısa kod veya başka bir şey kullanılarak kolayca enjekte edilebilir ve her şey hazır olur.

Ancak, başsız bir kurulumla, bu sosyal simgeler, posta içeriğinde bulunmadığından API çıktısı aracılığıyla iletilmez. Ve belirli bir gönderi için API uç noktasının çıktısına bir şekilde eklenseler bile, ön uç özellikle bu çıktıyı aramak ve düğmeleri görüntülemek için oluşturulmadıkça sitenin ön ucunda görünmezler. İmkansız olmasa da, bu birçok WordPress eklentisini başsız bir kurulumda uygulamak için daha fazla zaman harcar.

WordPress'e aşina olan ekipler her zaman "kafasını yitirmez"

Geliştiricileriniz veya geliştirme ekibiniz, temada görüntüleme mantığının bulunduğu ve çoğu özelleştirmenin tema dosyalarında yapıldığı daha geleneksel bir WordPress kurulumuna zaten aşinaysa, bu zihniyeti başsız bir kurulumla çalışacak şekilde değiştirmek bazen zor olabilir.

Geliştirme süreci perspektifinden bile, başsız bir kurulum bazen sürüm kontrolünün nasıl kullanıldığı, otomatik dağıtımların ve barındırmanın nasıl kurulduğu ve işlendiği konusunda bir değişiklik gerektirir ve özellikle iki farklı geliştirici veya ekip üzerinde çalışıyorsa iletişim ihtiyacını artırır. sitenin ön uç ve arka uç parçaları. Tüm bunlar, geliştiricilerin daha standart bir WordPress temasında hep birlikte çalışmaya alışkın oldukları görevlerdir, belki de daha önce hiç uğraşmak zorunda kalmamış olabilir.

Hata ayıklama daha zor hale gelebilir

İster dağıtılmış ister daha çok monolit olsun, herhangi bir sistem, çalışma sırasında ortaya çıkan hatalara sahip olabilir. Bununla birlikte, dağıtılmış sistemlerin zorluklarından biri, bir sorunda hata ayıklamaya çalışırken yapmanız gereken çok daha fazla veri ve çok daha fazla seçenek olmasıdır. Örneğin, başsız bir WordPress kurulumunda, gönderilerin beklediğiniz sırada yüklenmemesiyle ilgili bir sorun yaşarsanız.

Bu sorunda hata ayıklamaya başlamak için bile, sorunun sitenin ön uç kısmında mı yoksa arka uçta mı olduğuna karar vermeniz gerekir. Bunlar büyük olasılıkla iki ayrı yerde barındırıldığından, hatanın kaynaklandığını düşündüğünüz sistem için doğru günlük dosyasını bulmanız gerekir.

Arka uçta, örneğin API uç noktası aracılığıyla doğru gönderileri sağlamadığı bir sorun varsa. Normal bir WordPress sitesinde hata ayıklıyorsanız, bazı hata ayıklama bilgilerini echo veya var_dump yapmayı deneyebilir ve ardından hata ayıklarken bu bilgilerin ön uçta nasıl ortaya çıktığını görebilirsiniz.

Ancak, başsız bir kurulumla, bu bilgiler şablonunuzda değil, API uç noktalarınızda görünür. API uç noktalarınızın nasıl yapılandırıldığına bağlı olarak bu tür bir hata ayıklama hiç çalışmayabilir.

Özellikle sitenin ön ucunu ve sitenin arka ucunu koruma işi iki farklı ekip arasında bölünmüşse, başsız bir WordPress kurulumunda hata ayıklamak genellikle daha zordur ve daha geleneksel bir WordPress sitesine göre daha fazla iletişim gerektirir. Özellikle dağıtılmış sistemlerde hata ayıklama konusunda deneyimli değilseniz, bu daha basit bir kurulumu tercih etmek için iyi bir neden olabilir.

WYSIWYG daha zor

WordPress'teki Block Editor'ün en önemli vaatlerinden biri, WordPress deneyiminizi birçok CMS platformunun ideallerinden birine çok daha yakın hale getirmesidir - içerik editörden diğerine geçerken "Ne görüyorsanız onu alırsınız" deneyimi sağlar. sitenin ön yüzü.

Ancak, editördeki blok stilinin ön uç ekrandan ayrı bir kod tabanında olduğu WordPress sitelerinde, bu bileşenleri senkronize tutmak biraz daha zor olur. Ön uç kod tabanında herhangi bir değişiklik yapıldığında, tutarlı WYSIWYG deneyimini sürdürmek için bu değişikliklerin de iletilmesi ve editör stillerine yansıtılması gerekir.

Başsız WordPress'in yukarıda belirtilen diğer dezavantajlarından bazılarında olduğu gibi, bu sadece iki kod tabanını senkronize tutmak ve hem arka ucu kullanan içerik oluşturucular hem de son kullanıcılar için en iyi deneyimi sağlamak için daha fazla iletişim ve organizasyonun gerekli olduğu anlamına gelir. sitenin ön yüzü.

Peki hangisi daha iyi?

Buraya kadar geldiyseniz, muhtemelen bu cevabı tahmin edebilirsiniz, ancak bir sonraki site projeniz için başsız WordPress kullanıp kullanmamanız gerçekten size, üzerinde çalışan ekibe, projenin nasıl dağıtıldığına ve diğer birçok faktöre bağlıdır.

API'lerle rahat bir şekilde arabirim oluşturan ve değişiklikleri iletmeye ve daha dağıtılmış sistemlerle çalışmaya alışkın olan güçlü bir ön uç ekibiniz varsa, ayrı bir ekip asıl WordPress parçası üzerinde çalışırken sitenin ön ucuna odaklanmaları mantıklı olabilir. .

Ancak, daha çok yalnız bir serbest çalışansanız veya daha fazla dağıtılmış sistem, sürüm kontrolü, dağıtım vb. konusunda çok fazla deneyiminiz yoksa, daha geleneksel bir WordPress kurulumuna bağlı kalmak mantıklı olabilir.

Headless WordPress, modern teknolojilerden yararlanmanıza ve içerik oluşturucuların aşina olduğu bir editoryal deneyim arasındaki boşluğu kapatmanıza izin verirken, henüz WordPress ekosistemine gelmemiş bazı yeni teknolojileri kullanabilmenize olanak tanıyan güçlü bir paradigma olabilir.

Başsız WordPress'i çevreleyen geliştirici araçları, başsız bir kurulumda geliştirmeyi kolaylaştırmak için tasarlanmış başsız özel barındırma ve diğer araçlarla daha iyi olmaya devam ettikçe, yalnızca daha fazla geliştirici ve marka için daha erişilebilir hale gelecektir.

Kısacası, başsız WordPress kalıcıdır ve doğru kullanılırsa, bir sonraki WordPress sitenizi oluştururken araç kutunuzda harika bir araç olabilir.