The new block editor makes creating content easier. It might not feel so easy, though, to bring a complex enterprise site over to Gutenberg for the first time. That’s where this free webinar comes in.

In this webinar, you will:

• Study real-life Gutenberg use cases from Xbox, Atlassian, and others
• See examples of when to use core blocks, third party block libraries, or custom blocks
• Learn how to plan for dependencies and ensure backward compatibility
• Get tips on managing the human element (think buy-in, usability, and training)
• Hear audience Q&A with Reaktiv’s Gutenberg experts

Transcript

Tess Needham (00:00):

Hello everybody, welcome. Thank you so much for attending WordPress VIP’s webinar, Upgrading to Gutenberg. We’re really excited to share this with you. So here at WordPress VIP, we’re really excited about the Gutenberg project. It’s brought unprecedented agility to Enterprise WordPress, but we have seen that for many of our Enterprise clients, they’re managing large sites with many users and so upgrading to the new editor can be a bit daunting. So we invited our featured partner, Reaktiv, to the webinar to share some of the things that they’ve learned from upgrading Enterprise clients to Gutenberg, so we hope that you find it informative and inspiring when you are planning your own upgrade. Cory Webb is here. He is a senior developer at Reaktiv, and he’s going to take it from here. Thanks, Cory.

Cory Webb (00:57):

Thanks, Tess. Good morning. Well, I know it’s already afternoon for a lot of you, but it’s still morning here in Texas so I’ll just say good morning. I want to thank VIP for hosting this webinar and for giving us the opportunity to share our experiences with moving Enterprise WordPress sites to the new block editor. I’m going to start off with introductions and telling you just a little bit about who we are at Reaktiv Studios and who is here with me today to help answer your questions. Then we’ll take a look at how we approach the process of migrating Enterprise WordPress sites to Gutenberg, starting with the human element or working to make sure everyone gets on board and ultimately stays on board with the big change to Gutenberg. After that, we’ll talk about handling dependencies and backward compatibility, so things like design dependencies and how to deal with existing tools like short codes, widgets and meta boxes.

Finally, we’ll discuss choosing a block strategy. We’ll focus on the whens and the whys to use core blocks and third party blocks and custom blocks. And we’ll save time at the end. Excuse me. We’ll save time at the end to try to answer any questions you may have. If you have a question, please feel free to post it in the Q and A tab in Zoom. You should see a button down at the bottom of the Zoom window that says Q and A, so you can enter questions there at any time. And someone may try to answer it right then, or we’ll get to it at the end during the Q and A time.

So I want to start off by introducing who we are. We’re part of the team at Reaktiv Studios, which is a digital agency focused on WordPress that was founded in 2011. Now we’ve been a VIP Gold partner since 2014, and we currently have 13 team members spread out all across the US. Now we’ve had the privilege of working with some amazing companies in enterprise tech, media and higher ed, and on some really fun and interesting projects. So today we’re going to talk about a few of those projects, including WGN America, which is a nationally distributed television network that reaches close to 75 million homes. We’ll talk about Xbox, which is Microsoft’s gaming console, Major Nelson, which is the Xbox live gamer tag of Larry Hyrb, who is a director of programming at Microsoft.

We’ll also talk about Atlassian, which helps power team productivity through their software products, GolfNow, which operates the largest online tee time marketplace in the world with over three and a half million registered golfers. And we’ll also talk about Tala, who offer an accessible consumer credit product, offering loans ranging from $10 to $500 through a smartphone app. Now, my name is Cory Webb and I’ll be the one presenting today. I’m a senior developer at Reaktiv and I joined the team a little over two years ago. Joining me today are Jay Hoffman and Josh Eaton. Jay is our lead developer and Josh is our CEO, and these guys will be helping me answer any questions that you might have.

So we’ll start off by talking about the human element, because ultimately our job is not to build and implement these things, these great tools, for our own satisfaction. Our job is to build tools to make life easier for the people who manage content on these sites every day. So the first step when implementing a major change like Gutenberg is to earn buy-in from the end users. Ultimately they’re the ones that have to live with all the technical decisions that we make as developers. Next we’ll talk about making the system easy to use and providing training and documentation. So let’s talk about earning buy-in. First of all, who are the people that are ultimately going to use the new editor? And this is not a rhetorical question. I mean, really find out who they are. These are the content managers, authors and editors who are stuck with these tools that we give them whether they like it or not, so let’s find out who they are.

And then next, find out if they’re open to change. Now, a lot of times you’ll hear things like, “Well, that’s not how we’ve always done it,” or, “I don’t want to have to learn something new.” As developers, we tend to be early adopters so these kind of statements really frustrate us, but the reality is not everyone is as open to new things as we are and it’s our job to help them get there. So to do that at Reaktiv, we like to schedule a live demonstration with the team. We want to show them how the new editor can add value to the system and demonstrate Gutenberg’s improvements and usability and flexibility.

We also need to listen to their concerns. So like, “Will I be able to create, fill in the blank, or will it be more difficult than what I’m used to?” These are valid concerns and it’s our job to help them see how Gutenberg can be used to do everything they’ve always done and more, and it’s really easy to use. So for example, WGN wanted the ability to schedule out new posts. Now, Gutenberg doesn’t do this directly, but we were able to find a Gutenberg compatible post scheduling plugin to fulfill that requirement. When we talked to GolfNow, we learned that their biggest concern was flexibility. They needed to be able to create a wide variety of layouts with Gutenberg, so we were able to assure them that, indeed, this was possible, and those conversations actually helped us to deliver a more flexible solution for them.

Now, this probably goes without saying but I’m going to say it anyway. Make the system easy to use. Don’t just build a solution that works, but build a solution with the end user in mind. So ask yourself, does this solution make their job easier or more difficult? So also consider different use cases. You may be designing a solution for a particular use case, but users always find a way to use things in ways that you didn’t anticipate, so be ready for that and ask questions early and often to get a better understanding of how they intend to use the system. Finally, follow up to see how people are actually using the solutions that you provided, so you can always go back and refine and improve things once you see them in real world scenarios.

Now, at Reaktiv, we believe that a big part of the job is not only delivering usable solutions, but also helping the end user understand how to use them. So at Reaktiv, we’re transitioning from more written documentation to more demonstrations and videos. So Gutenberg is a visual tool, so it works better to provide visual demonstrations. Prior to launch, we schedule screen share presentations with stakeholders to demonstrate how everything works. We also like to record all screen sharing sessions to make them available later. That’s always useful for people who couldn’t be there, or for new hires, or just people who want to go back and review what they learned. And finally, you should always be available to answer questions. Remember, you’re the expert, and so users will want to come to you for help.

Another important step in the process is to provide documentation. We typically start by providing links to existing Gutenberg documentation, but we also supplement existing documentation with our own when needed. Now there’s not much out there for user documentation, but here’s a short list of some existing documentation that you can use. We also take the time to document any custom functionality that we built specifically for a client, because if we don’t do it, then the documentation won’t exist. Okay. So that’s kind of the touchy feely human element stuff, so now that we’re done with that, we can start getting more of the technical stuff. So again, before you dive into building things, it’s best to first consider all dependencies and backward compatibility. So you have to consider design dependencies, current workflows, existing short codes or widgets, and then any existing meta boxes and how those will be affected with your project.

So hopefully you’re starting a project with a design, or you’re working with a designer who will provide a design for the project. So the first step is to take that design and break it into what can become reusable blocks. It’s also useful to identify variations in those blocks. Now, when I say blocks here, I don’t necessarily mean Gutenberg blocks. When you’re looking at a design, it’s helpful to think about each element on the page as a self-contained block of content that may or may not be reused throughout the site. How you implement that block could be with a Gutenberg block, but it doesn’t have to be. Just because we’re using Gutenberg, that doesn’t mean it’s the only tool in our toolkit.

So let’s take a look at the Xbox blog design for example. We broke this in half so that you see the whole page on a single slide. Starting at the top, on the left side, you can see there’s an area that displays a Twitter feed. Below that, you see what looks like a featured post. And both of these are contained within the green gradient area at the top of the page. Below that we see five loop posts with a sidebar element that appears to be another featured post. Now this is followed by what we’ll call a speed bump with another featured post. And then after the speed bump, we can see another five loop posts that are controlled by the navigation directly above them. So let’s break this into reusable blocks. First, we have the Twitter feed block, and then after that we have the featured post block.

And both of those again are contained within an area with a green gradient background, so we have to have some way of grouping those blocks together. Below that, on the left, we see the post feed or the loop, and then to the right of the post feed you can see that sidebar element which appears to be a post with a featured image and the post title. And again, also, those are contained in the layout that looks like some columns so we need to keep that in mind as well. And then at the bottom here, we see the speed bump. And then finally, we see the other elements that make up the post archive feature down at the bottom of the page. So once we have an idea of what all the elements are on the page, we have to start making some decisions about how to implement the design.

Do we want to use Gutenberg for this page or does it make sense to just create a really complex archive template? If we use Gutenberg, do we make everything a block or are there some elements that would be better to implement maybe within the template itself? Ultimately, we decided that everything above the post archive would be Gutenberg and we would implement the post archive with its own template partials and some other code that get rendered out on the front page template due to the overall complexity of the post archive and the dynamic nature of how it’s being rendered. We’ll get into more detail on some of these blocks a bit later.

When considering how to implement a particular design, you also have to find a balance between rigidity and flexibility, depending on the project and the needs of the client. So for some clients, a fixed design with fewer choices is better because it forces adherence to a particular design or layout. For others, more flexibility makes sense because they need to be able to generate multiple layouts. So for example, on the left here is the inspector controls of a custom block we built for Xbox to display a single post. There are basically two options here.

The first is to select the post to display, and the second is to select one of four or five pre-built layouts. Now there isn’t much flexibility in this block because it needs to adhere pretty strictly to the design. Now, on the right is a button block from the Ghost Kit block library. And as you can see, you can basically customize every little detail about the button within this block. This is great if you need flexibility, but it does put a lot of power into the end user’s hands. You have to consider that. You have to consider how much power you want to give them when deciding what type of solution to implement.

So even though we’re working on implementing this major change, we do need to review the client’s current workflows. How are they currently doing things, how will these updates impact their workflows, and can we improve upon how they currently do things? So let’s take a look at Major Nelson for example. Major Nelson has a weekly Deals with Gold post that displays a table like this one, with sometimes hundreds of deals on games for the Xbox. Now this table uses a jQuery plugin called DataTables.js to make the table sortable and add pagination.

This is a great feature for the reader to be able to scroll through all of the deals, but the process involved copying data from one spreadsheet into another spreadsheet that helped generate the table HTML, and then the table HTML was copied from the spreadsheet into the WYSIWYG editor. And it had to be done this way because the HTML had to be written in a specific way with specific classes in order for the DataTables.js Script to work. This ended up being a time consuming process for everyone involved, so we needed to come up with a way to improve upon that process within Gutenberg.

So with Gutenberg, adding a table is a little different because you can’t just paste the HTML into the table block the way that they were doing it. So the first thing we needed to do was come up with a way to easily add a table with all of the data they needed, and the second thing we needed to do was to incorporate the DataTables.js plugin so the user could get a true visual experience in the editor to see what they were creating. Rather than reinvent the wheel here, we decided to go ahead and use the core table block that comes with Gutenberg and add filters to extend the block’s functionality.

We added a couple of inspector controls, one to let the user indicate that this table would be a Major Nelson data table, and the second to enable uploading an Excel file with the deal data. So when you check the data table check box, that triggers the DataTables.js script and adds the necessary headers and styles to the table. The upload button uses a JavaScript Excel file parser to parse the deal data and then place it into the table block.

So this solution is a huge improvement over their previous workflow and it saves everyone time when adding new deals pages each week. You also have to consider what existing short codes and widgets are in use and determine the best approach for dealing with them. So can you maintain or improve existing functionality by creating a block? So if you create a block to replicate that functionality, do you then need to get rid of the short codes or widgets that you’re replacing? That really depends on the effort it would take to go through and replace every instance of a short code or a widget with the new block, and in some cases it’s just not worth the effort and you can just leave the existing tools in place on legacy posts.

So let’s look at some examples again. So Major Nelson has a JavaScript widget for displaying a product from the Microsoft store. Now, to render this they use a short code. They used to use a short code, and we replaced that with this block that makes it easy to simply add the product ID and select the layout, or it’s called a badge type here, to use. And we opted to keep the short code in place because it wasn’t worth the effort to replace every instance of it within the block, and those things are able to exist simultaneously. Another example, Major Nelson also uses a countdown timer on their Deals with Gold posts to indicate when the deals on the page will expire. Before upgrading to Gutenberg, they used a meta box and a short code for that countdown timer, and we were able to combine them both into a single block to make it quicker and easier to add the timer.

So Xbox also had a video short code that they used to render YouTube videos with an optional age verification step before showing the videos, because some of their games are intended for older audiences. And so we were able to replace that with a custom block to make it easier to add the video, so they just add the YouTube video ID, the intended age of the end user, and then the video size. And so then you can see on the front end, you’ll see the age verification step, and then once you submit your age you get to see the video.

All right, sorry about that. I couldn’t resist. You all just got Rick rolled on a webinar. Sorry about that. Anyway, back to what we were talking about. In some cases there may also be meta boxes that you need to determine if you can or should replace them with a block, so the countdown block I showed was a good example of that. So things to think about first, you have to consider the purpose of the existing meta boxes. Do they provide metadata about the post? Is the data being shown on this page or on another page?

So like, for example, if you have a short excerpt about the post that might be displayed on another page in a list of posts. And third, you consider is it for a design element that has to be rendered on the post page with a template. So in that latter case, you could likely replace the meta box with a block. For the first two cases, you might need to consider if a sidebar plugin is a better solution than a meta box. And so let’s take a look at sidebar plugins and what that means.

So for the product widget we created for Major Nelson and Xbox, we needed the ability to add a product widget to a sidebar on the post that is specific to that post. So we opted for a plugin sidebar in Gutenberg because it uses Gutenberg JavaScript components and makes it easier to render the output right in the editor sidebar so the end user can see what it will look like. So you can see here that you click on the little pin icon up in the toolbar to display our custom plugin sidebar, and then simply add the product ID to display the widget.

