Live Q & A: Discussing the Block Directory in WordPress 5.5

Discussion the Block Directory Live Q & A w/ Kelly Dwan, Alex Shiels and Otto Wood, hosted by Birgit Pauli-Haack

In time for the roll out of the new feature with WordPress 5.5, we held a Live Q & A with Kelly Dwan, Alex Shiels and Samuel “Otto” Wood, discussing the Block Directory on Zoom and YouTube.

At time stamp 9:26 – Kelly Dwan gives us a demonstration of how the Block Directory works from the Block Editor view. Below is a table of contents with the questions, the list of links of shared resources and the transcript with all the questions.

Table of Contents

Shared Resources about the Block Directory

Block Directory Slated for WordPress 5.5 Version

Transcript

Birgit Pauli-Haack:  Hi there. Welcome to the 24th Gutenberg Times Live Q&A. My name is Birgit Pauli-Haack and I’m your host and the curator of Gutenberg Times. Thank you all for joining us today. Chandrika from Cupertino in California. That’s really great. Thanks for being here. Bud from New Jersey. Hope you are good.

In today’s show, we will discuss what’s this new block directory, its genesis, and how it works. We will talk about the guidelines and the block plug-in checker. I like that, block plug-in checker.

Meet the Panel: Kelly Dwan, Alex Shiels and Otto Wood

We have an awesome panel for you today with three developers from the Meta Team and long-time WordPress contributors. I am pleased to introduce you to Kelly Dwan, JavaScript engineer at Automattic on loan to the Meta Team. Thanks for joining us today.

Kelly Dwan: Yeah. Thanks for having me.

Birgit Pauli-Haack:  So, Kelly, what’s your role on the block directory, just briefly?

Kelly Dwan: So, like you said, I’m a JavaScript developer, so I worked a lot on integrating it into Gutenberg and making it work with the editor.

Birgit Pauli-Haack:  Awesome. And we will, later, have a demo from you about how it works. Also, with us this morning, Alex Shiels, developer and code archeologist at Automatic and team rep on the Meta Team for many years. Thank you for being on the show a second time, Alex.

Alex Shiels: Thank you for having me again.

Birgit Pauli-Haack:  Absolutely. I’m so glad. And last but certainly not least, Samuel “Otto” Wood, developer at Audrey, WordPress guardian of the community and the plug-in repository, and also developer on the Meta Team. Many people in the WordPress community just know you as Otto, so I hope it’s okay that I on the show also address you as Otto.

Otto Wood: All my friends call me Otto as well.

Birgit Pauli-Haack:  All right. So how long have you been working on WordPress, Otto?

Otto Wood: Fourteen years, ten of them full-time.

Birgit Pauli-Haack:  Wow. That’s longer than Alex?

Otto Wood: It’s quite a long time, yes.

Birgit Pauli-Haack:  Wow. Yeah. Alex was number 12 or something like that on Automatic?

Alex Shiels: Yeah, roundabout there. Yeah, 13 years, I guess. So yeah, you beat me, Otto

Otto Wood: Hey, it’s not a competition.

Birgit Pauli-Haack:  No, it’s not.

Alex Shiels: That is true.

Birgit Pauli-Haack:  But I’m so glad to have you all here and thanks for taking the time today.

So before we start, I have an announcement and a few housekeeping notes. Tomorrow we will record the 26th episode of the Gutenberg Changelog podcast. We’ll cover Gutenberg plug-in 8.7 release notes and have more details on the block editor changes for WordPress 5.5. Co-host Mark Uriane and I will also answer listener questions and talk about community contribution, plug-ins, themes, tutorials, and the ecosystem of WordPress. And, drum roll, new virtual events formats are coming to WordPress, so stay tuned. We will have the peak view on it tomorrow when we record it. If you haven’t subscribed yet, you can find the Gutenberg Changelog podcast on any of the popular podcast apps. We record tomorrow and then it will be released over the weekend, probably Saturday but sometimes it takes us until Sunday. 

 Speaking of questions, for those of you watching this on the YouTube live stream, use the chat box next to the video player to pose your question and include where you’re watching from. Here on Zoom, use the Q&A button at the bottom of the screen or the chat bubble to share your thoughts and questions. Please be kind, even if you disagree. This is a family-friendly endeavor.

 Well, okay. Let’s start at the beginning.

Why was the block directory actually started?

Why was that necessary or why is it such a great way to install new blocks?

Alex Shiels: Well, it came from Matt’s, what was it, nine projects for 2019. One of which was a new way to seamlessly install new functionality into WordPress using the editor without leaving the editor. That’s basically turned into the block directory, the idea that you can install a WordPress plug-in or, more specifically a block, without ever having to go to the plugin screen or go to WordPress.org or anything like that. You can just search and add it like you would a block that’s already available in core.

