 Hallo, dus ik heb veel ervaring met de Kuttenberg Compatible Themasbouwer, en ook een eerste redelijk stevige experiment achter de rug, dan wel. Dus het is vooral vandaag een paar kweek winst dat we willen delen en een beetje de instinkers en de dingen die dan we zijn tegengekomen. Misschien even hoe over ons wijs gaan al even mee in het WordPress-wereldje hier, maar het was de eerste woordkant dat we erbij gewoond was WordPress in Nederland in 2010, als ik het goed heb. We werken al vrij lang bij WordPress, dus vooral Word Custom WordPress Development. Ik ben een beetje een allround diff, dus niet per se een deep diff, maar we hebben heel breed verschuld. Ik vind het javascript in de soort dingen het leukste. En in Antwerpen, een beetje mijn uitbreiding in België, ben ik ook nog wel actief in de lokale WordPress-community. Samen met Dave, we hebben ook al de twee wordcamps in Antwerpen organiseerd. En binnenkort onze vijftigste meet-up en april, dus wie dat zin heeft, kom af, 25 april, feestje. Een beetje quick overview van onze talk. Eerst een beetje quick winst. Kleine dingen die dat je kan doen waarmee je meteen kan profiteren in dat thema van nieuwe meisjes die daar binnen Geutembert beschikbaar zijn. Nadien focussen we specifiek op het project waar we gewerkt hebben, wat we nodig hadden. En nadien onze kwesten voor hoe we dan allemaal effectief in en uit de nieuwe editors te gaan krijgen. En met een paar take-aways hongen dat iedereen ook per is van Amerika. Quick winst. Ja, het werkt gewoon. Je hebt team support, bijvoorbeeld een berg meisjes die je kan toevoegen. Je kan zelfjaar je CSS-jaar beschrift toevoegen en blog templates. Dat kan er redelijk voor, denk ik, worden overlopen. It just works, bedoel, eigenlijk gewoon mee, want de content werkt nog altijd. Dus alles wat je in een editor de laterbees invliegt, komt er nog altijd in één erwelke thema gewoon mooi met de content uit. Dus eigenlijk zou je zelfs niks moeten doen of niks moeten veranderen aan je thema om toch Geutembert compatible te zijn. Dus dat is toch wel m'n redelijksteelige quick winst, denk ik zo. Twee kleine instinkertjes van It just works, ja. Maar om in een admin Geutembert als editor te krijgen, moet de rest API enabled zijn voor je custom post-type. Dus op het moment dat je post-type registreert, kan je helemaal parameters meegeven. Showing rest, dat default of false. Dus dat dat je al post-type zet, of die dat door een plugin geregistreerd worden of die dat je vloer lang geleden in je tiff maakt geregistreerd, whereas API is nog niet zo lang in je wordpress score. Dus als je het editor niet ziet, checkt even of dat je parameter effectief wel troost staat. Kan je ook nog toevoegen na te registreren van je post-type. Een van de andere parameters is welk, wat je ook custom post-type support. Misschien een evidente instinker, maar editor moet daar effectief wel toestaan. Als je custom post-type geen editor support, heb je ook geen beoezend werk. Dan de team supports. Die zijn redelijk uitgebreid, uitgelegd in het handboek. Dus dan sowieso de slides delen, ook op alle stappen. We hebben geprobeerd zoveel mogelijk rechtstreekse links erin te zetten. Soms is het een beetje zoeken naar de juiste bronnen of juist informatie. Dus misschien de slides een beetje als uitgangspunt werken. De team supports, daarmee kan je in je eigen thema een paar van de Gutenberg-nices gaan activeren. Je moet die letterlijk gaan activeren, want Gutenberg heeft van zichzelf eigenlijk niet een eigen ontvelling je thema uit te gaan ingrijpen. Dat is niet moeilijk, wat dat ook is. Maar als je bevoorbeeld die Align White, Align White wil, die daar je waarschijnlijk al wel in verschillende Gutenberg-demo's bent tegenkomen, wil je dat ook in je eigen thema hebben, dan moet je letterlijk aan team support Align White gaan toevoegen en waarschijnlijk via functions PSP. Ook weer, ja, die hersen zijn die rechtstreekse links. Maar de moment dat je team support toevoert, kan je in de editor, krijg je die nieuwe opties voor verschillende bloggen, elke blog die dat support kan je dan nu ook op whitewit.com gaan zetten. Vergeet niet dat je dan ook wel in je eigen thema de juiste CSS moet gaan toepassen. Standaard gaat WordPress uit. Je kent de classes Align Left, Align Right wel. Je krijgt er nu twee nieuwe bij. Align White en Align Full. Dus zolang je niks in je CSS, dat komt niet vergeten, krijg je de knoppen wel, zie je geen effect. Hoe dat je die Align White, Align Full in je CSS juist implementeert, hangt een beetje van je thema af en van je structuur. Er zijn wel verschillende opties. Ik heb nog een paar links aan toevoegen. Team Support voor de kleurpaletten. De standaard gaat Gutenberg eigenlijk een brede uitgebreid kleurpalette gaan suggereren. Ook mijn color picker, dat iedereen weet ik veel wat de kleur kan gaan toevoegen. Dat standaard kleurpalket palet van Gutenberg, dat kan je overrulen door je eigen colorpalet. Ik kan ook die color picker aanschakelen. Met redelijk basic code, dus via Team Support er is er colorpalet. Daaraan hang je je eigen kleurpalette door de slugs die je hier meegeeft aan je kleuren. Die gaan Gutenberg sowieso in classes meegangen aan de elementen waarop die kleur is gekozen. Dus ook weer terug om de links krijg je mooi de kleurenpickers en jouw kleurenpalet in de editor. Voeg je css2 voor alle kleuren die dat je toevoegt. En zowel als haas, slug background color maar ook voor de voorgrondkleur. Dat is de tekstkleur zelf voorbeeld. Is het een haas color css. Vergelijkbaar heb je voor de editor font sizes weer terug Gutenberg. Fond sizes suggereren die gaan je zelf gaan overrulen door font sizes die dat voor je eigen timmen een beetje strakker en een beter plan zijn. Ook de font size picker dus als iemand vrij een aantal pixels kan invullen kan je er ook uit flickeren. Vergelijkbaar de hd op weer terug naar het eilig met jouw font sizes. De editor gebruikt pixels die ik weet. Maar in je css kan je uiteindelijk je eigen font sizes toevoegen en dus kan je gerust met rums of ems werken of wat je tofst vindt. Team support dat is een beetje een veel warmte heb ik al gemerkt. Front and styles. A team support WP block styles. Die moet je letterlijk toevoegen. Maar eigenlijk gaat Gutenberg een hele op css in de front van je site aanspuren. Alle css die nodig is voor alles wat je uit te maken hebt. Daar heb je eigenlijk zo geen thema. Dus als je de column gaat toevoegen in Gutenberg, dan gaat in de css van je front als sowieso de css al zitten op dat je de diffs effectief mooi als columnen te zien zijn. Die WP block styles heeft niet echt iets met die basically uit te maken. Die heb je sowieso. Maar dat zijn een paar core blocks die dan wat extra styling krijgen. Zoals de pull quote van de wp block styles toevoegd of actieveerd in het thema dan krijg je nog een neintje bovenin omhoog. Maar dat is al een beetje hoe zeg je dat? Ja. Dan gaat het eigenlijk al een beetje gaan moeien met de styling van je site. Daarmee moet je dan ook echt expliciet gaan toevoegen. Ben je niet akkoord met hoe de columns gebouwd zijn in de core Gutenberg css? Je kan ook al die reacties eruit gooien maar dan moet je echt gaan dequeen. En dan moet je ook wel weten wat jij moet doen want dan kan je alles ook media deft, text strike, ook al die blocken. Al je gaat er wel van mooi onder elkaar uitgespuit worden dus dan ben je ook verantwoordelijk voor al die css. Wat kan? Ja. Komt van het core maar hij gaat zich niet moeien dus hij gaat het niet sowieso uit spelen. Daarmee die acting support moet je echt expliciet in je thema aanroepen om die styling effectief te hebben. Alles wat je nodig hebt voor de langs zoals die columns enzo daar heb je sowieso de extra wat moet je nog gaan toevoegen? De editors. Je komt sowieso altijd al ook aan tiny mce een status sheet gaan meegeven om bijvoorbeeld de typografie in de backend een beetje uniform te laten lijken met wat dat er aan de voorkant uitkomt. Nu is het iets complexer opgebouwd als je met editors styles gaat werken check sowieso elven de documentatie want je kan bijvoorbeeld niet de body gaan aanspreken dus de css wordt een klein beetje herschreven zodat je alleen maar binnen de editor zelf kan gaan beginnen stylen. Er is ook een dark mode beschikbaar er zijn we nu voorlopig afgebleven maar alles dark mode, dus waarom niet? Responsive embeds zit standaard in het core ook css om als je bijvoorbeeld een youtube video je hebt een iframe embed die aspect ratio van die video die wil je dat hij altijd bewaard blijft daar heb je css voor nodig core bt css aan maar gaat hij niet automatisch gaan toepassen want misschien wil je binnen je eigen thema dat op een andere manier afvangen ben je niet akkoord met je core toe dat wil je het zelf doen dus je moet ook wel letterlijk gaan opt-innen voor de css van responsive embeds die css heb je sowieso alleen wat die team support doet is een klas toevoegen aan de body en waardoor dat css nodig voor responsiveness van iframes effectief toegepast wordt maar ook terug als je thema het al zelf op een andere manier deed kan dat conflict te geven dus je moet letterlijk hoe dit gaan zeggen css in javascript gaan toevoegen we hadden al de actionhooks wp in qscript en qstyle nu hebben we er nog 2 nieuwe bij gekregen en qblock editor assets wanneer je css of javascript uitsluitend in editor wil gaan toevoegen assets die je zowel in editor en dus in de front wilt gaan toevoegen kan je aan qblock assets gaan ophangen uitsluitend in de front gaan uitspoelen ik kan ook met die qblock assets maar nog met een extra conditional van if is not admin voor de rest kan je ze gewoon gebruiken zoals je vroer werkt voor je eigen css vergeet niet de nieuwe classes die je nodig hebt als je die aline white of color palette sept geactiveert wil je zelf css gaan toevoegen aan coreblokken of aan bloks van het plugins je zal zien dat elk blok krijgt sowieso een class mee de classname wordt altijd op een specifieke manier opgebouwd bijvoorbeeld voor de corebloks gaat er altijd een wp-blok- en dan de slug van een blok zelf zijn dus daarmee kan je zelf je eigen bulkodes gaan stylen in plaats van default of the basics te houden algemeen wordt geadviseerd om de editor te houden hoe de editor eruit ziet en voelt om zo veel mogelijk conform te houden met hoe uiteindelijk de content aan de voorkant van de site gaat uitkomen dat is niet één op één daar gaan we het straks nog nog wel over hebben maar zodanig dat als je editor of als je zelf in de site ontschrijven bent of je klant dat het voorspelbaar wordt van hoe dat het aan de voorkant gaat uitzien dat is uiteindelijk toch één van de grote pluspunten of de grote doelen van Gutenberg dus probeer dat als je zelf gaat stylen om het ook zo conform mogelijk te houden een algemeen tip van een kitchen sink page kan zeker helpen of aan de moment dat je veel extra styling gaat toevoegen maak een goeie kitchen sink page voor je project of voor je thema zodanig dat je ook respond naar responsiveness toe in alle varianten die je bloks kunnen gaan hebben zodat er echt mooi en consistent gaat uitkomen er is ook een plugin een blok unitest die dat eigenlijk zo is over je pagina aanmaakt waar alle koordblokken alleen zitten met alle mogelijke variaties custom javascript dan zit je al waarschijnlijk in de realm of custom blokdevelopments er zijn een hele noop nieuwe javascript goodies in koord dat je veel naar je gebruik kan maken vergeet dan wel niet als je je javascript en culd die je als dependencies meegeeft dus je moet echt letterlijk de pakketjes van koord die je wil gebruiken dat zijn je dependencies blok templates dat is ook nog een beetje een quick win als je in Gutenberg echt gewoon gaat schrijven dan is dat misschien een hele mooie editor je krijgt een mooie titelveld en je kan gewoon beginnen te hebben in paragrafen volgen elkaar op en je kan nieuwe blokken gaan beginnen te oefoegen voor heel veel site eigenaars of voor redactoren is het niet altijd even leuk of even evident vanuit een wide page te gaan starten in Gutenberg en met die blokken je hebt quality outs heb je wel wat mogelijkheden het kan wel helpen om een suggestie te geven aan je authors ik kan een blok template in code gaan maken ik kan elk post type kan je andere blok templates aan elk post type kan je blok templates gaan toevoegen en die blok templates die kan je, dus de shablonen die je voorstelt die kan je dan ook nog eens een keer gaan fixeren maar daar zit er nog een beetje haken in ogen aan omdat dat echt op een gebruik om hier te doen er is al wel er zijn redelijk wat voorbeelden van die blok templates dus dat is ook de link naar het handboek maar ook een blok post van Bill Ericsson waar er heel veel redelijk concrete voorbeelden in zitten die gaat best wel ver hoe dat er wat concrete uitziet dit is nu een stukje code om op het core post type post template te gaan toevoegen dus elke keer als ik nu in de admin een new post open dan krijg ik al een suggestie van de blokken die hier beschreven zijn dus mijn template is eigenlijk gewoon niet meer of niet minder dan een array van bloks met een per blok welkom blok, dus leuk eventueel al wat default attributes die het meegeeft en eventueel op kind blokken bijvoorbeeld een column blok kan dan ook weer terug een heading en paragraph en weet ik veel wat bevatten om een ongelooflijk lange array worden met ongelooflijk veel geneste arrays erin hou je hakken en commas in de gaten maar als je het toepast dan krijg je eigenlijk iets zoals dit dus links heb je hoe mijn editor er nu uit ziet wanneer ik een new post begin te maken dus ik krijg al wel een suggestie ik kan als redacteur al altijd beslissen van nee, ik heb die overimage niet nodig of ik heb maar één tussen dit onmoldig of ik heb er veel meer, ik heb een veel langer artikel maar ik moet niet meer vanaf een blank pagina gaan beginnen zeker wanneer je een paar pagina's eigenlijk gaat designen een layout gaat voorstellen dan kan dat echt wel helpen om het wat consistent te houden dat ook niet elke blok poster per se compleet anders uit ziet dat helpt meestal uw bezoekers ook niet echt vooruit denk bijvoorbeeld wanneer je een calendarplugin hebt of zo al je calendaritems, als je er allemaal compleet anders uit ziet en al die datums en weet ik veel wat ze dan overal op een andere plek niemand vindt dat heel gebruiksvriendelijk denk ik als ik alles heb ingevuld zie je dat er zo uit in de editor rechts boven en op de front rechtsonder dus dit is ook nog wel redelijk mooi in sync zowel de styling van de back als van de front het was ook nog 2017 maar we wonen gewoon een Aline White op hebben toegevoegd als experiment oké, dat waren eigenlijk de quick wins ik was eigenlijk op in de kwaliteit ik had hier al mijn aardgescholen zo dan nu specifiek die quick wins is heel leuk maar wij doen custom theme development wij designen niet zelf dus soms wij zijn helemaal in het begin van een project en dan kunnen wij redelijk wat bepalen ook van de flow van een project soms is de design en content alleen maar klaar en dan mogen wij tot leven gaan wekken dat was een beetje de situatie waarin we nu zaten er waren zoveel ja misschien ineens deze laten zien er waren zoveel verschillende pagina's met zoveel verschillende soorten content en helemaal gaan discusseren of dit nu een goeie manier is om die pagina's op te bouwen, maar heel veel echt wat long pages, landingspagina 80e elementen ja, dan is eigenlijk de talk voor ons aan oké, hoe kunnen we dit nu op een redelijk gebruiksvriendelijke manier allemaal in de WordPress laten invullen en hoe kunnen we er op een beetje een performante manier ook uitkrijgen dit lukt er niet voorblocks van WordPress Gutenberg is eigenlijk in the deliverable ook tijdens het project dus design was ook niet echt heel component based of heel recyclerbaar qua component dus eerst wat we eigenlijk zijn aan het wonen is een beetje reverse engineer van oké, welke patronen zie je hier wat komt hier terug wat hebben we daar voor nodig hoe kunnen we die dingen opbouwen een voorbeeld van zo'n patron is bijvoorbeeld cards dat is redelijk klassiek denk ik een sexy met 1 of meerdere items in en dan per item dat kan er dan altijd wel een beetje anders uitzien maar als we dat samenvatten dan kwamen we neer op een soort van cards component en met 1 of meerdere cards en dan elke card, dat is de groene dus elke card kon een bepaalde breedte hebben een kwart, een derde of de helft van de breedte van de beschikbare container en soms een border soms niet, soms een afbeelding soms niet en ja, uiteraard responsief en het moest ook kunnen uitvullen dus als er nu vier items zijn en er zou nog een item bij komen van een derde breedte dan zal er gewoon op de volgende lijn komen met een derde breedte dus gewoon elke keer blijven aan het schuiven een andere voorbeeld was een soort van sticky was een subnavigatie omdat het vrij lange pagina's zijn hadden de meeste pagina's een subnav soms was er gewoon een soort van inhoudsopgave die bovenaan de pagina bleef staan op andere pagina's werd het een sticky subnav op zich is het dezelfde html die we gaan nodig om aan een andere styling een iets ander patroon dus dat is eigenlijk dezelfde blok opgebouwd, maar dan een stuil variant en ja, die links en die titels moeten wel kloppen met wat er effectief voor de rest nog op de pagina's staat dus we hebben met seksies gewerkt en elke seksie die een hashlink had en een subnav label die komt automatisch in de subnavigatie te staan dan denk je dat op welke moment ook in een editor zelf nog kan controleren klopt dit nog is deze consistent van opbouw en er waren nog redelijk veel andere patroon die we erin terug zaten dan echt gaan zien wanneer we hebben ons patroon we weten wat er allemaal in moet komen en hoe dat er uit moet komen hoe gaan we deze nu aanpakken waar moeten blokken zijn als het een blok is welke opties moeten blokken hebben wat hebben we al een beetje in onze trucke-doos zitten welke plug-ins zijn er beschikbaar kunnen we eventueel ook oude patroonen, oude code gaan herbruiken wat moeten we nog allemaal gaan beschrijven om het effectief te doen werken van voor en van achter ik heb dat moment begonnen de quest eigenlijk, dus onze zoek toch naar welke dat we konden hergebruiken of welke dat er moesten gebouwd worden maar er zijn allemaal ook wel wat opties er wordt dan er coreblocks, zijn plug-ins er is ook een shortcode blok dat je ook kan gebruiken maar wij hebben vooral eigenlijk meer custom bloks gewerkt waarom zullen we direct nog zien en daar kan je nog een onderscheid maken dus de statische blokken in dynamisch de statische, wat ik zei ik heb samen met de attributen die tijdens het edit bepaald dat die worden opgeslagen in de postcontent en dynamische blokken, dat wil ik zeggen vanuit de PSP wordt gegenereerd en voorbeeld is een place-host als een featured image of zo dus we moesten custom blokken maken, maar daarom kwamen wel wat problemen tegen met er eigenlijk vooral een gebrek aan documentatie er is wel wat, maar het is heel verspreid en vaak onvolledig het geval is dat je jezelf nog gaat proberen en gehoopt dat je goed bezig zet en komt eigenlijk op neer de codex is eigenlijk niet brakbaar voor gutemberg er is wel een goed handboek er staat wel in, maar ook daar vaak iets te onvolledig dus eigenlijk zit er vooral in de github de code uit te lezen en proberen iets zinnig in te ontwerpen alleen om te proberen dat te begrijpen voor plug-ins van blokken is het nog wel vroeg er zijn er wel maar nog niet zoveel dus ja, er is vooral veel te zoeken een voorbeeldje van die kaart, om daar nog eens op terug te komen dus je hebt zoals veel aan het zeggen een soort container en daarin zitten verschillende kaartcomponenten elke kaartcomponent heeft ook wel verschillende componenten dus voor zoiets simpel zit er al direct aan 5 verschillende blokken waarvan 1 die kaart component eigenlijk nog 2 verschillende styles moet hebben dus een breedte en een border dus wat hebben we nog voor deze simpel geval eigenlijk we hebben al direct een kaartcontainer nodig dus dat is een blok uiteraard en die gebruikt inner blocks inner blocks is eigenlijk een manier om blokken te nesten en die inner blocks zijn dan uiteraard die kaartcomponenten een kaart op zich is ook een container je kunt definieren dat die als parent enkel container kan hebben zoals gezegd kan deze kaart een column style hebben dat is die breedte van een vierde en deze of een tweede en die column style is belangrijk want die heeft ook invloed niet alleen de breedte van die kaartcomponent maar de image die erin zit die moet ook een andere size krijgen naar gelang de geproze column style en er is ook een border style zoals gezegd heb je rechts een soort menu met een aantal settings die je kunt zetten en je kunt er dus zelf ook settings toevoegen dat hebben we dan gedaan voor dit geval en zoals gezegd werken we met inner blocks het is een image block de optionale is een heading en een paragraph voor heading en paragraph hebben we de core blocks kunnen gebruiken voor image niet omdat we daar toch een paar speciale mensen hebben bijvoorbeeld die column style wat ik al over sprak die breedte nog iets is dat die gewoon de core block voor image die image kun je resize en dat mocht in dit geval ook zeker niet dus zelf heb ik al gezegd wat er onwille van de grid, dat hebben we specifiek vereist en bovendien mocht die image ook niet recised worden maar het aantal core blocks hebben we kunnen gebruiken als we het perikt de plugins daar vonden we ook niks om licht mee te maken nu is een voorbeeldje, je wordt een card block toegevoegd er zijn verschillende cards die worden toegevoegd een beetje traag en dan zie je dus eerst voeg je verschillende cards toe op de moment van toevoegen kan je de size of die breedte wijzigen maar dat kan je ook echt eraf doen en dat wordt de middelijk doorgevoerd en dan wordt van de middelse even de bewuize van voorbeeld de breedte gewuizigd en de front zie je natuurlijk hetzelfde en dan laat ik het even terug gaan hallo oké, dit is gewoon om een idee te geven het overzicht van de blocken die we hebben gemaakt voor deze project misschien want erover zijn heel veel keuzes die we gemaakt hebben tijdens heel veel blocken zijn ook enkel gebruikbaar in context van een ander parent block zoals dat van die cards en die card image die size, er is alleen relevant in context van die card we hebben ook ACF blocks gebruikt, ik weet niet of dat het ondertussen al gerulist is met de beta versie van ACF blocks die is eigenlijk alles wat je deed met de custom fields vroeger kan je nu geen blocken gebruiken een editor die kan ook een block preview te regeren dus dat is best heel gebruiksvriendelijk tot nu toe dacht ik dat het alleen nog maar blocken zijn waarbij geen meta ook geslagen naar de database dus het zijn echt als je zegt oké, ik wil hier 5 medewerkers gaan tonen of ik wil die en die medewerkers dan kan je wel met ACF dat formulier maken je editor kan dat als een block gaan toevoegen op de plek waar dat hij wilt en eigenlijk je kan inhaken op ACF en dan via een PHP template schrijf je gewoon je ACF output zoals voorheen of zoals default en dan wordt je block ook runtime dus dat zijn sowieso dynamic blocks worden die gewoon geoutput dus dat hebben we vooral gebruikt wanneer dat het eigenlijk andere posts waren die dat opgehaald moesten worden naar de database en make front and editor look the same DC ik was vorig jaar had ik even een heel naïeve idee van oké dan kan je de CSS van de front gewoon op de editor gooien en alles werkt geweldig goed nee vooral omdat het HTML in de editor redelijk anders is opgebouwd je hebt heel veel divs waarschijnlijk allemaal voor de ui flow maar dat betekent wel dat als je bijvoorbeeld zelf op je eigen block flex toepast ja, de kinderen van de flexcontainer op de front zijn misschien achter klein kinderen achter achter klein kinderen van die flexcontainer in de editor dus dat gaan we echt heel specifiek moeten gaan aanspreken met data attributen heel voorzichtig zijn met patronen om blokken op eenzelfde manier geleihout te krijgen in de editor dan in de front gaat het echt puur over non-leihout styling dus kleuren en achtergronden en dergelijke dan is het al iets bruikbaarder maar dan zou ik sowieso wel aanraden zoveel mogelijk met classes te werken ook bijvoorbeeld ja, als je een button hebt op de front is dat een a-tag maar in de editor is dat helemaal geen a-tag is een content editable dus ga niet weer in een styling in ESCS van oké, ik heb mijn WP block button daar van de a die krijgt een achtergrondkleurtje mee nee, probeer die a dan ook wel effectief een class mee te geven gewoon op classes gaan stylen en dat is sowieso veel meer recyclerbaarder in de front en in de backend issues dat we zijn tegenkomen onder andere ja, je block styles die zijn heel tof je voegt een button toe en je hebt direct drie opties voor dat je button er dan uit gaat zien blijft dezelfde HTML maar gewoon een extra CSS-class daar van alle andere leuke dingen mee doen van de moment dat een block inner blocks heeft zoals die cards of die card had ook inner blocks kan je geen block styling gebruiken of toch voorlopig nog niet ik heb een link toegevoegd naar het github issue bijvoorbeeld ook images die kregen vroeger met een MC altijd een class mee waarin je met de CSS eigenlijk kon zeggen oké, alle images van die size die worden zo geleid kan je nu niet dus een editor kan wel een size kiezen of kan een image resize maar je figure element krijgt geen size class niet meer dus als je gewoon bent om dat heel veel te gebruiken dan ben je nu een stukje kwijt er is nog altijd een redelijk stevig lange discussie lopende ook size options binnen galleries je kan dat momenteel niet kiezen dus dat wordt een stuk gegenereerd voor je hoe je foto's komen te staan ergens is dat logisch want dank je vanaf dat je jouw output of jouw noden zijn of dat dat handig is of dat dat een beetje in de weg loopt en de block templates in principe het idee van die block templates is heel krachtig bijvoorbeeld ook bij dat card block als je het juist zag in de editor als iemand een card toevoegde kreeg hij al meteen een suggestie voor een paragraph dat is bijvoorbeeld ook een block template dat we dan op die inner blocks hebben toegepast je kan die gaan locken ik kan bijvoorbeeld zeggen van oké dit mag enkel dat zijn maar dan zijn er nog wel wat bugs van de moment dat je met nest het block zit met block templates dan loopt dat locken een klein beetje fout dus je kan dan elementen die bijvoorbeeld alleen maar als perrante bepaalde container mogen hebben en er ook toch ergens anders neer gaan zwieren dus het is niet zo de voorspelbaarheid ergens toch kan ook nog altijd hele leuke dingen gaan beginnen doen en met de template locks die er voorlopig zijn ik was meteen iets geturrigieden uiteindelijk weet je niet op voorhand hoeveel paragrafen dat iemand nodig hebben in een tekst dus je kan wel een paragraph gaan toestaan maar als je echt wilt locken dan moet je te weten hoeveel paragrafen wij zouden spreken vonden allemaal best redelijk complex ook die discussies heel nobdingen ook geen antwoorden of ook niet geroepen voelen om heel hard te gaan moeien of mengen of bij te dragen maar wat daar we hebben er juist ook al zei van in die kwesten van je hebt het Gutenberg handbook van het moment dat je ergens op een issue vast loopt GitHub is eigenlijk echt wel heel goed gedocmenteerd de discussies waarom dat iets op een bepaalde manier is geïnplimenteerd of nog niet of nog in discussie ligt kan je allemaal bijlezen ook erbij soms maar ik zal even zo snel over gaan dus ja, we schipen een react gedeelte wat we gebruikt hebben is create Gutenberg dat is met één commando kan je een volledige plugin bootstrappen eigenlijk en heb je gebruik kan je gebruik maken van alle fijne dev tools zoals Babel, Workpack Lint kan je ESS gebruiken en react in WDUX het is er ook allemaal in uiteraard hebben we zoveel mogelijk probeerd de componenten van die in koor zitten van werken zelf te hergebruiken er zijn er heel veel wat toolbars en buttons de genuut meest gebruikt te worden zijn de media upload, block controls inspector controls en de rich text hebben ook gebruikt van block templates zoals veel juist zijn maar er zijn dus wat issues mee higher order component dat zijn eigenlijk wrappers rond componenten waarbij de functionaliteit eigenlijk uitbreidt custom component hebben we ook moeten maken in react context hebben we ook gebruikt de issues die we tegenkomen zijn er zijn heel stomme dingen bijvoorbeeld probes ik weet dat het concept bekend is als je iets uit react waarbij als je zo kinderen hebt van een component zoals die kaarts dan je eigenlijk probes als data die je dan wilt doorgeven van de ouder naar de kinderen maar dat kunt je niet doen met inner blocks in Gotenberg dus dan hebben we de context moeten gebruiken ook het heel stomme als je iets rendert dan kan je niet meer de tijd veranderen, dat is eigenlijk logisch want een verandering van tijd triggert opnieuw een render en dan krijg je een loop maar soms heb je dat wel nodig dus dan moesten we echt rondwerken die template locks hebben we het ook al over gehad github, daar staat heel veel in maar dat is enorm moeilijk om er iets terug te vinden dat is voor dat je dat gewoon zei waar dat was staat heel lastig is ook de console staat vol met warnings tot de meeste als je die bug hebt opstaan en je begint te denken dat dat een loop ligt en ze heel lang aan het zoeken maar het blijkt dat er heel veel issues nog zijn met Gotenberg waardoor die warnings tevoorschijn komen en heel vervelend ook als je aan de save functie durft moroelen dan reskeert je heel snel alle content te breken wat moet je doen? dat het gewoon weer gaat ja, dus dat eigenlijk de parser probeert dan in jouw save functie te beschreven te matchen met je dat inderdaad bezig is en dan gaat hij snel merken dat klopt hier niet meer en dan gaat hij dat als een corrupt blog beschouwen en als je dan een foute keuze maakt dan is de content weg ok als we algemeen een vraag zijn van is Gotenberg ready voor bespoke websites en voor baatwerk sites ik ben op voorhand heel veel gaan zoeken naar blog posts naar mensen die het al geprobeerd hadden op één na die dat niet zo heel positief was ben ik eigenlijk niet zo heel veel tegengekomen dus als er iemand een paar tips heeft stuur ze door in onze ogen ja, Gotenberg is perfect klaar om te gebruiken in bespoke sites maar hou je wel rekening met zeker nu een eerste project misschien ook iets klein schaliger aanpakken voor een eerste project dan wat wij hier nu hadden gedaan hou rekening met dat je ook voldoende tijd uit trekt er is wel een zekere leerkurven en wat zoek tijd dat je moet gaan reserveren zie dat je hoesting hebt al hier dat je er in duikt eventueel met kleine stappen met azf-blocks bijvoorbeeld gaan proberen of ga kijken hoe de andere blogs zijn opgebouwd uiteraard heel Gotenberg kan je de code op GitHub vinden kan je elk blog zelf apart gaan bestuderen maar ook alle blokken in de repo als je een blok uit de plugin uit de plugin repo download er zit heel dikkels een originele source code in maar ergens in de ritme heb ik bijna altijd wel een verwijzing gevonden naar een GitHub repo waar je dan de non-compile JavaScript en zo ook kan bekijken hoe dat ze het aanpakken een beetje een algemene take-aways ik denk dat hoe langer hoe meer dat is sowieso een algemene trend denk ik maar ik denk dat ook een beetje in een WordPress landschap is aangekomen echt veel meer focus op components components based design and development proberen blokken zo reseclerbaar mogelijk te houden herbruikbaar mogelijk designers hun plaats van pagina's te gaan tekenen denk in blokken denk in structuren dat wil niet zeggen dat je design allemaal op elkaar moet gaan trekken het is nog heel veel custom werk gaan doen maar dat wel in de structuur klopt mee daardoor ga je eigenlijk ook een betere focus op HTML en CSS leggen in mijn ogen het loont ook wel ook misschien een klein broertje, maar dat werden er net zij van die safe-functie van het moment dat je ook maar één karakter in je HTML in je safe-functie verandert is je content weg dus zeker van het moment dat je de editors al in de admin bezig zijn moet je eigenlijk al wel al zeker zijn dat je HTML goed is het is solide genoeg is dat je ook alle classes hebt die je nodig gaat hebben om alles deftig te kunnen gaan stylen denk op voorhand begin met een plan uit te bouwen en dat plan helpt verdegelijke gestructureerde HTML CSS dan vooral de styling in de editor toch wat meer kronkelsvraag heb ik toch wel de indruk en ja als je geen zin hebt om zelf echt in de ruimte van react en consorten te duiken zoekt uw eigen goede JavaScript developer tot op zekere hoogte denk ik dat we er allemaal ook nog wel geraken en bedoel je kan ook leren van de code er is ook redelijk veel info in de handbox maar van het moment dat je iets complexer nodig hebt zoals er van die sections met die subnavigatie zijn er componenten die data moeten gaan doorgeven aan elkaar of je card dat aan zijn format moet gaan doorgeven aan een image dan kom je toch wel rap in een iets funkier JavaScript-wereld terecht voilà, dat was het ongeveer eerst dan nog een open links op links naar de handbook maar ook naar een paar react-cursus voor wie dat geïnteresseerd is vooral WS-boss en Maximilian Schwarzmuller dat zijn zowel de favorieten heb ik de indruk Starter teams er is een Gutenberg Starter team maar eigenlijk 2019 is ook wel een heel goeie team om in te gaan spieken of eventueel allemaal als basis te gebruiken in je eigen team eruit te vorken of manager team te werken dus dat is het begin-start van de create-cuton-blok ik heb ook de indruk dat de meeste blokplugins die ik heb gedownhoud eigenlijk ook allemaal gewoon create-cuton-blok gebruikt hebben dus dat is echt wel een beetje een kickstart om vertrokken te geraken plugins, ACF-blocks en een plugin-bloklaap die heb ik zelf nog niet geprobeerd maar al wat overgehoord en ja, cursus-blok-development ene die er als vandaag ook ging een blokprinsen, maar die was verzetgelukkig en dan ja, Zag Gordon heeft die er ook wel redelijk ingestort en het is afgelopen zegt-ie