 Welcome to the panel session. I hope you had a nice morning tea break. This is Deteal, aka the web princess, a project manager at HumanMade, and she is going to be MCing slash moderating the panel. I'm going to hand over to her to introduce our panelists. Thanks, Kirsten. Can you hear me? Is my coming through? Awesome, great. To my right, and your left, this is Luke Carvis. He's the product manager, head of product at XWP. We're a press development agency. Next to him is Rob. He works for Automatic. He's a developer, a JavaScript developer, so he can answer your really gnarly technical questions, so we'll hand all of those to him. And Kath is a designer who's actually going to do a talk about design after this, but she can answer some questions around. Have you done your talk? You haven't done your talk yet? You haven't done your talk yet? Yeah, so she's going to answer some questions around that, so she can answer design questions. I will do my best. The mic, it is on. Okay, cool. I'll stop turning my head away from the microphone and turn all of me instead of just my head. Sorry. So, just to get us started, I've got a couple of questions that we prepared earlier, and then we'll open it up to the floor. So, let me just pull those questions up here. Right. So, there was obviously quite a lot of conversation after Luke's talk yesterday, so I'm hoping that some of these questions will have already been answered, so I'm going to answer some of the slightly gnarlier questions. Ask them some. I'm not answering questions. I'm just driving. A developer agency, WebPerson, says they've never heard of it. What do I need to tell them? Is there anybody in the room who's actually never heard of Gutenberg, who wasn't here first thing yesterday morning and didn't actually hear us talking about it? Great. Let's start, Luke. Will you explain, Sena's given the elevator pitch about Gutenberg? Sure. Gutenberg is an entirely refreshed approach to editing content on the Web. It learns from the mistakes and also from some of the good things that other publishing platforms that exist in our ecosystem use to create a new tool for editing content, and it replaces the existing WordPress editor. So, that's a pretty big deal. What should you tell your clients? I think you should tell them that WordPress is getting an update and the editor that you're used to is going to change, and it's going to get way better and it's going to be much easier to use than it's ever been before. If you just go ahead and add a new post or edit one of your old posts, you'll notice that it's really easy to use. If you do need any help, then give me a call and I'll be able to talk you through it. That's what you should tell them. Cool. So, here's a good one. I've half built my site. Do I have to start again? No. I have a website. I've got a couple of them. I've built a few of them, like hundreds of them. I turned Gutenberg on to my own site yesterday while we were doing the talk. It didn't break. Nothing broke. I have a page builder that I use to build the fancy pages on my website. It didn't break. It's still there. I don't think that you're going to have too much problem with backward compatibility. I think that you have to be mindful of the new blocks and the styling around those blocks and it's actually going to open opportunities for those of you who are theme designers or people who are getting new themes in the next year or two are going to be able to take advantage of the new little design components in the regular editor. But for those of you who are building a site or who's developed as a building site for them, just be mindful of it. I'd reckon just give it a crack, turn it on, see what happens, and I think you'll be pleasantly surprised. How do they turn it on? Rob? Yeah, so right now if you install the Gutenberg plugin, it will be on for all of your posts. If you install the plugin or later if you upgrade to WordPress 5.0 which would have it included, new posts would be entirely Gutenberg and existing posts you would open. All of the post content would be in what we call the classic block and there's an option to migrate that old post over into full-on blocks. What's a block? A block is... Someone yesterday said there are short curds 2.0. You can kind of think of them like that maybe. The block is the unit of... A post is going to consist of a series of blocks. The block is going to be the basic building block if you will for WordPress going forward. Luke might be able to explain it better. You're good at the elevator pitches. Okay, so I have one more question here and then we'll open it up to the floor. What do I need to learn to develop a new Gutenberg block? JavaScript. Take a deep breath. We've tried to make it as easy as possible but you're going to need some JavaScript. There's a lot of good resources right now. If you go to WordPress.org slash Gutenberg slash Handbook there's all sorts of documentation including how to extend to Gutenberg and how to build your own block type. There's also a few talks if you go to WordPress.tv. That's a really good place to start too. Right, so that pretty much answers all of the questions that I had already organized. How many of you have come with questions of your own and who would like to go first? Luke has a question. I have a question, a development question. So I'm pretty sure I can find tutorials online on how to build a block but the part that I'm confused about as a developer the part that maybe is the most scary for me is all of this business about NPM and having to use the command line and what's Webpack and things like that and that's not something I'm used to. Could you tell me how do I get started with that sort of thing? Yeah, definitely. JavaScript tooling can be pretty complex nowadays. It's a good question. You don't need to use Webpack or anything to build a block in Gutenberg. The API that we expose is all kind of ECMAScript 5 compatible so just regular old JavaScript that you can run in the browser as is. And just using, and on the handbook the wordpress.org slash Gutenberg slash handbook we have snippets in both ECMAScript 5 which is stuff you can just kind of copy and paste into the browser straight away. You don't need to have any tooling set up at all and that will work fine and that's completely supported. Many JavaScript developers prefer to use newer JavaScript features in particular because Gutenberg users react. Many people prefer to define their components using JSX which is the kind of HTML looking syntax for JavaScript and you can opt into that. That's when you would have to set up Webpack and something like that to compile that fancy new syntax into something that the browser can understand but it's not necessary. Does that answer your question? Why don't we take one from the floor and then we'll come back to your question, Kat. Yes, when you say use JavaScript I spoke at a very experienced developer and he says no one uses JavaScript. That's yesterday's news. You need at least a solid IDE to actually do something with that. How does it integrate with any extra IDEs because cutting JavaScript may not necessarily work very well for a lot of people? Yeah, of course. You would define your block probably in a plugin that you're building and most of us who are writing plugins would use an IDE Visual Studio Code or PHP Storm, something like that. Most of us would use something like that to build our plugin and I can't name an IDE that doesn't have good JavaScript tooling in it so it should work very seamlessly. So is the question then you don't need different JavaScript tooling for Gutenberg than you would for any other JavaScript development that you were doing? Exactly. Okay. Is anyone here a front-end developer, a theme developer? Okay, so this question is for all of these people. You people. How much more styling needs to be added into their themes to accommodate for all the blocks and the spacing and the new components that are actually in the editor? Yeah, that's a great question. So Gutenberg defines a small amount of CSS for all of the blocks that are included in it. And as a theme developer, you could introduce more CSS than what comes built in to tailor the blocks for your specific needs. Maybe you want to match the appearance of your website or maybe you want to customize the block styling somehow. The styling you introduce in your theme would add on to the styling that comes with Gutenberg. Does that answer your question? I think that would be an interesting exercise for someone to do to kind of catalog the blocks that are there to be able to say, if you are a theme developer, you might want to look at tailoring what your in-store Gutenberg, have a play with it, and then have a look at the kind of blocks that you might want to customize for your own. Hi, I have a couple of questions from Twitter, actually. So the first one is a reference to yesterday's keynote Advanced Custom Fields says, super impressed with the demo. So congrats, Luke. The reusable shared blocks feature is a great idea, but only works with a single paragraph block. What about images and text? Yeah, shared blocks, they work for any single block. So if you have an image block, you can convert it into a shared block and use it throughout your website, throughout posts and pages in Gutenberg, or a paragraph block, any block, a shared block, any block can be made into a shared block. Is that the kind of answer? I think so, yeah. That's how I understand it as well, yeah. And the second question I have is from Robi Lawrence. Can you create Gutenberg templates or layouts so that post design is always consistent without recreating the layout on each one? Yes. Yes, you can. I think it's when you're defining your custom post type, you can specify the kind of initial set of blocks that will appear in that post. You can even lock it down so that the user can't add any more blocks. You can even lock it down further so that the user can't rearrange the blocks, which is kind of nice. You can build a custom post type that really matches the kind of design for your site. Does that happen in the interface that you know the editor, or is that something that has to happen in the code? That's something that you're specifying the code, yes. I know it's not really a complete solution to replace things like ACF, but if you are able to write that code and you're able to develop your own custom blocks, then templates and custom blocks combined would go a very long way towards solving that ACF problem actually in a much more user friendly way. So that's starting to sound like Gutenberg becoming more of a page builder than just a content editor. Is it there yet? Is it that? So page builders, I'm sure, is a topic we'll get on to. I'll say one more thing about this ACF topic and then answer what you're suggesting. So where I think ACF may go in the future or a plugin could replace it doing a similar thing. ACF, all it does is it provides you with a user interface for adding custom meta. We could do that with code if we wanted and create custom meta options for a post or we can use ACF which is a nice user interface that stops you from writing the code. So there's no reason why another plugin couldn't come along and help you define custom types with preset block templates. Which is basically what ACF does in a different context. On the topic of page builders I think there's a lot of confusion because I don't define Gutenberg as a page builder. I define it as a content builder. Because when you start to pick up page builders and things like this, a lot of the time it goes far beyond just the content of that page. Sometimes you can do things like, I want my header on the right hand side, my logo, and then put the navigation at this point and three widgets in the footer and things like that. Gutenberg doesn't do anything in terms of the layout of your website. It just handles the content of your blog posts and your pages and your post types. So there's a bit of a difference there. On that thing that you guys are talking about just now, even if you code from the code you have all these blocks in Gutenberg in the content in order to replace it with the ACF pro, how are you going to do that a base query on that field specifically because they're going to be all sitting in the content instead of sitting in different fields. So when you're building a custom block in Gutenberg you can specify that the content from that block is sourced from post meta rather than from the post content. You pretty much create a new field from a code perspective and then you put whatever content in that block into that field. Yeah, so for example if you're defining an author bio block or something that might have two attributes that might be like name and description and you could source the name. You can specify in the kind of schema for that block, you can be like this is the name field and it comes from meta. This is the description field and it comes from meta or from content wherever. Thanks. Sorry. With the editor, I guess I come from an ACF background as well my idea is to not allow people to change things like colors and that type of thing just for no reason. Is it easy to turn off some of the features of the blocks like some of the say colors or sizes and things like that? Yeah, there's a lot of different ways to extend Gutenberg. Colors specifically I think we have like an array of allowed colors or something that we source from that you could specify but in general any of the standard types there's many different ways to customize we could for example disable a particular block type or if we want to lock that type down a little bit we could maybe remove one or two features from it there's hooks and filters in Gutenberg to do some of that customization and if that's not flexible these blocks are open source you could create a new one that's kind of based on one of the existing blocks. You touched on something briefly there which I think maybe needs to be reset because it's huge, especially if you are a theme designer or you work at an agency how many of you have had that experience where you build a beautiful looking theme handed over to the client and two days later it's the most ugly thing you've ever seen. Yeah, not just me. So one of the one of my favorite features in Gutenberg I don't know if you would have noticed during the demo yesterday but you know there's a sidebar and it's got the block options there and for some blocks you can do things like specify a background color or specify the text color well two interesting things with these color palettes you can choose as the theme author which colors it's possible to choose from and lock it down so maybe you can choose one of just three different colors and not the color picker where they choose blue or pink and the other cool thing with this is that so maybe you've got five colors that you use in your theme you can just set those for the text and the background but the other really cool feature is that suppose I set my background to white and my text color to pale yellow right Gutenberg will give me a notification give your users a notification that says this is going to be really hard to read you should consider changing the color of the text or the background because it's not enough contrast so yeah that's one more question hi I read online that this is going to be default feature in WordPress with WordPress 5.0 I have a concern with it we have plenty of websites online and once it's going to be default feature we use some other plugins like Visual Composer and various others in different websites so once this gets launched and we update our WordPress is it going to affect the current website or is there any option that we can use either this one or other content editor if there is a problem yeah so I actually ask the same question from the team that are developing and designing Gutenberg and working on it at the moment and it was one of my fears as well so firstly the initial release of Gutenberg and correct me if I'm wrong Luke but is going to give you an option to actually try it that's the next release of WordPress so the next release of WordPress and then when Gutenberg drops into core it is going to give you an option to disable it or to replace it with the classic editor or to be able to download the classic editor plugin to override the Gutenberg so you will have some options there is that correct does that answer your question I think my I was going to add something if I may I think one of the recommendations is the plugin is available now to download now and so my recommendation is if you are fearful about what's going to happen in the future download it and try it on a staging server or on a local development environment to see what kind of effect it's going to have and then you can plan ahead for that just to make sure that it doesn't all go to custard when it does become core okay so you use visual composer right so right now in visual composer isn't there an option when you go to create a page with the visual composer tooling to just create that page with the normal editor instead we don't want to do that I know I know what I'm saying is once Gutenberg lands that same option will still exist you'll open up your visual composer be able to compose a web page just the same way as you do now and then if you want switch to Gutenberg you can choose it's the same with beaver builder it's the same with divi you can choose whether you want to use their interface or the built-in editor and so right now it's you choose the classic what we're calling the classic editor or the page builder and in the future you'll choose between Gutenberg okay is that that default content editor even like if we download this plugin and install on the website on stating server is that other plugin also available so that we can try both like installing this one and then if it doesn't go well then we install the other one you mean the classic editor plugin available now yeah the classic editor plugin is available now if you install it then and activate it then when WordPress updates then you won't get Gutenberg okay but don't do that and here's why I'll tell you why is because Gutenberg is more than just a new editor the block paradigm the Gutenberg users is going to make its way into every part of WordPress in the future WordPress won't have widgets maybe they'll still be called widgets but they'll be completely under the hood translated into blocks content blocks in the future when we go into the customizer we'll see our content blocks on the front end of our website and maybe update them from within the customizer so you can imagine all of these different ways where content blocks as a paradigm are going to make their way into all different aspects of WordPress if you want to install the classic editor that is definitely an option available to you but you'll be left behind Luke has a question no I have a question for Luke the previous question is actually to me very relevant because it's a bit of a sample of what I hear from a lot of people in the community so I know Luke has a great vision for where Gutenberg is going to take us and if you'd like to share it I'd love to hear it again but on the flip side of that we also have a lot of people that I suppose in essence are a bit scared of change and is this going to break my site what do I have to do to get on board what is this going to mean for my business for my blog and you've got these two total opposites opposite views of Gutenberg that puts us as engineers and developers in a very tricky spot because now who do you cater for if you take on any project right now it's very hard to know all in Gutenberg because soon WordPress is just going to be Gutenberg or the need to cater for everybody that's still using the classic editor so I suppose from the panel I'd like you guys maybe to take out your crystal ball and have a look and think what's the adoption for Gutenberg going to be once it hits course everybody just going to see this is great let's just get on board and within a month everybody is just Gutenberg is there going to be this long trail of people kind of trickling in and what does that mean for us as engineers and developers let's all have a shot at this hey and then we can compare later on my prediction is that we'll hear a lot of very vocal descent in the first three days after 5.0 comes out within a month there'll be less than one percent less than half a percent of websites that don't run Gutenberg I mean already I've noticed in the last year since WordCamp US the attitude in the community has shifted somewhat from that of a fear of the unknown to a positive attitude how do we make this happen what can we do to help I hope it's an instant success is that what you said yes that would be my hope okay so I'm going to approach this from the the small business user and my clients so the users of the websites that we create and also I do a lot of WordPress tutoring one on one and for the last few weeks at least I've been turning on Gutenberg and so the first instance of these people seeing WordPress editor is actually these blocks and it's surprising me actually how quickly people are embracing that and going I thought it wasn't going to be like that I didn't know we were able to do this so there's a sense of kind of a little bit of excitement when people see it because it's quite refreshing and when you compare it to things that have been around for a while like Squarespace where you've got these drag and drop kind of blocks and still limited but like within content and it's just quite natural and I think people are going to be quite pleasantly surprised that WordPress has kind of brought it in and making it native I don't know if that is future but I know that it is present and I think that it's exciting not scary I would like to add something too may I so I approached this question from the other end of the market which is the large scale enterprise and we as an agency have embraced Gutenberg very very early on and there is pain there has been pain for us in some cases because we look at some of the things that we want to build it takes longer than we thought it was going to because there's a huge learning curve and even for our guys who are very experienced PHP developers in a lot of cases having to embrace this new paradigm with developing a lot more closely and react in the JavaScript on the other side of that are the clients who are we're putting them in a place where we're almost free not so much future proofing them things do change the stuff that we're building now we're not going to have to go through the technical debt of then converting them into a place where they're actually using the classic editor sort of going forward but we but it it has come with some pain and some challenges and but I think we're all on this place at the moment where we're prepared to embrace that for the good of the community and for our clients going forward the thing that I wanted to add to the conversation on this particular topic is that I love WordPress as much as the next guy right but the current editor is objectively bad it just is bad it's old and it's clunky and it hasn't been updated in years and so if you're going to tell me that you don't like Gutenberg fine but show me what's the alternative to the current editor because you know we need we need it to be updated we can't just love it because that's the way it's always been exactly and on that note I think Matt Mullenweg said something that I agree with which is like it would be very profitable and easy in the short term to do nothing but if we want to build a WordPress for the next 15 years you know let's do it I think the beauty of WordPress in general and the way that they have added many changes over the last few years that we actually really they you the automatic team and the team behind WordPress really respect the users that have been using it for a while they respect the different different capacities that people use it and that you know they understand that not everyone is looking at their WordPress website every day so they do tend to make things backwards compatible and I think that they've done a really good job of giving us options with Gutenberg and giving us an opportunity to test it and to disable it if we need to in order to get our sites ready and I think that that's kudos to the team they haven't just kind of you know slammed it down and said good luck there's been a lot of respect and care taken to make sure that too many people aren't affected by it. Who's next? Ricky Hi guys. Just want to a little developer question back to what you said at the beginning what do you need to create a block? You said JavaScript, that's a great answer. You didn't say react. So my question is about Gutenberg compatibility with other framework, JavaScript frameworks if it's possible to create a block in other frameworks and if it is possible like I heard with Zoomer would you assuming that you have different skill set or you could have a team in UJS or whatever Angular or stuff, would you actually even try or would you just like build a new team and react or a high react person? I mean how flexible the API that's my question. We've tried to build the APIs to be as react independent as possible I think I've even seen a just somewhere or maybe even a poor request I forget where I saw it where someone had built like an interoperability layer between view and what we expose so it's definitely something you could look into doing I don't really know how to answer what I think you're asking which is like is it worth retraining your team to use react I don't know maybe where we can we have tried to make it as framework independent as possible you've seen any UJS Angular implementation of blocks out there or is it not? find me later I'm pretty sure I've seen a view implementation of a block so we've got maybe eight or nine minutes to go so just giving you that heads up basically we have eight minutes to go so if you are desperate and busting for a question then get it up get your hand up the question they're going about the structure of Gutenberg there is a word that it's not only JavaScript but also PHP hence when you start testing you've got to have a specific hybrid environment to do that is that correct could you just put more light on that what is that actually mix of JavaScript and PHP for example a block yeah so it depends on the block you're building if you're building a kind of a user facing like an entirely user facing block then I think you would only need JavaScript where you would need PHP to enter the mix is if you're building a what we call dynamic block which is for example the latest Posts block that Luke demonstrated yesterday that's a dynamic block because when you view it on the front end the content you know is generated on the fly and that's done with PHP is that can I help one is in terms of framework one is entirely browser based JavaScript and the PHP goes into a back end as you're saying doing some operations so you need actually some setup for local environment or what's the advice on that yeah you if you're building a block you would be doing that in a plugin and your plugin would contain both JavaScript and PHP code in that case did you have something I think I would look at WordPress.TV and there are lots of good talks there on setting up your IDE so there was a talk just yesterday about setting it up with using XD bug for your PHP and then there are different things that you can use as well for debugging JavaScript in the browser so in terms of your IDE setup and all of that sort of thing I'd just refer you to some of the previous talks at WordPress question over here sorry just we also have seen in the community a tool called create gluten block which might be useful too as like a boilerplate for getting started awesome yeah hi so during the keynote yesterday Luke you were discussing some social media orientated content blocks for Instagram, Reddit, YouTube etc I was wondering how they were implemented regarding whether the content was brought in directly through the browser or if it was possible to cache some of that content PHP or server side and what we can do to make those content if the service on the other end wasn't serving fast interestingly that is not a new feature you can do that in the current WordPress editor only there's no button for it you just have to know that you can paste a link if you were to paste in that same Reddit link into the current editor and hit enter it would actually embed that in a very similar way users technology called that it would embed and I don't believe there's any caching layer but correct me if I'm wrong I think it happens on the fly in the browser yeah my understanding is that those blocks are implemented by the front end hitting the or embed endpoint if you wanted to implement caching on the server you could maybe look at customizing that block to have a to make it into a dynamic block I would note that a block doesn't necessarily have to be static or dynamic you can have a hybrid you can have the static content that renders you know everywhere like in an email client or an RSS reader or something like that and then also define in PHP a render callback which will replace that block with some dynamic content on the main front end of your website if that's a use case that you have I've really enjoyed the Gutenberg experience in developing websites but my question is around this what usability tests have been undertaken in assessing high performance bloggers workflow and performance in writing content lots actually I've sort of been involved watching the Gutenberg development process from the designer perspective and there's been some a bit of design led work done on the customizer in the past but to me Gutenberg is really the first major WordPress component to be created with designers sort of implementing the first idea of how it should work and then the developers coming in around that so to me that's a really exciting development and I've been a part of and seen a lot of user tests taking place actually a lot happened in Brisbane surprisingly and all around the world at word camps like this one and I've seen them at a word camp in Europe and in the US and basically there's been a lot of user testing and there was published on Anna Harrison's blog the user test that she got people to do and that I think was used as a bit of a template around the world so yeah it's exciting because this is really the first time that's been done in WordPress and I hope we see more of it in the future okay we got time for one more question so what would you suggest as the perfect transition to get used to Gutenberg for the for a website is it to install the plugin and be proactive I guess and if so what will be the difference between the Gutenberg as a plugin and once it's in a car will there be any difference there'll be less bugs in core so is it ready to go live now as a plugin on a live site I use it in production so I don't know I think I think it's a good time now we're using it in production as well we've been bitten a couple of times but it's changed but now that there's code freeze or feature freeze I feel like that's going to happen less and less so my advice is install it there's still people that would say install it locally and try it out before you commit but I install it and use it and give people feedback there's plenty of opportunity to be able to give feedback to the team to be able to help make it better I'll ask you since you guys are using it in production now what's going to be the best way to flick over from being using the plugin to when it drops into core what's the kind of process do we turn the plugin off or will it automatically turn the plugin on for us I have the answer on that one if you install the plugin version of Gutenberg now when Gutenberg makes its way into core in 5.0 the plugin version automatically deactivated so it will be completely seamless that's awesome, thank you that's a good place to end it we're around if you guys have any other questions you want to ask us directly we're more than happy to do that thank you thanks to our team