Gutenberg Cloud: A Cross-Platform Community Library for Custom Gutenberg Blocks

During their presentation at Drupal Europe, the Frontkom team behind the Drupal Gutenberg project announced that they are working on a block management system called Gutenberg Cloud, a collective library of blocks online.

The library will offer a content repository for custom Gutenberg blocks, such as forms, a call-to-action section, product grid, or even a web component. Since the blocks are JavaScript-only, they would work across both Drupal and WordPress alike, so developers can build for both platforms simultaneously. The Gutenberg Cloud creators are aiming to facilitate a new level of cross-platform sharing that few envisioned when the Gutenberg project began.

“Gutenberg to us is much more than just another module,” Frontkom CIO Per André Rønsen said during their presentation at Drupal Europe. “We think of it as a platform for brand new features. We are very excited about the sharing/community aspect and the possibilities here. We want to make it easy to share and reuse custom blocks across pages, across projects, across companies, and even across publishing platforms. Drupal has always been great at sharing backend style of code. Now let’s make it great at sharing frontend code as well. This is why we’re working on a block managing system.”

Gutenberg Cloud would provide a plugin for WordPress and a module for Drupal (and eventually other applications) that would enable users to browse, filter, and discover blocks within the admin and download the ones they select. Early mockups I previewed show an interface similar to the theme and plugin browsers inside the WordPress admin.

A cloud-based block service solves a few problems that Gutenberg early adopters are already experiencing when hunting for blocks. WordPress theme and plugin shops have have been releasing their own block collections bundled into a plugin, but it’s not easy to discover or browse the individual blocks. Having blocks available on Gutenberg Cloud would prevent developers from having to create a new module or plugin for each individual block. It also prevents users from having to download an entire collection of blocks in a plugin when they really only need one or two of them.

Gutenberg Cloud Will Launch as a Community Project, Developers Contribute by Publishing Packages to NPM

Rønsen said they plan to launch Gutenberg Cloud as a community project. Any developer can contribute blocks by creating an NPM package and tagging it with “gutenberg-cloud.” The description on the cloud service outlines their intentions: “Code once, use everywhere: As Gutenberg blocks are CMS-agnostic, we want to provide an ecosystem all systems can connect to.”

An example Hero section block published to NPM

“We imagine everything from freelancers to big agencies and even community minded non-profits to contribute,” Rønsen said. “When people benefit from a better user experience, they tend to want to pay it forward. We have already talked to people in both communities wanting to contribute with code, so that is a great start for the platform.”

I asked if his team envisions block creators being able to sell access to their blocks in the future. He said his team is open to finding a payment solution for commercial blocks but only if the community demands it.

“Personally, I would be skeptical about committing to a community project that had a very commercial edge,” Rønsen said. “I think it’s important that the project stays focused on open source contributions, with a sharing-is-caring attitude. It’s the only language we know in Drupal. However, there is nothing wrong in providing high quality content and getting paid to do it. That’s why it’s on our roadmap to facilitate a payment solution for premium blocks – if the community wants it. It’s not central to the success of the platform, but I imagine it could be a great way to make some money for a skilled designer.”

Rønsen said his team plans to launch Gutenberg Cloud sometime later this year after completing internal testing and an invitation-only closed beta with a different companies. One of the most challenging aspect of the project is creating a system that can handle updates.

“By default users will get the latest stable release for the block from the author,” Rønsen said. “There will be a way to lock into a specific version and to version control that in Git, however. The plugin update system is a good analogy, but the infrastructure is completely outside of WordPress core. There are also some issues we haven’t solved yet regarding updates; it’s hard to make a system that doesn’t require a high maintenance effort for block developers.”

The Gutenberg Cloud project is contingent upon Gutenberg development continuing on a path towards being a library that is decoupled from WordPress. Last week Rønsen told the Tavern that his team hopes “that Gutenberg core devs will catch onto the vision of Gutenberg as the ‘editor for the open web’ — not just for WordPress.”

Gutenberg team member Gary Pendergast indirectly acknowledged this in a recent blog post that affirmed the Drupal Gutenberg project and reiterated WordPress’ mission to democratize publishing.

“One of the primary philosophies of Gutenberg’s technical architecture is platform agnosticism, and we can see the practical effects of this practice coming to fruition across a variety of projects,” Pendergast said.

“From early experiments in running the block editor as a standalone application, to being able to compile it into a native mobile component, and now seeing it running on Drupal, Gutenberg’s technical goals have always included a radical level of platform agnosticism.”

If the Drupal community ends up adopting Gutenberg for its core editor, the shared library presents an unprecedented opportunity for deeper collaboration across the two publishing platforms. As an agency that has done client work for publishers on both CMSs, Frontkom saw the potential before many others and took it upon themselves to fork Gutenberg for Drupal. This is the beauty of open source software in action.

“WordPress has many advantages that make it so popular, but hoarding those to ourselves doesn’t help the open web, it just creates more silos,” Pendergast said. “The open web is the only platform on which publishing can be democratized, so it makes sense for Gutenberg to work anywhere on the open web, not just inside WordPress. Drupal isn’t a competitor here, we’re all working towards the same goal, the different paths we’ve taken have made the open web stronger as a whole.”

Rønsen said he could see other applications and e-commerce platforms like Magento benefitting from better page-building tools. His company has a special interest in publishers and plans to release a set of open source tools for building news front pages later in 2018. Rønsen said he is hopeful the Drupal Gutenberg project can evolve alongside WordPress as it enters into the site building and customization phase of the project.

“I’m hopeful that the Gutenberg project will stay decoupled from WP one way or another,” Rønsen said. “This will leave room for Drupal to innovate on top of it. It could even be the case that the page building tools and customizer integration in WP will play nicely into the current architecture. In any case, I believe the basics of the editor and block concept will continue to be a good fit for Drupal. There is already some consensus out there on how to use Gutenberg for page building. A great example, is Big Bite’s work with Amnesty. If the continued experience is anything like that, I think we have a perfect match.

12 Comments


  1. I like the idea, and I look forward to a WordPress plugin that will enable the ability for these cloud blocks to be selected and downloaded (?) and used in a WordPress system.

    At the same time, I remain unconvinced that js-only blocks have a place which is meaningful other than the trivial layout based things that blocks can do. Yes, you can build great looking blocks with JavaScript only, and since it’s an editor, that is a really big deal. But without any actual support on the backend to “do stuff of substance”, it is just visual glitter.

    Don’t get me wrong, making a big library of visual fluff is a great idea. Layouts for some, tiny American flags for others. (I voted for Kodos!)

    But, I usually write server code. I like the Gutenberg editor, but JavaScript just isn’t enough to do the things that I tend to do. And it can’t be, because the client isn’t the place to be doing them.

    That said, I do understand that what I consider to be “trivial” is HTML and CSS, which is decidedly not trivial to most people. So yes, it’s a good idea. I’m just the wrong person to try to convince of that.

    Report


    1. Not sure if I know enough JavaScript to understand fully but could you clarify ‘actual support on the backend to “do stuff of substance” ‘?

      Report


  2. It still feels like the majority of CSS/JS should be controlled from theme part and not from a plugin. Backend should be more involved in block generation the majority of blocks should only control the data, not the actual CSS/HTML/JS code.

    Simplest example:

    – Plugin/theme “A” wants to display image gallery as elements
    – Plugin/theme “B” wants to display image gallery as elements

    Gutenberg block generated gallery with elements. What should plugin/theme “B” do? Parse HTML (ew)? Write the second image gallery block?

    Report


  3. Wow! Could Gutenberg eventually turn into a universal head for headless systems?

    Report


    1. Indeed! It’s open for anyone to use, ready to integrate with any underlying system. We even have a sandbox where all content is stored in local storage; no server involved.

      Report


  4. Well .. it certainly is going to clash a lot with data protection rights (and issues), eg. the GDPR :)

    cu, w0lf.

    Report


  5. Looks great. Since I’m not a dev, one of the the things that has been bothering me about Gutenberg integration is the difficulty to find already made specific blocks in existing plugins. Plugins of this kind tend to contain several or a lot of blocks, the majority of which you may never use at all. Furthermore, you can find your needed blocks in different plugins, making it difficult to accept that, to use 1, 2, 3 blocks, you have to load 2 or 3 different plugins and tens of blocks.

    So, the alternative is building your own blocks. But the majority of WordPress site owners won’t know how to do this.

    A blocks infrastructure like this – or single-blocks-plugins, for that matter – can alleviate the need to load different plugins and useless code, allowing us to use only what we need.

    One other question I have is how does a solution like this allow us to use WordPress dynamic content? If the blocks are CMS-agnostic, how do they communicate with WordPress content?

    Report


    1. That’s similar with plugins already now. Currently you find your needed functions in different plugins, the majority of each plugin functions are never used, and majority of WordPress site owners do not know how to write own plugins. That’s why wp.org provides a plugin repository.

      A blocks repository needs to be provided by wp.org itself, similar to plugin repository, but for single blocks. Third party repositories (this can be “plugins with many blocks” or “some external blocks cloud”) are no solution. Would be a loss of qualitycontrol as well as gdpr issues.

      CMS-agnostic blocks would require js-only blocks, which Gutenberg tries to achieve (at least in its theoretical concept), but as @Otto explains above, it does and will never work for more complex serverside provided dynamic data. The current REST API is not abtract enough, it is just a “hacked up” version of the old REST API and atm. causes more problems than it solves.

      To get CSM-agnostic serverside data, a whole new and well structured API would be necessary, name it “Fields API” or whatever you like, but as @photomatt explained in “State of the word 2017”, this proposal has been rejected for the time being.

      TLDR: Since you’re not a dev, you need to hire devs, with Gutenberg even more than before.

      Report


      1. Thank you Steffen. I hear you on the dev hiring issue. But, you know, WordPress has expanded so far exactly because it empowered those who did not have the skills for complex stuff, that could find a lot of ready-made solutions and go from there.

        With Gutenberg, although it is painted as a solution to simplify the creation of content and pages, this flexibility and plasticity, which allows almost anyone to learn little by little and build more complex stuff, is somewhat gone.

        Don’t get me wrong, I’ve hired devs for some work that I can’t or would not dare to do. And I should do it more, definitely. if I only knew that I would come to this point of being involved in creating digital publishing solutions, I wouldn’t have wasted my time studying psychology.

        Report


  6. This is awesome. As a middle tier developer, I’ve come from the custom field and template realm of WordPress. I’ve been creating my own forms of blocks using custom fields. I like the idea of Gutenberg because it speeds up that process but I’m not adept at React so I’ve shied away from developing my own blocks.

    I REALLY like that I won’t have to download a plugin with a bunch of needless functions. It’s my biggest pet peeve of themes and plugins. I’d rather have 30 plugins that each do something specific and needed then 5 plugins with 50 different features I don’t use or need that add unnecessary files to my websites.

    Report


  7. From the start I felt blocks should be something parallel to and independent of plugins. This isn’t quite that, but I like it a lot!

    Report

Comments are closed.