Birgit Pauli-Haack:  Well, that sounds really awesome. Are you ready, Kelly? Do you want to do a little demonstration, so we all start from the same platform, so to speak, on knowledge?

Kelly Dwan: Ah, sure. Yeah. 

Birgit Pauli-Haack:  Yeah, it would be great. Well, I’ll say hi Susan from Israel. Susanna, actually. She’s German. We had some connections and did you share the YouTube? Yes, thank you so much for sharing that. I’m going over there and look also, so I don’t miss any questions from there.

Kelly Dwan: It looks like I can’t share my screen.

Birgit Pauli-Haack: You cannot share your screen?

Kelly Dwan: I cannot. No.

Birgit Pauli-Haack:  Why? Nobody gives you… Oops. All panelist should be able to share screens. Try it again.

Kelly Dwan: Um, there we go.

Birgit Pauli-Haack:  All right.

Kelly Dwan: I think.

Birgit Pauli-Haack:  We won. We beat the technology. All right.

Kelly Dwan: I’m having a little technical difficulty. It’s just going to take me a second to do this. Sorry.

Birgit Pauli-Haack:  Well, take your time. We’re staying here with you.

Kelly Dwan: I need to give it permission and I can’t do that unless I quit and restart Zoom. I don’t know, Alex, do you want to do a demo or should I rejoin?

Alex Shiels: Sure, sure. I can do that. Give me a few seconds here. I think I can share my screen.

Birgit Pauli-Haack:  You know if you ever consider what needs to happen that this all works, it’s actually a miracle that it works so often very well. It’s mind-boggling to me. Every time I started working on the internet, which is about…

Alex Shiels: I’ve got the exact same issue as Kelly I think.

Birgit Pauli-Haack:  Oh.

Kelly Dwan: Maybe they changed their permissions?

Alex Shiels: Yeah, I think they must’ve.

Birgit Pauli-Haack:  The Zoom changed permissions?

Alex Shiels: Yeah. Sorry about that. Yeah, the app. I think perhaps when you install a new version or you update it or something it wants to…

Birgit Pauli-Haack:  Oh, yeah. So we all going out and coming back or do you want to…

Alex Shiels: Sure. Do you want to do that Kelly?

Kelly Dwan: Sure.

Birgit Pauli-Haack:  Okay.

Kelly Dwan: Can I just rejoin with that same link?

Birgit Pauli-Haack:  Yeah, please. That’s your Kelly Dwan link.

Kelly Dwan: All right. I will be back.

Moving Parts of the Block Directory

Birgit Pauli-Haack:  Yeah, so, while we’re waiting for Kelly to come back, maybe, Alex, you can say what are the moving parts that kind of make it quite a complex undertaking in the back end of things. It will be very easy for a block editor but in the back end, there are a lot of moving parts that need to play together.

Alex Shiels: Well, yeah, I wouldn’t downplay the complexity on the block editor side. I mean, we’ve tried very hard to make it seamless and look very simple from the user’s perspective so certainly for me, a UI point of view, it just looks almost like you’re inserting a regular block. But yeah, on the back end, we’ve had to do a lot of testing and validation and so on to make sure that block plugins are going to be compatible and actually technically work with the inserter. Because it turns out there are a fair few restrictions that need to be in place. As much as we’d love to be more open about allowing everything, we’ve had to keep it very small just so it’s actually going to work. Kelly, are you about ready? You can perhaps show us what we’re talking about.

Demonstration How the Block Directory Works in WordPress 5.5

Kelly Dwan: Yeah. I can share now. Here. Okay. You should be seeing WordPress.

Otto Wood: Yeah, I see it.

Birgit Pauli-Haack:  Yeah.

Kelly Dwan Excellent. Okay. This is just a dev’s install WordPress so this will be what people see when they install WordPress 5.5. No plugin installed or anything. We’ll go over to posts and pick up editing a post that started. Okay. My local install is being slow now. All right. Here we go. Now that we’re in the editor, if we want to install a new block, or we want to look for something that we don’t have locally, we don’t even realize that we’re installing a new block. 

 All we have to do is search for what we’re looking for. Maybe I want to create a cool header area with some interesting gradients so I can search for gradients. Initially, it searches through the installed blocks but if it can’t find anything, it goes off and looks for anything from the block directory on WordPress.org. So now we see that we have these two results; we have waves and starscape. These both sound kind of interesting but maybe I’ll try waves first. I just click add block and behind the scenes, it’s installing the plug-in for me but I don’t need to know that. It is slow, I think because I’m also doing this video. It is usually faster than this.

Otto Wood: Well, video takes up a lot of CPU.

Kelly Dwan: Yeah. There we go. Now I have this waves block I can move this. I can control it. It’s installed. It’s like it’s a block that has been installed the whole time. Maybe I decide I don’t really like the way this looks, so I could remove it. Let’s look for something else. So, that’s going to show me “Waves”? No. Okay. So I removed it. I think it’s saved so it removed “Waves”. Now I’ll try this “Starscape” block, and we’ll wait for that to install too. Again, this is transparent to the user. No one needs to understand what’s going on behind the scenes, but behind the scenes, we are going and installing the plugin and inserting it into the editor.

