 To Birmingham, we are glad you're all here and you are in the production studio. So, hi. We are here to learn about how Gutenberg uses the developer evaluation, not just for blocks. So, I hope you're in the right place to hear Kyle Johnson, who is right here. He's making to us. Kyle is the senior software developer for GWP, is a contributor to the WordPress core, and he speaks several wordpamps and various other open source conferences. So, he's also a collector of hobbies, a musician, makes furniture, picks locks, reads, he wants to be an author, does that mean you are an author or you just one day aspire to be an author? I want to be a book author specifically. I want to be a book author. All right, stuff online, that just feels not permanent. Great. Well, thank you, Kyle. We're looking forward to hearing from you. Oh, okay. Hey. Hello. My name is Kyle Johnson. I did not expect as many of you to be in here as there is today. So, thank you for being here. I know it's early. Hopefully this goes well. Yeah, so when we're talking about Gutenberg as a development foundation, more than just a content editor for WordPress, I was told I can only put logos and stuff on the opening slide. So, I went a little NASCAR with it. I won't forgive, which is under the umbrella of StellarWP, which is a brand owned by Liquid Web. It's a little complicated, so I have to put it there. So, I remember the structure. Give to operates as an independent small team, thankfully, but I also contribute to WordPress core, plug into the directory, speak at wordcamps, WPCI contributor. You're probably familiar with my work in some way. Ninja Forms and WP Caldera Forms. U.S. to fill a WP with real mess in Gutenberg are some of my bigger contributions. So, yeah, if you recognize any of those things, that's partly my work. So, I'm not just a random person up here. It feels like it at times. So, yeah, Gutenberg as a development foundation. So, we're familiar with the WordPress block editor as developers in WordPress. I'm sure you've used it. If not, the general idea is that content is broken up into this concept called blocks, similar to Lego, so they can be stacked or rearranged and moved around. Previously, in WordPress, you would have just a text area, just a single block of code, or content, if you will, and then copy and paste, move things around. It's just one piece of content. This allows us to fragment our content into small pieces that can be rearranged or reused in different ways. For example, WordPress uses it to output on the front end using a theme. You can also do headless WordPress to pull it in, and then with that block content, rearrange it if you need to. If you want to do, like, a stepped content, inject ads or other dynamic content, it allows you to play with it as data and not just a single data point. So, the block editor in WordPress is Gutenberg, but Gutenberg is not the block editor. Square is a rectangle, but a rectangle is not a square kind of thing. Gutenberg itself is actually a package built under the WordPress umbrella with a lot of automatic developers, and the idea is that it can be used in other places other than just WordPress. Previously, WordPress code was written for WordPress. We're written in a very specific way, the WordPress way. If you're familiar with that phrasing, their intention here was to do something different, build it outside of WordPress and bring it in to WordPress, and there's still some crossover there, but on the whole, it's made separately. So, the block editor is becoming the new interface for WordPress content management, and as I said, it can be used in different places as a standalone JavaScript application. For example, this is the Drupal Gutenberg editor. So, it's moving beyond WordPress rather quickly. It looks like the WordPress editor, the logo's different, the sidebar's styled a little bit differently, and it works a little differently in terms of some of the features they have, like Drupal has this revision log message thing that's native to Drupal. If you're not familiar, Drupal is another popular CMS written in PHP open source, very different like niche compared to WordPress, but they're using it also to bring it in in order to elevate their content in a way that can be more dynamically manipulated. So, like I said, it looks a lot like the one we have in WordPress. This is a package for Laravel called LaraBerg, which is Gutenberg for Laravel. This allows you to create your own custom application using Laravel framework and then drop in a Gutenberg editor kind of like the Gutenberg anywhere that WordPress is doing. If you go on the WordPress.org website and leave a comment, you'll notice it's no longer just a text area. They're slowly moving it to this Gutenberg anywhere isolated block editor system. We're also seeing it in October CMS, which is a CMS written using Laravel, and they're implementing the LaraBerg package into their content management system in order to introduce blocks into that system also. So standalone JavaScript application has an interface for data. It doesn't matter what platform it's on. And over the past nine months, I've been reusing Gutenberg to build the new donation form builder for GiveWP. It is a standalone block editor. It does run in WordPress, but it doesn't have to. And it's using the components of Gutenberg like the block list in here. It's got the inspector and the text controls and select controls and a lot of the button components. The shared components are working together here. But as much as this looks like the WordPress block editor, but with green instead of black on white or white on black, this is actually built in with components from the ground up. So a very generalized example of how WordPress implements the block editor is represented here. You see the individual components. Inside of all that, there's a block list component, which is very core to Gutenberg as a concept. This is the repeater for all the different blocks wrapped inside this block list component that you can use outside. But this is generally the context deep within which it's used. Observe typing is a higher order component around that. Writing flow is the same thing. And then block tools is a higher order component above the blocks that allows it to interact with the blocks using that bar of all the buttons and controls and things. For my purposes, for our purposes here, two of the important ones are block tools and block list. If you're creating a block editor for something other than just written content, things like observe typing and writing flow aren't necessarily as important. The benefits of observe typing and writing flow is you can do things like select text across multiple blocks. Or it will automatically, on the keystroke of enter, create a new paragraph block for you. So those are all content specific. And if you're using Gutenberg not as a content editor, then those aren't necessary for your implementation. So a block editor can be boiled down even farther to a much simpler implementation, where the block list is kind of the core of that application. One of the big controversies around Gutenberg has been the way it stores data in HTML comments. A lot of questions were raised. If we're separating the data dynamically from the content, why would we still store it in HTML and use HTML comments in this wacky way to encode the data into the content as opposed to just storing JSON or another format of data serialized using PHP? There are a couple reasons why they did that. One, it allows for backwards compatibility. By storing the block data in HTML comments, the block editor can work with existing content that was created using the classic editor and vice versa. And so because it's just HTML, you can render on a page. You can open it up in the block editor and it parses the blocks. Open up in the classic editor and it's still just HTML. It's a backwards compatible format. That's very important to WordPress as an ecosystem and not want to introduce an overly breaking change. That's absolutely necessary. Next, it fails gracefully if a block no longer exists. So in contrast to short codes, whenever a plugin introduces a short code for use and you add that short code to the page and then disable that plugin, that short code renders as raw text on the page in the square brackets. You lose the dynamic rendering or the content replacement of that plugin's functionality. But with blocks, either the existing HTML that was rendered by that block plugin remains. Or if it's a dynamic one, it's an HTML comment, which then just doesn't render. So the benefit of the HTML comment is you can render it but not get the artifact of that plugin no longer dynamically replacing that content. It also makes it easy to parse the blocks. HTML provides a clear, the comments provide a clear delimiter for where one block begins, another ends, which makes it easy to parse the content and identify individual blocks. You have the opening and closing ones. It works as like a header for each block. So you have, you know, what kind of block it is and you know what kind of, what data it has. It also stores data, some in the HTML, some in the HTML comments. There's some cool stuff with the way it works there if you want to get into it. And then, yeah, it allows easy access to block data. As I was saying, the data can be then parsed out of that. It also doesn't rely on having JavaScript or any more complex methods for reading that data. The HTML as a string value can be parsed in a stream and so you can pull data as you go through it as opposed to having a JavaScript object that can be hydrated into memory, which can be a very large object with a lot of nested properties, multiple levels deep, and that all takes up memory in your application. Every single chunk of code or block or interblock would have to be converted to in-memory objects to then go through them. And there are advanced ways to handle that with streaming JSON as well, but one of the really big benefits of the HTML and HTML comments is they can be more easily streamed in terms of parsed in a stream or using like regex or something, which means at this point it's easy to extract the data using regular expressions, which is more efficient than using a DOM parser, which again converts that into objects in memory and all that. One caveat here is with the regular expressions, it's easily extracted when using regular expressions. You have something like this, you have the type, you have the attributes, and there's intercontent. So unfortunately that's not the actual regex that WordPress uses. It actually looks a little bit more like this. And in the actual WordPress code, the opening comment is I the magic. It goes on to explain how all that works. And even here that's not the full regex. It actually goes on to farther down the line. And so it's the kind of thing like don't look into this function as you've seen before with like database changes and stuff. And so it is rather complex, but unfortunately these days we do have tools to help us better understand regex, such as ChatGPT that can actually walk you through how this regex works and what it does. And I'm actually kind of surprised at how terse this response is for how wild that regex is. So the HTML comments structure does allow for easy parsing with regex. Once the regex is written, you now have this stream parser for that. So here's an example of that HTML structure with the comments in a very simple like hello world, welcome to WordPress post. You see there's the namespace and the block type. So this is a core block. WP is the namespace for WordPress core. And then paragraph is the type of block. You'll see as an opening and a closing tag. The closing tag identified by the backslash. Regex is able to determine the difference in those to see a closing tag as well, then the content in between. And so if this were a dynamic block instead of like a paragraph that has rendered HTML, it would be just the comments and then they would just be not rendered if the plugin's not active, which is a nice benefit here. But also this paragraph tag is a paragraph tag. And if you delete that paragraph block, the paragraph tag still exists in the content, which is highly beneficial as opposed to a short code that injects something but only injects it if the plugin's active. So a lot of benefits in this system. However, the HTML comments are not the only way to do data in Gutenberg, but rather actually they are a concept of WordPress. So the Gutenberg editor doesn't necessarily use the HTML content, comments. It actually has, you pass in the value to this block editor provider for state and it's an object of blocks in data. And then on change, you can call this dispatch form blocks to export the data. And that actually happens as objects in JavaScript, in memory, in the client browser and all that. So WordPress is actually taking those JavaScript objects and parsing it into HTML comments to then store. Then when it loads the editor, it brings the HTML out of the database and parses it back into JavaScript objects for use by the JavaScript application. So actually the HTML comments are not a Gutenberg concept. They are a WordPress concept, which means if we want to reuse the block editor, HTML comments are not something we're tied to and we're more free to work in the JavaScript object JSON notation that we were otherwise used to and there's a common standard across API systems. This is an example structure of how a block is represented in JavaScript or JSON notation. Again, you have that name. There are attributes and then interblocks. If you remember back to the Regex, it was looking for name, attributes, and inner content, which are more blocks recursively. So this is that representation of that. It's a standard structure that then gets repeated inside of interblocks and it can just be going down blocks all the way down as far as you would like. So this is how we're using it in Give. This is actually how it comes out of Gutenberg as this JSON format. So we stuck with that natively for our own use cases because it better fit our application. One way we're doing that is we created this PHP layer that is able to actually take the blocks from the JSON and parse it into this block collection for manipulation within PHP syntax. And then we use that to validate and all that and then save the form data. GiveWP has a Fields API. I know WordPress has been working on a Fields API for I think 10 years now and it hasn't materialized in WordPress core. But GiveWP has one that we use for our needs and this works out really well in converting that JSON block into this collection of blocks and then into our Fields API which allows for a more fluent syntax. Like you can say field. You can have a field object and then method arrow name method and then pass it a name. Or method arrow description, pass it a description. It's a fluent almost language type syntax for doing that and we're building that around that blocks interface which means we can use it on the front and so the back end has JSON data in the front and using this Fields API to then render a different JavaScript application. So the output of Gutenberg as JavaScript is actually highly beneficial and flexible for developers' use to build any other kind of block editor you would like. And that's benefits further made evident by its use across Drupal and Laravel and October CMS and GiveWP and Contact Form 7 blocks has a new plugin that does that and how it's converting from blocks to short codes is really flexible there. So I have plenty of time for questions but that's the basics of Gutenberg as a foundation. There's a lot more detail to dig into in terms of the block list components and all the other different components and control components that work as a style guide and all that that are specific to an application itself so I don't want to go too deep into that. But if you do have any questions pertaining to an application or a piece of that I'd be happy to attempt to answer best that I can here in front of a room of people or I can talk to anyone afterwards if you like. I'll be around for the duration of the camp as well. So thank you. Water, thank you. Thank you Kyle so much. Here's what we're going to do. Oh good, it's remote. We're going to try to pass the mic around so the transcription can continue. So please speak clearly into the mic and wait until we can talk. We're going to give Kyle a moment to dry his throat and rest a little bit. But Matthew I think you have a question first of walking slowly over to you so the moisture can absorb. Any non-hecklers with the question? Anyone not from Cleveland, Tennessee have a question. So if you're using Gutenberg as a foundation but you're not using it as the block editor and you're storing this JSON, are you storing that in the post table? How are you actually storing the data? Do you have a recommendation there for what that would look like? Are you storing the column or what does that look like for what you've shown us here? Yeah, originally we stored it as the post content. We just stored it as JSON instead of HTML. It was never intended to be rendered directly from that post content. We didn't feel the need to put it in a renderable format but we did use the post content column of that table. Due to other business and product reasons we wanted to reuse that post content for something else so that each form has its own page because it's a custom post type called give forms and so we want to actually use that post type or post content to render the form itself which is a page that has a form block on it. So we ended up switching tactics and just moved it to a meta field, a custom meta field and that gives you all the space that you need. It's a flexible format. It's just a blob of JSON that then gets parsed as a string into JavaScript objects. So it's fairly flexible there. There are probably some more advanced ways where you can split it out if you wanted to but such use case would kind of depend on if you're needing to query the database based on that data but we're not querying it based on the contents of that JSON. We're just using it as a storage, a blob of storage to then bring in and parse. Hey, that's Rich from Automatic. So a lot of people are moving towards using dynamic blocks, really dynamic blocks. Do you see that becoming an issue if you turn off the plug and you lose the block just like in short curves? You would lose the blocks content, possibly. There are two ways to do that. You can have fallback content, I believe. You can render content but then update it later on and I'll handle that. You will lose the dynamic portion of the plugin if it's disabled, but you won't have an artifact remaining in the content unless you specifically choose to have a placeholder or a fallback. So as a problem it depends on the perspective of the problem for the content manager. It goes wrong, that could be a problem, but to the end user reading and consuming the content or whatever system is consuming that, it's just like it's never there without any artifacts, which I think is a smart fallback kind of a thing, certainly depending on the use case, whether how important that was, but if it's important you can just keep it enabled so I think it's kind of a non-issue there. So you would lose the content but that's also kind of a feature here where there's no artifacts remaining after the fact. Thank you. Anybody else with a question? Okay. Oh, please, please. Okay, this is the second one. So from your experience building the give donation with form and the editor, did you run into any limitations and is there anything that CORE can do to help alleviate this? So we've been trying to contribute back to Gutenberg as we've gone through. There's been at least one issue that comes to mind to where you could have, it was like a block limited to a single instance but you could still drag and drop it into the block list which in the WordPress block editor, that block's not listed in that tree to then drag and drop, so not an issue. We came across a small issue to where we were in during it anyway, but grayed out but even though it was disabled you could still drag and drop it and so that was something we addressed. Otherwise in terms of limitations, the biggest one is documentation. You go to the documentation, it's like, oh, here's the property or component I need to learn about and it says documentation not available. It's like, oh, it's right there but it says there's nothing here. So that's the biggest limitation and then jumping in you can still click through in like an IDE to find the implementation of it in order to extract how it's supposed to be used. So I spent a lot of my time in the early months of this troubleshooting and learning the internals of Gutenberg so we could then develop an application using those components that weren't otherwise documented. So using the code as documentation worked. It just requires a much deeper dive and a much more intimate understanding of the code base. So increasing, filling in the documentation would help there are lots. There's also the isolated block editor package that automatic has and that's supposed to fill in a lot of those gaps in terms of configuring the thing but even there the documentation is lacking. As much as I've spent on this, I tried to use the isolate block editor last night and it was just like one compile error after another. I think it has like SAS as a dependency, that's not listed anywhere and also not included in the dependency tree. Documentation is kind of the big thing but as fast as Gutenberg moved, it's kind of hard to expect it to be developed in real time because it changes so frequently but as it moves towards a more stable position as being used in other real applications outside of WordPress the documentation is going to become crucial but also it's a point where it's going to start to solidify and so it might be now time to start putting more resources in the documentation itself. So one of the things I was thinking about is if you have like a headless WordPress installation and you have your custom Gutenberg editor, would you see any problems on the front end like building out, I don't know, let's say you build out the front-end reactor system if you had your own Gutenberg thing or if you were still using WordPress Gutenberg with the comments and stuff. What are your thoughts on that? Yeah, I'm currently using a headless WordPress installation for a blog and just using the block editor to build out the content and there is some concern with the dynamic blocks and are they going to work in a headless situation because you don't have access to the plugin itself to render the content dynamically unless you try to intentionally fetch it through an API endpoint which is an option. I was trying to read it from the database directly and so I was able to find things like a code formatting block that has headless supports so it actually fully renders that code block inside the content so that it's static and not dynamic. So there is some consideration there. If you were consuming it in another application, you could, if you're building your own application or block editor for your application, you could certainly implement the dynamic parts into different sides of the application or just consider since it's your own thing having it generate content because you're not, in that case, worrying about the large scale and scope of WordPress and how it's used. So, answer your question at all? Yeah. Okay, if not, we can talk more later. Yeah. Life-cycle, that there were memory leak and just memory cycle, life-cycle issues. That has improved considerably from what I can tell. Inside of WordPress, WordPress's version of Gutenberg, outside of WordPress, are any of those issues still kind of coming up? Were they fixed in WordPress side or were they fixed with Gutenberg side? Just from a memory usage and kind of bogging down at longer content links and that kind of thing. Yeah, I know there's been a lot of work done to make it more performant, more optimized. The interaction's gotten a lot faster, as you've mentioned and noticed. We have not come across any of those issues in Give perhaps in large part because we're not doing really long content. We are using it as a form builder so you can add any number of fields that you want. In my testing, I'm not using a ridiculous amount. I know in the world of WordPress and products and products in general, customers will use things in ways you don't expect so that very well might come back and get us in which case we can reconsider some things, reach out to the Gutenberg team and work with them because I'm sure they're dealing with that also if it's a problem with this implementation as well. For our use case, donation forms have a lot more opinion to them than do general forms like at Ninja Forms would create or something. So, not been an issue for us. I don't foresee it being an issue but it certainly could and I'd be caught on awareness. But as fast as the Gutenberg project has moved in the past, any problems that arise, often it would be resolved rather quickly. For example, I have an open track ticket for WordPress Core. It's been open five years now, almost twice as long as I've been at Giv and it's still open. I've submitted a patch and had testing instructions and all that and so it's just still sitting there, right? So, we've came across this issue in Gutenberg. I patched it for our own use. Our development manager was like, I submit that as a PR to Gutenberg. I'm like, yeah, that's a good idea. I just did it in this way in ours so we can move forward and not worry about it. I don't know how long it's going to take. He's like, you just go ahead and submit the PR. So, okay, yeah. So, took the time, wrote out the PR, hit submit and I went to tell my development manager I had submitted the PR and when I went back to link it to him it had already been merged and approved and reviewed. So, that's very good to see. The responsiveness of the team has been great but also it just doesn't have the baggage of WordPress core so it's able to move fast now. Surely in the future we'll see diminishing returns in that as WordPress, depending on the philosophies they keep and backwards compatibility and maybe that's different in the JavaScript space because browsers and support for JavaScript versions move at the pace of the browser and the client not on the same as the server. So, the whole back with PHP upgrade and version of the server requires the person using the software to contact their host and update the PHP version if they'll even allow them to do that. Whereas JavaScript depends on the browser and browsers move at their own paces and so it's probably more likely that doesn't have the same baggage but there'll be some certainly over time but they've been very responsive, very helpful and we have not run into any issues over the past nine months of throwing new weird things at it. Okay, coming on back to you. I do speak highly of Gutenberg out of my experience of using it. Absolutely no connection to Matt Mone-Wig or Automatic or the Gutenberg team whatsoever. Also I don't get any compensation or paid for doing the talk or sharing about Gutenberg. Yeah, open source contribution is part of the community aspect. It is. We've recently packaged it up into a standalone package on GitHub. It's under the namespace of StellarWP StellarWP being the WordPress umbrella under Liquid Web. We did it in such a way that we could share it across the different plugins and so we should see more adoption from other plugins in using this which interestingly might have weight enough to get larger growth. The Fields API being developed for Core as a feature plugin doesn't have the benefit of a multi-million dollar company pushing it on other products. So this might actually have a chance to get weight and move into a larger sphere of influence. So yes, it is available on GitHub, github.com slash dellarwp under Fields API. If that's not currently public, if I miss speaking, it'll be available soon otherwise. It's also available inside of the GiveWP GitHub repository in the source framework directory. You can lift it right out. We did build it with the intention of it living outside of Give and becoming a dependency and so it does not have any of our... Well, as little of our bias as we could manage in the direction of the Fields API, we actually have a implementation of it in our own code. Framework pieces in our code in a different spot. We have the implementation of it. So we're using it as an internal dependency for that very purpose. To generate this JSON block... Yeah, so we parse the JSON string into a block collection, which is a class we have in PHP that reflects the same data structure as it does in the client in Gutenberg. And then we have a custom parser that converts that into fields. So the blocks get mapped to things. There's some opinionated ones. The amount field in our donation form is highly opinionated, but things like custom fields are just like text fields and we map those into the Fields API. And so it's just a... It's an adapter pattern. We loop over the blocks. We check the type and then convert that to a different structure for the Fields API. For things like properties that are acquired or the label or a description or help text. In Gutenberg, that exists in the attributes array. It's a flat structure. Whereas we move it into very specific key value pairs inside the Fields API. So that's the work we're doing is matching up the namings and really mapping it for one to the next. Great questions today. The next session starts at 10 o'clock. In the meantime, we have a question stopping by to say hi. Thank you for sponsoring this. You can find this hobby in water. Thank you. You'll be available today? Yeah, I'll be here today and tomorrow walking around. Happy to talk this stuff. I'm also happy to talk about working on client sites. If you're interested in foster care adoption. I know a lot about that too. Happy to talk about it. Or any of their hobbies listed prior. So I'll give them a hand.