Când și când să nu folosiți WordPress fără cap

WordPress Headless a câștigat din ce în ce mai mult interes din partea dezvoltatorilor și a companiilor de găzduire deopotrivă, în special în ultimele luni. Odată cu WP Engine lansând găzduirea Atlas și din ce în ce mai mulți dezvoltatori care preferă cadrele Javascript pentru a alimenta front-end-ul site-urilor lor, WordPress fără cap pare să ofere tot ce este mai bun din ambele lumi: o experiență editorială familiară pe backend cu flexibilitatea de a alege o stivă tehnologică modernă. pe front-end.

Cu toate acestea, pentru toate beneficiile WordPress fără cap, există cu siguranță și unele dezavantaje. Nu toate mediile de găzduire sunt configurate pentru a gestiona WordPress fără cap în mod nativ, așa că dacă sunteți obișnuit cu o configurare WordPress mai tradițională, poate fi necesar să fiți creativ cu găzduirea dvs.

În plus, deoarece front-end-ul și backend-ul sunt separate, unele dintre bucățile WordPress care sunt incluse în mod normal trebuie recreate sau cel puțin reimaginate.

În acest articol, vom arunca o privire la unele dintre cazurile de utilizare în care WordPress fără cap strălucește cu adevărat, precum și unele dintre situațiile în care este posibil să doriți să rămâneți cu o configurare WordPress mai tradițională. Și, în cele din urmă, sper să vă dau o idee mai bună dacă WordPress fără cap este o opțiune bună pentru următorul dvs. proiect. Să ne scufundăm.

Ce este Headless WordPress

În timp ce o configurare tradițională WordPress rulează pe un server care oferă atât backend-ul pentru editori și creatorii de conținut, cât și șablonul și orice altceva pentru a face site-ul web să arate bine pe front-end, WordPress fără cap este un termen folosit pentru a descrie când interfața și backend-ul care alcătuiește un site WordPress sunt separate.

Aceasta înseamnă că, deși experiența tradițională de backend WordPress este aceeași, WordPress nu este responsabil pentru difuzarea niciunui șablon sau conținut legat de temă.

Într-o configurare fără cap, WordPress scoate tot conținutul site-ului prin punctele finale API (de obicei fie API-ul REST WordPress, fie WP GraphQL). Aceste puncte finale API sunt consumate de o interfață separată care este în întregime responsabilă pentru gestionarea afișării conținutului.

În multe cazuri, acesta este un site creat împreună cu unul dintre cadrele Javascript populare, o aplicație mobilă, o aplicație de conversație alimentată de Alexa sau Google Home sau aproape orice interfață care poate consuma conținut prin API. Aruncă o privire la videoclipul WPCasts de mai jos pentru a vedea cum ar putea arăta.

Acest lucru face un site WordPress fără cap mult mai flexibil în ceea ce privește modul în care poate fi prezentat conținutul. Cu o configurare WordPress tradițională, sunteți în mare parte blocat în ieșirea care este controlată de temă, dar cu headless, puteți scoate același conținut și îl puteți prezenta utilizatorilor finali în multe moduri diferite, deoarece prezentarea este controlată de platforma care consumă în cele din urmă punctele finale API.

Beneficiile WordPress fără cap

WordPress fără cap continuă să crească în popularitate, deoarece pentru unele echipe de dezvoltatori și de conținut, există cu siguranță câteva beneficii puternice pentru o configurare fără cap.

Echipe diferite pot face ceea ce fac cel mai bine

Unele organizații, chiar și companii de software care angajează dezvoltatori, constată că, deși departamentul de marketing dorește să folosească WordPress pentru site-ul de marketing, acesta nu se suprapune cu setul de abilități ale dezvoltatorilor lor existenți și ajung să externalizeze această muncă către o agenție sau un freelancer. cine este mai centrat pe WordPress.

Cu toate acestea, cu o configurație WordPress fără cap, dezvoltatorii interni pot alege să folosească orice cadru de front-end le place pentru a dezvolta front-end-ul site-ului, valorificându-și abilitățile existente chiar dacă nu au experiență cu WordPress.

Lucrarea specifică WordPress poate fi apoi externalizată și conectată cu interfața internă prin API, economisind potențial costurile de dezvoltare a site-ului, precum și permițând ca toate cunoștințele specifice mărcii și companiei care sunt interne să apară pe front. a site-ului unde ar putea fi ceva pierdut în traducere altfel.

Editorial poate folosi WordPress-ul cu care sunt familiarizați