Okay. So choosing a block strategy is likely the first thing that most of us think of when thinking about migrating a site to Gutenberg, because it’s the most visible element of the process, and frankly it’s the most fun part. But we wanted to cover the human element along with dependencies and backward compatibility, because those are equally as important as which blocks you choose to use. Now, when I say blocks strategy, I mean you need to be strategic about which blocks and types of blocks you use in your project. You have to consider which blocks are right for the different use cases in your project and decide on a case by case basis what type of blocks are the way to go. You can choose between core blocks that come with Gutenberg, third party blocks, and custom blocks that you build from scratch. So let’s talk about core blocks first.

Core blocks are those blocks that, like I said, come with Gutenberg, like a simple paragraph block or the column block that lets you add a column layout to a post. We want to look at when to use core blocks, and then the pros and cons of using them, and then some examples of how we use core blocks in some of our projects. You have a lot of choices when it comes to blocks, so you need to consider when is the right time to use core blocks over third party or custom blocks.

So the first is obvious, but you use core blocks when they get the job done. So if a core block does what you need for a particular use case, then it makes the most sense to just use it. The second is when they can be extended to get the job done. So in some cases a core block gets you most of the way there, but you may need to extend it to do exactly what you need. And again, there’s no need to reinvent the wheel. A paragraph is a paragraph and there’s not much you can do to improve upon the existing paragraph block.

Now, there are a few pros and cons of core blocks. And for pros first, they’re built in, so there’s no need to do anything special to get them because they’re already there. You can simply use them. Also, the core blocks are already documented and they’re standard across all sites, because everyone using Gutenberg has them. For cons, core blocks have limited functionality. They’re meant to do all the standard things you would do when adding content to a site, but they don’t always cover all use cases.

So we use core blocks in every project we do with Gutenberg, and here are some examples of how we’ve used and extended some core blocks. So for WGN, we used the columns block. Now, initially the columns block only allowed for equal width columns. Now, that’s not the case anymore. It’s improved since the latest releases of WordPress and Gutenberg. But initially that wasn’t the case, you could only add equal width columns. So we added some inspector controls and output some custom classes to allow for greater layout flexibility, so this also put us in a position to adapt to the core columns block as it brought in new features.

So for Xbox, we used the new group block which gave us the ability to combine blocks into a group container with common styling such as a full width background. So we used the group block to render the header design on the Xbox homepage by adding custom styles like the green gradient background that you see here. For Major Nelson, like I showed you before, we extended the core table block to add the DataTables.js functionality, and to add a way to import Excel files into the table. And then for Atlassian, we added custom styles and inspector controls to the core image block to give the user the ability to add, “Tweet this,” functionality to images.

Now, third party blocks are blocks that are created and maintained by a third party or just by someone else basically. The block ecosystem has grown and evolved significantly over the past couple of years, and you now have a lot of really solid options when looking for off the shelf blocks. Third party blocks don’t fit every situation so we’re going to talk about when to use them along with some pros and cons of third party blocks, and then I’ll show you again some examples of how we incorporated third party blocks into some of our projects.

So when does it make sense to use third party blocks? They certainly aren’t right for every situation, but in many cases third party blocks are great for fulfilling the requirements of a project. The first thing I look for is whether or not there’s a core block to fulfill a particular requirement. If no core block does what I need it to do, I start looking for third party blocks. If there is a third party block or a block library that does what you need when no core block can do it, then using that block usually makes perfect sense, especially when shorter timelines or smaller budgets prohibit you from building something custom.

There are a few pros and cons when it comes to using third party blocks. So for pros, the Gutenberg ecosystem again has grown significantly over the past couple of years and you really do have a lot of quality options to choose from. That really wasn’t the case when Gutenberg first launched, so it’s nice to see how things have evolved and grown over the past couple of years. The biggest pro for third party blocks is that you can add a lot of additional functionality out of the box without having to resort to custom development, so this can save you a lot of time and money. Also, third party blocks are usually really well documented, so they’re easy to learn and easy to train people to use. Now for cons, they still don’t cover all use cases. They likely never will, because there’s always some new feature that someone will need that you just can’t achieve with a core block or a third party block.

Also, third party blocks don’t offer the same type of tailored experience that custom blocks offer. You basically get what you get, usually with a lot of options that make simple things a little more difficult than what you can create maybe with a custom block. And finally, it’s possible to add too many third party libraries. I call this the kid in a candy store effect, where you see all these great new things and just start loading up on them. It happens with regular plugins all the time. I can imagine there are people out there that have hundreds of plugins installed on a site when really they only need two or three of them. And then this same effect is definitely possible with blocks, so what we try to do is we try to stick to a single library whenever possible to keep things simple.

So let’s take a look at some examples of how we’ve used third party blocks in a couple of our projects, and also some additional third party blocks in libraries that you may find useful for your projects. So with Tala for example, we used Atomic Blocks, because the container block gave us an easy way to allow for full width and fix width elements within the same page layouts. You can see there, we can set the inside container width, and so that gives us a lot of control. For GolfNow, we used Ghost Kit to help give them the flexibility they needed to produce a wide array of styles across a network of almost 2000 sites. So we made a few adjustments to the CSS and it fit nicely inside the theme and gave them several blocks that would’ve taken dozens of hours to write custom. You can see here with the button block, again, they have a ton of control. You can set icons, you can change colors, you can set the border radius, so it gives them a lot of flexibility to set these elements exactly how they want them.

Another great block library that we haven’t used on any projects yet is Stackable, so it offers dozens of useful blocks that would fit nicely into just about any project. WPForms also has a great block to make it really easy to embed custom forms in the block editor. This is not an exhaustive list obviously, there’s probably dozens more but we just don’t have time to cover all of them, but these are some useful tools for you. Now, as developers, we need to avoid the temptation to jump immediately to custom blocks. So I intentionally save this part for last because providing an enterprise solution in Gutenberg doesn’t just mean custom blocks. With that being said, I do want to talk about when it makes sense to build and use custom blocks, along with some pros and cons of using them. And finally, I will show you some examples of some custom blocks that we’ve built for some of our projects.

So we’ve built custom blocks for every project that we’ve done with Gutenberg, but again, we don’t just jump immediately to custom blocks until it is absolutely necessary to accomplish what we need. So these are the things that we think about when deciding when to use custom blocks. First, is there a core block or a third party block that fulfills a particular requirement? If not, then we build something custom to do what we need it to do. In some cases, a core block or a third party block is too general and a very specific targeted result is needed to make the system more usable. So if you’re skilled at using Gutenberg, you can do just about anything with the right combination of off the shelf blocks.

But often we need to provide solutions for users who don’t want to spend their time combining multiple blocks to get a certain outcome. They just want to insert a simple block, fill out a few fields and be done with it, and so that’s where custom blocks are useful. Also, one of the more important things to consider, or one of the most important things to consider, is budget and timeline, so if you don’t have the budget or the time to build something custom, you’ll have to do the best you can with off the shelf blocks. In some instances also, you may need to connect data between post types, which is something you really can’t do without writing something custom.

Now, as with core and third party blocks, there are pros and cons to using custom blocks. So for pros, custom blocks provide a fully tailored experience specific to the needs of the site because you can build it to work exactly how you need it to. Also, custom blocks give you custom functionality that wouldn’t be available otherwise. Sometimes core blocks and third party blocks just don’t cut it. And finally, you get greater control over the output from a custom block. You can control every aspect of what gets rendered in the editor and on the front end, and you can control how it gets rendered. Really the biggest drawback of custom blocks is that they require additional time and budget that your project just might not have. It also requires developers with a particular set of skills to build the blocks. And no, I’m not talking about Liam Neeson, but that’d be pretty cool, right?

But seriously, custom block development is a different skillset from custom plugin development and you may not have a block developer available for your project. Another con is the ongoing support and maintenance costs associated with custom block development. With any custom programming work, you can’t just program it and forget it. There will be ongoing costs to support and maintain that code. One of the things that makes ongoing support and maintenance necessary is breaking changes in the Gutenberg core. That hasn’t really been much of an issue lately since Gutenberg was officially launched, but it was definitely an issue prior to that and it might become an issue in the future, so there will be ongoing support and maintenance costs.

So let’s take a look at some of the custom blocks that we’ve created. We’ll first look at some of the ones we’ve built for Xbox. First is the Twitter feed. So for Xbox, we created a Twitter feed block using the Twitter API to pull in a list of tweets from a given account, so you can see that here. So you can set the account name and the number of tweets that you want to display, and then you can also select a layout and it’ll show all the tweets from that feed. We also created a single post block that lets you select a single post and then choose from a handful of prebuilt layouts to display that post. So you can see here, there’s a popup window that lets you select which post you want to display, and then you can choose the layout that you want to use for displaying that post.

Next is the post feed block that we created for Xbox, which gave us the ability to visually split up the post loop into multiple sections on the homepage. If you can remember from the Xbox homepage design, there was a speed bump in between the two sections of posts. So you can add a speed bump or other important content sections in between different sections of the loop, and the way it works is you can add one instance of this block in one part of the page, and then add it, and add another instance of the block in another part of the page,, and it’s smart enough to pick up where it left off and display the next set of posts in the loop.

And then finally the plugin sidebar that we built for Xbox. This isn’t really a block, but it’s built using a lot of the same Gutenberg components that you would use for a block. And with a plugin sidebar, the plugin sidebar that we built, the user has the option to syndicate a post from one site to another within the Xbox Wire network of sites, and the user can easily add a product widget to display a game that’s for sale on that particular post. For Major Nelson, again, I showed you this earlier, but we replaced a short code for displaying Xbox games for sale in the Microsoft store with a block that made it easier to simply add the product ID and select a layout to display that product. For WGN, we created a block to display posts from the episodes post type on a connected series page. So here you can see that you add the block. There you go. So you add the block, and then you select a series, and then a season of episodes that you want to display.

Then for Atlassian, we built a couple of things. So we built an image carousel block, and this is a way for them to add images to an image carousel using the Owl Carousel jQuery library. And you can see that here, and it renders it in the editor and it also renders it on the front end. We also created a playbook block for Atlassian, and this is a good example of a block that you could probably build by combining other core or third party blocks. But by creating a custom block, we made this simpler and much easier for the editorial team to create a widget that adheres to a specific design that was needed.

And that’s all that we have for today. So I want to thank you so much for your time and your attention today. We’ll try to get through as many questions as we can with the remaining time. So if you want to ask questions, please feel free to post it in the Q and A tab at the bottom of the Zoom window. I see we have maybe two or three questions already. So with that said, we will get into it, so I’m going to stop sharing my screen and you can see us. Hello everybody. And we’ll start looking at some of these questions. So let’s see. Jay, had you looked at any of these yet or do you have any?

Jay Hoffman (37:43):

Yeah, I think maybe the first one we can take is, is there a site performance impact to using Gutenberg, so maybe we can talk through a little bit of that.

Cory Webb (37:52):

Okay. Yeah, go for it.

Jay Hoffman (37:53):

Yeah. So I think we showed examples of custom blocks and third party blocks, and your biggest performance hits are going to be from the third party blocks because a lot of them, because it offers the flexibility, they also have to bring with them quite a few scripts or potentially additional libraries. So that’s potentially another advantage of going with a custom block, if let’s say there was a third party block that worked for you but you didn’t want to have to bring with it everything. A lot of these libraries are being pretty smart though and they’re offering ways kind of to turn off and on features, which will also selectively include different libraries with it. So it’s worth investigating. There’s not an impact right off the bat, it’s really just about what you use it with.

Cory Webb (38:47):

Great. Let’s see.

Jay Hoffman (38:53):

I think there was a question earlier in the presentation about which blocks came right out of the box and which were custom too. I just want quickly to answer that. Hopefully as we moved through the rest of the presentation it kind of became clear. But one thing to mention is just that core obviously is constantly being upgraded. It’s always a good idea to look at the roadmap of what’s coming to see maybe if you upgrade to an experimental version of Gutenberg that’s still fairly stable, you might be able to get something for free right there. So-

Cory Webb (39:26):

Yeah. And I think a lot of the ones that I showed in the presentation are ones that we customized a little bit, but a lot of the blocks you’re just going to use straight out of the box, the way that they come, right? I mean, like the paragraph block or the heading block or the list block, those are things that you’re not going to have to do a whole lot of customization to probably. In this case, I felt like it was a better use of time to show you the ones that we customized to show what’s possible with customizing off the shelf core blocks.

Jay Hoffman (40:00):

This one might be a good one for you, Cory, a question from Sean Grant. What are the high level code requirements for custom blocks to be created? I’m interested in how much code it takes to create a custom block with a few options. Maybe just talk through that real quick.

Cory Webb (40:14):

Yeah, so there’s a few ways to go about it, but I mean, from a high level, you’re really going to need to know at least some React development, because Gutenberg, obviously the Gutenberg components are all based on React. And then, how much code it takes to create a custom block with a few options. Honestly, it’s not a ton of code. It’s just kind of a matter of knowing what to write and how to write it. And so, you know, you can generally write a pretty simple blog with, I don’t want to say the wrong amount of code, but maybe 50 to 100 lines of code or something like that, but obviously they can get as complex as you want them to be or need them to be. But for something simple with just a few options, it really doesn’t take a ton of code. It’s just a matter of understanding React and understanding how all the system works together.

Jay Hoffman (41:17):

The developer handbook for Gutenberg is a great place to start. I mean, there’s lots of resources that are developing, but I think that one’s usually overlooked even though it’s kind of pretty foundational. So if we can post a link to that, we will.

I think one question got up voted that I can speak quickly to, which is can you speak to how you handle the data migration of legacy content. Many clients use page builders like WPBakery. That is an active problem. So as Corey mentioned, if some of that data is locked in things like short code, which a plugin Visual Composer will depend on, you have to kind of make a decision at the beginning of the project about whether or not it’s worth just leaving the legacy content as is and then using Gutenberg moving forward, or whether or not it’s worth trying to do a migration.

