Cancel

Sarah Gooding

Gutenberg Cloud Plugin for WordPress is Now in Beta

Frontkom, the team behind the Gutenberg Cloud project, has published the beta version of its WordPress plugin to the official repository. Cloud Blocks serves as a connector, allowing WordPress users to browse and install open source blocks from Gutenberg Cloud. The blocks are hosted on NPM and their assets are served from CloudFlare using unpkg.com.

Gutenberg Cloud’s online library of blocks is CMS agnostic, offering blocks for both Drupal and WordPress sites, and more CMSs in the future. The service advertises three key benefits for developers who host blocks on Gutenberg Cloud:

  • Wider adoption: Your blocks can be used outside of WP
  • Discoverability: Your blocks will pop up in the Cloud Blocks UI
  • Faster development: No plugin/SVN needed, just publish to NPM

Frontkom is actively recruiting WordPress developers to add blocks to the cloud to test the process. Documentation for migrating blocks from a plugin is available on GitHub. Frontkom has also produced a new boilerplate generator for building Gutenberg Cloud blocks.

Users should note that the team is still ironing out the experience for developers adding blocks to the cloud, so the plugin isn’t yet ready for general use. It’s currently under active development.

WordPress Developers Say Gutenberg Cloud May Not be the Best Way to Release Blocks but Platform has Potential

I contacted some WordPress developers who have tested sending their blocks to Gutenberg Cloud to get their initial reactions to the platform.

“The idea that folks will be able to install blocks a la carte is interesting,” CoBlocks author and ThemeBeans founder Rich Tabor said. “It’s pretty much as easy as installing plugins.”

Tabor experimented with migrating his Block Gallery blocks and said the process was not difficult but he foresees difficulties in maintaining blocks across parent plugins and Gutenberg Cloud.

“As a developer, I’m still not entirely convinced Gutenberg Cloud is the best way to release blocks, aside from relatively simple blocks,” Tabor said. “I personally lean towards building suites of blocks that share a relative purpose, instead of one plugin (or one Cloud Block instance) per block. For one, it cuts down on maintenance quite a bit, as custom components can be shared between blocks. And there’s much better discoverability on getting relative blocks in the hands of users — if they’re grouped together.”

Block collections have been criticized for making it difficult to search for and discover individual blocks, but Tabor makes some good arguments for improving block discoverability by grouping together features users often need. That is the whole point of successful plugins like Jetpack, but this type of packaging also lends itself to criticism about bloat.

“It’s a similar conundrum when we look at grouped/not grouped shortcode plugins,” Tabor said. “I suppose the main difference is that the nature of blocks is much more complicated than that of shortcodes. History seems to repeat itself.”

Tabor said he is considering distributing a few of his free blocks through Gutenberg Cloud but he hasn’t fully decided yet.

WordPress core contributor, Josh Pollock, who has worked extensively with React and Gutenberg, also tested the Gutenberg Cloud platform. He said he thinks it has a lot of potential for developers who write blocks that are mainly JavaScript already.

“I could see how an agency that builds WordPress sites could save a lot of time and hassle building out a block library,” Pollock said. “As a plugin developer with a lot of little ideas, the pain and time of setting up a block and block environment, which no one has gotten right yet, makes me very excited about this.”

Pollock also reported a positive experience with the create-cloud-block generator.

“The code that create-cloud-block generates is well-written, but not too opinionated,” Pollock said. “The developer experience is both really cool — you preview your block in a functional Gutenberg-powered editor with no WordPress site attached — and a little frustrating as there is no live reload yet. I know they are just getting started and the tool doesn’t lock you into any structure, which is great. I’ll be keeping my eye on this project.”

Frontkom CTO Per André Rønsen said his team will continue testing the cloud internally until they get more developer feedback on the corresponding WordPress plugin. For Drupal users, Gutenberg Cloud will be shipped as a submodule of Gutenberg, which means all sites that install Gutenberg will also get the Cloud module. It can, however, be disabled. Rønsen said his team plans to showcase Gutenberg Cloud for D8 at DrupalCamp Oslo in November.

Category: ,
Tags: ,
26

