 Welcome to the Headless Block Editor. Now it's rapidly becoming much easier to implement a block bridge from the back-end editor, from the block editor, into headless applications. And in fact anything other than the block editor is actually a compromise too far into headless applications. So I'm going to say this in about 40 minutes or so. So let's have a look at the evidence together. Let's see some of those changes, some of those opportunities that we're seeing in this space. And let's see if these statements are valid and if we think that these hold true. So what I'd like to do is I'm going to fly over the what very quickly just to make sure that we're aligned in terms of what we're talking about here, the definitions essentially. Let's also look into the why, why we should be combining the block editor into our headless applications. And then we'll have a deeper dive into the how, and we're not going to look so much at the how to, but more some of the principles that we've implemented to create the block editor into headless applications. So very briefly, let me introduce myself. My name is Sean Blakely. I'm the technical director at AmericanEagle.com. We are a 800 strong agency, consultancy essentially. We work with large enterprise organisations on large digital sort of transformation projects across a number of different platforms, site core and a number of others. But WordPress is often at the beating heart of the solutions that we implement for these for these organisations. So let me take you back for a moment. Let me take you back to a kind of pre block editor. So the experience that we had within the classic editor as we called it at the time TinyMCE. Now what we could do here is we could kind of change the fonts, the type, the typography. We could add images and we could also add short codes, which were kind of an abstraction kind of placeholders for code. We could drop into that text area, this kind of single text area. But those were essentially the limitations of our editing experience within WordPress at the time. Now fast forward to today and what we have is a true visual CMS. WordPress has become a true visual CMS where content creators, where editorial teams can create this extraordinary content, this extraordinary flexibility to create these truly unique interfaces for their end users. So we really have propelled WordPress into this extraordinary tool over a relatively short period of time. Now the alternative for headless applications and this is actually indicative of many headless CMSs is this more abstracted kind of interface. So you've got something more akin to a form where you're kind of filling in these input fields, you're filling in information. It's not necessarily clear what the consequences are of those decisions that you're making in the back end. So maybe you've got a tab open as a preview of the information of the output of those decisions. And maybe you've got another tab open with that back end and you're kind of switching between the two. But this is definitely not an ideal experience for those content creators. And so why should we prioritize the block editor? Well, it's really that thinking about that visual experience, being able to interact and create those unique interfaces in the way that we were just looking at. And the fact that the block editor is supported by core. So those updates, those security patches, those accessibility updates, all of those really important updates that we get from being close to core, close to WordPress core. Now when we think about headless applications and just ensuring that we're kind of thinking about this in the same way. So headless decoupled applications. It's really in its simplest terms where we're removing the PHP templating engine. So we're kind of removing the front of the site or the kind of architecture. Now we might replace it like for like. So we might implement a React front end application powering our website to present to our end users. But it might be that we're not actually powering a website tool. And it might be that we're distributing information across a multitude of different services. So in that model we're really using WordPress as a data center that's then distributing to this sort of omnichannel receiving sort of set of services that WordPress is interacting with. And so there are a number of reasons why we should stop and consider whether headless is the right kind of approach for some of the problems that we're presented with. So some of the things that we need to be mindful of is that the total cost of ownership tends to be higher with a headless implementation. You've got your back end application. You've also often got your front end application on a separate hosting platform. So those are two kind of infrastructures that you've got to think about. It might be that you can put a next sorry a node server onto the same hosting environment. But then of course what you're doing is adding complexity and that complexity comes into play for the life cycle of this platform. So that kind of support and maintenance cycle becomes much more complicated when you have a lot of custom code, a lot of custom solutions into your platform. And then there are a number of challenges around sort of governance and other things that we need to be mindful of. And of course we're removing one of the key tenants of WordPress which is that notion of plug-in and play, that ability to look across the vast array of plug-ins that we have at our disposal and know that it's going to work within our environment. Well we've removed that ability with headless and we need to do that with responsibility. We need to be very clear and very transparent about removing one of those core tenants of WordPress. But there are also some compelling reasons why we should look at headless. So headless allows us to create custom components in our front end application which are a kind of dedicated interface to the custom needs of that application. It also enables us to be more secure by design so often we can sort of limit the surface area for attack for security issues. We can limit the number of database calls by designing in such a way that we're sort of hydrating from other sources or indeed we're sort of statically generated content. And there are some great scalability sort of benefits and also integration, integrating with other tools, integrating with other services. It gives us much more flexibility to share components across a design system, across a larger ecosystem, but then also to be integrating with a variety of different services around that ecosystem. So why is it important to bring these two approaches to our sort of technical challenges together? Why is it important to bring the block editor into headless applications? And the answer is simple, that it's really about giving all of the stakeholders, the protagonists of creating a successful project, the ability and the very best ability to deliver that success. So if we think about kind of three key roles, if we think about our engineers, well we want to give our engineers the flexibility, the freedom to make technical choices, technical decisions to have the ability to make the right technical choices. But equally we want to make sure that our content teams, our editorial teams have got that visual CMS, that ability to create that rich, engaging content that the visual CMS gives them. But then equally we want end users to be able to have those unique interfaces, those custom journeys, custom implementations within the front end application that really allows them to have that unique experience. That custom experience that's been designed for the end user. But kind of sitting above that as an umbrella is essentially the success that this delivers for our clients as the agency partner forming long term partnerships, partnerships for the longevity of those partnerships. We really need to think beyond just the successful delivery of a platform, that's really just a phase in the building of a strong partnership. We also need to be mindful of the successful adoption of that platform within the organisation and that will often be by the content team, maybe the marketing team, maybe the editorial team or maybe all of those. But successful adoption within the organisation is critical to the success measures of that organisation and equally successful usage by the end users. Can they achieve their goals within the application? Can they achieve those conversions that they're looking to do to get what they need from the application? And we really do need to think about this holistic whole. What we like to call internally is the tux, which is the total user experience. Thinking about that holistic whole, thinking about these different experiences of the same application, thinking about the different needs of these different groups because that's what delivers us true success. So let's look at how we can get there. Let's look at how we can kind of take the block editor and start to integrate it into our headless applications. Now, it's kind of deceptively simple, the concept that we need to implement. So we've got the block editor, we've got these kind of discrete blocks within the block editor that we can extract. And so we need to have that kind of bridging mechanism where we can move the data out of the back end application into our front end application, map it to our components within the front end application, and then of course display it to our end users, distribute it around our ecosystem or whatever that kind of end goal is. But that is deceptively simple. There are a huge number of challenges and a lot of heavy lifting that we need to do to make that a possibility. And so until recently, there's really only been two key options that we've had. So we've had static HTML where we can kind of extract that static HTML. On the other hand, we've had GraphQL, extracting via GraphQL. So looking at static HTML, what we could do was extract either via GraphQL or via the REST API. We could extract the content, the rendered content from the block editor, and we'd extract it as one string. So we'd get this great big blob, this sort of single string. We could then pull that into our application and all of that parsing, all of that heavy lifting would need to happen in the front end application. So switching out the links, for example, from pointing in the back end application to now be pointing in the front end application. Things like images maybe, if we're using Next.js, we might want to switch out images from our back end platform and switch them out for Next.js images in our front end application. An all manner of other changes, but definitely with this approach, we don't really benefit from, we don't really benefit from React and from those native components. And so the good thing is it's easy, it's straightforward, it's flexible, but there are a lot of drawbacks in terms of we can only work with static content. We don't really have that. It's not really scalable in terms of performance and it doesn't really give us the flexibility that we need. We're also pulling data across via data attributes within HTML and HTML is notoriously fickle in terms of changing its structure. We need to try and match to patterns that exist in that HTML and we're using data attributes essentially as an API where we're trying to push data across via the HTML blob that's in that string. And it's really just not very robust. So we did have another option and this was GraphQL. So with GraphQL we can pluck information out of our graph, out of the graph that's created for our site. So we can pluck very specific information and really just get back the information that we want. And just to remind ourselves of those two approaches, the difference of GraphQL and the REST API. So with GraphQL it's a declarative query so we can, as the requester, define what we want from the payload that we want to get back. And as long as we've got the right permissions, as long as we can access that data, then we'll get back that payload. Now that's as opposed to the REST API which is an implicit query. So this is where the server decides what payload we get back. Now there's often parameters, settings that we can change on that endpoint that will change the payload that's returned to us. But again, the server controls those parameters. The server controls what impact they'll have on the payload that's returned. So this is what we can extract via GraphQL. This is using a community-supported plugin, WP GraphQL Gutenberg. And this exposes a new field for us. So it's the blocks JSON field. And again, as you'll see, this is a single field. So we've got a big blob of data here, but it's more structured data. So this is data that we can start to inspect. We can start to pull in and structure into our front-end applications. So there are a number of benefits to this. It's giving us access to blocks as opposed to strings. So we do have that discrete blocks. It's much more structured data than within a string of HTML. But again, there are drawbacks with this approach. So we can only get globally-scoped blocks, so blocks that are scoped to pages. We can also, we face some performance issues here in terms of getting this data back. And we don't get a full set of the attributes. So we've got a kind of partial information list. So again, there are drawbacks of this approach. Now, unfortunately, the kind of challenges go on. So as if this wasn't enough. We've got a number of other challenges that we need to be mindful of. Now, the first and probably the most impactful is that for all intents and purposes, the block editor until very recently was invisible. And what I mean by that is that the block editor sits as a JavaScript application, so it's kind of sat outside of the standard WordPress stack, our kind of PHP stack. And so what's happening within the block editor isn't available to WordPress. WordPress can't see it. The CLI, the REST API, GraphQL, it can't see what's happening within the block editor. What's happening in the block editor is completely separate and outside of WordPress. Now that creates huge problems in terms of being able to access that information. And that plug-in that we were talking about a moment ago, that community-supported plug-in, well, Gutenberg plug-in. Well, it had an ingenious workaround for this where there's a button in the admin, in the back end of WordPress. You can click on that button. It actually opens a hidden iframe and it opens a page and it extracts the DOM, the client-side DOM. It extracts the block registry and then dumps it into the options table. So now, as a kind of ingenious workaround, we've got these blocks become accessible to us on the server side. Now, it's not perfect, it's not robust, but it's an ingenious workaround to this problem of the invisibility that the block editor was prior to this. And then this concept of contracts. So this is quite prevalent in WordPress, that we establish these contracts. So you think of kind of two entities, pieces of software, or even parts of the same platform. Well, there's a set of rules, there's a set of agreed structure that these entities are aware of, this kind of shared schema, essentially, that then they can communicate and they can interact and they can manipulate that entity. So within WordPress, if we think about the way that we register custom post types or register taxonomies, those registries are essentially contracts. So we've got those fields, we've got those very clear declarations and then the rest of the WordPress platform can interact with that. So think about the REST API, the permalinks, plugins, they can all be aware and interact with these registries, with these contracts that we've created within WordPress. So one of the other challenges and we've kind of seen this a wee bit over the last few minutes, is this great big blob, this kind of non-discrete data. We've got this great big blob of hards we need to process. And if we think about some of the other kind of challenges that we've faced, one of the really key ones is that trying to keep up, and if you're trying to support core WordPress, trying to keep up with the rapid changes that are happening within Gutenberg, the rapid iterations, be it new blocks, the deprecation of blocks, the new attributes that are being introduced, it's incredibly challenging to stay in sync with core Gutenberg. And in fact for many agencies it's been a step too far, and what they've done is created their own block library, their own sort of group of blocks in Storybook or something similar and then exposed those to the block editor, exposed those to their front-end application. And so avoided needing to try and keep that synced up and process with core Gutenberg. And for some individuals and for some agencies, it's really they've not seen the value in connecting to the block editor and so they're using something like ACF or similar and creating something more akin to that non-visual interface. There's something a bit more like we saw a moment ago where we've got something more akin to a form is the kind of interface for the editorial team. So in spite of all these challenges and there are many that we need to overcome there's also been huge success stories within WordPress, huge success stories within the headless WordPress. Now some of these we can't talk about publicly, they're not in the public domain, but some are and some we can talk about as these huge successful implementations of headless WordPress. And one I'd like to talk to you about today is Wicom.com. Now this is a site that we created and went live with in Easter of 2023 and this is a I think it's the largest in-person auction company in the world and they run car auctions, they sell thousands of cars, tens of thousands of cars each year across multiple different in-person auctions across the United States and they do this at incredible scale. They have something in the region of a quarter of a million lots, lots of cars, essentially cars that they're selling at those auctions and they have something in the region of eight to nine million digital assets that they're kind of maintaining around their ecosystem and they're often getting in excess of 20 million views a month that they're having to maintain across this platform. So as you can see there's kind of a huge scale that we need to be mindful of here and there's a huge ecosystem that we need to be connecting and ensuring that we are enabling that kind of scale and performance at that scale. So this is what we created in terms of the architecture for Wicom. So you'll see WordPress at the kind of beating heart at the centre of our architecture but actually there's something before WordPress, there's something that's kind of coming in and that's Salesforce. So data is actually coming in from the source into WordPress and we'll talk about that more in a moment. But then from WordPress we're kind of coming into the block editor we're then pushing that data out into our front-end application we're triggering the build for us it's a next.js application. We're also using WordPress to build our indices for Algolia and so this is then being made available to the front-end application we're kind of pushing that data through. Cloudinary is managing our eight, nine million digital assets videos, images and so on. So that's our dam essentially and that's connecting via Salesforce into this platform into the application. And then finally we're also exposing that data via a content API and exposing that to a multitude of different services around the kind of the Wicom ecosystem that's then being ingested and consumed elsewhere. And that's a huge platform that we've implemented. And that kind of bridges that we've built that essentially we've got Salesforce we've then got this data bridge that we've kind of built from Salesforce into WordPress and then conversely from WordPress we've got this block bridge that we've built into this into our front-end application. So we're kind of taking data from any where WordPress is absolutely critical, WordPress is our kind of processing engine but there's also a lot of other things that are happening kind of around WordPress around this kind of larger architecture. And so this sort of portion of as we call it the data bridge where what the client we're looking for was enabling the team to continue to use Salesforce as an inventory system essentially. So their quarter of a million lots would be maintained within Salesforce. That would be their kind of interface. And what Wicom wanted was to be able to make those changes within Salesforce but for those to automatically push through and generate a block driven page within WordPress. So they wanted to programmatically pull that Salesforce data in and construct it into a block driven page. But they were also looking to be able to have the editorial team to add narrative to that page to really add the story of that lot into the page. So we had this interesting challenge where we had to have both programmatic content and editorial content that was shared within the same entity that was really sort of shared within that same lot page. So the concept that we came up with was this content slot, we called them content slots. So we would have these Salesforce blocks that would keep their connection with Salesforce. That would be a persistent connection but the editorial team could then put their content into these dedicated content slots and we created this dual saving, this kind of concept of dual saving where that Salesforce connection would persist and so if edits were made in Salesforce and we were seeing very rapid edits every few seconds a lot would be changing they're very quick to update their data. Well that would come in but it would the editorial content that's been created by the content team would still be saved. It wouldn't be overwritten. They are saved as separate entities. We've got this kind of dual saving process that's happening both for our content but also our editorial content. So let's have a look in a little more detail about that how we did that connection and particularly around this kind of data bridge how we approached that. So this is an example of the data coming through the data feed. This is a JSON data blob that we're receiving. So Salesforce, the team, the inventory team within Salesforce will be making updates to that lot. The kind of equivalent of publishing triggering an event within WordPress. Well that event trigger then pushes that payload to a webhook within WordPress that we created, an endpoint essentially. And so when that information is received into WordPress it's received into or distributed into these kind of pre-baked templates these programmatically generated templates that we've created where within Salesforce they can dictate which template they want to use and so that will then be distributed into our back-end application into WordPress and as you may be able to see we declare and we call classes like core paragraphs and core columns and so on well that's actually mapping to a dedicated plugin that we created, the block builder. Now this plugin maps to all of the core blocks and so we've got this ability to inject content into these programmatic blocks and we can create these blocks on the fly. And so it really enables us to programmatically generate an entire block driven page and push that data into the relevant block. Now there were one or two gaps, things that we need to be mindful of. Dynamic blocks are very hard to maintain here, they're quite an abstraction and things like the YouTube embed was quite challenging with some of the sort of DOM requirements but it was almost universal, we've got this kind of coverage of all of the core blocks that we can now programmatically generate and generate that content into Gutenberg because this is what the editorial team sees, so if the editorial team go into Gutenberg they will see the content that was really just Jason coming from Salesforce. Well now it's been transformed into a visually enriched page that is fully Gutenberg and you can probably see some of these blocks there, some of the structure that's been programmatically created to create that lock page and this is where they can optionally add new content, add narrative, add editorial knowing that if the lock is changed in Salesforce it won't be overwritten, that information will persist and so as we're trying to sort of extract that data, so remembering that so far like everything is happening before the block editor so this is Salesforce kind of exposing that information we're pulling it into the block editor we've now programmatically generated that page, well for the first time we're now exposing it so we're just kind of about to go into the front end application so this is that blocks Jason field, we saw it a little earlier so it's that great big field it's that single field of data but it is fairly structured so we're going to kind of pull this into our front end application and that's exactly what we do here so we've got this big switch statement, this is where we're pivoting on the name so core paragraphs, core heading so on we pivot on that and so we've got this great big switch statement sort of enabling us to distribute and so to map to those native components all of our core blocks and what we then do is go into this big processing we use atomic designs so this is actually a molecule that we're going into but a big processing kind of phase where we're taking that opinionated data from the block editor and really sanitising it we're parsing it, changing it and trying to reconstruct it into something which is then fed into our native component so a huge amount of mapping essentially, a huge amount of processing that then results in this which is a simple native component a simple component in our front end application now this component can be now repurposed across the ecosystem can be used in any manner of different platforms in different parts but different software different entities within our ecosystem it really is truly independent now of its source where it started its kind of life cycle as a block within the block editor and so for the end user they've got this seamless experience where they have no idea that actually this has been fully automated from the changes that have been made in the Salesforce within the inventory system there really hasn't needed to be any human interaction or intervention at all that that data has flowed right out of Salesforce has been processed within WordPress before then generating pages and locked pages that are powered by the block editor it's then in turn exposed that data to the front end application the front end application has distributed that to native components and then those pages have been built within the front end application with those native components no all-automated no interaction needed there and so really enabling us to do that at huge scale across huge numbers and so as a quick shout out to the huge success of this project so many thanks to Carmen E. Colettino and to John Jeeves who are absolutely instrumental in ensuring that Meekam was the huge success that it's been and in terms of across the entire platform and so huge success stories like Meekam provide us as a community as a group with new opportunities they often accelerate that change they often sort of break new ground and we as a community kind of benefit as a whole from those changes that are implemented and so the idea of the block bridge and the potential of introducing a standard a standardisation of that block bridge is really coming into play that it's really beginning to look possible that we will be able to implement a standard that we can all adhere to and there's been a huge upswell of tools in very recent times we are not talking about in recent years here we're talking and in some terms we're not even talking about in recent months we're talking about weeks in terms of the extraordinary momentum that we're seeing in this field the extraordinary change that we're witnessing it really is a moment of huge change within this field but before we talk about that let me rewind just for a second because there was a critical event there was a kind of critical enabler that has really been the catalyst for all of this change and that's something called the block.json file was introduced to sort of enable visibility of blocks within the block directory but actually it's had a huge impact in terms of the block editor because it can be treated as a special metafile you can drop into your blocks folder and it becomes a single source of truth where you can declare your attributes, declare your styles declare all manner of other things that are kind of the default declarations for your block and that becomes available to both PHP and to JavaScript do you remember we were talking a little earlier about Gutenberg being invisible well no longer because the block.json becomes that single source of truth where we can register blocks on the client side we can then also register them on the server side we've got that kind of dual registration both pulling from that single source of truth and that blocks.json file so this really has been like turning the lights on for the block editor like suddenly it's no longer invisible we can see these things and indeed we can even go back and retrospectively register client side only blocks on the server side so we can even go back and bring those into the view into the visibility of the platform as a whole so let's talk about some of these extraordinary tools that are coming that are becoming available to us as a community so the first one I'd like to talk about is WP Engine it's the Gutenberg React bridge now this is essentially a two-part sort of tool so it's the GraphQL content blocks that's an extension for GraphQL and then we've also got an MPM package blocks that we'll look at in a moment as well so what this content blocks GraphQL extension does is it exposes blocks as we saw kind of earlier within GraphQL but as you can see now it's these discrete fields so we've got this very different breakdown of this content and we can start to inspect these individual attributes we can start interacting with this data in a completely different way than we've been able to before and it really takes a lot of that heavy lifting that parsing sanitisation all of that mapping that we were doing in our front end application will it bring some of that heavy lifting into the back end and it really enables us to inspect our data and understand our blocks in a much deeper way incidentally nested blocks was quite a challenge previously where we wouldn't necessarily know how deep the nesting went in terms of our nested blocks so to traverse up and down what WP Engine have come up with a genius solve for that where they flattened out the list of blocks so they've added a block ID but also a parental ID so you've got this sort of flat list but then you can stitch them back up together so you can kind of reconstruct the hierarchy and that's exactly what the blocks MPM package does it actually has a flat list hierarchical function where you can kind of reconstruct your hierarchy you can reconstruct that hierarchy within the front end application so the blocks MPM package is a kind of a pinionated way of being able to discover blocks be able to see and sort of construct and map this data into custom components into your native components on the front end application now they are part of a kind of headless offering from WP Engine which is the Faust.js tool now they're not dependencies you can use them independently you can use them independently of each other they don't have to come together but they are part of this larger platform Faust.js which offers things like template hierarchy and your front end application and sort of previews and other solves of this kind of the challenges that we have implementing headless applications and then another tool that has come out has come out of beta really in the last few weeks I think sort of three or four weeks or so which is the the blocks data API from VIP now this is a new endpoint on the rest API forward slash blocks and what it does is it exposes block data to us so the kind of content in a very discreet way again a way that we can assume rather than trying to extract the rendered content or the big blob of GraphQL the kind of blocks Jasonfield that we had prior well now again we've got this discreet data this discreet breakdown we've got much more flexibility about how we can utilise this data how we can bring this into our application again more heavy lifting happening in the back end now so softening the load on the front end one thing we have been that we are aware of is that at the moment it is just encapsulated to the content so we don't get the header and we don't get the footer and so if we're building static pages if we need the header we need the footer we're either going to have to build that logic into our front end application or extend our endpoint extend that data but this is a huge step beyond where we've been previously and the challenges that we have faced previously and I would also mention as if these tools aren't sort of exciting enough there's also the Head Start WP from TenUp and again this was released about a month or so ago and this is a headless starter kit this is kind of a cross that straddles again that kind of block bridge this concept of the block bridge it's an opinionated it's a fairly thin kind of layer that sits on top of Next.js it's got an opinionated discovery discoverability and ability and way of creating, generating native components it only works with the REST API it's very opinionated about not supporting GraphQL but this is a really exciting platform it's a really exciting sort of option and certainly one that we will be looking at in greater detail and then the final thing that I would mention as well is that a recent white paper from Human Made talks about utilizing GraphQL and the REST API in the same projects so really kind of utilizing both either to play to their strengths and this is a fascinating idea it's not one that we've considered before to actually utilize them both within the same project but certainly something that we will be considering at a future day so I think it's worth noting that there is, there's kind of a natural tension here that the core WordPress team the core REST API team they're not driven by headless it's not part of their success measures and equally GraphQL isn't part of core it doesn't form part of core WordPress so we need to be mindful though there's a kind of natural tension here their focus isn't within WordPress isn't within headless WordPress it's not within these headless tools kind of sit outside of the core WordPress project and I think what's also becoming clear is just the sheer amount of change that's happening within this space that it feels like the bar of entry is lowering that the cost the implementation costs the development costs are lowering and then also one of the critical things that we always need to consider the support and maintenance of these large headless projects well it feels like that's coming down as well because we're beginning to have these tools that the community are supporting we're beginning to have the first steps into that standardisation that we're starting to see tools that we can reuse and repurpose and I think it's really exciting as we look forward as to where we're going maybe we'll bring in support for dynamic blocks they're quite complexity there they're quite abstracted but maybe that will be on a future sort of roadmap but another interesting fascinating possibility is putting a post method on that REST API so what that would mean is that we could push blocks into WordPress we could generate content from outside into WordPress and remember the block builder plugin that we were looking at a few minutes ago well that would kind of be on the receiving end of our data where it reconstructed and programmatically generate that block driven page so that's really exciting for big migrations if you work with other migrating from other platforms from other services that could be a hugely powerful tool in the way that we implement our platforms, implement our technology and then things like shared components where as we've seen at the moment we've got Gutenberg blocks that we're building but then we're also building these native components well is there the opportunity to share these components can we kind of build one component that can be shared across these entities so that's definitely an exciting possibility and then the theme JSON that has the potential to become the kind of source of truth for style for the look for the kind of structure of our site and kind of style guides well could that also be shared could that be the source of truth both in terms of our front end application and our back end in terms of the block editor within WordPress so there's huge amounts of exciting change that we are we are likely to see as we're kind of exploring further in this area and projecting ourselves even further forward maybe Gutenberg, maybe the block editor maybe other methodologies for creating content will start to standardise into something like the block protocol so we kind of abstract away all of the differences within these methodologies for creating content that they are just opinionated layers that sit on top of this block protocol a kind of block standard now the beauty of that of course is that all of your receiving entities all of your receiving services well they only need to map into a single service into the block protocol and then it really doesn't matter what you've utilised to create that content it's really only just mapping to that single block protocol so that would be an extraordinary standard if we were to achieve that as an industry as a community would be an incredible achievement so I think as we can see there are lots of challenges remaining there are lots of big challenges that we face together but we've also come an extraordinarily long way the distance that we've travelled in terms of addressing some of these major challenges some real innovation and some exciting things and momentum that's building into this this kind of space and I think as long as we maintain that focus on the tux on the total user experience as long as we're kind of thinking about that holistic usage of the platform then I think we're destined to achieve huge success here and I think there is the possibility of WordPress becoming the true sort of de facto visual headless CMS which I think propels us into an extraordinarily exciting space so coming back to that quote that we had sort of right at the top of this conversation is you know is it becoming easier to implement a block bridge well I think it definitely is and we've seen it's becoming increasingly easier I wouldn't say it's easy I think there's lots of challenges remaining and there's lots of challenges that we need to take on to implement these platforms but it's undoubtedly becoming easier and we've got a multitude of opportunities now that we simply didn't have weeks or certainly sort of in months ago and then to the second point that anything other than the block editor is a compromise too far I think it is certainly when we talk to enterprise organisations when they talk about wanting to create rich content rich user experiences they want that visual experience they want that visual CMS as their interface to create those those interfaces and so I think as WordPress as a community with this opportunity to become this de facto visual headless CMS opportunity to keep that within open source to ensure that this technology is available to all and is available as an open source tool and I think that's incredibly powerful opportunity because it ensures that WordPress will continue to have a hugely positive impact not just on technologies but I think in our community as a whole and well beyond thank you okay I actually have a question the question that I have it's going to kind of go they kind of intertwine but earlier you were talking about the scalability of using React or HTML so like in a situation where you're using React or like JavaScript HTML, CSS and you're individually using the I would say an editor to to get through to the assignment why is it harder to move data or like I would say just allocate data I guess along the website, why would it be more difficult to scale that versus using something like WordPress or a Shopify so if we think about we're really extracting the data away from the CSS from the JavaScript from any of those the mechanisms for our styling for the kind of interface because what we're doing is having to extract just the data so from the block editor we need to remove all those extraneous kind of settings and really just narrow down to just the data just that pure data and pull it into our front end application or indeed another service wherever we're pulling it into but the challenge is then we need to reconstruct all of those all of the CSS settings or all of the JavaScript functionality that we had so one that often catches us we've had to be very mindful of is something as simple as a line where you've got left align centre right I mean it's so simple but it's almost ubiquitous all of the blocks everything's got kind of a line concept in and so we've got to reconstruct that within our front end application and we've got to not just implement that logic we've got to create that CSS class if that's how we're going to implement it and then we need to make sure that we've got the CSS corresponding with that class and we've got the right declaration that's attached to that attribute and so we're really like there's a huge amount of depth to go into to really stitch together those functions and the align one is a really interesting one because as soon as a content creator goes in and clicks on the align and sort of aligns their text but then goes into their front end application and maybe for whatever reason that hasn't quite been mapped they'll throw their arms up and say it's broken the whole kind of implementation is broken and so this is the other challenge the smallest details make a huge impact on those content creators and so we need to be so careful to map all of these different features and it is a huge, huge undertaking one more question thank you so what would you say is the importance of a UI or UX designer then when it comes to working hand in hand with WordPress how would you implement having that kind of knowledge and then bringing it into also the functionality of the website so having a the sort of UX in particular I think is absolutely essential we work in creating design systems so we try and be kind of component driven which sometimes necessitates an education journey with our clients where rather than thinking about kind of template driven design where they're thinking about the home page then the about page and so on we get them more into the paradigm of thinking about these discrete blocks these pieces of Lego that they can then repurpose and reuse across their site that they can build their narrative by utilising these different entities these different blocks that can be challenging because at times they're not sure where they've maybe previously been used to a high fidelity home page with every pixel considered and every loromips and text perfectly lined and everything is across everything corresponds to two lines so everything looks perfect well it's what we often call utopian design that doesn't exist as soon as you put your real content in, as soon as you put your real images in well you're going to start to see this creaking you're going to start to see the outliers where maybe the UX wasn't quite right because we've gone to three lines of text or one line of text or what we often see is like three lines on one box and one line on the other and we've got to try and make that work as an experience where it feels deliberate and it feels consistent and so this is where it's absolutely critical that we get our UX and design involved but interestingly we are increasingly trying to bring our designers bring our UX into WordPress we're trying to get them out of Figma we're trying to get them out of their comfort zone their kind of software we're trying to bring them into WordPress and the way that we can do that is through things like block patterns where very quickly they can start prototyping UI components they can use again that term Lego like they can use the baseline Lego to start to very quickly prototype block patterns within WordPress and of course these are prototype in the software that we're actually going to be utilizing the platform that we're utilizing and I think that's incredibly powerful and I'm increasingly on a mission to try and bring UX bring designers into the platform that we're creating because I think that's an incredibly powerful paradigm and it really kind of brings our brings our worlds together I really really really appreciate the knowledge that you guys just gave thank you so much it was a wonderful speech thank you