Dacă aveți o echipă editorială sau creatori de conținut care sunt deja familiarizați cu experiența de editare WordPress (care este din ce în ce mai comună pe măsură ce WordPress preia și mai multă cotă de piață), nu trebuie să vă decideți între a vă lăsa frontend-ul să fie la curent. cu cele mai noi tehnologii și oferind echipei de creare de conținut o experiență cu care sunt familiarizați.

Folosind o configurație WordPress fără cap, creatorii de conținut pot continua să producă conținut în experiența WordPress cu care sunt familiarizați, în timp ce echipa de dezvoltare este liberă să folosească orice tehnologii frontend cu care sunt mai confortabil.

API-urile backend pot alimenta diferite platforme

Când lucrați cu o configurație fără cap în care WordPress alimentează punctele finale API în loc să furnizeze pur și simplu șabloane frontend, aveți flexibilitatea ca aceste puncte finale să împingă conținutul către alte interfețe decât doar un site web.

Aceleași puncte terminale API care scot conținutul dvs. pe web pot alimenta, de asemenea, aplicațiile mobile, pot interfața cu un alt CMS care alimentează o publicație tipărită, pot fi furnizorul de conținut pentru o aplicație vocală cu Alexa sau Google Home și multe altele.

Deoarece sunt configurate atât de multe interfețe pentru a consuma API-uri, utilizarea WordPress ca aplicație fără cap mărește cu adevărat posibilitățile de unde puteți utiliza și reutiliza conținutul pe care îl scrieți deja în WordPress.

Dezavantajele WordPress fără cap

Deși există câteva beneficii pentru o configurare WordPress fără cap, cu siguranță nu este pentru toată lumea. Dacă sunteți obișnuit cu o experiență WordPress mai tradițională și nu vă potriviți în niciuna dintre situațiile de mai sus, iată câteva dintre potențialele dezavantaje pe care veți dori să le luați în considerare înainte de a intra.

Pluginurile nu funcționează întotdeauna

Majoritatea oamenilor au impresia WordPress și a ecosistemului WordPress că, dacă aveți nevoie de funcționalitate suplimentară pentru site-ul dvs., puteți căuta un plugin care să ofere acea funcționalitate, să îl instalați și „pur și simplu funcționează”, adesea fără niciun cod sau configurație necesară.

Cu toate acestea, cu o configurare WordPress fără cap, multe plugin-uri nu funcționează din cutie, deoarece nu sunt neapărat conștienți că trebuie să-și ofere funcționalitatea prin API. Pentru unele plugin-uri, acest tip de comportament nici nu este posibil.

Luați, de exemplu, un plugin care adaugă linkuri de partajare socială în partea de sus a paginii cu o singură postare pentru a face conținutul mai ușor de partajat în diferitele rețele sociale. Cu o instalare WordPress normală, acest plugin ar putea fi activat, iar pictogramele de distribuire socială ar putea fi ușor injectate automat sau folosind un shortcode sau ceva și ați fi gata.

Cu toate acestea, cu o configurare fără cap, aceste pictograme sociale nu sunt transmise prin ieșirea API, deoarece nu există în conținutul postării. Și chiar dacă ar fi adăugate cumva la ieșirea punctului final API pentru o anumită postare, nu ar apărea pe front-end-ul site-ului decât dacă frontend-ul a fost creat special pentru a căuta acea ieșire și pentru a afișa butoanele. Deși nu este imposibil, acest lucru face ca multe pluginuri WordPress să consume mai mult timp pentru a fi implementate într-o configurare fără cap.

Echipele familiare cu WordPress nu „devin” întotdeauna fără cap

Dacă dezvoltatorii sau echipa dvs. de dezvoltare sunt deja familiarizați cu o configurație WordPress mai tradițională, în care există logica de afișare în temă și majoritatea personalizărilor sunt făcute pentru fișierele de temă, schimbarea mentalității pentru a funcționa cu o configurație fără cap poate fi uneori dificilă.

Chiar și din perspectiva procesului de dezvoltare, o configurare fără cap necesită uneori o schimbare a modului în care este utilizat controlul versiunilor, a modului în care implementările automate și găzduirea sunt configurate și gestionate și crește nevoia de comunicare, mai ales dacă doi dezvoltatori sau echipe diferite lucrează la piese frontend și backend ale site-ului. Toate aceste lucruri sunt sarcini cu care dezvoltatorii obișnuiau să lucreze împreună într-o temă WordPress mai standard nu a mai trebuit niciodată să se confrunte înainte.

Depanarea poate deveni mai dificilă

