26 Comments

  1. Matt Mullenweg

    It’s awesome to see cross-platform adoption of Gutenberg — we’re helping create the future of the web not just of WordPress.

    Report

  2. Carl Hancock

    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.

    Report

    • Per André Rønsen

      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.

      Report

      • Carl Hancock

        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.

        Report

      • Per André Rønsen

        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

        Report

    • Scott Bowler

      The ClassicPress migration app was rejected for this exact reason. Either our plugin should be allowed, or this one should be rejected. Can’t have it both ways…

      Report

      • Daniel James

        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.

        Report

      • Scott Bowler

        Daniel, we re-submitted the finished plugin since then (last week) and it was rejected citing the reasons that Carl highlighted.

        Report

      • Daniel James

        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.

        Report

      • Scott Bowler

        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.

        Report

      • Otto

        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.

        Report

    • Otto

      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.

      Report

      • Christopher

        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.

        Report

      • Otto

        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?

        Report

      • Christopher

        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.

        Report

  3. Torsten Landsiedel

    Looks like a GDPR nightmare. Is there a privacy policy anywhere on https://unpkg.com? I don’t see one. Who gets the IP address? What if I don’t want that? How do I inform my users about it? Couldn’t be used in the EU at the moment, I think.

    Report

  4. Jon Schroeder

    If this is now being allowed, I’d love to see projects like Andy Fragan’s Github Updater be hosted on the WordPress repo.

    No idea if that one was rejected, but you could see a similar rationale if in fact it was submitted and rejected, because it allows for both installs and updates directly from other repos.

    Report

    • Otto

      No, that would violate the guidelines. This plugin does not violate those guidelines.

      Report

      • Vova Feldman

        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?

        Report

  5. John Layton

    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.

    Report

    • Otto

      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.

      Report

  6. John Layton

    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

    Report

  7. Marcus Hiles

    Seems like a pretty cool idea, I look forward to other solutions like this.

    Report

Comments are closed.

%d bloggers like this: