Block Directory: a New Way of Extending WordPress

Updated: August 28, 2020:
In August 2020, the Block Directory was released with WordPress 5.5.

On August 7th, 2020, we published an article on the Workings of the Block Directory: Block Directory Slated for WordPress 5.5.

In our August 6th, 2020 Live Q & A Show we discussed all the ins and outs of the Block Directory with the meta-team members Kelly Dwan, Alex Shiels and Otto Wood. You can watch now the recording and read the transcript: Live Q & A: Discussing the Block Directory in WordPress 5.5

In July 2020, I gave a talk at the JavaScript for WordPress conference 2020 on WordPress Blocks: From Code to Plugin Repo, a walk-through the Single Block “Create-Block” scaffolding script and relevant pieces for the Block Directory

---

January 13, 2020

The Block Directory is going to impact Gutenberg and WordPress is some amazing ways. It’s a new way of extending WordPress in a very granular way.

At WordCamp US (2018) Matt Mullenweg announced the nine priority projects for 2019 and the Block Directory is one of them. The task is “Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them.” In August 2019, we checked in with the Team working on this task.

Back in August 2019, we had a very insightful Live Q & A with the team working on the Block Directory, Mel Choyce on the Design team, Alex Shiels and CK Lee from the Meta team.

Mel walked us through the prototypes and explained it all from the user’s point of view. You can search within your block inserter for a new block and it will show you some options, and once you select it, you can use it in your posts. In the background it is downloaded to the site. If you decide to not use it after all, it will be uninstalled again.

Extending WordPress on Block at a time

Then Alex explained how it will work in the back-end and how plugin developers can interact with the directory. It’s going to be a subsection of the plugin repository, and will list single blocks plugin with a specific block.json file.
CK Lee is almost done creating the Gutenberg relevant pieces in the inserter and handling the search, the preview, install and de-install. We also had some great questions from the audience.

To be release with WordPress 5.5

Josepha Haden, executive director of the WordPress project published in her “Update: 9 Projects for 2019” that the targeted version for the Block Directory is WordPress 5.5, scheduled to be released in August 2020

Earlier versions will be part of the Experiments in the Gutenberg plugin release in between.

In December 2019, the meta-team release the draft of Guidelines for block plugin submission to the directory and the design team published the v1 for the WPAdmin

To start testing your single block plugin for this new feature, connect with Alex Shiels (username: @tellyworth) in the #Meta channel on the WordPress team Slack.

Below is the list of make blog posts from both teams with ideas, discussions and specifications of this awesome new feature. A transcript of the show is available below, too.

Resources about the Block Directory

• Update: 9 Priority Projects
• Nine Priority Projects

Gutenberg Team

RFC for Block Registration in Gutenberg

Design Team

• Dec 19, 2019 Block Directory in WP-Admin: V1
• Mock-ups on Figma
• Jun 7, 2019 Block Library: Mockups & Prototype
• May 28, 2019 Block Library: Initial Explorations
• May 17, 2019 Block Library: Competitive Analysis Recap
• Apr 26, 2019 Block Library: Installing Blocks from Within Gutenberg

Meta Team

• Dec 6, 2019: Block Directory plugin guidelines
• July 31, 2019 Block directory Update
• Mar 28, 2019 The Block Directory, an a new type of plugin
• May 8, 2019 Block Plugins and the Block Directory

Community Voices

Jan 13, 2020: Justin Tadlock: Can the Block Directory and Business Interests Coexist?

Transcript of Q & A about Block Directory

Birgit Pauli-Haack: All right. Hi there. Hello.

Welcome to the 18th episode of the Gutenberg Times Live Q & A. My name is Birgit Pauli-Haack and I’m the host and the curator of Gutenberg Times. Thank you all for joining us tonight. It’s so great to have you.

In today’s show, we will discuss a completely new feature for the block editor, the block directory. What it is, how we will use it, and how plugin developers can have the single blocks listed, is what we will discuss tonight, and so much more. I’m honored to have with me Mel Choyce, member of the design team and product designer at Automattic. I have Alex Shiels, team lead on the Meta team and developer and code archeologist at Automattic. And CK Lee, also a member of the Meta team and JavaScript developer at Automattic. All right. We’ll do proper introduction in less than a minute.

I have a few housekeeping notes and one announcement. I just want everybody to know that tomorrow we will record the fifth episode of the Gutenberg Changelog podcast and we will cover the latest Gutenberg plug-in release, 6.4, that came out yesterday. We also discuss features in active development, so those that are interested can chime in on the discussion on GitHub or the link blogs. We also answer listener questions we receive via Twitter or email. If you’re not subscribed yet, you can find us on any popular podcast app, just search for Gutenberg Changelog.