There aren’t currently any automated tools, so if the short code usage, or if there’s a too much of a vendor lock in, it can be a bit difficult to get it out of Gutenberg. But we have had success in the past using Gutenberg Ramp plugin to basically enable Gutenberg on a select number of posts. So you can say create a new post type where Gutenberg is activated on, but leave the classic editor on older posts, or you can even set maybe within a post range, from a post ID and up. So I think the Gutenberg Ramp plugin will allow you to maybe have best of both worlds if you find yourself in a scenario where it’s just not possible to migrate all the content.

One general question seemed to be is Gutenberg a page builder or a content writer’s tool? Does it have any benefits for content heavy news sites? Yeah.

Cory Webb (43:16):

Yeah. So an answer to the first question is yes, it’s both, or it can be both. I don’t know that it’s… Out of the box, I don’t think it’s a great page builder. You’re not going to get the same kind of functionality that you’re going to get with Beaver Builder or Elementor, all the other page builders, right? Because right now it’s more geared as kind of a visual editor for publishing content, but there are things that you can do, and then some of these third party tools like Atomic Blocks or Stackable or Ghost Kit that really take it a long way towards becoming more of a page builder, but you do have to develop a theme or use a theme that’s geared more towards using it as a page builder. And then does it have any benefits for content heavy news sites?

Yeah, I think so, because what it provides is a rich editing tool for providing more rich content to the end user, right? So the early days of the web was all about text and pictures, but now it’s all about things like videos and interactive elements like polls or social media integration with Twitter and Facebook and things like that. And so Gutenberg provides tools to help make that kind of thing easier for the editorial staff to provide that sort of functionality and that sort of content for their end users looks.

Looks like an add, a follow on to that, is how quickly, easily did users become accustomed to use in the block editor for writing text heavy posts? Do you have any user feedback that you can share? So it kind of varies, but generally people take to it pretty easily, especially for adding just basic content. So writing in Gutenberg is pretty simple, right? You just start typing and it kind of automatically starts doing a paragraph blog and you can easily add a heading. People get used to that kind of stuff pretty easily, so that part of it was actually not a big deal. When you do a lot of custom things or do things that are maybe outside of standard usage, so if you’re trying to use it as a page builder, it does get a little more complicated and so there’s a little more training and a little more handholding involved in that sort of scenario. Let’s see.

Jay Hoffman (45:54):

One question I wanted to get to was as a consultant, the most difficult thing is the convenience of the marketing team as they are familiar with their existing flow of uploading things at their end. How do you manage additional marketing automation, customize blocks with Gutenberg, with the specific requests to address ad blocking and DFP? Just integrating with an ad network, I believe. So I think one thing to remember is that you don’t have to go all in on Gutenberg necessarily on your pages. So there’s a couple different ways you can handle this, but I think one of the things Cory mentioned was that we had this post archive section in Xbox, and that is still just integrated into the post template itself and not actually customizable inside of Gutenberg. And meta boxes don’t disappear, and they don’t cease to work inside of Gutenberg. In fact, they continue to work pretty well.

So you can continue to use some of the workflows that marketers or editors are used to while still kind of making a move into Gutenberg incrementally. So it might be a good idea to introduce a block or two where, kind of like the examples that we demonstrated, where if they just enter in let’s say an ad code or some sort of code into a text box and all of a sudden this magical widget appears, they might start to feel like Gutenberg is a tool that they can use and offers a bit more flexibility. So I think continuing to use existing workflows while also incrementally making a change into Gutenberg should hopefully help you, just over time, make that change.

Cory Webb (47:37):

So this top question here is how are you guys migrating million WYSIWYG simple HTML posts to Gutenberg blocks? So that’s a good question, and the reality is on some sites where you’ve got thousands and thousands of posts, sometimes the best decision is to leave them alone, right? Because when you migrate to Gutenberg, all those posts, all the content in those posts will just automatically go into the classic HTML block within Gutenberg. So you may need to review based on how your site’s set up. You may need to review all the legacy posts and make sure that they’re actually displaying properly on the front end and that it’s still a good experience for the reader, but the reality is it’s not always worth the effort to go back and actually migrate all those things to Gutenberg blocks. In some cases, it makes sense just to leave them alone.

Jay Hoffman (48:36):

I think kind of related is another question that came in. Would you consider building a WYSIWYG a primary mission for Gutenberg? My concern is that to achieve this, the front end platform has to be integrated within the editor environment, making it a little more difficult to maintain in case of changes or future layout changes in the front end. So I think some of the hesitation there comes from the fact that your HTML from your Gutenberg blocks makes its way into the post content database table. It kind of all groups together. There are a few different ways to handle that, but I do think that building a editor experience that replicates, just to answer the first part, building an editor experience that replicates the front end is the end goal of Gutenberg, and I think right now it’s just providing the tools to do that.