Now I love this star night sky thing, so we’ll definitely go with this. I can enter some text here. That was supposed to say title but my computer is not responding very fast.

Birgit Pauli-Haack:  Well, I’m glad that not everybody is a good typer in demo situations.

Kelly Dwan: No, not at all.

Birgit Pauli-Haack:  I can’t type to save my life.

Kelly Dwan: So, if I save this post, you can see that on the front end, which is going to be too slow, so I don’t think I’m going to go see it, that it would have that Starscape block. But we can also go over to plug-ins and it should have it so that only Starscape is still installed, despite you having tried Waves. Since you didn’t end up using it, it’s not just installing and installing plugins for you.

Birgit Pauli-Haack:  Oh, that’s cool.

Kelly Dwan: Yeah. There we go. Only Starscape.

Birgit Pauli-Haack:  Right. Yeah.

Otto Wood: That’s very cool.

Birgit Pauli-Haack:  Wow, yeah. So, we are not ending up with 280 blocks.

Kelly Dwan: Right. You are free to try as many things as you’d like and then only what’s used in that post should be left installed.

Birgit Pauli-Haack:  All right. That’s excellent. Well, we don’t have any questions yet but you can, of course, after this demo, there might be a lot of questions in your heads. Use the Q&A at the bottom of the screen and put them there. Until you do, I take my privilege that I’m the host of the show and ask all those questions that I have. So, you started talking about the moving parts. One of the moving parts is the plugin directory and it needs to have a certain category of blocks or how is that organized?

The Plugin directory & Block Plugin Checker

Otto Wood: Alex, do you want to answer that or should I?

Alex Shiels: Sure, I’ll get started. Yeah, essentially there’s a category within the plugin directory for block plugins. We’ve just recently added a tool, the block checker which you mentioned earlier, that plugin developers can use. If they’ve written a block plugin that they think is maybe suitable for this, a nice, simple JavaScript-only or JavaScript-mostly block, they can use this block checker to check their plugin. Just click a button to add it to the block directory. From their point of view, that’s about all there is to it. I mean, there are certain restrictions and guidelines they need to abide by to make sure it’s actually going to work. But yeah, on the back end it’s all powered by the plugin directory. These are just a particular type of plugin. Yeah. Otto, did you want to expand on that?

Otto Wood: I mean, you pretty much nailed the basics. It’s really just, internally, sort of taxonomy tag that we used to differentiate these specific single-block plugins that should show up in the block inserter. We can expose that through WordPress.org. I think we do. I’m not 100% on that right now.

Birgit Pauli-Haack:  Yeah, we do.

Otto Wood: There is a way to expose those so you can browse them and view them and things like that. Realistically, the main thing was they needed to be, at least for the first iteration, they needed to be very simple and very basic plugins. So, the block checker you were talking about is the most important part of, at least in the plug-in directory side, the most important part of this whole venture. Because we need them to be simple and straightforward and not add anything; just be very basic, almost JavaScript-only plugins. I think that was literally the hardest part of creating that system, which these two people did. Thank you very much for doing that.

Are there any plans for a browse blocks feature?

Birgit Pauli-Haack:  Bud Kraus already has a question, and he writes, “The block directory assumes users have a certain UI vocabulary. If a user doesn’t know they need an accordion, they can’t search for it. Are there any plans for a browse blocks feature kind of thing?”

Otto Wood: Well, obviously, browsing is built it but I think that, as far as searching goes, we have to see what happens first. If people are searching for terms, then we need to come up with a vocabulary of what people are searching for in order to show them things that are most relevant to their answers. I’m not sure what a synonym of accordion would be in this case. But once we get some search done and I record the queries on it, then we can probably come up with some kind of way to make things more obvious and work better in terms of giving users better results. Currently, the plugin directory is using Elasticsearch. The block directory probably uses the same search but a much more limited search, obviously. I’m not 100% on how that-

Alex Shiels: Right now it’s using a very limited search, but we are very shortly about to switch it over to Elasticsearch. The search will improve.

Otto Wood: Yeah, exactly. We can probably do something like that and it will recognize terms and synonyms, things like that the plug-in directory already has, just not there yet. We’re getting there. It’s one step at a time. 

Birgit Pauli-Haack:  One thing is also that plugin developer can put some categories or some keywords into the block itself to take care of that as well.

Otto Wood: Sure. The tag system is basically how they do that.

Can I adjust the editor different for different roles?

Birgit Pauli-Haack:  Yeah. So, we have more questions. Susanne has, “Can I adjust the editor different for different roles?” I’m assuming there’s contributor to editor to author to administrator. I think the block directory has some capabilities restrictions there.

Otto Wood: The block inserter as far as I know is tied to the plugin install. You have to be able to install a plugin to install a block. Right now, I think it’s the same. I’m not sure if it’s separate, and they just tied to it.

Kelly Dwan: No, it’s the same. It’s using install block plugin or something like that. I think it’s only admins.

Otto Wood: So administrator only, basically, is what, by default, plugin is. If we are able to create a system where those plugins are very limited, and we can prove they’re very limited, then that might be expanded in the future. It’s an idea. Maybe we can come up with a separate role install block or something like that. That way it would be basically the same but since we know it’s a limited block plug-in that can’t do anything, then possibly-

Birgit Pauli-Haack:  Well, it can do a lot.

Otto Wood: Or that can’t do anything dangerous. Plugins are very strong. They can do a lot of things. If we’re going to limit it to blocks that are very limited in what they can do, maybe a Sandbox kind of atmosphere, then there’s a possibility we could have it install by users less than administrators; by editors or authors. Maybe not authors. Contributors, something to that effect. Editors at least.

Is there a way to limit what plugins are available for the site user to install?

Birgit Pauli-Haack:  Yeah, and John Richards has a question, said, “Beyond the turning the feature on and off, is there a hook to add filters to limit what plugins are available for the site user to install?” I don’t see that’s yet implemented in the block editor.

Otto Wood: I don’t believe so. It’s just, right now, searching for very specific, limited category. We don’t have a lot of block plugins there yet. 

Birgit Pauli-Haack:  Four pages or five pages. Yeah.

Otto Wood: It’s pretty limited. It’s less than 100.

Alex Shiels: It’s about 85, I think, at the moment.

Birgit Pauli-Haack:  Oh, that’s good. Yeah. So-

Otto Wood: So that could be filtered. There are probably filters there to do it, but they’re not specifically there for that purpose.

Birgit Pauli-Haack:  Yeah, I think the block editor only has in the theme, you can allow certain core blocks or the theme blocks, but not for the block directory yet. So Ian Misner has, “A permission that defaults to the same restriction but can be changed with the role editor would give the site owner the choice.” Well, the site owner normally has administrative privileges to install plug-ins but if they have editors then I don’t know if the user capabilities plugin can add that to it without… Yeah, not the plugin. Sorry.

Otto Wood: Well, if the capability doesn’t exist in core then just adding it with a plugin wouldn’t do anything. At some point, as the block editor expands, new capabilities would probably be added for it. At present, there’s nothing there for that.

Is it possible to have ablock be installed with an official CDN for the JS code itself

Note: CDN – Content distribution network

Birgit Pauli-Haack:  We have a question from Marius Jensen. Quite a deep, technical one, I think. “Would it then technically be possible to have block be installed with an official CDN for the JS code itself so you do not need to install the block code locally on your site’s server?” I see you smiling, Alex.

Alex Shiels: Yeah, yeah. That’s initially how it worked. We were actually loading the JavaScript from the WordPress CDN. But about a month ago we switched that to loading locally to help with various sorts of problems that we were running into. Do you want to expand on that a bit, Kelly?

Kelly Dwan: Sure. Let’s see. I think there are two parts to this which is that you still probably need to have some PHP installed from the plugin if you’re doing anything with an API call so you can’t just rely on JavaScript CDN. That was one thing that we were running into. Then the other issue I just think was with asset detection was we weren’t consistently finding those JavaScript files. Loading things locally made that a little easier. That’s about what the problem were.

Alex Shiels: Yeah, and we ran into those problems with translation as well. I mean, yeah, in a perfect world if we designed this from the ground up independent of WordPress plugins, then we probably could have done it from a CDN. But plugins being so flexible, there are so many different ways of initializing code and loading things and so on, that we just found it pretty much impossible to only load it from a CDN. Installing the plug-in actually lets us find all of those assets and initialization things and so on that are needed for it to actually work.

Birgit Pauli-Haack:  Yeah, I can see that that being in an existing ecosystem being so much easier than starting a new one, even if the new one would be new ground and new innovation or something like that. That can still help and there is an initiative out of the Netherlands that have this Gutenberg block repository that works for if you install a plugin on WordPress or a plugin on Drupal, then it would tap into both in that particular directory. You can download it. I think they didn’t get anywhere yet because there’s not a whole lot of traction on that. 

Will the queries that people are using be available anywhere for developers to help assess what needs to be built?

 So Ian has another question, a follow-up question. No, it’s not a follow-up. It’s a new question. “Will the queries that people are using be available anywhere for developers to help assess what needs to be built?” That’s an interesting question, Ian. Thank you.