Speaking of questions, if you are watching on the YouTube live stream, use the chat box next to the video player to post your questions, and include from where you’re watching. Here on Zoom, use the Q&A on the bottom of the screen, or the chat bubble to share your thoughts and questions. And please be kind, even if you disagree. This is a family-friendly endeavor. Please say “Howdy” via chat!

Block Directory on WordPress.org – A priority project for 2019

So, that’s about that. What’s the show about? Well, throughout the year 2018, especially after Gutenberg was introduced at the  DrupalCon, the questions about a better way to discover blocks and organize them started. People in the Drupal community started a Gutenberg cloud initiative, exploring a way to share blocks across different content management systems. It’s an intriguing idea but at WordCamp US, Matt Mullenweg announced in his State of the Word the nine focus projects for 2019 and the block directory is one of them. The task is building a WordPress.org directory for discovering blocks and a way to seamlessly install them. It’s now August 2019 and we are checking in with the team working on this task.

So, well, I’m thrilled you all agreed to come to the show, and I get an hour with you talking about the block directory. But first, tell us a little bit about yourself personally, and I have the same questions for all three of you. So who are you, where do you live and what you do to unwind away from the computer? Mel, you want to start?

Mel Choyce, Designer at Automattic

Mel Choyce:  Yeah, sure. I’m Mel Choyce. I’m a designer at Automattic, and I live in Boston, Massachusetts, so streaming from my office. I play drums and I play bass. I’m in a band, so a lot of my time has been spent doing that recently when I’m not on my computer.

Birgit Pauli-Haack: That’s creative. Awesome. Alex?

Alex Shiels, developer at Automattic since 2007

Alex Shiels: Yeah, I’m Alex Shiels. I work at Automattic, have done for about 12 years now. I live in Melbourne, Australia, and I’m in my living room right now which is where I usually work from. When I’m not working, I’m a keen amateur photographer. I like to get behind the camera, not in front of it usually.

Birgit Pauli-Haack: Well, so this is a special place now. We have you in front of the camera, am I right?

Alex Shiels: Mm-hmm (affirmative). For once.

Birgit Pauli-Haack: Just a follow up for Alex. Automattic was founded in 2006.

Alex Shiels: Correct. Yes. I came on in 2007.

Birgit Pauli-Haack: Yeah, so you employee 30, or something?

Alex Shiels: I think about 15. Somewhere around there. The first meetup was pretty small.

CK Lee, JavaScript developer at Automattic

Birgit Pauli-Haack: All right. CK.

CK Lee: I’m from New Zealand and Alex is my team lead, and I’ve been a java script developed for a long time. I joined Automattic probably five or six months ago, and what I do to unwind. I have a young family, so as you know young family, to unwind, you basically try to sleep as much as possible. So that’s what I do.

Birgit Pauli-Haack: Yeah, I can imagine that. So how big is your family?

CK Lee: My wife and I have a fourteen month old daughter now, and a dog that we usually take the dog out for a long walk on weekends, too.

Walk-through Prototypes and Mock-ups of the Block Directory

Birgit Pauli-Haack: Yeah, that’s fabulous. Fabulous. So the project itself, the block directory, spans multiple teams, obviously. Design team, meta team, and also on the Gutenberg editor team. Mel, you have done a lot of work around the mockups and the design for the block directory, not only of this part but also around how it all fits in WordPress admin kind of context. But could you please walk us through the various parts of what will make the block directory when it’s finished? What’s the vision and how will it work for content creators? If you want, you can share your screen.

Mel Choyce:  Yeah, let me get that set up. Okay, so you should be seeing Figma right now.

Birgit Pauli-Haack: Yes.

Part 1: Install Blocks directly from the editor

Mel Choyce:  So the block directory, the design portion has had three parts. The first part we wanted to explore what it would look like to install a block directly from the editor. So say you’re searching for something and right now you don’t have it installed, you get a no blocks found message, which is pretty sad. The goal with this is that if there are no blocks found, we do a search of the directory and then we pull in results, say the top three results from there, and then link off to other ones.

Doo doo doo. Here we go. Yeah, this is the right screen. So you go to look for a block, and let’s say I try to look for a slider block. I don’t have a slider block installed on my site yet, so what it does is it searches the directory and finds the top slider blocks and so you can preview them, check them out, and then when you drop them into your page or post you can customize them. And so what we’re doing is actually installing the block on the back end while you’re doing this. We have various error states if it doesn’t work out, and then once you filled it out, you can go and publish your post and we’ll give you kind of like a preview of what you added when you were writing this page or post. In this case, we’re saying you added one new block, just so you can kind of remember what you did.

If you decide you don’t like this block, you want to get rid of it, we’ll silently uninstall for it you. So you aren’t really … you don’t have to worry about the installation process unless something goes wrong, like you lose your internet connection, and you don’t have to worry about getting rid of it if you decide not to use this block. Especially if you want to try all the top blocks that we show in those results, you can end up picking the one that’s best for you and then not having to worry about going back and deleting the other ones later.

So pretty much as soon as you publish, that block is there. It’s on your site.

Birgit Pauli-Haack: All right. And the others are already installed if you tried them in between and they are not … yeah.

Mel Choyce:  Yeah. So you add them and you’re like, “Uh, no. This doesn’t have the options I want.” You get rid of it. You remove the block from the post and when you go and publish with your final selection, that one is installed and the other ones aren’t.

Birgit Pauli-Haack: Right. And I think what ties all this together, you go back to the screen where you search and you get the options that are down in there. Those are then … the idea is that those come from the block directory that’s on the plugin on the WordPress directory, WordPress.org directory.

Mel Choyce:  Yeah.

Birgit Pauli-Haack: Yeah. So that piece has … I think that’s what the meta team right now is working on, to make that the push. Awesome. Yeah.

Mel Choyce:  Yeah, and if you wanted to browse more blocks, that would bring you out to the WP admin section.

Birgit Pauli-Haack: Oh, okay.

Part II: Block Directory in the WP Admin 

Mel Choyce:  So that’s step two, which is the actual directory in WP Admin, and so, so far that looks like this. There’s a post up on MakeDesign that has a link to this and some screenshots. It would be a new section in WP Admin that’s about blocks, and so you might notice the header is a little bit different. We’re trying out a new pattern that we can potentially use across the entire Admin just so everything’s a little bit unified. If you wander around WP Admin, you know that there’s a lot of different sections that pretty much look totally different.

So it’s kind of like an intro, some basic documentation and some FAQs and then a link out to get help. The landing page is really focused on education, and then you go into adding blocks. Like the plug-in and theme directories, you could see some featured stuff, some popular, some stuff recommended to you based on whatever algorithm you’re using. These would be just like curated categories. I’ve just pulled out some random stuff for now.

Birgit Pauli-Haack: If I understood this correctly, those would not be plugins. That would be single blocks, right?

Mel Choyce:  Yes. Single blocks. Correct. So, one of the big goals with the directory is that when you download a block, it’s only one block at a time. For instance, right now you might be like, “Oh, I really like the container block in this plug-in and I really like the testimonials block in this plug-in,” but right now to get either one of those blocks you have to download usually a suite of blocks. So you’re like, “Oh wait. Which container block did I like? Oh, I don’t need this. I don’t need that.” So the goal is really to focus on one thing at a time and so when you are downloading a block, you’re just downloading that one block.

Birgit Pauli-Haack: Awesome. Yeah.

Part III: Block Management Screens

Mel Choyce:  And then we just have like a couple management screens, for seeing all the blocks that you’ve installed, managing all the blocks you have on your site. You could hide certain blocks. Right now, this screen is … you could do this in the editor itself, in this modal, so it’s like bringing that out into a different kind of WP Admin managed screen.

Birgit Pauli-Haack: And I think in the editor, you only can do this for this particular post or page, not over the whole site.

Mel Choyce:  Oh, I thought it was site wide.

Birgit Pauli-Haack: No, when you click on the little icon up there, that’s just the whole.

Mel Choyce:  Oh. Well, I didn’t know that. So this would be for your whole site, so.

Birgit Pauli-Haack: I do have posts where I have 190 blocks in there, but it’s all one post.

Mel Choyce:  Yeah. That’s a lot of blocks. So far, we haven’t really addressed the scaling issues yet and so having this block directory and these management screens is another way to kind of help with the fact that blocks are going to explode and scale up and so at some point you need more than a little modal.

Birgit Pauli-Haack: Yeah. Yeah. Yeah. Definitely. Yeah. So, well thank you. That’s a great demo. We all know have a visual of that, but there seems to be various paths that lead to be interconnected with other things.

Mel Choyce:  Yeah.

WordPress Plugins with a single block and block.json file

Birgit Pauli-Haack: So, who’s now working on the other part? I know there’s the block editor part where you have the inserter and the search. Then you have the Gutenberg installation preview, as well. That’s also in the block editor. And then you have the plug-in directory on the meta site. The connection would be a block.json, kind of a data format to push data back and forth between that, yeah.

Unless the block plugin developers add the blocks into that directory, content creators won’t find them, right? So what is it, Alex and CK? You both have been working on the meta side of it. Alex, could you catch up how this all supposed to work for the plug-in developers?

Alex Shiels: Sure, sure. Yes, I’m working on the meta side of things, the plugin directory essentially, or the block directory. The way we built it to begin with is the block directory is just a section or a category within … it’s a taxonomy within the plugin directory. These blocks are WordPress plugins at the moment. We’ve made a small section so far, which has about eight block plugins in it. We’ve sort of reached out to a handful of developers there to get some early ones in that we can test with, and we’re hoping to get some more soon.

As you say, the block.json file is kind of key to all this. The JSON file has meta data about the block that indicates what it’s titled and things like that, but also additional meta data that we’ll make use of in this install screen in Gutenberg, and we have an API set up. It’s a rudimentary one, but it’s searchable now so you can search by block name, block title, that sort of thing, which is exactly what’s going on when you start trying to insert a slider block and don’t have one installed. Those pieces of it are built in, dare I say, a slightly hacky way at the moment but they’re there. We expect to ramp that up soon.

The other piece of the puzzle on the meta side of things is, of course, plugin developers, working with them and encouraging them to build blocks, build single blocks. Get used to this idea of building rather than sort of ominous collections of blocks in a plugin, which is still a totally valid thing and we’re not going to stop people from doing that, but encouraging people to build small, simple pieces that can be installed independently. So we’re putting together some guidelines and rules and things like that, some draft rules, to sort of guide people how we think that should work and of course we’re going to consult with developers in the community to make sure we get that right.

So, yeah, from the meta side of things, that’s the major work that’s going on there at the moment.

Birgit Pauli-Haack: I am. You’re my guests today. You should be talking. So, I have you, and actually thought … I know Mel said it’s one thing at a time and not these big loaded … well, not loaded, but kind of block collections. That’s, right now, the way people experience blocks and install them and they have a one uni-forward system that also comes from the theme developers. How much more work would it be to actually kind of single out all those forty blocks that are now in one collection?

Alex Shiels: That’s a great question, and that’s the kind of feedback that we really need to get from plugin developers. I mean, I would imagine in a lot of cases, especially with the simpler blocks, the kind of ones that we want to get into the directory to begin with, it’s perhaps a tedious job to split them all out. For the most part in the code, in the way we want to encourage people to build things, I don’t think we’re asking a difficult architectural or coding problem. It’s more the management and the splitting things up. That’s kind of a one-off job. Because we built this around the plugin directory and these blocks are plugins, there is overhead there in building the thing and in packaging it up as a plugin. There are some great tools, command line tools, scaffolding type tools for building this, which I’m hoping that going forwards, developers will make use of the new blocks.

It really is a great question, how much are we asking developers of existing blocks and collections of blocks to move those into this block directory. I mean, we’re not going to stop people from continuing to make collections of blocks, and we’re definitely going to be using some of the new search, like block search functionality, within the block directory. We are going to extend that to all plug-ins, so if you want to go the web plugin directory and search for a block name, slider or something, you’ll be able to find them whether they’re single blocks or whether they’re collections of blocks or whether they’re larger plugins that just happen to have a block contained within it. That’s all totally valid, and we’ll make sure that’s all included. But from the installation within Gutenberg, we really do need to keep things simple. It is a bit of an ask that we expect developers to kind of change and adapt to this, but I think the best we can do there is consult with people and try and keep it as simple as possible.

Birgit Pauli-Haack: Yeah, yeah.

Mel Choyce:  Yeah, and I actually got some inspiration earlier today, talking to another designer, Shawn Andrews, about how we could feature collections we like on that Add New Blocks page. So it would be like, “We really like co-blocks. Here’s a bunch of the different co-blocks blocks for your to download.” Just also ways of making it easier to get new content, and also get consistent content, if you want.

Birgit Pauli-Haack: Yeah. That’s great. So, now CK, what have you been working on to kind of make this all come together?

Search, Preview, Install, Uninstall from within the Block editor 

CK Lee: Yeah, I’ve been working primarily on the Gutenberg side of things, especially on the block editor on inserter part, so that’s what Mel has shown. When you type in to search for a block, if a block does not exist or installed in the server, it will go away and fire a search to actually try to look for blocks that is not installed in the server but is actually available for you to download. Also on top of that, working on the installation of the block directly to the server, kind of like work seamlessly like magic in the background and just make it happen.

Birgit Pauli-Haack: So you’re the magician.

CK Lee: I wouldn’t call it that way, but again tying back to the single block, it makes it easier for us to actually do things like this, right? When it’s smaller, it’s more manageable. I suppose from a JavaScript point of view, it’s quite natural because you’re sort of like using components and single component. It’s obviously more if you’re coming more from a PHP background. It’s a bit more different, so I guess it’s sort of like a switch of a mindset to if we have smaller reusable block, it will help with maintenance of things going down to the future year, and then we can look into further ideas like what Mel has suggested, to actually sort of pull them into together. So start small, which is good, I guess.

Birgit Pauli-Haack: Yeah, yeah. Absolutely. So we have Luke Curbis is watching us also on the Zoom. Hi, Luke. You’re also in Australia, I think, and you’re part of the Block Lab team who just released a whole set of blocks. Not blocks, but block building tool. Do you have any questions, Luke, for our little group here, on that? If not, I am kind of wanting to … so there is other specifications online that people can look for, especially plug-in developers and how they would build it. What are the sites where they can kind of look through those?

Specification for Plugin Developers for adding blocks to the Block Directory

Alex Shiels: There is a post on make meta which is from a few months ago that sort of outlines my early vision for what I think a single block should be. I think that was one of the links in the notes you had earlier. So that gives some idea as to where we’re coming from there. I mean, one of the big controversial things in that post was the idea that these blocks should be more or less JavaScript only, with no server side rendering, which is I think is sort of necessary technical limitation that we’ve had to stick to for the initial implementation of this because getting this seamless installation to happen when you have a lot of server side code is just … it’s much more complicated.

So yeah, I am working on a more revised version of those guidelines and more specific guidelines. They’re not online yet, but I expect them to be up soon. That will outline, I think a bit more specifically and a bit more clearly, what it is we think that these plug-ins need to look like, which essentially will be mainly JavaScript, minimal server side code. I’m very much aware of the limitations of WordPress and the REST API, and the limitations of what you can do at the moment with purely client side blocks. We don’t want to make it impossible for people to build things, but on the other hand, we really do need to minimize the amount of server side code that’s involved and make use of that process of finding those limitations. Use that as a way of improving the REST API. I mean, there shouldn’t be these limitations in the first place. We’re hoping that this will sort of guide us going forwards as to where the REST API and where WordPress needs to provide better APIs and better tools to developers so that all this server side stuff that is necessary at the moment can maybe, in the future, become either already done for you by CORE, or at least doable in a purely client side context.

Birgit Pauli-Haack: That’s interesting, yeah. So a few months ago, Greg Ziolkowski, he had a request for comments on a blog registration for Gutenberg, which also touches on the block directory, but also went to kind of half the comments come in in terms of server side usage and creating blocks on the server side, or at least register blocks. Is that also something that plug-in developers could do, that they register them server side, put them on in a JSON file and then be part of route directory?

Alex Shiels: Right. Yes. I mean, when I say server side, it’s not so much about the registration as the functioning of the block itself. But yes, you’re absolutely right that RFC and the block.JSON file is kind of key to this because without that, we do have code in the plug-in directory, in the block directory, at the moment that can sometimes detect what blocks are registered by a plug-in. But because it can be registered in PHP, or in JavaScript, and because we’re just examining the code to look for registered block type function calls and we don’t have very sophisticated tools for finding that code. There are many different ways of writing that code. It’s not super reliable, and it’s not the right way of doing things, either, trying to parse the code to find out meta data about blocks. So that’s why it’s important that this block.json file exists and why the standard exists.

It serves a purpose, a functional purpose, within Gutenberg as well of providing just a standardized way of registering blocks. We are going to make use of it in the plugin directory, probably with a few slightly different requirements. There is some fields within the file that are optional within the RFC, but we’re probably going to have to make them required for the block directly. Eventually, I expect we’ll get to a place where we require a block.json file with certain fields set in order for your plug-in to make it into the block directory. At the moment, though, we’re playing it a bit fast and loose and just trying to parse out and detect whatever we can and fill in the gaps based on guesswork.

Birgit Pauli-Haack: Yeah, I think it’s a smart approach to go more the prototype route, kind of with the first discoveries of can we really hook it and what’s missing and now let’s do it the proper way and see how that would work.

Q: Are the panelists worried about pushbacks from the community around this?

So, Luke has two questions. “So are the panelists”, and I’m going to read the first one. “Are the panelists worried about pushbacks from the community around this? General feedback from WordCamp Brisbane was lots of agencies haven’t yet adopted Gutenberg and certainly the classic editor plug-in is very popular. Is this too much too soon? Shouldn’t we be more focused on better Gutenberg adoption before moving too far forward?” Who wants to take that?

Alex Shiels: I can take that one, if you like.

Birgit Pauli-Haack: Yeah.

Alex Shiels: Hi, Luke. We spoke at WordCamp Brisbane on a similar topic. So that’s a very good question. I’m not worried about pushback, because what we’re trying to do here is get feedback and build what it is that people need. There’s kind of a chicken and an egg problem here. We need to build this for people to adopt it and to use it, and I hope that by building it the right way people will adopt it.

I mean, yes, you’re absolutely right that there’s some resistance to Gutenberg from people who like the classic editor or who are heavily in sites that rely on the classic editor, and that’s totally reasonable. I understand that. I mean, I don’t see that as being a problem. We’re building something here for Gutenberg. Nobody has to use it. I hope that by building it well enough, building something that users need and that developers like, that we’ll hopefully get some more agencies, some more sites over the line in seeing how useful Gutenberg can be and come to that side of things, I hope.

Birgit Pauli-Haack: Yeah. Yeah. Yeah.

Mel Choyce:  Yeah, I had a good conversation with a friend who works at an agency, actually like two days ago, and for him the hardest problem his agency has had has been finding the time to train people to build with Gutenberg. I think the more that we can do that at WordCamps and other conferences and kind of help people along the way, the better we’re going to have adoption.

