Cancel

Jeff Chandler

New Toolkit Simplifies the Process of Creating Gutenberg Blocks

Ahmad Awais, who created the Gutenberg Boilerplate last year, has released a Guten Block Toolkit. The toolkit substantially simplifies the creation of Gutenberg Blocks by providing no configuration, one dependency, and no lock-in.

Awais created the toolkit after receiving feedback that configuring things like Webpack, React, ES 6/7/8/Next, ESLint, Babel and keeping up with their development was too difficult.

"Developers told me that they built Gutenberg blocks with ES5 because the amount of time required to configure, set up, and learn tools like Babel, Webpack, ESLint, Prettier, etc. wasn’t worth it," Awais said.

"So, yes! I went ahead and built a solution — a zero-config-js #0CJS WordPress developers’ toolkit called create-guten-block!"

Creating blocks using the toolkit is a three-step process.

Developers begin by installing Node version 8 or higher on a local server. The next step is to run the create-guten-block command and provide a name for the plugin that will be created. This command also creates the folder structure necessary to maintain the project. The last step is to run the NPM start command which runs the plugin in development mode.

Once these steps are completed, the WordPress plugin will be compatible with Gutenberg and have React.js, ES 6/7/8/Next, and Babel, which also has ESLint configurations for code editors to detect and use automatically.

The Guten Block Toolkit comes with the following:

  • React, JSX, and ES6 syntax support.
  • Webpack dev/production build process behind the scene.
  • Language extras beyond ES6 like the object spread operator.
  • Auto-prefixed CSS, so you don’t need -webkit or other prefixes.
  • A build script to bundle JS, CSS, and images for production with source-maps.
  • Hassle-free updates for the above tools with a single dependency cgb-scripts.

The project has received positive feedback, including from members of Gutenberg's development team.

With a stable release now available to the public, Awais is working on 2.0.0. "The next step is to get this toolkit tested and mature the entire app to release version 2.0.0 for that not only do I need your support, I ask that you hop on board and contribute — that’s the only way forward," he said.

Create Guten Block Toolkit is MIT licensed and available for free on GitHub. Contributions are welcomed!

Category:
Tags: , ,
36

36 responses to “New Toolkit Simplifies the Process of Creating Gutenberg Blocks”

  1. 🙌 Thank you, Jeff, for writing about create-guten-block :) — that’s awesome!

    📦 I just pushed a minor update with better communication messaging during watch and failed builds.

    Folks, developer of create-guten-block here, ask me anything related to this software if you find an issue report it to the GitHub repo link below.

    🔰 Lastly, I have not seen a single good software that’s built by a single developer, I’d love for you folks to help me improve this and move closer to the create-guten-block v2.0.0 milestone.

    Resources:

    — Git Repo: https://github.com/ahmadawais/create-guten-block
    — CGB 2.0.0 Roadmap: https://github.com/ahmadawais/create-guten-block/issues/11

    Peace! ✌️

    • Awesome work, Ahmad. I already cloned the project locally and started diving into the code — I’m sure it’ll help me and other developers to ease the transition to Gutenberg. Kudos!

      • That’s great. BTW the code of this project is of less use to you, I think you should use it and report any issues you find. First few issues have already been addressed and I released a minor update today.

        So, glad you liked it! 🙌

  2. While this is a brilliant tool, what have we ffin done for new users dipping their toes into web development? Before even tinkering with a few lines of code we first have to configure all this complexity just to get started. Installing node on a local machine, with hundreds of modules being pulled in. Trying to parse JSX and React. Build scripts operated by complicated projects few developers understand. Yes, it’s nice that a lot of this complexity can be magicked with a tool like the one covered here. But why has it gotten to this in the first place? WordPress has now inherited the worst aspects of contemporary JS development. What a disservice to new users and beginners that is.

    • Gutenberg will surely attract lots of new regular users to WP, but I foresee a decline of plugin and theme devs over the next years because of the unnecessary complexity that JS will add to the platform. One of the strong points of WP was the use of an extremely easy-to-learn but powerful language like PHP, despite the hate it gets from a segment of the developer community.

      • I happen to think that it will be a good thing. We need to make WordPress easier to use and not develop. Developers can always learn a new skill but users are getting used to tech made easy for them.

        The better UX for users means the better platform. And if devs/designers that got away with coding bad themes and plugins before are now being forced to learn better ways to write code and write standard compliant code, then that’s a good thing right?

        With only quality themes and plugins, with quality devs, I think WordPress stands a chance to grow bigger and better.

        Right now, IMHO, the themes market is a mess.

      • if you see the sheer amount of adaptation that Visual Composer, Divi builder and other drag-and-drop builders brought on you realize how much demand is out there for this.
        Those third party builders were all packed with JS, so I think bringing something similar to the WP core it’s just the right thing to do going forward

    • If we don’t innovate now, we don’t stand a chance to of making it to the future with WordPress. New tools are far more superior and WordPress which once was a cutting-edge software now feels like a broken tool.

      The publishing experience is such a nightmare that so many folks have moved away from WordPress to something like Medium without a second thought about the fact that now they publish for Medium instead of their own publications.

      I think technology is hard by its inherent nature. Nothing you can do about that. That also shouldn’t be the reason to not move ahead.

      Two cents.

      • And if devs/designers that got away with coding bad themes and plugins before are now being forced to learn better ways to write code….

        With only quality themes and plugins, with quality devs, I think WordPress stands a chance to grow bigger and better.

        That’s quite a bold statement, bordering on obnoxious, to be honest. The “modern JavaScript” workflow doesn’t by default equate to “better ways to write code” nor does it by default make one a better developer, and the QA problems you mentioned in the theme ecosystem, while very real, certainly aren’t going to be solved by React.

      • technology is hard by its inherent nature

        But this is exactly the kind of catch-all excuse that justifies any level of complexity. It rests on a false premise, that all of the crap developers (including me) have built around the languages is symptomatic of a better way of doing things. Most of these tools are hideous creations made because browsers and languages didn’t evolve fast enough.

        But that’s no longer the case. But now we’ve normalized all of the extracurricular crap, from transpilers to unspeakably complex config files, from literally thousands of files being required for the tiniest of projects to slavishly following the latest over-complicated solutions of tech companies (would React even exist if browsers rendered dom updates more efficiently?). This is not progress. It never was.

        Consider what’s happened in the CSS world. Did Sass make beginners fall in love with CSS? I very much doubt it did to any significant degree. And do we really desperately need it today, now that we have CSS variables while most new features no longer require a prefix? Not really. You can write professional CSS code without ever touching sass or less or stylus and sass doesn’t turn people into better CSS coders either. But it does introduce a higher barrier to entry for people getting started. And there’s a silent cost to that, a cost that we are also willfully ignoring in WordPress as we introduce even more developer contraptions dressed as progress and necessities.

      • f we don’t innovate now, we don’t stand a chance to of making it to the future with WordPress

        BS. I’m sick and tired of people trumpeting that WP is awesome and used by 30% of the sites out there and in the next breath it’s close to doom and cannot survive. I’m even more annoyed when people do this without differentiating that WordPress the software, while it does need o change and evolve, is OK. The WordPress.com side is what’s under threat from Wix, Squarespace and the like and it’s a very real issue that Matt has such power in WP when he’s also running a business based on it.

        But this is all for naught. The team does not care about our comments. They can’t even put out a roadmap. They can’t or won’t commit to features, answer clearly questions about why Gutenberg in its first incarnation has to take over the entire edit screen vs just the editors, etc. Either the team is amazingly incompetent at the basics of software project management or they simply don’t want to tell us this stuff.

    • This. Exactly this.

      The success of WordPress as it stands today is also based to great factor on PHP and that it was/ is easy to learn and understand for beginners. Like Matt once said: “WordPress brought me into PHP” – hey, the same for me.

      With JS and all those JS frameworks and stuffing my machine up with all these useless build tools and the whole kitchen sink is no fun.

      It all creates a new entry barrier for WordPress users, “implementors” and developers.

    • Exactly.

      The way I see gutenberg, is as a big differentiator between the 10$/hr developers and 100$/hr ones. You will not be able any longer to hack something quickly with some code snippet you found on the web, instead you will have to understand build environments and maintain them. Even core sucks at it right now with the small build step that is required to build wordpress in 4.9.1 as it did (does ?) not work with the new version of node and you have to figure out that you need an older version….

      But this is JS in general problem, and not gutenberg specific one. JS is a much more complex language and less mature than PHP (obviously talking about PHP 7+ line here) and you actually need the supporting tools. But building JS is just the first step, debugging is going to be even more fun with all the minimized and compiled dependencies.

      • Nothing to add here.
        Please find me at least one savvy people who can onestly say that is “normal” for a project of 20/50 files to require the building of an environment with hundreds of dependencies, framework, parser, makes steps, just to build the developing environment. Hours over hours of digging in obscure config files just to run the place where finally you can code your ten files WordPress plugin.
        There is too much hipe around all of this, and unfortunately WordPress leaders fell in it.

        Oh, btw, I still think that something like Gutenberg is desperately needed for the survival of WordPress in the next years as a successful project

  3. Looks like an improvement over the normal way to do things. What about creating blocks from inside a theme?

    As it is now, it’s just a matter of writing one PHP function add_meta_box() in your functions file, update_post_meta(), some PHP and basically you’re done.

    I don’t know any webpack, React, ES 6/7/8/Next, ESLint, Babel, etc.

    • For now you only have to add support for the REST api in order to display your meta box in Gutenberg editor. Check this thread. Big relief for me.

      • Guido, what is the Extended Settings Tab? Is it something (a panel) in the right sidebar? Or the normal place, below the content editor?

    • Glad you liked it! 💯

      About themes, you shouldn’t be doing that. I think blocks should always be in the form of plugins. This is just how I think at the moment.

      • Hi Ahmad, thanks for your answer and the work you put in the toolkit.

        Would you say it’s technically not possible to build the blocks inside a theme? More complicated? Or is it just a preference?

        Having about 60 active WordPress sites online at the moment, most of them use a few lines of PHP inside the theme itself to create meta boxes. Even though I understand the reasoning for putting meta boxes inside a plugin, for my use case it’s better to put everything in the theme. They are themes specifically build for clients, not distributed. So I prefer everything to be in one place.

    • Guido, what is the Extended Settings Tab? Is it something (a panel) in the right sidebar?

      Yes! In this “panel” your meta box will be displayed like in the classic editor. So meta boxes are still supported, using Gutenberg editor. And you don’t have to change them into blocks (for now at least).

      Guido

  4. To everyone dishing out the hate, give this toolkit a go and also checkout Zac Gordons course too. I was a bit on the fence with GB, but the team have done an amazing job. I have been playing around for about 1hr and have been able to make a reusuable text and image block which I normally use a page builder for.

    There is some really amazing features with GB under the hood such as the ability to write css to the back/front end which is a total game changer.

    • Man (no gender discrimination intended) you are just doing it wrong. You are using wordpress as a frontend/dreamweaver replacement and not as a CMS.

      There was nothing except of lack of knowledge that would have prevented you to insert and edit images in whatever fancy way you would like, all you needed to do was to override/extended the relevant backbone template.

      Why didn’t you? Why very few others done it? because after the initial excitement of having backbone templates in core there was no one which took upon himself to maintain proper documentation about it.

      WordPress core for years had failed to produce any decent documentation and guides regarding the usage of JS in core. The idea that the same people that have not done it before will suddenly start doing it properly now is ridiculous. The fact that an outsider had to create a tool which the GB team should have is a bad indication and the fact that GB has right now 500 open issues with an un believable release date of april indicates that no one will put any attention into it.

      Creation of block is most likely to become a kind of ‘dark magic” like using the media library APIs today.

      • Tbh you are very right i dont know a lot about the wordpress backbone framework.

        Truth be told i havent touched backbone for over 5 years. Most of my day to day work is in react so in that respect its good for me vs backbone.

        You are using wordpress as a frontend/dreamweaver replacement and not as a CMS.

        Yep exactly and? I will still continue to use the CMS aspects as well in combination with gb.

        My clients are typically marketing agencies and project managers, they want websites that are easy to visually update – this is the world we live in.

        We’ve dabbled in squarespace and wix and we found they lack a lot of the cms aspects of wordpress. Take a look at some of the videos from state of the word you will see the vision for gb is really to get the best of both worlds (cms and visual editor)

        Now will people continue using and documenting gb? I know i will because i am going to start using it for all projects moving forwards.

      • @Rhys,

        Sure there is a huge segment for which a page builder is exactly what is needed. But if you go that direcion you need to ask yourself whether GB id better than element/beaver/divi etc.

        Regardless, it seems like your lack of understanding why people complain is the result of this. The people that complain use wordpress as CMS with cleints that need to be able to manage relatively big and complex content. Those clients are not a “one off” project, and have people that will need to be retrained in order to keep using their complex systems. You will need to explain to those people why is there an additional cost to maintain their site, just because core introduced a new feature that do not bring any improvements to their system.

        Than there are people with the more abstract objection about project planning and dependencies. Everyone that have done enough software development knows that those things are the real killer in the long term.

        When there is no official feature planning developers are most likely going to just hack randomly, and only after fixing all the bugs you are likely to get a useful product. It is likely that in 5.0 GB will not be useful for anything other than simple blogging.

        And the other long term killer is dependencies. Can you actually use a tool maintained by a big company as a dependency? The history of angular and HHVM shows that the answer is a NO. The big companies are interested in their bottom line and if a technology do not cut it any longer they will just scrap it or make fundamental changes to it that will require all of the users to adopt.
        So in two years (avarage life time of all JS frameworks) GB will need to be redone to use react2 or some other framework, and plugins and themes redeveloped, and most likely clients retraining again.

        Unlike what people like to say, no one is complaining here about the change because they are afraid of change. You might disagree with the reasoning, but no one bashing GB without a reason (as it seems like you think). The fact that the core team do not want to engage in a real discussion with the community is just sad.

      • Hey @mark k – you make some very valid points and you are definately very knowledgeable with regards to WP however I would encourage you to take a deep dive into GB docs, talks and Zac Gordon’s course – some of the points you bring up are addressed.

        For example, I originally was concerned about the use of React, but then when taking a deeper dive into the GB repo I could see that there is a WP abstraction layer that sits on top of React’s core API’s. In this respect React could be switched out quite easily with another JS framework.

        Also I would encourage you to engage in the project itself via Github or other means (if you haven’t already). You seem like a very knowledgeable person and would be a real asset to the project.

  5. Awesome work from Ahmad! This tool really speeds up the process working with Gutenberg. Setting up the environment is a huge pain!

    • Glad you liked it! 💯

      Keep up with this and I have a few more releases planned for four different projects to help WordPress devs get better and write better code.

  8. 🤐 It’s sad to see that some people fail to even try what I have built here and are continuously complaining about hundreds of dependencies and configuration files that I actually set out to remove from the equation.

    🔰 Let me reiterate: with create-guten-block you don’t have to do any of that. It’s just one dependency and no configurations. #0CJS

    I’d like to suggest that if you just give this toolkit a try and run

    npx create-guten-block my-block

    inside your local WordPress install’s plugins directory — you’ll know what I am talking about. (Make sure you have node >8 and npm >5.3 installed — npx comes bundled with npm >5.3 and doesn’t install anything globally).

    Peace! ✌️

    • I don’t think you should be sad Ahmad. You can’t please everyone and I think it’s better to accept that. For me personally, this tool will be super useful and I thank you for that.

      Peace!

  9. How can I program a Gutenberg block without all this npm and node and whatever files, on Windows with Notepad++, which I use since 5 years to develop all kind of plugins and themes?

  10. The problem most designers and some devs do not seem to understand is that content creation in CMSs is already invented and pretty much standardised.

    It is just like with the wheel. That has been invented several thousands of years ago and anyone who tried to reinvent it, has failed. The wheel is still round. So no matter how fancy UI you develop, people will just want to type letters and use images/videos/sound for illustration. In reality they just simply do not need all the hassle with too complicated technologies for so easy things. And by the way, those who create content, simply do not want a really fancy design as it would just distract your mind from the actual content they wanted to share. If you are hungry for design and eyecatching art, you should rather go to an art gallery, paginate picture books, paint pictures, etc.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: