Crocoblock developers team is always open to new approaches and embraces everything top-notch in the field of web technologies and programming. That’s why we just couldn’t miss the brand new Gutenberg WordPress editor that becomes more and more popular with each passing day.
One of our team’s senior developers, Andrey Shevchenko, is fond of complicated tasks and looks forward to challenges that arise with time. He’s the very developer who’s behind many of Crocoblock’s popular products.
Lately, our team has launched a new and very uncommon product, which will never be added to Crocoblock subscription because it’s not suited for Elementor.
We’re talking about JetGuten addon for Gutenberg page editor. This is a light plugin which adds 9 special content widgets to the list of available blocks in Gutenberg.
Today we’ve prepared an interview with Andrey Shevchenko, our senior developer, to clear up how the process of web development for Elementor differs from the process of developing addons for brand new Gutenberg editor.
But first let’s add a little explanation on what’s Gutenberg editor for those, who haven’t heard of it yet.
Actually, many bloggers were talking about it even back then in 2017, however, the end-users have got an opportunity to use Gutenberg not so long ago. At the moment, Gutenberg editor is represented in WordPress v.4.9.8 Dashboard and you can easily install and activate it right from there.
In the plugin’s description on WordPress.org you can see that “Gutenberg is more than an editor”. This can’t be denied, as we all are used to builders that completely change the UI and look like something completely different from the native Dashboard.
While working with Gutenberg, you get an impression that it’s an irreplaceable part of WordPress that provides even more functionality than you had before.
Sure, Gutenberg editor is completely different from Elementor, and it would be not fair and not professional to compare these two products.
Gutenberg is different both in its appearance, as well as in the principles of work. And the last thing is really important for developers.
So, if you want to start developing functionality for Gutenberg, this article might be really useful for you.
Our senior developer Andrey Shevchenko will answer all the questions and will gladly share his experience with you.
Why, of all editors, Gutenberg?
Andrey: I guess, that’s because everyone’s lately been talking about it *jokes*. Well, our team just wanted to check if we can add the similar functionality we already implemented for Elementor, to Gutenberg. We also were curious to compare the usability of the same widgets and block in Gutenberg, when compared to Elementor.
I have been observing Gutenberg for a while, and developing an addon for it was rather a question of time. Of course, I think Gutenberg will eventually become popular when it’s added into the core of WordPress. Actually, we’re talking here about the accessibility of Gutenberg – all WordPress users will be able to work with it.
From where came the idea of creating an addon for Gutenberg?
Andrey: Our team already has some successful experience in creating addons for Elementor. Our first and most popular addon is JetElements plugin, that adds more content widgets to Elementor. The first thing I thought when I opened Gutenberg was: “We need more content, and more ways to style it up”.
Then, when I thought more about creating an addon for Gutenberg, I decided that we could add at least the most basic widgets that are available in JetElements. That would be the right thing to do.
Gutenberg editor has already rolled out, yet the users notice that developers keep improving it: lately there were changes in the interface and functionality. How difficult was it to work on addon for Gutenberg?
Andrey: Gutenberg editor is relatively new, yet it is was officially released. However, everyone knows that you need to start from somewhere in order to create a great product. I guess, Gutenberg editor is on its way to becoming a better version of itself. We don’t know if it is destined to become great, yet we believe in it.
Answering on the second part of the question: one of the problems our team’s faced is updates sensitiveness.
We have created JetGuten addon in several weeks, and all this time we were constantly making changes to make sure our product is fully compatible with the new versions. First, we added several corrections into the code because the API has changed. Then, there were other corrections, as the newer version was released.
However, Gutenberg developers always make sure we know about the upcoming updates beforehand. There is a notice in the browser’s console, it is easy to be seen, so if you’re developing your own plugin for Gutenberg, I’d say, you’ll be more than able to add the fixes beforehand and be sure that your addon works with Gutenberg smoothly.
You can also follow Gutenberg in order to learn about the future updates and improve the addon’s compatibility with the future versions of Gutenberg before the new version is out in the world.
I think, ensuring that everything works properly and the addon is compatible with Gutenberg, is a must.
Also, I have noticed that the blocks used in Gutenberg are extremely sensitive to any changes of the HTML-markup used inside of them.
For one, almost any little bit of changes in the save() method, which I’d like to mention later, will cause the issues in the blocks created before. When you’re still on the development stage, this is not a really big deal, yet, if you’d want to update your addon in the future, the changes in the markup will lead to breaking the blocks that were added earlier for all the clients who’ve used the block before on some of the pages, and then installed an update.
Does developing for Gutenberg requires specific knowledge or experience?
Andrey: Not really *jokes*. Well, if you’ve been working in the field of web-development for some time, this won’t be a newsflash for you.
In Gutenberg we just see that Matt Mullenberg actually gave us a direct pointer.
Let me explain it in more details.
If you take a look at the diagram below you’d see the statistics of programming language usage for our brand new JetGuten addon.
Actually, in the first version of JetGuten we used PHP only for creating the classic “wrappers”, enqueuing CSS and JS files and for several AJAX callbacks.
The JS file of the block includes everything concerning the appearance and the settings of the blocks.
Also, I’d like to pay attention of the developers who’d like to work with Gutenberg in the future, that they won’t be able to go without Gulp, NPM or Grunt knowledge.
However, once you’re on board with Gutenberg, you’d need to convert the code you’ve written, and that’s when you’ll have to face the fact that you need to use automatic development tools.
E.g., our Banner block has 530 lines of code.
In general, JetGuten provides 9 blocks for Gutenberg, and when you sum up everything, you’ll get 4770 lines of code for 9 blocks. That’s huge! It might be very frustrating to support such plugin in the future.
How developing an addon for Gutenberg is different from the past projects?
Andrey: I have been in the development process for years, and I relied heavily on one of the most basic principles in programming: “always separate the logics from the presentation”. You learn to use it in practice while working on different products.
However, it’s really different when you work with Gutenberg.
Let me explain.
Usually we divide the logics from the presentation. On more basic level, the theme represents the appearance while the plugins are responsible for the logics. Bringing in closer to WordPress products, you can divide any plugin or theme components into two separate types of files:
- Templates, that are responsible for the appearance and layouts;
- The files with logics.
For one, in WooCommerce plugin we have “templates” directory with the files that are responsible for appearance. And you can see the files with logics mostly in the “includes” folder.
The templates can be often overwritten from the theme itself, and this gives the ultimate freedom to the front-end developers as well as end-users. It is easy for everyone to change the design and appearance without making changes and influencing the actual logics of the product.
When you work with Gutenberg, you don’t see the separated logics and appearance, everything is tightly intertwined. Logics is tied to the appearance inside the block, and the design can be overwritten by user from the theme. So, we’re bound to CSS for editing the appearance of the blocks. And we can’t make changes in the HTML code in some situations.
What are the most vivid advantages for the developers, when you compare Gutenberg to other editors?
Andrey: The first and foremost advantage is that we’re free to create the needed UI that would be the most convenient for the user.
Actually, it’s a bit of exaggeration, yet the developers have access to 2 different locations for adding the UI elements:
The body of the block inside the editor – here we can give the user an opportunity to fill in the needed title, set the images, and he’ll be able to see the changes this instant;
The side panel with the settings (also called “block inspector”) – here we can place even more customization settings, like color pickers, typography settings, etc.
Actually, you can place any controls to both of these locations, including the standard ones, that are already included in Gutenberg. Or you can create your own ones and also place them inside the side panel, or block’s body.
I think it’s very convenient. E.g., we have added the control for flipping the Animated Box to Front or Back side and placed it in the toolbar in the block’s body.
Another advantage of Gutenberg is that this editor allows to change how the block is represented inside the editor, and on front-end. There are two methods that are responsible for the view on front-end and in editor:
- edit() – this method is used to create the interface in the editor;
- save() – here you can define how the block will be written in the database.
So, we’re not limited by the same looks in editor and on front-end. And this helps us make the editor even lighter.
For one, in Image Comparison block from JetGuten we have an ability to compare two different images by dragging the control. We have used the third-party library to implement this functionality, and once the person changes the settings of the block, the script has to re-initialize, and it influences the performance in browser.
So, in edit() we have decided to create an HTML-markup, that is equal to the result you’ll have on front-end.
However, not to overload the editor with the extra actions in the edit() method, we have refused from using the option for toggling the control.
In save() method we have saved only the needed markup that is necessary for the third-party script to initialize.
This way we managed to tune up all the needed components in editor without slowing down the performance in the browser, and then on front-end we’ve got the block with full functionality.
Which sources would you recommend to other developers who’re brave enough to work with Gutenberg?
Andrey: Gutenberg is a relatively new editor, and in contrast to those editors that have already been a while around, it has a lack of best practices. However, I’d be glad to recommend the resources our team used when working on JetGuten. These are:
- Gutenberg handbook with full documentation;
- Examples for creating blocks at GitHub;
- WordPress community members;
- Gutenberg’s repository.
All these sources immensely helped us in creating JetGuten, and I’d gladly recommend them.
Do you think Gutenberg will be popular among end-users? What does this mean for developers?
It’s difficult to tell for sure, yet we believe that Gutenberg editor will take its rightful place in the forthcoming WordPress v.5.0, and it will become one of the most frequently-used editors.
Even now I can tell that Gutenberg editor is a powerful tool, and it will evolve with time. It will certainly change the workflow of the developers who create products for WordPress.
Gutenberg gives us an opportunity to see how WordPress will be evolving with time.