26 responses to “Gutenberg Cloud Plugin for WordPress is Now in Beta”

  2. Isn’t this basically a repo within a repo?

    The WordPress.org repository doesn’t allow plugins that are repositories of code hosted outside of WordPress.org.

    Section 8 of the WordPress.org plugin repo rules:

    “Executing outside code within a plugin when not acting as a service is not allowed, for example: Serving updates or otherwise installing plugins, themes, or add-ons from servers other than WordPress.org’s.”

    Isn’t this pretty much what this does? It’s acting as a 3rd party repository of Gutenberg blocks. Which seems to fall within Section 8 of WordPress.org’s plugin repo rules on not allowing serving updates or installing plugins/themes/add-ons from servers other than WordPress.org’s.

    If this was a plugin that delivered plugins it wouldn’t be allowed. But it’s a plugin that delivers Gutenberg blocks so it is allowed?

    It seems to me the rules need to either changed or they need to be applied consistently because they obviously are not being applied consistently based on this being allowed in the WordPress.org repository.

    Create forum topic from comment

    • Interesting discussion – we’re happy to share our code and practises with anyone who wants to dig into this. We surely don’t want to break any rules.

      It’s also interesting to discuss what “installing” means. Technically, the plugin doesn’t download any files into WP, as the block files are really just files on a CDN. Other plugins do similar things. I do however see the issue with being a library of “add-ons” inside a plugin.

      Create forum topic from comment

      • Another rule in Section 8 of the plugin guidelines discusses delivering files via a CDN.

        Here is what it says specifically:

        “Calling third party CDNs for reasons other than font inclusions; all non-service related JavaScript and CSS must be included locally”

        The complete plugin repository guidelines can be found here:

        https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

        The relevant section as it relates to some of the things being done here can be found in Section 8.

        I agree Gutenberg Cloud is a cool plugin. But historically the WordPress.org plugin repository has been pretty strict with what it does and doesn’t allow when it comes to plugins that install other plugin. It’s basically outlawed plugins that act as repos and the Gutenberg Cloud plugin is basically a repo for Gutenberg blocks.

        Jetpack gets around this by installing themes via the WordPress.com Dashboard and not the self-hosted dashboard itself. But the Gutenberg Cloud plugin does this from the WordPress self-hosted dashboard so it’s definitely dicey based on how the rules are worded now.

        Create forum topic from comment

      • Good point, @Carl Hancock; I wasn’t aware of the CDN part. A SaaS would be accepted however. Anything preventing GutenbergCloud is a public API. What would be needed for it to be labeled a SaaS? The guidlines says things like: “The service itself must provide functionality of substance”.

        https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#6-software-as-a-service-is-permitted

        Create forum topic from comment

      • That’s not strictly true. In fact I read the discussions within Slack. The migration plugin was declined because it was produced before ClassicPress was even in a shippable ‘alpha state’. All the plugin did was disable the Gutenberg callout.

        So, it’s not for the same reason. I imagine that if it was submitted again, you’d have a better chance at being approved (potentially).

        I do agree though that the plugin repository rules are tightened and relaxed whenever it’s deemed necessary. The fact that this plugin would help promote Gutenberg is probably one reason why it was let through.

        Create forum topic from comment

      • Even so, it’s understandable why it was rejected now as it does violate the directory rules and it provides a one way ticket so to speak off the WordPress platform. It’s essentially a ‘one-use-only’ plugin so which would be dangerous for most users.

        But circling back to the main discussion at hand here, I can see why ‘they’ (the plugin team) would allow this in the directory. It provides people with more ways to interact with Gutenberg. Something I’m sure Automattic (specifically Matt) would be keen on pushing this through if there was friction in approving it.

        Whilst Gutenberg has got some sort of a so called ‘fan base’, there’s no denying there is a PR issue with Gutenberg and has been for some time. This plugin could be seen as damage control in a way.

        Create forum topic from comment

      • Daniel, yes – their motives are very clear, but they’re breaking their own rules to serve an agenda. End of story.

        You can make your case as to why you think that’s ok, but ultimately it’s irrelevant.

        “Rules for thee but not for me” hardly adheres to the WordPress ideal of democratizing publishing.

        Create forum topic from comment

      • Scott: no rules have been broken. No guidelines have been violated. Your plugin did something not allowed. This one does not. The difference is obvious, unless you want to intentionally muddy the waters.

        The waters are actually crystal clear here. “Install” has a meaning. If you want the guidelines clarified further, then that is a legitimate thing to ask, but it’s not going to allow your plugin or disallow this one.

        Create forum topic from comment

    • Carl: This is a service. It serves up blocks via an API and allows them to be included into the site. The javascript and CSS it serves up is service related, in so far that the javascript is the block. Also, we do allow CDNs for services when they are part of the same service, just like we would allow a plugin that talks to Facebook to get JS from fbcdn.net.

      This is a legitimate service. Simple as that. It doesn’t break any of our guidelines. Now, if it downloaded the JS into the site as files and such, then that would be much trickier. There would be security concerns there. That likely would break the guideline about installing executable code. But merely including some off-site javascript doesn’t instantly disqualify a plugin from being in the directory. There’s plenty of reasons for services to do exactly that. And there’s plenty of reasons for the plugins team to scrutinize those individual cases, because if somebody is hosting some malicious JS code off site, then that should be noticed and disallowed.

      Create forum topic from comment

      • How is this any less of a security concern? What if the Gutenberg Cloud CDN is compromised and someone inserts malicious JS? The script has credentials to send queries to your website’s REST API. If anything, the security concern is worse because the code can be changed at any point in time without being vetted or detected server-side via scanning.

        Let’s not split hairs about what constitutes installable code. The risks are inherently the same, if not worse. Either way, the code has access to virtually all data from your website’s database.

        Create forum topic from comment

      • Christopher: If the Gutenberg Cloud project becomes bad by including malicious code, then we’d pull the plugin from the directory. Same as with any other security issue.

        If they’re not going to maintain their list of blocks and keep it secure, then we’ll take actions then. But we’re not going to condemn the idea outright because of the possibility.

        Any plugin can include malicious code. We don’t read every update. That’s not actually possible. We trust authors until they violate that trust, and then we take appropriate steps. How else would you suggest that we do it?

        Create forum topic from comment

      • Now, if it downloaded the JS into the site as files and such, then that would be much trickier. There would be security concerns there.

        This quote implies that since the JS is being loaded from a CDN it is somehow more secure. My argument is that this is not accurate since the REST API provides CRUD access to your websites database.

        Maybe it’s time to reevaluate the definition of executable code? I understand it’s impossible to check every line of code from every plugin and theme. At the very least, I hope wordpress.org has automated malware and virus checks. With installed files (PHP or JS), I can easily scan my WP install for intrusions and look for modified files. JS loaded from an external CDN is exponentially more difficult for website owners to monitor.

        I don’t have all the answers for how to keep the repository secure, but I do know that opening the flood gates with CDNs is not the answer. It’s one thing to allow API usage from a FB, Twitter or Google CDN. They have funding for security experts and will suffer massive financial losses if there is a breach. It’s another thing to allow CDNs from services who have no publicly visible business or security models.

        Create forum topic from comment

      • Hey Otto,

        Could you please clarify why Github Updater violates the guidelines and Gutenberg Cloud doesn’t? What if the Github Updater‘s updates were served via an API?

        Also, bullet #6 in the guidelines mentions that the following services are prohibited:

        Storefronts that are not services. A plugin that acts only as a front-end for products to be purchased from external systems will not be accepted.

        Is the reason Gutenberg Cloud doesn’t fall in this bucket because it only servers free blocks? If so, will it get prohibited if/once they introduce paid blocks?

        Create forum topic from comment

  5. what about the premise of obfuscated code?
    https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/#4-code-must-be-mostly-human-readable

    We can’t user packer or uglify as our distributed code without also including the full source code, but if it’s a gutenberg block it’s okay to run your source through a babel process with uglify, and not share teh full source.

    A plugin is now pulling in minfied assets and we can’t even tell what the code is or does in most cases. I’m definitely not against the plugin – it’s a great idea, but it’s pretty clear that any plugin that makes use or supports gutenberg is automatically deemed as being accepted with no further thought to the existing plugin guidelines.

    Yes, I do agree it doesn’t fall under the whole “installable content” guideline, but given that, couldn’t most plugins offset any JS logic into a hosted CDN and not share the original source for the core functionality to keep certain logic or features “more private”?

    It really does appear to be that way. A lot of these new gutenberg plugins being approved instantly don’t even include the original source code. As an example Kadence Blocks: https://plugins.trac.wordpress.org/browser/kadence-blocks/trunk/dist/blocks.build.js

    The source files for all the blocks in that plugin aren’t included for reference. It must be because this is a Gutenberg based plugin, so it’s acceptable to get in the wp directory to just only include the minified build output of things so we can prevent our src files from being distributed. I mean shoot – even wptavern covered this plugin which clearly bypasses the plugin guidelines: https://wptavern.com/wordpress-theme-and-plugin-shops-are-pioneering-the-first-layout-blocks-for-gutenberg

    I also wouldn’t really say this is a sas application. The user isn’t creating an account or doing anything of that nature to connect and give permission for an external CDN to be used or acknowledging that Gutenberg Blocks being a plugin made by another developer is responsible for any of the block contents. It seems more like any JS code could simply be tagged with gutenberg-cloud on npm with an additional screenshot and be included in the install block area. No review is being done as to the safty of the code that users are now loading on their sites. The developer isn’t maintaining any sort of repo or service, they are just providing a way for data in another repo (npm) to be installed. It really seems like this shouldn’t be permitted by WordPress, and a similar adoption should be added for core to allow blocks as installable items like themes and plugins are.

    Create forum topic from comment

    • That will be something they need to address. If malicious code starts to appear on their plugin, then it will be pulled. They will need reviews, guidelines, etc. We expect plugin authors to adhere to the standards set. If they cannot do that, then they won’t last long.

      They have created a repository for a new kind of “thing”. We’re open to new ideas. But we’re not committed to them. We can always remove a plugin from our systems, or require that they uphold a set of standards. If they fail to act when bad things happen, or if they fail to maintain their systems, then they are just as subject to being delisted as any other plugin is.

      Being allowed in means you have a working service. Remaining there is a commitment that you need to hold up your end on too.

      I tend to take a long view on these things. If it works, great. But most things don’t, so it will need more work. If they do that work, great. If not, welp… Nice try and such. But I’m not going to require perfection in the first attempt. Reality is a series of fixing things. And then fixing them again. That’s just how the world is.

      Create forum topic from comment

  6. Actually scratch that about Kadence – it appears there’s a link shoved in there to link to src in the readme, so it does “comply” to the plugin guidelines, but I still stand by the fact that this functionality seems like it should be more core based than what it is. Why wouldn’t developers want to have their blocks shared in multiple platforms

    Create forum topic from comment

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.