You still have to do some of that work yourself, so creating or adding custom styles, especially to the admin, even when you are using core and third party blocks, is always a good idea to get your editors and writers and contributors into the mindset of parody from the front end to the back end. In terms of being difficult to maintain, I think there’s two takes, two approaches you can take there. One is there is a way to have deprecated markup specified inside of Gutenberg blocks, so I think it would be useful for you to look into the deprecated attribute and the registered block function.

But you can also rely on server side rendered blocks if it’s something that you feel like is going to change for a while, or if it’s something that relies heavily on let’s say pulling together a lot of data from different places, so the WGN episodes block is a good example of that, where we’re really just stringing data from one piece to another and that data is constantly shifting. It’s okay to rely on the server to generate the HTML when that’s appropriate, and that, you know, you can change that markup on the fly as needed.

Cory Webb (50:41):

So a question here, I won’t read all of it, but basically it’s saying do you think Gutenberg can be… Oh, I just lost it. Hold on. Okay, there it is. Do you think Gutenberg can quickly become a bigger mess versus classic content when you’re typing posts? Basically, this is one of the things we kind of mentioned in the presentation, but you have to decide between rigidity and flexibility when you’re providing a solution to the end user. And so you can actually make the content editing process a little more rigid if you have to so that you can control what ultimately shows up on the front end, you have a little more control as the developer. But you can also make it really flexible, and again, that goes back to the question of how much power do you want to give the editors or the end users of Gutenberg.

Because you’re absolutely right, users do have a knack for making a mess of things, and so it’s our job as developers to anticipate that and to try to mitigate that as much as possible. And also, I think training goes a long way too, right? Because part of the problem when end users make a mess is it’s our fault, right? Because we didn’t help them to understand the tools and understand what the best practices are for using those tools. So yes, it can become a mess, and I think it’s kind of on us to mitigate that through training and also through just how we implement and deliver this solution.

Jay Hoffman (52:16):

Cool. Just to get to two questions kind of quick. The first one is can you make block content parsable and structured by using JSON data? I would recommend looking into the parse blocks function. It allows you to extract the data from the HTML and make it available as JSON data on the front end or however you need to access it. So, no out of the box, but yes, pretty easily, so I think that’s worth looking into. The other is I’d like to understand better when do publishers decide to switch to Gutenberg? There’s kind of a few different scenarios that can go on there, so what’s the most common friction point when trying to convince them to switch to Gutenberg. So if it’s a new site, that’s probably the easiest recommendation. We often explain that the block editor is kind of where the WordPress is going. In fact, it’s where it is currently now.

So it’s actually a pretty easy sell for new sites because the editor experience matches, I think, expectations for a lot of people. For redesigns or new features, it also… That’s kind of a good segue. As I mentioned, the Gutenberg Ramp plugin, we can always say, well, this one section of the site needs a bit more flexibility, so maybe let’s try out the block editor over here on this post type, and you can sort of start to explore the tools. But we do make it clear to clients that the classic editor may not be around forever, so it’s a good idea to get ahead of that and to just try to use the block editor as soon as possible.

But I think incremental changes tend to help. And I will say that we haven’t had a complaint when people actually start using it, right? So when we shift the workflow over from the classic editor to the block editor, it’s always an improvement. And there’s a bit of a learning curve at the beginning, but in general I think we tend to overthink the experience because it actually is, it’s very intuitive. The block editor team has just done a great job there, so actually a lot of times the work kind of speaks for itself.

Cory Webb (54:37):

There’s a question here about building a site with ACF plus Gutenberg. It makes life easier for developers and users. Actually, I’ve actually built a site with ACF and Gutenberg and it’s actually really nice. I mean, there are some really, really useful tools there. I know ACF does introduce some overhead into the site, and so for an enterprise site it may not be the best solution because of the overhead that it does introduce. When you’re dealing with the kind of volume and the kind of traffic that you see with enterprise sites, it may not be the best solution. For a smaller site, and you want get some of the benefits of Gutenberg without having to ramp up your JavaScript and your [inaudible 00:55:23] skills, ACF is great. It’s a great tool and a great way to really build custom blocks in the same way that ACF has always let you build custom meta blocks. And so yeah, that’s a really great tool as well. That’s the last question. Any more questions, or are we out of time?

Tess Needham (55:44):

I think we’re at the end of the time, so it’s probably you’ve cut in right there at the end. Perfect timing. Thank you so much, Cory, Jay, Josh, from Reaktiv. Really appreciate you sharing all of your Gutenberg knowledge with everybody. And thank you to everybody for joining WordPress VIP and Reaktiv for the webinar. At WordPress VIP, we help some of the world’s top brands power their customer experiences through leveraging the open web, so some of those brands you heard about today that Reaktiv has worked with, and we work with many others as well. So please get in touch if you have any questions, or if there’s any topics that you’d like to see covered in a future webinar as well. And thank you again so much for your time. Bye.