WP Tavern › Forums › Create Topic
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.
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.
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