Otto Wood: At present, we’re not even recording them, so no. Until we record them, the answer is a very simple no. Because 5.5 is not out, we don’t know where it’s going yet. We don’t record data that we don’t know that we need. A lot of people think WordPress records a whole lot of stats and information. That is not true. We throw away most stats, most queries. We don’t record things until we need them so at the point we need them, we’ll record them and make that available. But until we need them, we don’t have that information. No.

Guidelines and Rules for the Block Directory

Birgit Pauli-Haack:  Yeah. Okay. So, we have the moving parts. We have the block directory. Should we talk about the eight guidelines that you had or what makes a good block to get into the directory and use? Besides the block checker, there were a few things like you had some eight rules. One is block plugins are for the block editor, which we established. Block plugins are separate blocks. Plugin titles should be reflected in the block title. So, when someone looks for something, it’s not the brand or trademark or something like that. It’s actually that users know what they’re getting. They must include the block.JSON file. Then it must not require payment or a paid account to function. Block plugin should work independently and server-side code should be to a minimum and not promote other blocks, plugins, or themes. Those are the preliminary guidelines. How do you feel about that? And, Bud, we go to your question right after that.

The block.JSON file

 So I have a few questions about that. The block.JSON file. Can you help us with that?

Alex Shiels: Yeah. So, the block.JSON file is something that users don’t need to worry about, but for developers, it contains the metadata like the title and block name and those kinds of things, the JavaScript path name, and so on, for a block. It’s currently possible for blocks to work without one of these, but we would really like developers to use this metadata for their blocks because it means everything is in one place. Going forward, it will help with Gutenberg itself as a more consistent way of initializing blocks.

Otto Wood: Standard format.

Alex Shiels: Yeah, yeah. Single place standard format for all of this stuff, so we can pick it out for indexing it in the plugin directory, in the block directory. It’ll all be there when the block gets inserted seamlessly. It means you’re not duplicating stuff between JavaScript code and PHP code and everything. It’s all in one spot.

User-triggered search in the block directory

Birgit Pauli-Haack:  Yeah, I think in WordPress 5.5 there is actually the feature in there to use the block JSON for your PHP code as well; register block type code as well. Excellent. So Bud Kraus has the question, “If a user installs a block from the directory but doesn’t like it and wants a different but similar block, they can’t get access to it because the search recognizes the previously installed block. What plans are there to resolve this rather than just uninstall the block which is an inelegant thing to do?” I think what Bud is asking is for a user-triggered search in the block directory. Kelly, do you have an answer for that?

Kelly Dwan: I don’t have an answer. I know you created an issue in GitHub for this, though. 

Birgit Pauli-Haack:  I did.

Kelly Dwan: So I think it’s something that would happen in the future but not for right now. If an existing block matches the search term, it will not search the block directory.

Birgit Pauli-Haack:  I think that makes sense in the first iteration to kind of keep it that restrictive. Why would you search for them? Use what you have. Why install additional things? Yeah, I get it but I can see that that is further down the road. I think Mark also put some designs together to how that could flow. Well, thanks, Bud. That was a very good question. I’ll share the GitHub issue number in the show notes, so to speak, so you can all advocate for it. That’s how it works in WordPress. You need to have good arguments and discussions about things. 

Server-side code should be kept to a minimum.

So I’m just looking through the other questions right now. There was another question that I had out of those guidelines. Server-side code should be kept to a minimum. Did you find a number for that or first kind of explain a little bit how you measure that? Then what is a good number and how do you check that?

Alex Shiels: That’s a great question. We have put in some arbitrary numbers into the block checker. If it’s more than so many kilobytes of PHP code, it tells you it’s probably not a good idea. It’s really not about the size, though. We’ll refine those checks as we can. The reason for us wanting to limit the amount of PHP code is because if your block is too reliant on PHP, it just won’t work in the inserter. It would rely on a refresh of the page, essentially, for it to work. 

Birgit Pauli-Haack:  Oh, okay.

Alex Shiels: So yeah, we have used some arbitrary limits on, I don’t know if it was 50 kilobytes or something. If there’s more than that amount of PHP code in there, it will start to warn you about it. But that’s very much just a stopgap. If we could in some way check and make sure that the PHP would actually work, then we would do something much more specific like that. I do hope to refine the block checker over time so we can be more helpful than just saying, “Here’s the cut-off.”

Birgit Pauli-Haack:  Yeah, the block checker is actually also working with a plugin that is not yet in the repository so you can actually put your GitHub repo URL into it and it checks it from there. That is really marvelous. I loved it when I tried it out with my plugin that has a lot of bugs but it would pass the block checker. 

Speaking of PHP and minimum, there is one type of block that a lot of people use that’s a dynamic block. So, things are in the database, but they rendered in PHP. Is that all kind of included in that stopgap there?

Alex Shiels: Yeah, so that kind of block won’t work at all. It really needs to be a JavaScript rendered block. And again, I mean, this is not because we hate PHP. I’m a PHP developer from way back. It’s simply because of what’s technically possible. If it’s going to work seamlessly as soon as you insert a block like that, it’s really got to be JavaScript mostly.

Birgit Pauli-Haack:  Okay. Yeah.

Kelly Dwan: So I’d actually say that if you’re using a dynamic block and you’re using server-side rendering to render it, it should still work in the block directory. Because that’s actually an API call, it doesn’t need to reload the page.

Birgit Pauli-Haack:  Good to know.

Kelly Dwan: That rendering is done because the plugin is already installed. It’s done locally and that actually passes. If you need to set it up somewhere else, that’s when it won’t work in the editor. It needs to be smooth flow.

Otto Wood: Right, if it has configuration.

Kelly Dwan: Right.

Otto Wood: I think a lot of, at least this first draft of the block directory, it’s all about getting the blocks that are mostly user interface. If you get right down to it, a block is basically just a user interface to create some very simple HTML, usually. Not always. It could be more complex. But it’s a JavaScript interface to give a user interface to make HTML simpler. That works better if it’s in the browser as opposed to having to go back to the server every time and be slower. JavaScript for blocks is better. Not always the case. Some more complicated things are fine but those can be added later to the block directory or to other plug-in that do a lot of server processing or anything like that.

Birgit Pauli-Haack:  Yeah, I understand. That’s interesting.

Could we have a preview of our blocks outside the editor?

William Patton has a question. “Could we have a preview of our blocks that is outside the editor, something like the theme previewer.”

Alex Shiels: We actually did some experiments with this idea early on and it is something I’d like to revisit. One of the initial ideas for inserting the block into the editor was to basically insert a preview rather than the actual block. We went down a different road. But yeah, I think we probably will revisit that idea at some point. I really like the idea that you could go look at these blocks in the plugin directory on the website, see the block itself, maybe even interact with it, and try it out there as well. I mean, whether that’s a really important path for user to follow, maybe not. I mean the whole idea is that you can do all this from the editor. We haven’t spent a lot of time on the website because it’s kind of a secondary thing. But sure, we’ll probably revisit that idea. I don’t exactly know, other than on the website, where the preview would be shown. Perhaps, in a block management screen or something like that. But we’ve got a bit of code hanging around somewhere that we could dig back out and try and refresh.

Birgit Pauli-Haack:  So blocks that are already installed, when you hover over them you get a preview panel in the inserter. The question would be before you install it, can you see the preview? That’s kind of where it would help the user to decide is that something that I want to install? Does it do what it’s supposed to do? That would be really helpful.

Otto Wood: That could be something that you could put into the block JSON which we could deliver via the API so it’s totally possible.

Birgit Pauli-Haack:  Yeah, I can see the plugins have the screenshot part so you can see that. Normal plugins. But for the preview, you could just an insert in there, and then it kind of can push through that. It would be an interesting way to do that. Yeah. 

How would the block directory evolve as Gutenberg begins to include Widgets and Navigation

 John Richards has another question. “Have you thought about how the block directory might evolve as Gutenberg begins to include Widgets and Navigation?” Somebody wants to take that?

Otto Wood: I mean I’ve thought about it. I have no idea where it’s going but I have thought about it. Full site editing is a confusing thing that is still being developed. So until we know where themes are going, it’s a little hard to guess where the block directory has to go. Once we have an idea of what a full site edited theme looks like, then it’s a little easier to determine what kind of blocks do we need? How do we integrate these ins? So on. It’s an evolving thing. I’ve seen some really neat stuff made with the beta full site editor in Gutenberg but I haven’t seen anything that is quite production-ready. One thing at a time is really what I would say on that. 

 Once themes change, then blocks will adapt to fill the space that is needed for them. Since blocks is fairly simple, really when you get right down to it, I think that the block directory idea can evolve to adapt. But yeah, no idea. It’s up in the air.

What does it mean: independent functioning block

Birgit Pauli-Haack:  Yeah. So, I have a question for another part of the guidelines that it needs to be an independent functioning block. But there are I think a few in there in the directory that I saw that actually have a parent and child relationship, so they have one block and then there are kind of other additional children in there. I haven’t seen an FAQ yet, but I think that’s kind of coming soon. Anybody will pick it up so how does that work?

Otto Wood: You mean like the nested block idea?

Birgit Pauli-Haack:  Yeah.

Otto Wood: As far as I know, those are fine. Those are still one block they just have separate sections in that block. I have to admit, I’m not as familiar with the JavaScript as I should be but those are still one block, so they can fit in the block directory just fine. They’re block within blocks.

Kelly Dwan: Yeah, it’s one parent block and that’s the important part is that there’s one FAQ. Then it may contain some question and answer blocks but those aren’t exposed as top-level so it’s all still one block to the block directory.

Birgit Pauli-Haack:  Oh, I understand. You cannot have a question block without the overall FAQ block.

Kelly Dwan: Exactly. Yeah.

Birgit Pauli-Haack:  All right. Okay. That was one. The other part was on the independent functioning is if I want to have Google Maps on there and Google Maps now also requires that you not necessarily always but also a Google API key that you need to put in. If it’s in the interface and you don’t have to go out of the block editor to pick that, is that possible that those blocks are getting into the block directory?

Alex Shiels: I would say it’s likely that they’re getting in at the moment. This is the kind of nuance that really we just need to work out, I think. The idea is for this to be seamless. I’d really love it if we could make these things work or if developers could make these things work where you don’t have to go, sign up, get an API key, and go through a whole bunch of hoops like that. If it would just work with a click, that would be fantastic. But of course, this is the real world and it doesn’t always work that way. So, we’ll figure out ways of refining these guidelines and recommendations so that we can deal with reasonable things like this.

Birgit Pauli-Haack:  Yeah.

Otto Wood: Well, also ultimately, all plugins get reviewed before being added so if somebody has a really good reason to have something there that has an API key entry in the block itself or something, we’ll take a look at it. The plugin review team will look at it and see what’s what. Until we have those submitted and to see what plugin authors come up with in terms of user interface, it’s hard to say. Whoever comes up with the best user interface wins. This is open source. Feel free to build whatever you like, and we’ll take a look at it.

What about block variations?

Birgit Pauli-Haack:  Yeah, that’s kind of the challenge for the plugin developers now to kind of find out what works and what users need. What about block variations? So, I could have one block and then 16 different variations. Would that still work?

Kelly Dwan: Yeah, if your variations are on the block that you’re submitting, then they’ll work because that’s still just one block to the block directory.

Birgit Pauli-Haack:  Oh, okay. I have my block and then I have variations to the core blocks, that would be two different things.

Kelly Dwan: Yeah, if your plugin only added variations to the core blocks, that wouldn’t work because if you think about the demo I just did, if you added the block that just variations, there’s nothing to show up in the editor. It needs to expose a single block that can be added to the editor.

Otto Wood: Sure. Variations or additions to blocks, not blocks themselves.

Kelly Dwan: Yes.

Otto Wood: But you can have one block and then add a bunch of variations to it all in the same plugin.

Kelly Dwan: Yeah.

Are there any considerations about block patterns?

Birgit Pauli-Haack:  All right. That’s cool. Yeah. Are there any considerations about block patterns? Is that the same story then? Block patterns are actually coming from core blocks, right? But you could put them in the inserter at some point. Does it already work for the block directory?

Kelly Dwan: So I think right now they’re two separate features, block patterns just being kind of a collection of blocks you can add. There isn’t a connection to the block directory at the moment, but potentially down the road, we could have something like that where if you add a pattern that has a block that you don’t have installed, maybe it knows to go and look in the block directory. That would be cool.

Birgit Pauli-Haack:  Yeah. It would be.

Otto Wood: Block patterns are still kind of new. It’s sort of a template of blocks going together.

Birgit Pauli-Haack:  It’s going to be new in 5.5. A whole lot of people have seen it but a lot of people have not seen it.

Otto Wood: It’s new to the point where we haven’t built an API for it. The idea of it is clever. I don’t know where it’s going. Until we know what’s needed, we don’t have a block patterns directory. This is just for blocks for now.

At what point does the uninstall actually happen?

Birgit Pauli-Haack:  Yeah. So we’re still having a few minutes on our time here together so if you have last-minute question. We have another 10 minutes and I’m just going to have another question for you. When you were doing the demo, Kelly, you were testing out two blocks and only one of them was installed. When I was testing that out a bit, I actually never got to that point. In the process of how I did my content, I obviously tricked the block directory not to know that it needs to uninstall something. What do I need to think about there?

Kelly Dwan: Yeah, that flow is also definitely something that needs to be improved. This is still where you can see the initial version edges, I’d say. So, that will work if you don’t refresh the page in the time between you start installing blocks and then you publish your page or you save your draft; just for technical reasons, the way it hooks into the editor.

Birgit Pauli-Haack:  Yeah, so I’m still kind of old school that I want to put something in there, save it, and then preview it. That’s the moment where I’m probably going to fool the block directory. It doesn’t know that I actually don’t want it. Because in the published version it’s not in there, but that’s not where it kind of hooks in. Okay.

Kelly Dwan: When you load up the editor, it has no way of knowing what plugins you’ve installed that you want and what ones you’re just trying out. That’s the issue you’re running into. Yeah.

Birgit Pauli-Haack:  So I can see a flag feature coming up.

Kelly Dwan: Something like that. We’ve talked about a few different ways of approaching this and that’s another one that will just continue to be improved.

Birgit Pauli-Haack:  I saw a few explorations, I said, on their design for the sidebar at one point to have an overview of which plugins were installed in that session. Then to maybe uninstall them, not automatically, but on user interaction.

Kelly Dwan: Yeah, if you save the draft, it should uninstall any plug-ins that you haven’t used yet.

Birgit Pauli-Haack:  And that was also that William Patton had. “At what point does the uninstall actually happen?” That’s on the save.

Kelly Dwan: On save, yeah.

Birgit Pauli-Haack:  On save.

Kelly Dwan: Either publish or save draft. Either as long as you’re saving the post.

Birgit Pauli-Haack:  So it’s not the autosave. It’s the save as draft kind of thing.

Kelly Dwan: I’m not sure. Sorry.

Birgit Pauli-Haack:  Well, then you really need to be really fast with your decision.

Kelly Dwan: I’m pretty sure it doesn’t run on autosave but I actually am not sure.

Birgit Pauli-Haack:  I’m pretty sure it does because autosave on my site is every 15 seconds and I’m not that fast in my decision making.

Kelly Dwan: It wouldn’t uninstall a block if it’s in your editor, though. So if you’re using it, it’s not going to disappear on you.

Birgit Pauli-Haack:  Yeah. Of course, yeah. I had hoped that it wouldn’t. Yeah. Any more question? Going once. Going twice. Wow, this was awesome. We had some great questions here from the audience. Thank you for Bud and Susanne and John and William. We are pretty much at the end of the show but at this point, I have two more questions for you, Alex, Otto, and Kelly. Do you have any announcements or tips and tricks that you couldn’t get in before that you want people to keep in mind about that? And if people want to get in touch with you, what would be the best way? Otto, Alex, Kelly?

Alex Shiels: One thing I’d love to mention is that we’ve got 80-odd blocks in the directory at the moment, which is fantastic. But we’d love to hear more from plugin developers and so on who are trying to get their blocks in or wondering how to develop these. Yeah, if nothing else you can find us in the #meta channel on Slack. I’m sure you’ll have some links in the show notes to the guidelines and some of the tutorials and things that are available. 

Birgit Pauli-Haack:  Yeah, we’ll put them together. I’m going to come back to the question. Do you have on the plugin team, Otto, some bandwidth to reach out to some of the plug-in developers that have already block collections in there? Or other single block plug-ins that didn’t make it yet?

Otto Wood: Some of them have asked us about that. If you’re a plugin developer and you have questions about the best way, advice how to get into the block directory, feel free to email the plugins team. It’s plugins@wordpress.org. Email is the best way to contact the plugins review team. That goes to our Help Scout inbox. All of the different team members can review it, read it, and we can pass it along to each other. A lot of these collection plugins have been asking how to get in there. Our general answer is to make them not collection plugins right now. Single block plugins are the easiest way. They’re small. They’re easy. They fit right in. But for some of them, that may not be the best way. Basically, just ask. It never hurts to ask. Plugins@wordpress.org is the best way to get in contact with the plugins review team.

Birgit Pauli-Haack:  Awesome. Thank you very much, Otto. Kelly? Do you have anything that you want the people to know that I wasn’t able to ask you?

Kelly Dwan: I would have probably just said the same as Alex. I would love to hear from people who are trying to develop blocks, or maybe if you’re running into issues to come hang out in Slack. I want to hear what people are having problems with so we can make it better. That’s my thing.

Birgit Pauli-Haack:  That’s awesome. Yeah. I think quite a few discussions are happening on GitHub as well. So, if somebody have issues, you’re also developing on GitHub, right? Meta.Trac or GitHub.

Alex Shiels: Yeah, all of those things. It’s all over the place.

Otto Wood: It’s a big combo. There are a lot of things happening. So yeah.

Birgit Pauli-Haack:  But it’s somewhere that people can see it.

Otto Wood: But it’s all coordinated in Slack. So if you just join the Slack, somebody will tell you what’s going on.

Birgit Pauli-Haack:  All right. This is awesome. Thank you so much for joining us tonight, or this morning. It was great to learn from you and see what this new feature is doing for the WordPress ecosystem as a whole. Big thank you also to the viewers with all the awesome questions. If you have more question, you can always send them also to me via email at pauli@gutenbergtimes.com. That’s P-A-U-L-I at Gutenberg Times dot come. The recording of the show is available in a few minutes on our YouTube channel and we’ll publish the transcript in a few days on the GutenbergTimes.com. I also will add the links to the YouTube description while we don’t have it posted on the Gutenberg Times. Thanks again, Kelly, Alex, Otto. It was a privilege to have you on the show and a great joy talking to you. Goodbye and good luck.

Alex Shiels: Thank you so much.

Kelly Dwan: Thank you.

Otto Wood: Thank you.

Birgit Pauli-Haack:  So thanks, Susanne. Thanks, William. William says, “Thanks for the discussion tonight. I’ll be sure to be annoying with questions in Slack. Ha, ha, ha.” Yeah, that’s a threat. You all take care. Bye.

Related Posts