 Mag ik een warm applaus voor Nieuws de Blauw? Dankjewel, superleuk dat jullie gekomen zijn. Vrijdag ochtend en tien uur. Ik had verwacht dat er wat meer rode oogjes, wat katen zouden zijn, maar volgens mij valt het mee. Maar ten voorbereiding heb ik wel de presentatie in Dark Mode. Dat scherm is echt een 40 watt lamp in je gezicht. Dus de rest van de presentatie is donkere tweede deentje. Er komen straks wat code voorbeelden langs. Hier zo kun je gewoon de slides downloaden, die staan een maandag op. Express niet voor het weekend, wat ga je gewoon lekker weekend houden, maar als je dingen na wilt kijken of je iets gezien hebt, waarvan je nog even denk van, even teruglezen, hier staan ze een maandag op. Als je foto maakt kan dat natuurlijk ook. Ben ik achterin goed te verstaan ook? Bredelijk. Bredelijk, oké, iets harder nog. Iedereen deze URL op die het wil hebben. Sets jaar geleden was voor mij de eerste wordcam die ik bezocht. Ik was zes jaar geleden net in dienst bij Level Level. Ik werd uitgenomen voor een tripje naar WorldCamp Europe in Sevilla. En ik zat midden in een verhuizing. Ik was net bij Level Level begonnen en daar heb ik overslagen. Twee maanden later was WorldCamp Nederland. Daar ben ik naar toe gaan. En daar super veel leuke mensen ontmoet. Ik kende op dat moment nog helemaal niemand binnen de WordPress community. Maar ik zat als voorbereiding op de prestatie wat foto's uit 2016 terug te kijken. En nu ken ik in principe heel veel mensen die nog op die foto staan. Het is heel grappig hoe er in die zes jaar hoeveel mensen er zijn blijven hangen in die community. Sets jaar geleden woonde ik een prestatie bij over de WordPress API. En die heette de WordPress API, hacking the WordPress West API. En dat was belangrijk omdat op dat moment de trend rondom de WordPress West API er zo uit zag. Dat best wel booming op elk evenement op dat moment werd overgesproken. Wat kan je ermee? Waarom is het belangrijk? En even kijken, dit praatje van Jeroen van Dijk. Dat was degene die mij echt triggerde om ermee aan het slag te gaan. Op WorldCamp Nederland zes jaar geleden. En nu dacht ik, oké, maar wat is er in de afgelopen zes jaar dan precies veranderd in de WordPress API? Zijn we vooruit gegaan? Wat voor ontwikkelingen zijn er geweest? Kunnen de dingen beter? Hoe gebruiken we het eigenlijk? En wat voor trucjes heb je nog steeds nodig waar hij op dat moment al van zei, hier moet je rekening mee houden, hier moet je omheen hacken. Eerst even terugkijken naar wat is de WordPress API? Wie is er gisteren naar het praatje van Johan geweest over de WordPress API? Best veel mensen hebben ook een beetje de historie van de rest-API in zijn algemeenheid meegekregen en waar het verdient. Maar voor iedereen die daar nog niet direct ervaring mee heeft, het is een gestandaliseerde manier om data in en uit WordPress te krijgen, of in ons geval WordPress te krijgen, waardoor je ineens platform onafhankelijk bent. Dus je kunt een externe automatiseringstoel aan WordPress koppelen, je kunt de handscanner van de Albert Heijn kun je aan WordPress koppelen, je kunt je Smartwatch en WordPress koppelen, je kunt van allerlei soorten devices kun je ineens met WordPress laten werken. En daar gaat WordPress van een CMS naar meer een soort van platform om content te beheerden. Ik ga dus niet verder praten over hoe de WordPress API ten stand is gekomen, maar meer over wat is er nu in de afgelopen zes jaar gebeurd sinds dit praatje. Allereerste, op het moment dat het praatje werd gegeven eind 2016, was de rest API nog geen onderdeel van Core. Het was een plug-in, op dezelfde manier dat Kuttenberg als plug-in werd ontwikkeld, en in WordPress 4.7 werd de rest API pas onderdeel van Core. Dus op het moment dat het praatje werd gegeven, was het nog een plug-in installeerd, was het nog heel erg niche van wie daar een gebruik van was. Op het moment dat het in Core werd gemurkt, nou je ziet hier zo, post comments, terms, users, meta en settings, maar er missen ook nog een hele hoop dingen op dat moment. Geen toegang tot menu's, geen toegang tot teams en plug-ins, geen search via de rest API, geen widgets. Dat was de start van de rest API binnen Core. Vervolgens, ik moet ook twee keer klikken, dat is irritant, kwam Kuttenberg in WordPress 5.0, de block-editor. De block-editor is in die afgelopen zes jaar echt een beetje een drijffeer geweest voor ontwikkeling van de rest API. Na 4.7 naar het gemurkt, stond het hele even een beetje stil, maar de block-editor heeft dat weer echt een beetje een boost gegeven. Ze hebben ook een beetje een gedeelde afhankelijkheid. De block-editor was niet mogelijk geweest zonder een rest API, en andersom is de rest API, heeft heel veel van zo'n ontwikkeling te danken aan het feit dat Kuttenberg erop werkt. Door de toevoeging van Kuttenberg zijn bijvoorbeeld de search- en content-endpoints verder aangescherpt en ook nu met full-site editing, merk je dat er ineens een hele hoop onderdelen, zoals widgets en block-patterns en dat soort dingen, aan die WordPress rest-API wordt toegevoegd. Maar je ziet wel dat de belangrijkste drijffeer voor ontwikkelingen aan de rest API is op dit moment de block-editor. Wat er ook gebeurt is in die afgelopen 6 jaar, is dat er plugins zijn geweest die mee zijn gaan doen met de rest API, die hun functionaliteit via de rest API aan het blootstijden zijn. Bijvoorbeeld Advanced Custom Fields, die sinds, even kijken, het staat hier zo, 2021 november 2021 het mogelijk maakt om bij de Custom Fields aan te geven dat ze ook via de rest API opgevraagd mogen worden. Contact Form 7 sinds maart 2017, WooCommer sinds april 2017, Gravity Forms maakt het mogelijk om formulieren, insturen, formuleren te renderen via de rest API, de Joost sinds april 2020, dus er komen best wel veel plugins die wij gewend zijn uit het ecosysteem van WordPress en die ook de kracht zijn van het WordPress-ecosysteem, die gaan ook met de rest API werken. Wat je wel ziet, is dat er nog heel weinig plugins zijn die echt gebouwd worden met een API-first mindset, waarbij de basis vormt voor hoe zij met WordPress werken. Het gaat veel meer nog om traditionele plugins die vervolgens een rest API de bovenop krijgen. Zeker klikken. De toeling ontwikkelt zich. Dat is ook een belangrijk onderdeel van het ecosysteem. Inmiddels zijn er veel meer tools beschikbaar over het werken en de debuggen van de rest API, waar je voorheen in het praatje van Jeroen zes jaar geleden nog om dingen heen moest werken om de rest API te verbergen of dingen uit te zetten in de rest API, kun je nu gewoon een plugin downloaden en aanklik van ik wil dit wel zien, ik wil deze mee te zien, ik wil die post-type wil ik niet terugzien in de rest API. Dus het aanzettenuitzet van content wordt makkelijker en ook het idee van WordPress als soort low-code-platform wordt daarmee aangesterkt. Verder toeling zoals de rest API-log, super in het zand, is een debugging tool die je kunt aanzetten in je WordPress-installatie en daarbij kun je zien wat voor requesten naar de WordPress-API wordt gestuurd. En dan kun je precies zien wat voor method er is gebruikt, naar wat verpatte het is geweest, wat de response-time is geweest, hoeveel content er is teruggestuurd, onder wat voor gebruik dat is gebeurd. Super nuttige tool om te hebben op het moment dat je wil gaan debugging en kijken waar komen de interacties met die rest-API vandaan. Want wat belangrijk is bij de rest-API is dat jij niet controle hebt over wie de gebruiken zijn van de rest-API. Misschien is er een externe partij die tickets verkoopt voor jouw site en dan ordersinschiet bij jouw WooComers-installatie. Hoe weet je dan hoe ze dat doet en wat voor die quest zij sturen en of dat goed gaat of niet. Rest-API-log. Ja, dat zes keer klikken volgens mij inmiddels. Maar dat komt goed, dan kan ik. Ik kan heel goed klikken. Nog even een detailview. Je kunt precies zien waar het naartoe is gaan maar ook de request headers. En dit maakt het ook heel makkelijk om lokaal bijvoorbeeld met curl of met postman deze request na te boodsen. Van oké, wat is er dan precies naartoe gegaan op het moment dat het niet lukt? Kun je kijken van oké, hoe format ik weer dan dat het wel lukt? Of is misschien de authenticatie verkeerd geweest? Waar ligt het dan aan dat het mislukt is? Dit is een swagger interface, plug-in gemaakt voor de WordPress OpenAPI-specificatie. En wat dit doet is, die zet het schema van jouw site om naar een OpenAPI-specificatie en deze tool vervolgens maakt dan mogelijk om via een GUI interlog request te doen. Je neemt je wat meer aan de hand dat je door een JSON-bestand moet gaan zoeken in wat er allemaal mogelijk is op deze site. Ook superinteressant om op een hele eenvoudige, laagdrempige documentatie te delen met externe gebruikers. Dit is query monitor. Sinds mei 2021 ondersteunen die debugging output voor restAPI-responses. Dus op het moment dat je op je website query monitor aan hebt staan en je doet een request, dan zie je vervolgens in de response daarvan zie je wat voor database queries zijn er gedaan, hoe lang hebben al die database queries erover gedaan, zijn er dubbele database queries, zijn er errors geweest op de site. Dus je kunt hier zo precies zien dat in deze pageload 15 database queries zijn gedaan waarvan dit er één is en die duurde een duizendste van een seconde en gaf 317 resultaten terug. Supernutig op het moment dat je performance problemen hebt om op deze manier te kunnen zien waar ligt dat dan precies aan. We hebben gisteren natuurlijk ook bij Praatje van Floris gezien dat je dan vervolgens verschillende mogelijkheden hebt om te kijken moet we wel de restAPI gebruiken moet deze plugin wel ingehaakt zijn op het moment dat we de restAPI call afhandelen. Dus als je die talk gisteren niet hebt gezien kijk die dan even terug op Purpose TV want als je hier zo dingen in ziet die niet kunnen dat is de manier om het op te lossen. Krik! Ja, ja wees. Even good op het scherm. Eén van de dingen die 6 jaar geleden nog moest was lag een hele grote focus op het aanmaken van je eigen endpoints. En dat was voornamelijk om te zorgen dat er wat custom data op endpoints beschikbaar waren. Er was op dat moment dat de presentatie werd gegeven en was er al een register post meta waarin je show in rest kon aangeven maar die kon alleen maar simpele datetypen aangeven. Dus alleen maar strings, ins, booleans dat soort dingen. Sinds WordPress heb ik hier niets aan. Volgens mij 5.5, 5.6 kun je ook complexe datetypen meegeven in de rest de API. Dat is op deze manier te registreren. Dus we doen een register post meta we geven aan dat er een metafeld projects is en dat die bestaat uit een array. Vervolgens in de show in rest kunnen we een heel schema definieren over dit bestaat uit een object en daar zitten twee strings in. Vervolgens is de output wat we je rest zien. Dus het is een stuk makkelijker geworden om voor jouw plug in op het moment dat je meta dat registreert om eigenlijk binnen een paar regels code de juiste formatting te krijgen om die data bloot te stellen via de rest API. Wat er ook nieuw is sinds die afgelopen 6 jaar en hiermee gaan we wat dieper op een authenticatie vraag stukken zijn de application passwords. En de application passwords zijn de manier om te zorgen dat jij vanuit een externe site of vanuit de first party site data kan opvragen die beveiligd zijn met gebruikers of plugins of edit commanders kan sturen naar de rest API server. Dus vanaf het begin is eigenlijk de manier geweest om te authenticeerden met de rest API om dat met een cookie te doen die standaard door WordPress wordt gezet waarmee wordt aangeven dat jij een ingelocht gebruik bent en dan vervolgens een nonce mee te sturen om te zorgen dat er geen externe website zijn die ons jouw aanpassingen kunnen doen in de WordPress API. Zijn maar een WP nonce meegeven aan de rest API om kals te doen voor wie is dat bekend allebei een beetje allebei een beetje wie heeft dit nog nooit gedaan wel een paar handen voor degene die het wel hebben gedaan heb je waarschijnlijk een stukje documentatie gezien wat er zo uitziet we doen een WP localize script en de WP localize script die zet vervolgens een nonce in de HTML van de pagina en die nonce kun je vervolgens gebruiken om in te loggen bij jouw WordPress website om authenticeerde kals te doen binnen jouw WordPress website het probleem hiervan is dat die nonce is specifiek voor de gebruik die op dat moment de pagina bekijkt en dat vernietigd caching want als ik ingelocht ben de nonce voor Niels komt er terug en vervolgens locht iemand anders in als Harry en die vraagt pagina op en die krijgt de nonce van Niels dan hebben we een probleem, kan hij niet emmel dit is niet handig wat wel handig is en ongedocumenteerd klik nou ja ik wil niet vervolgen ik wil de volgende wat wel handig is dat er een Ajax-call bestaat waarbij jij een nonce kan opvragen deze hoef je niet te caching de rest van de pagina kan je wel caching dus op het moment dat jij met jou eens op de pagina komt en je zegt geef mij deze nonce dan kan je de rest van de pagina uit caching halen kun je hiermee authenticeerde request doen andere optie is om basic authenticatie te gebruiken plug in je insterderen kun je met de gebruikers naam wachtwoord van de gebruiken kun je inloggen wat je bekent is bij een externe partij en er zit helemaal geen toegangscontrole, geen expiry op dus het ongedaan maken van dat iemand kan inloggen namens jou in je WordPress-website is het veranderen van je wachtwoord wil je over het algemeen niet op die manier bloot staan oplossing die woekomers gebruikt is om apkies te gebruiken kan heel handig zijn heeft de plug in ook volledig gecontrole hoe die authenticatie plaatsvindt het probleem hiermee is dat het niet gestandaliseerd is en je straks 30 verschillende methodes hebt om interlog in je website omdat de ene plug in bepaald apkie accepteert maar een andere plug in weer niet de meest standaard oplossing is om oaf te gebruiken oaf is plettig omdat je een volledig gedefineerde standaard hebt die al 10 jaar 20 jaar, na 20 jaar of er even 10 jaar gebruikt wordt door alle grote social media services dan kun je zeggen, ik wil via Google inloggen ik wil via Facebook inloggen kan helemaal veilig zijn kan helemaal zeker zijn want anders zouden Google het eigenlijk ook niet inzetten nadeel hiervan is dat binnen het WordPress-ecosysteem er eigenlijk alleen goede betaalde opties zijn het is niet een gratis ding om dit gedaan te krijgen wat er wel prettig aan is ik ga gewoon vanaf nu top wat er wel prettig aan is is dat je met oaf kunt aangeven binnen welke scope iemand iets mag doen in je website bijvoorbeeld, op het moment dat je iemand via je WPnons of via een basic authenticatie laat inloggen dan mag die alles wat je al gebruiken ook mag als jij een externe partij hebt dan wil je misschien wel dat zij gebruikers kunnen uitlezen maar niet dat zij plugins mogen installeren en via oaf is een mogelijkheid om door middel van scopes aan te geven ook al is die ingelogged als jouw beheerder gebruiker dat er nog steeds beperkingen zijn op wat zo'n gebruiker dan mag binnen jouw website maar WordPress heeft iets anders gebracht application passwords die hebben niet voor de standaard oaf implantatie gekozen je hebt iets anders gedaan het voordeel is dat het super laagdremplig is super eenvoudig om hier gebruik van te maken het nadeel hiervan is het is minder veilig er zit geen expiry op jouw application password er is geen refresh token waarmee we kunnen zeggen dat de externe server elke 3 uur moet bevestigen dat dat wachtwoord nog gelg is en er zijn geen scopes op het moment dat je iemand een application password geeft van een beheerder of administratieverrol dan mag die ook meteen alles binnen je site en dat is vaak niet wat je wil dus je kan eromheen werken door een gebruiker met specifieke rechten te maken en dan daar een application password van te geven maar is dat dan precies wat je wil even kijken naar wanneer gebruik je wat en mijn voorkeur is om altijd of oaf te gebruiken wanneer het beschikbaar is dat als methode kan gebruiken en anders application passwords ik zou die anderen even helemaal wegdoen omdat ze minder veilig zijn omdat het data zeg maar onversleuteld over de over het web gaat extra type op het moment dat het een machine is dus een stukje automatisering wil iets doen op jouw website gebruik in het geval van oaf gebruik je een client credential grant en in het geval van WordPress gaan we kijken naar een handmatig ingesteld application password op het moment dat we het hebben over een third part, dus een externe partij die iets op jouw website wil doen misschien is het een event ticketing systeem wat een woekommersoorde bij jou in moet schieten gebruik dan een authorization code grant of een authorized application en wat hier gebeurt is dat je zo'n popup krijgt met systeem x wil iets gaan doen op i en dat de gebruiker dan moet aangeven van dat vind ik oké er zit een explicite stap waarin de gebruik kan zeggen ik weet niet wat het is en ik vertrouw het niet superhandig dit kan de authorized application kan dit ook, dat is deze URL als je iemand hier naartoe redirect dan krijgen ze het schermpje hier zo rechts onderin te zien waarbij je zegt ik wil in dit geval WordPress on iPhone authenticeer dan kun je zeggen oké wordt die teruggestuurd naar jouw website met de application password in a header dan kun je de application password uittrekken en dan vervolgens dat gebruiken om met de RSTP te praten laatste situatie is iemand die iets wil doen op jouw website als ingelogd gebruiker maar jij hebt alles in beheerd dus jij hebt in principe wachtwoord van die gebruiker en al de toegangscontrole van die gebruiker die heb je hier bij oaf gebruik je dan in het oude geval een password grant waarbij je de gebruiker de username wachtwoord gebruikt om daarmee een access token aan te maken in het geval van WordPress gebruik je eerst een cookie authenticatie plus een nonce daarmee maak je dan vervolgens via de RSTP in application password aan dat ziet er als volgt uit hebben we net kort gezien we vragen vanaf de website vragen we nonce aan vervolgens vragen wij op het user endpoint met die nonce vragen we aan om wat voor gebruiker gaat dit en als derde maken we een call naar WordPress RSTP van maak voor deze user een nieuw application password aan met de nonce erbij in de response krijgen wij een application password die zetten we in de local storage en vanaf dat moment gebruiken we alleen nog maar een application password om te gaan met die gebruiker even genoeg over authenticatie laten we het hebben over het echte gebruiken van de RSTP en wat daarin werkt en wat daar een aantal trucjes in zijn en ook vooral wat niet werkt voorbeeldje van een teaser die ik op mijn website wil maken en ik wil dit doen dus misschien een react stukje of view om deze teaser te kunnen laten zien hoe zouden we dat doen we willen een soort van crime op pad laten zien we willen een afbeelding, we willen de titel van de pagina waar we naartoe gaan linken we willen categorieën laten zien, we willen text zien nou we gaan eerst een request doen naar de RSTP request zoals dit WPJs en WPV2 product nummer 14, we hebben gister geleerd wat dit is en hoe dit werkt nog 10 minuten, top dat lukt dan krijgen we dit terug gigantische response we willen de titel van de pagina laten zien de titel van de product laten zien we willen een link naar waar het naartoe gaat we willen wat informatie laten zien maar we zien hier bijvoorbeeld ook terug dat we de datum krijgen wanneer het gepubliceerd is die het laatste modified is we krijgen de content gerendend terug, terwijl we alleen de excerpt nodig hebben veel te veel informatie en we zijn natuurlijk gister bij Joost geweest tijdens zijn we een praatje over hoe we groene websites kunnen maken en we hebben dit allemaal niet meer nodig hoe krijgen we minder data met het fields field je kunt sinds WordPress 5 kun je in een request aangeven dat je alleen maar specifieke data uit de request nodig hebt dus hier geven we aan dat we de titel rendered nodig hebben we hebben de excerpt, rendered nodig en we hebben link nodig meer hebben we niet nodig krijgen we dit terug supertof, echt helemaal geweldig je ziet hier overigens ook nog een stukje links, dat heb ik uitstip links zijn relaties naar andere objecten waar zijn die handig voor als we gaan kijken terug naar wat we hebben gezien we willen veel meer data over dit product dan wat we nu in de response hebben we willen relaties naar andere objecten zien zoals wat is de bovenliggende pagina wat voor features image zit er aan wat voor text en categorie hangen er aan in de response zitten die links die ik net aangaf en dat zijn verwijzingen naar deze categorie hangt er aan deze features image hangt er aan je kunt hier zien over wat de metadata is die bij dit object wordt wat we ook zien is dat hier zo'n embeddable true bij al deze object staat dus met vraagteken en bed kunnen we zeggen geef ons die metadata die als relatie aan dit object hangt geef die maar als content van dezelfde request dus in plaats van dat we zeggen geef mij product 1 en dan vervolgens in een apparticaal geef mij ook nog de categorie van product 1 kunnen we zeggen embed die maar in het antwoord van die eerste kaal supertof alleen er ontstaan nu twee problemen 1, we hebben weer veel te veel data ik heb hier zo'n voorbeeld van het outer object wat in die response meekrijgt op het moment dat je een score en bed meegeeft alleen in onze diesen tonen we helemaal geen outer twee stukje probleem kom ik straks op denk ik even kijken nou het eerste probleem los op deze manier op we kunnen filteren op welke embeds we erin hebben dus we kunnen zeggen we willen alleen de weperterms we willen alleen de feature media en de up dat is de parent page die we in de pagina willen hebben kunnen we het speciferen naar wat voor metadata er is tweede probleem ja is op het moment dat we bijvoorbeeld een overzicht hebben met team posts en al die team posts zijn gepubliceerd door dezelfde auteur en wij vragen op die lijst van team posts vragen wij do the embed wat we dan terugkrijgen is 10 copie van exact dezelfde data over wie de auteur is en wat de naam is en de slug we kunnen hier ook niet op filteren dat underscore fields wat we net zagen dat werkt niet voor embeds dus we kunnen niet zeggen geef mij van de auteurs maar alleen de slug geef mij alleen de naam dus daar je krijgt heel veel overheid in wat daar geproduceerd wordt wat daar ook belangrijk bij is en dit zag ik gisteren ook bij jongestens plaatje terugkomen hij liet heel even kort zien op het scherm de jason double api als een specificatie hij vroeg zit dit in wordpress en ik hoor een paar mensen zeggen ja dat zit niet in wordpress wat wordpress doet is niet de jason api specificatie want in de jason api specificatie zijn die problemen die ik net noemde die zijn opgelost ze hebben namelijk in de specificatie ruimte voor sparse fields waarbij je exact kan geven welke dat je nodig hebt binnen jouw response je hebt ruimte voor includes wat die links zijn en dat je aan kan geven welke includes je nodig hebt voor je pagina je hebt ruimte voor compound documents waarbij je zegt oké als ik hier zo tien relaties heb naar dezelfde auteur dan hoef ik alleen maar aan het einde van de response aan te geven dat er een auteur is en de client vindt zelf wel uit dat dat de goeie is dus dan krijg je een stuk kleiner document terug even om mee te nemen nog even een kleine toevoeging als je echt helemaal controle wil hebben over wat er in de rest api terugkomt zonder de standaard response aan te passen dat wil je over het algemeen niet kun je met een context werken in dit geval heb ik een context frontend aangemaakt wat je dan doet dus op het moment dat je een rest field registreert of een post meta kun je in de schema meegeven dat die beschikbaar is in een specific context op het moment dat je dan met die context de request doet krijg je ook alleen de data terug die in die context beschikbaar zijn dat het helemaal 100% controle wil krijgen over wat zit er in die response gebruik de context ik zat nog 5 minuten oké, gaan we door dit stuk heel snel is de succes 81% enabled geloofverschatting, maar heel veel sites hebben het aanstaan 2900 plugins registreerden hun eigen routes via deze methode 600 plugins geven hun eigen meta data mee dus WordPress omarmt op zich die restAPI wel maar als je gaat kijken naar wat de trend in Google search is dan lijkt de trend af te nemen, dan lijkt er juist minder interest te zijn in de WordPress restAPI ten opzichte van 2016 en dat is wel interessant want the headless content management system zit nog steeds in the lift er is nog steeds meer vraag in de websites zonder de frontend dus die 2 matchen niet helemaal als je dat ook iets breder gaat bekijken zie je dat de talen dichtgebruikt worden om dat soort sites te maken dat die allemaal nog steeds in de lift zitten en dat het bij WordPress een beetje begint af te kappen hier komt het meest twijfelachtig statistiek van het hele weekend bereid ik maar was voor, dit zijn 2 sites die ken ik, ergens volgens mij zijn ze ook sponsoren onbetrouwbaar dus en insight partners als je daarop zoekt dan krijg je meteen allemaal p maar wel voor de orde van grote WP engines gaat de markt groeien van 2020 tot 2021 voor WordPress als ecosysteem op ongeveer 6,5% voor headless cms tot en met 27% wordt dat geschat op ongeveer 22% per jaar maar als je duiding te geven is het ecosysteem van WordPress volgens WP engine op dit moment ongeveer 600 miljard euro waard en het headless cms is ongeveer anderhalf miljard euro waard dus ongeveer 600 keer kleiner dus ja, headless groeit een stuk harder maar ze moeten nog wel heel lang heel hard groeien om überhaupt in de buurt te komen van WordPress waar zoeken klanten op het moment dat ze naar headless gaan dus vanaf een agency perspectief door de webskill als bedrijf opzet ze houden heel erg rekening of ze zijn bang voor de kost en nieuw development dan gaat het niet knijt te veel te kosten om een headless website op te zetten omdat je allerlei dingen opnieuw moet gaan doen en daar heeft WordPress een hele groot kracht omdat wij ecosysteem hebben van plugins wij kunnen heel veel plugins inzetten en dan zeggen oh die feature hebben we al alleen dat valt een beetje weg op het moment dat je met de rest API gaat werken want heel veel van die plugins die doen niks met de rest API dus wat we moeten doen als WordPress is dat we zorgen dat dat ecosysteem groeit security, andere grote enterprise sites die richting de rest API of richting headless willen die hebben nodig dat daar goede authenticatie op zit je hebt voor WordPress zelf aan LDAP koppelen of helemaal dark mode top kun je dat aan LDAP koppelen, aan Active Directory je kunt externe services laten inloggen security is over het algemeen best goed geregeld moeten we wat mee oh af, zou ik zeggen site performance net een beetje uitgelegd, de rest API is niet het meest handige als het gaat om wat voor data gaat er heen en weer sprint er even doorheen juist dus plugin ecosysteem moet mee gaan werken om de kracht van WordPress te behouden om die wens van kostenlaag houden te kunnen combineren met de innovatie van headless kijk naar GraphQL ik hoorde gisteren dat een paar mensen daar al geïnteresseerd zijn GraphQL is een manier om exact te vragen wat je nodig hebt om jouw baag na te renderen super interessant want het is 50 keer kleiner, 100 keer sneller super tof, ziet er zo uit je klikt wel dingen in elkaar je krijgt een response, je kan het meteen gebruiken op de frontend, dit is weer de schijmwerp in je gezicht staan deze features op de roadmap moi met heeft in 2018 gezegd toen we naar PRP 5.6 gingen ik zie dat er mogelijkheden ontstaan rondom OAV en richting GraphQL ik vond het ongelooflijk dat die twee in één zin werden genoemd dat het een heel mooie quote is we zijn nu inmiddels 4, 5 jaar verder het is er niet er bestaat één ticket over GraphQL die is 4 jaar geleden gesloten in core ja, er is een keer overgesproken nee, er is niet heel veel beweging die kant op 1 minuten laat dat was hem ja