Orice sistem, fie că este distribuit sau mai mult de un monolit, poate avea erori care apar în timpul funcționării. Cu toate acestea, una dintre provocările sistemelor distribuite este că există atât de mult mai multe date și atât de multe alegeri pe care trebuie să le faceți atunci când încercați să depanați o problemă. De exemplu, cu o configurare WordPress fără cap, dacă întâmpinați o problemă cu postările care nu se încarcă în ordinea la care v-ați aștepta.

Pentru a începe chiar să depanați această problemă, mai întâi ar trebui să decideți dacă problema a fost cu partea frontală a site-ului sau cu backend-ul. Deoarece acestea sunt probabil găzduite în două locuri separate, ar trebui să găsiți apoi fișierul jurnal corect pentru sistemul de unde credeai că a apărut eroarea.

Dacă a existat o problemă pe backend, de exemplu, în cazul în care nu a furnizat postările corecte prin punctul final API. Dacă depanați un site WordPress obișnuit, ați putea încerca să var_dump echo informații de depanare și apoi să vedeți cum aceste informații ies pe front-end pe măsură ce depanați.

Cu toate acestea, cu o configurare fără cap, aceste informații nu vor apărea în șablonul dvs., ci mai degrabă în punctele finale API. Și, în funcție de modul în care sunt configurate punctele finale API, este posibil ca acest tip de depanare să nu funcționeze deloc.

Mai ales dacă munca de întreținere a front-end-ului site-ului și a backend-ului site-ului este împărțită între două echipe diferite, depanarea unei configurații WordPress fără cap este în general mai dificilă și implică mai multă comunicare decât un site WordPress mai tradițional. Mai ales dacă nu aveți la fel de experiență în depanarea sistemelor distribuite, acesta poate fi un motiv bun pentru a prefera o configurare mai simplă.

WYSIWYG este mai dificil

Una dintre promisiunile cheie ale Editorului bloc din WordPress este că vă aduce experiența WordPress mult mai aproape de unul dintre idealurile multor platforme CMS - oferind o experiență „Ceea ce vedeți este ceea ce obțineți” pe măsură ce conținutul trece de la editor la frontend-ul site-ului.

Cu toate acestea, pe site-urile WordPress în care stilul blocului din editor este într-o bază de cod separată de afișajul frontal, ajunge să fie puțin mai dificil să menținem aceste componente sincronizate. Atunci când se fac modificări în baza de cod frontend, acele modificări trebuie să fie, de asemenea, comunicate și reflectate în stilurile editorului pentru a păstra această experiență WYSIWYG consecventă.

Ca și în cazul altor dezavantaje ale WordPress fără cap menționate mai sus, aceasta înseamnă doar că este nevoie de mai multă comunicare și organizare pentru a menține cele două baze de cod sincronizate și pentru a oferi cea mai bună experiență atât pentru creatorii de conținut care folosesc backend-ul, cât și pentru utilizatorii finali care se confruntă. interfața site-ului.

Deci care este mai bun?

Dacă ai ajuns până aici, probabil că poți anticipa acest răspuns, dar dacă ar trebui sau nu să folosești WordPress fără cap pentru următorul tău proiect de site depinde într-adevăr de tine, de echipa care lucrează la el, de modul în care este implementat proiectul și de mulți alți factori.

Dacă aveți o echipă de front-end puternică, care este confortabil să interfațeze cu API-urile și este obișnuită să comunice modificări și să lucreze cu sisteme mai distribuite, atunci ar putea fi logic ca aceștia să se concentreze pe front-end-ul site-ului, în timp ce o echipă separată lucrează la piesa WordPress reală. .

Cu toate acestea, dacă sunteți mai mult un freelancer solo sau nu aveți multă experiență în sisteme mai distribuite, controlul versiunilor, implementare etc., ar putea avea sens să rămâneți cu o configurație WordPress mai tradițională.

WordPress fără cap poate fi o paradigmă puternică care vă permite să utilizați tehnologiile moderne și să faceți o punte între o experiență editorială cu care creatorii de conținut sunt familiarizați, putând, în același timp, să folosească o tehnologie mai nouă care nu a ajuns încă în ecosistemul WordPress.

Și, pe măsură ce instrumentele pentru dezvoltatori din jurul WordPress headless continuă să se îmbunătățească cu găzduirea headless-ului și alte instrumente concepute pentru a face dezvoltarea într-o configurație headless mai ușoară, va deveni mai accesibil doar pentru mai mulți dezvoltatori și mărci.

Pe scurt, WordPress fără cap este aici pentru a rămâne și, dacă este utilizat corect, poate fi un instrument grozav în cutia dvs. de instrumente pe măsură ce vă construiți următorul site WordPress.