I’m kind of like I always assume that there’s going to be some pushback with anything I do in core, so it’s also all about making sure we know A, listening to what people are saying, because people pushback for a reason, but also be like being able to justify the decisions we’re making and being able to articulate those decisions. Sometimes it works better than other times.

Birgit Pauli-Haack: Yeah. CK, do you want to add something to the discussion for now?

CK Lee: Yeah, I just want to stress that it’s actually a chicken and egg problem, right? We really need to start working on the tools first just to get feedback and then we can actually continue to be forward, but one thing that we are quite conscious about is actually the features that we’re doing. We are always protecting that with a setting to actually enable and disable it so that should actually help people to actually start slowing ramping it up in the space of block directory on the Block editor side of things, so hopefully that helps everyone.

Q: Will a third party single block be able to have nested blocks also coming from a third party developer

Birgit Pauli-Haack: Right. Awesome. So we have another viewer asking a question, saying hi to Ellen Bauer. She’s German but she lives in New Zealand, I think. That’s right. So her question is, “Will a third party single block be able to have nested blocks also coming from a third party developer?”

Mel Choyce:  By nested, do you mean a block collection?

Birgit Pauli-Haack: Like a group block of stuffs in there.

CK Lee: I can answer to that. The short answer is yes. So if it’s by nature a nested block, but they still work together as one single block in implementation, yeah totally. It will be okay.

Birgit Pauli-Haack: So it could be a team block or something that is a banner. A picture and a title and a paragraph type thing.

CK Lee: Correct, correct. That’s a good idea.

Q: Would it be possible to disable the ability to add custom blocks?

Birgit Pauli-Haack: And then another question by Luke. “Many of the agencies I consult for have a strong preference to lock WordPress down so that their customers can’t break things, or their site. Would it be possible to disable the ability to add custom blocks and are we worried that people could really break custom themes with blocks from the block directory?” I think there are more questions. “So where are blocks stored, and by the way in the WP Content, blocks were in the database, all these kinds of things.”

Alex Shiels: Yeah. Actually, it’s the same answer to both of those questions, because these blocks are plugins. They’re WordPress plugins, although of course we’re building a UI to install them from within Gutenberg. You would be able to go through WP Admin and install them exactly as you would any other WordPress plugin. This is just a different interface, different UI, to doing the same thing. Yes, you can lock that down simply by giving or not giving permission to install plugins. At the moment, although we did early on consider the idea of ways that for example someone with a role that doesn’t allow them to install plug-ins could request a block be installed or something like that. For the time being to keep it simple, we’re basically made it so you have to be an administrator, or have to have rights, to install a plugin in order to see any of this.

Q: Do you think there will there be a confusion for single block and block collection blocks 

Birgit Pauli-Haack: Makes total sense, yeah. Thank you. So Ellen Bauer, here’s another question. “Do you think there will be a confusion of single blocks and block collection blocks since developers will probably tend to offer both their blocks in a collection as well as all of the same blocks in a single blocks?”

Mel Choyce:  Potentially.

Birgit Pauli-Haack: Potentially.

Mel Choyce:  Yeah, I mean the goal is definitely to push people towards doing more of the single blocks and one thing you should be able to do, too, is search by an author and then see all the blocks by those authors. So if you did want to download a couple different blocks that they’re offering, you can do it that way. I think it’s going to be a lot of good curation and smart UI decisions. That’s especially one area where we’re going to need a lot of feedback, because like right now, there are no limitations with plug-ins, like what you can install. It’d be cool to figure out a way like if you install a block suite, we still display in the block directory under one of those Manage screens, but limit what can you install from the directory itself to just single blocks.

Alex Shiels: If I can just add to that, I think this is somewhere where having good meta data in block.json files will help because if there are duplicate blocks in single block plug-ins and also in collections, that way we’ll be able to tell that these are the same blocks and display them appropriately, or not show duplicates or so on. I think this is something we’re going to need to work through with developers, and with users, to kind of refine how this works because at the moment … we’re testing with eight blocks in the block directory at the moment, and all of those are by different authors, so we don’t have any authors with multiple blocks. We don’t have any blocks that exist in other plug-ins. There’s stuff like this that as we test and roll this out a little bit more and get more eyes on it, I think we’ll discover these things and start to work through those design issues.

Birgit Pauli-Haack: Yeah, it’s really early and I can imagine that you don’t want to overload how things work with a lot of different things before you know that the foundation and infrastructure is really working

Q: Will block plugins show up in my list of plugins inside the WP Admin as well as the block directory?

Luke brought in, as well, another. “Thank you for your answers. Sorry if they came across as criticism.” They didn’t. “I’m really excited about the block directory. Will block plugins show up in my list of plugins inside the WP Admin as well as the block directory, or just in one?”

