1. Anh Tran

    Having a single block in a single plugin causes a fast growth of number plugins installed on a site. That’s a nightmare for users. And the .org will see likely 1000+ plugins for 1000+ different blocks (that doesn’t count duplicated blocks). While the idea of making the blocks searchable, filterable is great, the question on how to manage them is important.


    • Scott Hartley

      Pick your poison though. Would you rather have someone install a single plugin with 30 blocks in it loading all assets on every page and only needing a single block?


      Would you rather have someone install 10 different plugins containing a single block in each the amount of bloat is still less than the 30 blocking being bundled into a single plugin?


    • Otto

      So? Plugin count isn’t a problem, only complexity is.


  2. Danny Mitchell

    This is no worse than anything else about Gutenberg.


  3. Adam Paaatterson

    I think they also need to identify plugins that are premium or free with premium upgrades.


  4. Leonardo Losoviz

    Being able to install a block from within the editor sounds like a good idea to me. I find it similar to installing an extension in VS Code: while programming, if I find I need a certain functionality, the UI allows me to quickly install an extension, which will be enabled instantly, without having to restart the application. Programming like this is such a breeze. If Gutenberg could achieve something similar, so that the user could install a required functionality while editing the post, would be pretty helpful. (It’s one of those things that you don’t pay much attention to, but once you have it, you can’t do without it.)

    However, I do agree that this can lead to bloat, allowing users to install more blocks than are required. So the UI should make it easy to install blocks, but not so easy as to be overused, and always making sure the user knows what he/she is doing. And not all users should have access to this functionality, so I guess a capability “can_install_blocks_from_editor” would make the site admins be able to sleep at night.

    My vote is for it, but only if it is done properly.


    • Leonardo Losoviz

      Another thing to take into account is if the block is static or dynamic or, more specifically, if it will load JS assets only in the admin, or in both the frontend and the admin. If it is a static block, simply saving its HTML in the post content and not loading any JavaScript, then even if we install 300 of these blocks, it doesn’t really matter because the bloat is restricted to the admin side, so people browsing the website are not affected (also CSS, but it’s not as bad as JS bloat). And disabling these blocks at a later stage, once the user finds out about the bloat, will not break the website either, so it is kind of safe. Main problem is dynamic blocks, since these could break the site when disabled.


  5. Bob

    Remember how quickly “browser extensions” got out of hand. https://cdn-images-1.medium.com/max/1456/1*aUBalXt5fl6G7PFRJzEbgw.png This will be the future of “Blocks”.


  6. Sallie Goetsch (rhymes with 'sketch') (@salliegoetsch)

    I think we need to keep block installation out of the editor itself (since blocks are going to go beyond the editor Real Soon Now), but I would far rather have 30 plugins that just do one thing than 3 plugins that do 10 things each–especially when 9/10 of those things are the same.

    It’s not how many plugins you have, but how well each is coded and whether there are conflicts. I want to be able to add just the blocks I need.


  7. Glenn

    A block directory would be a dream come true!


  8. Marcus Tibesar

    I really like this concept of unbundling blocks – ala carte baby!

    Even though these singular blocks are installed with a plugin, I don’t think they should be listed in the Admin – Plugins listing.

    Perhaps all the installed singular blocks would be included in a new Admin menu. For example Admin – Blocks or Admin – Appearance – Blocks.

    Bottom line, I would like to be able to manage Blocks quickly without having to drill down into the Block Editor…


Comments are closed.

%d bloggers like this: