Live Q & A: Leveraging Gutenberg’s architecture to take plugin development to new levels

Awesome Live Q & A with Lena Morita, Jason Adams and Jon Waldstein

In this YouTube Live Q & A, participants learned how Gutenberg components and scripts can be used outside the block editor to revamp a plugin’s code base. Jason Adams, Director of Development and Jon Waldstein, Lead Developer from GiveWP walked us through their approach to rebuilding their highly popular Donations plugin using WordPress native interface components and scripts and then also discussed how their code fits into the ecosystem. Lena Morita, a JavaScript developer on the components team.

Table of Contents

Connect with the Panelists:

Lena Morita

Jon Waldstein

Jason Adams

Resources

Transcript:

Birgit Pauli-Haack: So welcome to our 34th Gutenberg Times Live Q&A. My name is Birgit Pauli-Haack, and I’m your host and the publisher of the Gutenberg Times. Thank you all for attending the show and it’s so great to have you. So today as announced, we will discuss how a product company can leverage WordPress built in Gutenberg architecture to take plugin development to new levels.

The team of GiveWP went all in on the approach and discovered new ways to build the new version of GiveWP Plugin. And we have the pleasure to meet two members of the technical team on the show and hear the genesis of the path and you can ask them questions. Before I introduce a panel, a few housekeeping notes. Speaking of questions, for those watching on YouTube, you can use the chat box next to the livestream and pose your questions and also chat with us or include where you’re watching from.

I might not go over that very often, but we’ll definitely will look through the questions. And then here on Zoom, use the Q&A bubble on the bottom of the screen or the jet bubble to share your thoughts and questions. Please be kind even if you disagree. This is a family friendly endeavor. If you might be wondering or your internet connection is not stable or you don’t have the time to sit through all of it, the recording will be available on YouTube later today after it’s fully rendered. Then the summary posts will be shared with the shared resources, will be on the Gutenberg Times within the next couple of weeks.

Introduction

So allow me to introduce our panel for today. Say hello, and let us know where you’re located tonight. I have the feeling that between the panel and the attendees, we span quite a bit of the globe. So I present to you, Jason Adams, director of development of GiveWP.

Jason Adams: Hi, I’m Jason. It’s good to meet y’all. I am from sunny San Diego, California.

Birgit Pauli-Haack: All right. Yeah. I’ll also present to you Jon Waldstein, the lead developer of GiveWP, and it’s all his fault. Oh, sorry. And then last but not least, my co-host, Lena Morita, who is a JavaScript developer and core contributor to the Gutenberg components and sponsored by Automattic. Hi, Lena.

Lena Morita: Hi, I’m Lena. I am based in Tokyo, Japan. It’s 2:00 AM right now.

Birgit Pauli-Haack: All right. So good morning, Lena. Good morning, everybody else? Yeah, Jason and Jon, yeah, are both on the West Coast.

Jon Waldstein: I’m on the East Coast, Rhode Island.

Birgit Pauli-Haack: East Coast, yeah. Rhode Island. Yes, sorry.

Jon Waldstein: Happy to be here.

Birgit Pauli-Haack: Yeah, geography can be always a bit tricky for me. 

Plugin architecture

So let’s start at the beginning. Jason and I met at the post status get together at WordCamp US last year and you just had announced, GiveWP just had announced the start of the revamp of the GiveWP plugin, version 3.0. Widely distributed plugin for nonprofits and others to collect donations on website with various add-ons. Then you mentioned that you are building the new version on top of Gutenberg components and WordPress scripts and I found that fascinating. So before we dive in head first, let’s get everyone on the same plate. In short, Jason, what is GiveWP?

Jason Adams: Yeah, so GiveWP number one donation plugin for WordPress. We have coming up on about 200,000 folks that use GiveWP to connect donations directly from their website, manage their donors and keep their nonprofits, which is largely our audience, running. Doing their day-to-day thing and not having to work too hard to bring in donations on there to keep their work going.

Birgit Pauli-Haack: Awesome. Yeah, GiveWP, I used it quite a bit when I was working for the agency, but what made you rethink the current architecture of your plugin?

Jason Adams: Yeah, so first Give still works very much kind of, you remember the classic editor experience of WordPress where it was it kind of data entry, right? You didn’t design or build your pages, you entered data about your pages, the content and tags and all this other stuff, and then you click publish and then you view on the front end, what did I get? We know that that worked great for decades, but now we’re moving more to a visual era of building things. People want to be able to visualize and have that kind of full more immersed experience. That was our motivator, was wanting to go down that route. We had a lot of ideas for how we wanted to do that, but we had technical debt building as all products do that was making it more and more difficult to go down that path. Yeah, we started to weigh our options of how are we going to go about taking GiveWP to the next level.

Birgit Pauli-Haack: Interesting. Yeah, the drag and drop, the visual editing, I think that’s kind of really where Gutenberg shines and having a plugin follow that path. How did you figure out the path forward? Because a revamp normally is really a big project and it’s a multi-year development project, so how did you go about it?

Jason Adams: Yeah, and we didn’t want to do a start from scratch kind of a thing. We wanted to iteratively build it out. So what’s been nice is that our underlying architecture for donations, donors, none of that’s changing. It’s just our forms. We first explored four years ago just building something proprietary and the reality was, it was not up to the standard that you see in Gutenberg and other sorts of things today. It’s a lot of work. It’s so easy to take for granted just the idea of a block, a thing that you can move up and down. It’s a fluid user interface, inner blocks, blocks inside a block. There’s so many things that are easy to take for granted when you go to set out to build something like this. We were like, “Well, it’s right there in Gutenberg.” And so we started to kind of peel it back and we knew that Gutenberg is not… Gutenberg is in WordPress, WordPress isn’t Gutenberg. You can go to the Gutenberg repository and it’s broken out into tons of packages.

We just started installing stuff and we did what we call spiking, where we’re just trying out an idea for a fixed length of time. I think we gave one of our developers, might have been Jon or our other senior developer on the project, shout out to him, Kyle Johnson, one of them had a week to see what they could do. We were really surprised how much we were able to get up and running. Have the list view of blocks, have the block editor itself, have our own blocks loading, the inspector.

It’s like you have so much that you can get up and running in such a short time that would’ve taken us months to achieve and it’s already so battle tested all of these packages. It’s hard to appreciate how much that’s worth by itself. Of course this is where WordPress is going. We didn’t want to have to reimagine an entirely new user experience and then train our users on how to use that. We wanted somebody to be able to go from working on a page or a post to a form and not have to relearn the whole journey, but to be like, this feels immediately familiar. It’s a little different, but it feels inherently familiar. Reducing that user friction from changing from context to context within WordPress, which I think is really important.

Birgit Pauli-Haack: Yes, it sounds right, a good path, but there are definitely some hurdles. So what were the first wins that you kind of say when your developer kind of set out, get a week, and then what was it exactly that they set out to do, but then found, “Oh, that is going to be fast to develop that in a week.” Normally development takes about four weeks or five weeks or something like that. Yeah. What are your first wins?

Plugin revamp

Jason Adams: Like I said, even the concept of a block, because for us, we have, and I’ll demo this in a moment here, but we have our sections and then our fields go in our sections, like name amount. To just have everything visually there and to have, “I want this field to be down there,” and making that as fluid user experience is not as easy as it sounds. Or we also have sections and fields inside of sections. So this inner block concept and then being able to select which blocks are visible based on what context you’re in. Or I click on a block and that block contextually shows up in the inspector. We achieved all of that within a week and I was like, “We have a lot of work to do.” But just the fact that we could get that far in such a short amount of time, those were the wins that were like, “Well, we don’t want to go reinvent this,” and it already is a familiar user experience, so it would be silly not to do this in short.

Birgit Pauli-Haack: Yeah. So I think that I find it fascinating and when you tried to describe it, I think it would be really helpful for us to have a short demo of the current state of your development so we can actually look at things and then I can see that we might have the first round of audience questions. What will you show us tonight?

Jason Adams: All right, let’s share my screen and show some stuff. All right. Can y’all see my screen?

Birgit Pauli-Haack: Yes, now we can.

Demo

Jason Adams: All right, cool. So this is GiveWP very similar to how it is now, but I have a plugin, what we’re calling our feature plugin right now installed, called NextGen that anybody can actually go test out themselves. We have a landing page for this that we can share the link for that you can just go click spin up a site and it will just spin you up a site and you can be playing with it literally in 15 seconds.

Lena Morita: I tried this and it was really easy.

Jason Adams: Yeah, thank you. So let’s see here. So I’ll add a new V3 form as we’re calling it. I won’t get into why it’s V3, but it is. So here you go. It’s funny, when we first showed this to people, it almost had an anticlimactic effect to it where they were like, “Well, what else would it look like?” Because it just fits right within WordPress. It’s like, “Oh, okay.” So you can see we’ve got the list view like you would normally have. We have our various sections, you can see everything within those sections. We’ve got the form itself. So a lot of this is very similar. Now you don’t have the fluid typing interface where you can just add paragraphs and paragraphs. You can’t just click somewhere and start typing. But that’s really neat is that you’re able to constrain how the block editor works, because for us, we don’t want people just typing in the forms. It doesn’t make sense for a form.

Instead, people want to do something, like add a text field, and so we can just click on a section and we can add a text field, favorite color, we can mark it required. So I mean, as you see, it’s just Gutenberg. It’s the exact experience somebody would normally expect, but it’s tailored to how our forms work. And for us, we also wanted to do things like, if I come down here, I can only add a section. We wanted all fields to be within sections. So that’s a really subtle thing, that’s really powerful actually, because this is root level blocks here, and a root level block can only be a section. But then when I’m in a section and I want to add fields, well now Gutenberg knows what blocks can go in there and that’s not something we had to build. Gutenberg already has a concept of all of that kind of stuff.