Alex Shiels: Mel can speak a bit more to that, but I think the simple answer to that is yes. Yes, they’re plugins. You’ll see them there as well.

Mel Choyce:  I’m hoping that if you install from the block directory, we can figure out a way to not show those also in your plug-ins page, but if you’re installing things directly, like if you get something from GitHub and then install it onto … through the plug-in, I don’t know what we can really do there, technically.

Birgit Pauli-Haack: Mm-hmm (affirmative). I saw at some of the screens, and I might just make it up because I couldn’t click on things, but didn’t I see some tabs where it says for plug-ins and blocks somewhere or was it-

Mel Choyce:  Yeah.

Birgit Pauli-Haack: Yeah. So that might be a good way to just separate them, then. So these are functional blocks, plugins, and then here are the blocks that you use in your editor. But it gets a little bit complicated when you get into the widget blocks and then the navigation block. So I think there’s a lot of movement going to be in there.

Alex Shiels: Yeah, that’s right, and I think there’s still a fair bit that’s uncertain about that aspect of it, how we display these in the backend and let people manage them. I mean, Mel’s done a brilliant job of designing that, but that portion of it is not built at all. It’s something where we … that’s kind of the next big thing for us, I think, is working through some of these issues and going not just from the design but from some of the more practical aspects of this. Just work out exactly how this should work outside of the editor and within WP Admin.

First version of Block Directory in Gutenberg with WordPress 5.3 release

Birgit Pauli-Haack: Yeah, I can imagine that there are still a lot of discussions left to have happening, which brings me to another question that is not in the Q&A here, but it is do you have a timeline? I know it’s very hard when you do new things to kind of figure out okay, how far can we push it or have a timeline together, but nobody will hold your feet to the fire. What are you aiming for in like a first beta or something like that?

Alex Shiels: I guess the simple answer to that is 5.3. The aim is to get this in 5.3, certainly the Gutenberg install side of it. We may need to push back the block management to later releases. I mean, CK’s got PRs sort of ready to go. There’s still some more of you and process around getting that into Gutenberg, but that part of it is largely built. I think very soon, this is going to be in a state where early testers and people who like to be on the bleeding edge are going to be able to try this out quite easily very soon.

Mel Choyce:  Yeah, I would especially love to see all the big block builders start splitting up into individual blocks to submit. And anyone … pretty much anyone who’s already released a block in the directory, it’d be cool to get them in under this block category so they can start getting used from the installation process.

Birgit Pauli-Haack: Well, that’s awesome. I had not thought that it’s going to be that fast, because beta is in somewhere in September, right? The first beta release, by that you probably should have things done, it’s merely a month to go, so that’s awesome.

Mel Choyce:  Yeah, like the big directory stuff, like the new section in WP Admin, is definitely going to be in the future, but CK’s gotten all the installation stuff in a really good place. It feels very, very testable now. We’ve been showing it off at some WordCamps.

Birgit Pauli-Haack: Oh, right? Awesome. Yeah. So how would, for instance, Ellen or Luke be able to be in the testing group of putting the blocks together and kind of see how that works?

How to get into testing your plugins in directory and Block editor? 

Alex Shiels: We don’t have a formal way of doing that yet, but certainly if you hop into the meta channel in Slack and ping me, I can help guide you through getting your plug-in into the block directory as it stands now. That’s something we’ve done already. It already exists. We can just … as long as it’s suitable, we can pop it right in there.

Birgit Pauli-Haack: Awesome. That’s cool. Is the Gutenberg part of your PR, CK, are they testable or are they in a different branch or are they just …

CK Lee: Yes, so I think I have four PRs submitted right now. Good thing is, like I mentioned before, these feature is actually protected behind experimental settings, so once it emerge, someone can actually just download the Gutenberg plug-in directly to their WordPress environment and then enable the setting and they can just start playing with it and just see how it looks like.

Birgit Pauli-Haack: That’s interesting, yeah. I know there’s some Admin pieces now in Gutenberg for the experimental settings where you also can test the widgets. So the block directory part of that.

CK Lee: Yeah. That’s right. That’s right. Exactly. So the widget is one of the experimental settings, so the block directory will also be another part of it, so early adopters can actually try it without much risk, I guess.

Birgit Pauli-Haack: So it’s not in the 6.4 yet, but it’s going to be in 6.5 or 6.6 of Gutenberg?

CK Lee: Hopefully. We’ll see how it goes with the reveal and everything. We’re pushing for it.

Birgit Pauli-Haack: Yeah, yeah. 6.6 is probably the one version that will go into 5.3 of WordPress when it’s going to be released, yeah.

All right. I don’t see anybody else having questions. I’m really happy that I now get a full 360 on that, because I couldn’t place all the pieces in there, so I’m glad you took the time out and explained it to me and others. So I think we are almost at the end of our show. Once it’s in 5.3 and then its iteration fast, but WordPress Core is not updating as fast as Gutenberg, so it will be probably … so the new things, are you expecting them to be in point releases when you do bug fixing or saying, “That didn’t work. Lets do it differently and fix it.” What do you envision there?

Mel Choyce:  I feel like the directory section in WP Admin itself is going to have to wait for a major release. In the meantime, we’ll just have the ED installation process drawing from blocks in the … using the custom taxonomy in the plug-in directory.

Birgit Pauli-Haack: Okay. All right. Okay. Yeah. Cool. Cool. Yeah, I’m running out of questions, but I have a lot of ideas in there and it kind of needs to settle down. Definitely going to connect with you on the meta team, on the Slack. This has been so interesting and inspiring. I’m really … I can see it come together.

Q: How to connect with the Mel Choyce, Alex Shiels and CK Lee?

Thank you so much, and at this point I have only two more questions for you. Do you have any announcements you couldn’t get in before and you want people to keep in mind, and if people want to get in touch with you what’s the best way? Yeah, so do you want to start, Mel?

Mel Choyce:  Sure. Getting in contact with me, my user name is @melchoyce on everything, like on Slack, on Twitter. Posting comments on the Make-post as we go along is also a really great way to chime in. I’ve been going semi-infrequent updates in the design chats every Wednesday. You can follow along also in the Figma file. That’s been linked to in a couple different posts, and you can watch me try things out during the day. Oh man. There’s a whole scratch pad file, or page, that’s just like stuff that I try out and I’m like, “Nope, not this,” or whatever. So, anyway, like a fun looking at my design head.

 There was another question. Announcements. I don’t know that I have any announcements, yeah.

Birgit Pauli-Haack: Okay. Yeah. So, CK, do you have anything that you couldn’t get out before because nobody asked you but you want to tell us about it?

CK Lee: No, but actually I have a question for you. Before joining this, I saw on Gutenberg Times that you have the #280Blocks Initiative.

CK Lee: That’s 280 Blocks Initiative that you have on Gutenberg Times. What’s that like? I’m just interested to know more.

Birgit Pauli-Haack: Well, it goes up and down depending on which version I’m using. It’s fairly fast. I need to switch off a few tabs on my browser but I get around places. What really helps me is when I have headlines and headings to go up to the little information tool and just jump to that particular heading.

CK Lee: Okay.

Birgit Pauli-Haack: And then to edit things. I don’t know if that was your question, how I manage those. The plugin post is definitely the biggest one, and I have a 100 plugins there. I need to weed it out. Some of them have been discontinued, I know, and I need to … but there are plenty of new blocks out there, yeah. Some of them go in … I probably need to split up that post into the different categories and a bit more manageable because it’s not only me who has to wait until it all loads, but those who visit it need to wait too, because it gets into the plug-in directory and grabs the embed part of it and of course it download is a little bit … with a 100, it’s a little bit cumbersome, yeah.

CK Lee: No, just interesting idea. I just thought just to mention. No announcement for me. To get in touch with me, it would be on Slack. My alias is CK3Lee, so just ping me on Slack.

Birgit Pauli-Haack: Well, thank you, and we will put all the links into the show notes once we get the transcript going. So, Alex. Any announcements or how to get in touch with you?

Alex Shiels: Well, they’d be more or less the same thing. Like I said earlier, we’re definitely interested in speaking with block developers or anyone who has a sort of stake in that side of things. So if you have opinions, if you have a block plug-in that belongs in this block directory, then reach out to me. I’m tellyworth on Slack, or you can pop into the meta channel, is a good place for it. I usually at least mention any new developments in the block directory project in the fortnightly meta chats, which we just had a day or so back so there’ll be another one in a couple of weeks. You could join us in that as well.

Birgit Pauli-Haack: All right. Well, I’m going to definitely go back and catch it in the back scroll. It’s my favorite part to do because I’m to [inaudible 00:50:22]. Yeah. All right. Well, big thank you to you panelists to come out this morning, in Australia and New Zealand, and this evening, Friday evening for Mel. We are really touching the whole world here.

If you have questions, you can always send them to me via email at pauli@gutenbergtimes.com. The recording will be available in a few minutes on the YouTube channel and we publish a transcript maybe in about two weeks. It takes us to get through the content of it. As mentioned, the … well, thanks again to everybody, and let’s get out here. Good luck and good bye.

CK Lee: Thank you.

Alex Shiels: Thank you. It’s been great.

Mel Choyce:  Thank you.

Yeah, and close the meeting now. Bye. Thank you.

Related Posts

Happy 20th Anniversary, Governance of Block Editor, Playground and a new FSE call for testing #WP20 – Weekend Edition 255

WordCamp Europe 2023 – Block editor talks, meet & greet, Contributor Day and more

Share