So I can come in here, you can click in and you can have that same… Gutenberg comes with a lot of what they call controls out of the box. So things like, I want to have inline text editing or something like that. That’s not something that you have to build. One other thing that I’ll point out here, is that if I go to add our blocks here, you can see that you have only our blocks. So we didn’t want to open up the form to every block that exists in WordPress. We thought about that, but we had very specific reasons why we didn’t. That’s another thing that’s really neat, is you can think of Gutenberg as creating your own sandbox environment for what you want to build. So you don’t have to think to yourselves like, “Oh my goodness, we have to…” So every block is open to this? No, you can make it limited to only your own fixed list of blocks.

The other thing that is really neat that we’re able to do is add an additional tab over here that we call design. So this is breaking out a bit from what Gutenberg natively does. We wanted folks to have the ability to, in this view, we call it the builder view, which is where you’re focusing on the structure of your form. So it’s kind of a very vanilla, very plain looking, it’s just meant to be very clear. You can see with our donation summary here, it’s not really showing you anything real. It’s purely so that you can do things like I just want to position things where I want to have them in my form. So then you can switch over to the design tab and now we can actually view our form and this is the exact form as it’s going to render in the front end, and you can play around with secondary colors.

So my secondary color in this form design is being used here. I can make this a nice little purple color, I can change the header, I can hide it, show it. You can do all sorts of fun things in here. But I mean that was pretty powerful of just the ability to add an entirely new type of experience within Gutenberg and giving people the ability to preview. For us, because Give forms are fairly widgety, right? We’re not trying to preview the entire page, just one thing, it worked out really nicely to be able to do it right within here.

I’m trying to think what else. So the last thing that I’ll point out here, let me publish this. Let’s go to our form. Let’s take a look at it on the front end. Okay, so we’ve got our form here on the front end. I’m going to dive deep into the weeds here, it’s a dev audience, so just track with me. Okay, so typically when you’re working in Gutenberg, the way that we typically think of it saving is it saves as a string version to the post content. So you think of the Gutenberg HTML comments where it includes attributes and stuff about the block. You can load it dynamically and so on and so forth, but it saves to the post content column of the database. Then when you’re rendering the page, you grab that post content and you stick it on your page.

Now for us, we didn’t want to just do that. We had to do a heck of a lot more. So if I fill this out, green for anybody who’s wondering. Then let’s throw on our test card, let’s say for five, donate. So I just made a real donation to my Stripe account. So a lot just happened there. That was obviously a lot more than just, “Oh, it looks like a form.” No, it has to actually work like a form. Forms submit data, forms store data. You can see here it’s referring to my favorite color that was stored in the donation meta. So has a lot that it needs to actually do and validate and all of this different stuff. What we did differently, is that when our forms save, so coming back here, so when I click update, it’s actually saving as JSON.

So before Gutenberg turns into the big string that we know it to be, that saved content, it actually first stores as a JSON object. A bunch of blocks, block attributes, and then child blocks and so on and so forth. It’s a very simple structure actually. We’re doing nothing with the string content, we’re using just that JSON, and we built what we’re calling our field API and we’re converting the JSON structure into the field API. So this email address field, here it’s a block and then it gets converted into an email field on the front end, which is meaningful within GiveWP. So in other words, this is purely presentational so to speak and structural and we can convert it in any context we want. That’s a really powerful thing when you think about it, that you can take something like this, structurally speaking, and just convert it into your own API. So the block JSON, it’s focused on how is this all laid out within Gutenberg.

When we load this page, literally all we’re doing is we’re grabbing that JSON that we save and we’re handing it back to Gutenberg and we say, “Here’s the form,” and that’s it. It just works. Then when we go to save it, we do the conversion and you can actually see that at play. If I just add another text field here, maybe. If I go to design, like that’s showing up here, because just as we’re working within, so even though I didn’t save it, that’s the kind of thing I’m showing there. Even though we didn’t save it, we’re still just grabbing that JSON object and converting it to our field API and rendering it that way.

So I think for a lot of plugin developers and whatnot, I really want them to grasp the concept of Gutenberg is not just a way of being able to lay things out and then you just have to take whatever it gives you and slap it on the page and there you go. It’s like, no, you can use it as a tool for interacting with your user and then you can convert it into whatever context you can imagine. And that’s a pretty powerful thing.

I think that’s it for what I had in mind for demo. Anything that anybody wants me to show a little more or poke into here?

Lena Morita: I have a question. So on the front end, on the actual front end form, how are you adding interactivity? Like the JavaScript parts?

Adding interactivity – how a form works

Jason Adams: Yeah, so the way this works is that, so it takes the Gutenberg JSON, converts it into the field API, and then that is serialized and this is an iframe. Inside the iframe is a React application that’s just running independently. The React application takes in the form and then it connects to things like gateways, other add add-ons, that sort of a thing. But yeah, that’s where it’s coming from. This is just a React application of our own design, built specifically for Give forms.

Lena Morita: So basically field API converts all that JSON data into actual React components and stuff?

Jason Adams: The field API is a PHP layer.

Lena Morita: Oh.

Jason Adams: It’s pure just PHP objects, but it’s focused. Whereas the Gutenberg API is focused on blocks and child blocks, attributes, that sort of thing. Our field API is focused on how does a form work. So for example, is this a field? Is this field required? What are the validation rules for this field? Does it have any sanitization that needs to happen? So things that you would typically think about from a field or field form perspective, that’s what the field API thinks about.

It was also really important to us that developers could programmatically… So if I want to programmatically move a field, add a field, add a section, do anything, you can do it using our field API in PHP. So you can kind of add a middleman layer between Gutenberg, a programmatic layer to be able to make more adjustments to your form. Then that’ll just show up here. For example, when I submitted this form down here, how does it know that this is a required field and what does that even mean, right? Because it has to validate on the other side. So when we submit this form on the server, it’s grabbing the form again in the structure of the field API, it’s finding the favorite color field, and then it’s checking the validation rules such as, “Hey, this is required,” or “It can only be up to 255 characters,” or whatever else. Does that make sense?

Lena Morita: Yeah. So wait, the initial render of this form is not in PHP, I think you said this was initially rendered in React, or is it actually a PHP rendered page?

Rendering

Jason Adams: I know there’s so many layers.

Lena Morita: It’s so interesting.

Jason Adams: It’s no worries. The field API lives in memory and PHP. That can be used both for rendering a form or validating a form or doing any number of things. This form represented in memory and PHP and it knows all the responsibilities of that form. Then we say, “Hey, I want to render that. That’s what I want to do this time.” And so then what it does is it, I think it’ll show you, it serializes everything. I thought it would show here. That’s fine. But anyway, it takes the whole field API structure, the form, all of its internal fields, elements and so on and so forth, serializes that, passes that to the front end, which is received by a React application.

Lena Morita: Oh, that’s how you hydrate it.

Jason Adams: Exactly. Yep. The React application is ready to receive a form in the structure of the field API JSON.

Lena Morita: Yeah, I’m not sure if everybody’s aware, but the interactivity API is kind of an experimental phase in Gutenberg right now. And this is a very hot topic. I feel like it’s on everybody’s minds. How do we hydrate interactive components on the front end? So it’s very intriguing how people have done this before any kind of ready-made abstraction layer.

Jason Adams: Right. There’s also the difference between, for example, I’m making a page, on my page I’m adding a component. This component is an accordion. It’s presentational, but there is a JavaScript element to it of, I want to be able to make interactivity happen on a presentational level versus what I’m describing here. It’s pretty complex, because there’s both a front end validation and server side validation, and we want them to be the same. There’s a lot of complexity around a form and what the form even does. So for us, our forms don’t just save and entry, our forms actually output into a donation and donor. So trying to capture the lightning in a bottle of boiling this down to interactivities, it’s like, well, it’s doing a lot more than just being interactive. It’s also validating and doing a whole bunch of other stuff.

Validation

Actually, one thing I’ll show here if I switch to our multi-step design, so let’s just update this. Okay, we’ve got a completely different experience here. So now in this one, every single step, so when I do that, you notice there it kind of loaded for a moment in between steps? It’s validating with the server. So every single step is now validated against the server to make sure that everything here is in fact correct.

Well, actually I have that differently set. Anyway, so if I were to try to continue, I’m going to get immediate validation feedback from the server. Even if you try to trick the JavaScript and make it not work and validate in the front end, it’s still going to validate on the server. So yeah, it’s a complex piece. So I think the interactivity API and stuff like that is really, really great for a lot of simpler forms of interactivity. But when you’re building what is in effect a small application, I think something like that is still a ways away from covering everything that we need this to do. Does that make sense?

Lena Morita: Yeah, it makes a lot of sense. Thank you.

Birgit Pauli-Haack: Totally sense for me too. Especially the other pieces, not only the validation of the form, but it’s also the connection with the external services like Stripe and the databases and all of that. Those need to be abstracted too and then kind of come back through the server API I would think, to then push it again to the front end in some other places.

Jason Adams: Exactly, because we don’t have a fixed list of gateways here. That’s injected. We also have our own add-ons, like fee recovery, form field manager, those add additional blocks and fields and those are injected at different points. It’s a highly customizable system, so there’s a lot going on.

Birgit Pauli-Haack: Super. Yeah. Well, do you have any other questions, Lena, to get them to show you something or shall we talk a little bit higher level now?

Lena Morita: Yeah, we can go higher level.

Birgit Pauli-Haack: Well, thank you so much, Jason, for the demo. It’s fascinating, especially how the difference between before and now, because I only know the current version or the version three years ago and what you do now. So it’s a total different beast, I would say, as complexity, but also easy to use. 

How it’s built

So just a ballpark, would you say from the code base, how much is actually based on the WordPress components and scripts and how much of that app do you have to rebuild kind of thing? So I would think the field API on PHP, that’s kind of the interface between those two as we saw.

Jason Adams: Yeah.

Birgit Pauli-Haack: Maybe it’s kind of an odd question. Yeah, I get that.

Jason Adams: Twenty-five percent. I mean a lot. Gutenberg definitely attributes to quite a bit.

Jon Waldstein: I could take that one.

Jason Adams: Yeah, go for it, Jon.

Jon Waldstein: We built the donation form, the new one that you were seeing on the front end, completely from scratch. That whole thing with React serializing or hydrating data from the server, we did that from scratch, because our old forms were just using post types. So everything is server rendered, and it’s a little difficult to add that level of interactivity with React using the old system. So we really built it, the front end, from the ground up. The form builder that Jason was demoing is mostly things you can get from the Gutenberg package. We had to customize a couple things that we had to fork and call our own, mainly the sidebar that you saw where we have that design tab, that’s not something that’s available to us. So we had to create that and implement it on our own. But for the most part, what you’re seeing on the form builder can be achieved from Gutenberg packages.

Birgit Pauli-Haack: So the sidebar, when you say that, I saw the controls that were there, they looked like Gutenberg components, the color, bigger, and the different kind of… Yeah. So that definitely might have come through that. Yeah.

Jason Adams: We barely invented anything in the inspector.

Birgit Pauli-Haack: Yeah.

Jon Waldstein: Yeah, and that’s the beautiful thing about using Gutenberg is if you want to create a block in our form builder, there’s nothing different about it than building a WordPress Gutenberg block. And we really wanted to make sure that was the case so that there’s nothing, no crazy documentation that you have to relearn. So we do have a community of developers that interact with GiveWP, external developers, and we want to preserve the customization of the plugin. So if you know how to build a block in WordPress, you’re going to know how to build a block for us as well.

Birgit Pauli-Haack: Oh, that’s awesome. Yeah. Well, this is all talking about the good sides, but were there any surprises or challenges that you encountered while you were building that, or are you still encountering? What are the biggest surprises that you’ve found?

Challenges

Jon Waldstein: Yeah. Well, we mentioned we had to customize some components like the sidebar. But I think the one I want to mention is GiveWP is not just one plugin. We have a lot of add-ons that extend the functionality of GiveWP, whether it be gateways and different ways to customize your form. We have a lot of things that interact with our main plugin. One of the bigger challenges recently was figuring out how to open up our customized Gutenberg form builder with our add-ons. Now, another shout out to Kyle Johnson, who is a developer on our team who built the first iteration of the form builder. To get things up and running we used just React, Create React App, which ends up bundling all the scripts together into one JavaScript file. So when you load the form builder, you’re just loading a page and it’s just loading that one JavaScript file.

What we found out later is that in order to load external blocks from our add-ons and other things that are interacting with the form builder, all of these different things are always reacting with certain dependencies like React. They can’t all load Gutenberg at the same time. It’s just not going to work, which is how the post editor works and why WordPress Scripts package came out is that you can extract all the dependencies from your script and let WordPress load those for you. So that was a big kind of structural change we had to make so that we are now relying on WordPress to provide us with Gutenberg, which is actually something we didn’t want to do. We wanted to have full access to the latest version of Gutenberg, but it wasn’t possible for us, because we have add-ons that also need to interact with Gutenberg and React, and they can’t all just be loading their scripts at the same time. It’s just not going to work.

Like most of us know, wp_enqueue_scripts, you add an array of dependencies that you want your script to use, and WordPress will load those for you. And that’s how we had to go about loading our form builder and then having add-ons come in and give us a block or give us something to customize the form builder and just let WordPress handle loading external scripts. That was the big one.

Jason Adams: I’ll add to that.

Lena Morita: I’m curious.

Incorporating ReactJS

Jason Adams: It’s easy to take for granted that the Gutenberg team had to tackle this issue of we’re creating a single React tree. We don’t want everybody to load their own version of React, and it has to all end up in the same place. So I remember when Gutenberg first came out and there’s the Gutenberg elements, they tucked React inside of Gutenberg, why’d they do that? And why did they come out with WP-Scripts that just swaps out for you’re doing at WordPress/components? What actually that does, is it grab it from WP.components. It’s like why is it doing all this? Well, the reality is, they went through all of the hard work of figuring out how to have everybody using the same version of React and loading everything to the same React tree all at the same time from 1,000 different places.

That’s actually a lot harder than it sounds. Once we ran into that, we were like, “Okay.” We just had to switch everything to using WP-Scripts, because we’re like, “It’s just not worth it for us to try to solve the same problem of extensibility that Gutenberg itself has already solved so well.” It has some trade-offs, but it really, as a whole, it actually works quite well. So huge shout out to the Gutenberg team, because originally we actually had the first version of this loading in GitHub pages. It was literally totally standalone, but then we tried to extend it and we’re like, “This is a lot harder than we thought it would be.” Yeah.

Trade-offs and compatibility

Lena Morita: So speaking of trade-offs, I’m also sympathetic with the major downside of this. As a plug-in developer, you cannot rely on any version being in action at any moment. It’s very hard. Upstream changes can break your app at any moment. You don’t know what versions running. What are some things you’re doing to mitigate this risk I guess?

Jon Waldstein: We have to manually test it now. Before, if we were loading the latest version of Gutenberg, well, there’s only one instance of that. But since we’re loading Gutenberg from WordPress now, we actually had to bump up our minimum version of WordPress to whatever the version of Gutenberg that we support that comes with WordPress. That’s a major change for us, but it’s necessary.

Jason Adams: We previously supported back to WordPress 5.0. So this whole thing actually made us come up with an entirely new policy around which versions of WordPress do we support. Before it was like we would support a version of WordPress until we were like, “I guess there’s something that we really need,” then we would bump it up to… We were talking about bumping it up to 5.5 or something like that, but we saw no reason to cut backwards compatibility until we had a specific reason to do so. This whole thing made us realize like, “Oh, we’re really tightly coupled now.” We’re really on the WordPress bandwagon and it’s really important what versions we support.

We didn’t invent this, other plugins are doing this, but we said, “Okay, we’re only going to officially, moving forward, support the latest released version of WordPress and the previous two.” That’s how we’re going to keep ourselves from getting into compatibility hell as new changes roll in that we have to become compatible for. Then that makes it harder and harder to be compatible with older versions. So we’re having to really kind of tighten in on that window. Fortunately, I will say, according to our telemetry, people are actually pretty darn good at staying within the latest or a few most late recent latest versions of WordPress. We don’t have a lot.

Lena Morita: That’s good to know.

Support team

Birgit Pauli-Haack: Yeah, I was thinking so, what is your customer servicing to that? Yeah, because I can see that there are quite a few nonprofits that have not updated their WordPress for a while. But they could stay on your older version of GiveWP because it’s still supported, and you’re not going to cut it out right there.

Jason Adams: So a good product question there. So our support team is actually very much in support of it. What we’ve found is that typically people fall into one of two camps. One, they’re set it and forget it. They set up their website five years ago, and it works, so don’t touch it, right? And that’s perfectly fine. Or you have people that keep things fairly up to date. You don’t have many people that are in this weird middle space where they update some stuff and not others. And if somebody does reach out to our support team and is having an issue or something, our team is trained. One of the first things they do is they say, “Are you updated?” So it’s not like they’re going to have to suddenly change their tune, because of this new policy. It’s something we’ve already recommended to people for years is, if you’re having a problem, you should start by updating what you have to make sure that… because the problem might be fixed already and you’re just not updated.

So yeah, we’re really not anticipating, and others like the events calendar and others have had this policy for a while, and so I did ask around within the product space, “Hey, was this a pain point for you? Did you notice a decrease in sales or higher churn rate?” The answer was unanimously, “No. No, actually, it’s a very healthy policy to have and it hasn’t caused us problems.”

Birgit Pauli-Haack: Yeah. So we have one more question from Anton, and I think it goes back quite a few minutes, he was asking about the sidebar if that is accomplished through slot fills.

Sidebar customization – isolated Block Editor

Jon Waldstein: That one, no, we actually had to fork that. But I wanted to bring up the isolated block editor, which Lena works on or has worked on, because we’ve been following that project for a little while now. I think at its inception we were also building ours, which our form builder is very similar to how the isolated block editor works. One of the biggest problems was the sidebar customization, which to answer Anton’s previous question, if you were to use isolated block editor now, you can accomplish that with technically a slot fill, because we submitted a feature request to do that, and it was actually added just recently.

It makes it a little bit more feasible to actually switch over to the isolated block editor shortly, because we’re really not doing anything crazy. That was kind of the main thing about using WordPress as dependencies. It’s like we’re really not customizing anything that crazy. We’re just using Gutenberg. We’re not like forking every single thing. We’re loading a bunch of blocks into it and maybe doing some style changes. So it should be pretty reliable. But we are looking at the block editor, the isolated block editor, as a way forward for this. I would suggest it for anyone else looking at this project or looking at something similar to this, because it’s a really easy way to get started.

Lena Morita: Yeah, I agree.

Jason Adams: Played around using it and realize like, oh, it has things like undo, redo. We don’t have that right now, but if you use the isolated block editor, you just have it. So yeah, part of our post 3.0 launch roadmap is to switch the isolated block editor, which will also take a lot of complexity off of our plate.

Birgit Pauli-Haack: Excellent. Excellent. So I have another question. I’m so happy that I’m privileged to run this show so I can ask all the questions that I want.

Jason Adams: Go for it.

Making it easier with documentation and components

Birgit Pauli-Haack: You started kind of three, four years ago thinking about it and maybe a year and a half or two years ago, really doing proof of concepts and all that. So put yourself back into the shoes you would start out now, because that would be something that plugin developers might think about. What is it that you would ask of the Gutenberg team to improve or to build on the components or on the scripts so that work is a little easier? Or much easier, not just a little easier.

Jon Waldstein: Documentation has been a little bit of a struggle for us, especially being like… And we understand we’re no experts at documentation. It’s tough work.

Birgit Pauli-Haack: Can you specify a little bit on the documentation? Which piece?

Jon Waldstein: Well, if you know are going down the path of building your own block editor, there’s very little documentation on there. If there is, it’s a little outdated. We had to do a lot of digging through reading code and finding how to actually pull this thing off that didn’t quite match up with some of the documentation out there. So that was one of the biggest hurdles. Then also some components in Gutenberg are not accessible that we wanted to pull out and use ourselves. So some of those were just not exported. Maybe they’re just internal components. We found ourselves really wanting to, and we did use some of these components, but once we switched over to relying on WordPress to provide us the scripts, we lost some of those, because they’re not available. I would have to come up with a list to give you…

Lena Morita: With the block editor package? In the block editor package, you mean?

Jon Waldstein: Yeah, block editor. Maybe some more. We would have to define the path to the actual build component to grab, and sometimes those were missing from the exports. We would often have to fork the whole file, which causes side effects, because it’s relying on some things. So limiting that was tough at first, but we kind of worked around it. I would’ve to come up with a list to figure out which ones are really important to people like us.

Lena Morita: Yeah, please send me that list. I’m interested. There is something about it.

Jon Waldstein: Yeah. Some of these would be documented like, “Hey, they’re available,” and then you’d go to use them and they’re just not.

Birgit Pauli-Haack: I know that Ryan Welchers is actually on the path to put example code into the read me files and all that, and he found quite a few that if you want to use that code snippet, you couldn’t, because it didn’t export. So he actually goes through it and while he is updating the documentation to also add the export feature to it. So I didn’t find it yet now quickly, that little issue or the tracking issue of that, but I can certainly share that with you and in the show notes and also with you personally, so you can add to the list so you don’t have to start from scratch. Have you, speaking of documentation, there’s also a separate documentation site that’s called The Storybook for the components. How did that help you?

Jon Waldstein: That was helpful. I’m not sure how complete it is or how up to date it actually is.

Lena Morita: It’s getting more complete by the minute.

Jon Waldstein: Yeah, there were some things on there that were very helpful.

Lena Morita: It’s really nice right now. We spent a lot of time on it this past year.

Jon Waldstein: Yeah, I love the idea of that. There’s different documentation sites. We’re not really sure which ones are up-to-date. So maybe add a version to what thing was added, that would be helpful.

Jason Adams: That’s a really important note, I think. If you go to some documentation sites out there, I think React does this or Stripe does this, where the docs themselves are versioned. That’s really helpful, because otherwise that’s been a part of our struggles. We’ll find some piece of documentation on Gutenberg and we’re like, “Is this old? Is this current?” We just don’t know how to trust it. So we always end up going back to the source code anyway to validate the documentation that we found to make sure that it is in fact still recent.

Birgit Pauli-Haack: Yeah, totally get that. Especially because the documentation is actually built on top. The automation of the references is actually built on top of the Gutenberg plugin, but it doesn’t tell you that when you look at it. You are looking for something and you find it and then you try it out on WordPress without the plugin and the feature isn’t there yet, because it’s coming. It’s one of the upcoming kind of things. So I totally get this. Yeah.

Lena Morita: This is on our radar, definitely.

Birgit Pauli-Haack: Yeah, absolutely. Yeah.

Lena Morita: We’ll try to push for this.

Some things are hard-coded

Jason Adams: One other minor thing on the original question I’ll add is, there are still some things in Gutenberg that are hard coded that you can’t really do anything about. One that we’re kind of just hoping nobody notices is if you click on a block and then there’s little header piece of the block there and there’s a contextual menu and options that drops down where you have things like copy styles or paste styles or that sort of a thing, we can’t get rid of that. Copying and pasting styles makes no sense in our context. We looked into it. That’s just hard coded. You can’t get rid of that. It’s just there. I was like, “Oh.” So there are still little pieces like that that you’re just like, “Well, hopefully nobody will notice that.” And then the last thing with Gutenberg that we ran into that is like, “This is interesting,” is well, not the last, another is…

Birgit Pauli-Haack: I’m sure it’s not the last, yeah.

Locked blocks

Jason Adams: … locked blocks. So that’s kind of an interesting concept where, for example, you have to have an amount field for us. You can’t take that out and still have your form work. So you can lock the block, but then they can go unlock the block. So locking something, it’s more like a pinky promise with the user, like please don’t get rid of this. I think it used to be that locking was like it was done. There was no way to unlock something, and then the UI was added in the list view to be able to unlock things. That was kind of an interesting one of like, “Oh, well, how do you actually enforce that something can’t be removed? You should not be able to delete this.”

Then the other thing that we found that was interesting with locked blocks, is that if you have a locked block in one as a child block, so we have our two sections, if I have my amount block up here, when it’s locked, I can’t move it. So you can’t take it out of this section and move it into this section. If you drag and drop, it just will do nothing. So there’s just little itty-bitty things like that that kind of pop up. So the concept of what locked means in Gutenberg is a little bit, you kind of just got to play with it to find out what does lock even mean?

Birgit Pauli-Haack: Yeah, yeah.

Jason Adams: It’s not clear and consistent, I would say.

Filters and blocks

Birgit Pauli-Haack: Yeah. Yeah. So in the last few versions of WordPress, there were server-side filters as well as client-side filters to customize your blocks and to curate the experience and switch off interfaces and all that through PHP filters or server side or JavaScript filters. Have you been able to mitigate some of the problems that you saw before?

Jason Adams: With the locked stuff that we talked about?

Birgit Pauli-Haack: Yeah. So Nick Diego just posted on the developer blog a new… So how to modify theme.json data, which is kind of part of it. Yeah, that’s the style part, but it’s also block styling. Oh, I can share it here. Whoops.

Jon Waldstein: Oh, I’ll mention one. I’ll shout out to one filter that we just found extremely useful is the JavaScript filters for registering a block type, which really was amazing because now we can have core blocks. Let’s take the amount field or something, and we can have an add-on come in and add more settings or attributes to that block using the register block type. There’s a couple other filters for doing that where you can add things to a block that wasn’t there before. That’s new to me that you could do that natively, but for us, that was huge.

Birgit Pauli-Haack: It’s a little late in the game. Yeah. Yeah, I’m sorry, but we are getting to the end of our show. It was only scheduled for an hour. I think we could talk another two hours. I feel that way. And I don’t know, Lena probably has even more questions for you.

Lena Morita: Definitely. So many questions.

Birgit Pauli-Haack: But it was such a great experience to have you on the show and to share some of the secrets that you encountered and how you made it all work for yourself. We will have some resources in the show notes. 

Announcements and contact Info

At this point, I only have two more questions for you all three. So do you have any announcement that you wouldn’t get in before or you want people to keep in mind? We can go around Jason, Jon, and Lena. The second question is, if people want to get in touch with you, what would be the best way? So you can answer one of the questions, both questions or none.

Jason Adams: Yeah, so keep an eye out for Give 3.0 that will be landing at the beginning of Q3 is what we’re aiming for right now. You can go to the landing page, I provided the link for that and go spin it up and test it out yourself. We’re updating that. So as we roll out new internal versions of what we’re calling next gen, which is our 3.0, we’re updating that and we actually have it all set up. So if you do have that installed locally and we roll out a version, you can update it just like you would any other plugin and continue to test out, provide feedback. So we love getting feedback from folks on this. You can also reach out to me personally at jason.adams@givewp.com, or you can find me on Twitter as Jason.Adams.

Birgit Pauli-Haack: Excellent. Yeah. Thank you, Jon?

Jon Waldstein: Yeah, and I’ll mention for any other developers that are interested, what we’ve demoed and what we’re showing is completely public. You could go on GitHub and look at all of this code that we wrote. It took us over a year. I think we’re coming up on a year and a half or something, maybe a little less than that, but a lot of work has gone into it. If you want to see actually what we’re doing, come on to GitHub and if you want to ask some questions, you could start a discussion on GiveWP, or we have a Canny board for additional feedback. If you were to go to the landing page and actually play around with this thing, you can actually provide feedback and we’ll take all the feedback into consideration for the future of GiveWP. And if you want to get in touch with me, I’m on Twitter, Jon Waldstein and jon@givewp.com if you want to send me an email.

Birgit Pauli-Haack: Excellent. And Lena?

Lena Morita: Yeah, I guess for me, I mentioned I work on the work path components package and me and the team that works on it, we really, really are always looking for new contributors. So if anyone’s interested in contributing back, we love working with new contributors. We are highly engaging and we collaborate a lot. So if anybody’s interested, just pick up an issue or I don’t know, ping me and we’ll help you find a fun, good issue to work on. You can find me on Twitter at Mirka, M-I-R-K-A. Same ID on GitHub.

Birgit Pauli-Haack: Excellent. Yeah. And so my link or my answer is that we will do another live Q&A in two weeks actually, but on Friday, on Friday, July 21st. We’ll talk about design systems and theme.json. I know that there are large agencies and large entities like universities, and so they all have a design system. They have corporate design, and they need all the websites kind of to follow that. The WordPress VIPs team built a bridge between Figma and theme.json. I hope I get the people who created that on the show. We will have some demos there, of course. We also will talk with Joni Halabi, who is the web developer at Georgetown University, and she also has, as a university, big design systems and how she works with patterns. So it’s a great show and I hope you will join us again there.

So a big thank you to our viewers and to Anton for the great questions. If you have more questions, you can always send them to me via email. That’s pauli@gutenbergtimes.com. P-A-U-L-I at gutenbergtimes.com. Recording, as I mentioned, will be available in a few minutes on the YouTube channel, and we’ll publish a transcript in a couple of weeks on gutenbergtimes.com. 

Thanks again to Jason, Jon, and Lena for being here. It’s been a privilege to have you on the show, and it was a great joy talking to you. Be well and goodbye and good luck. Take care.

Jason Adams: Thank you.

Lena Morita: Thank you.

Birgit Pauli-Haack: Thank you.

Jon Waldstein: Bye.

Lena Morita: Bye.

Birgit Pauli-Haack: Bye, everyone.

Related Posts