Yesterday, Alex Shiels posted an update to the proposed guidelines for the WordPress block directory. The document adds eight rules for plugin authors to follow if they plan to add their one-off blocks to the directory. The guidelines are additional requirements on top of the existing plugin directory guidelines.
While the wording and organization of the block guidelines received a revamp in comparison to the original proposal, the overall sentiment is unchanged. Shiels thanks community developers for the feedback on the original guidelines but does not go into detail about the things that changed as a result.
The primary guidelines are mostly expected, run-of-the-mill requirements for blocks. Developers need a block.json file. They should name stuff appropriately. Plugins should contain only a single block. Plugins should only touch the block editor. Blocks should work seamlessly once activated.
The remaining guidelines are certain to be a disappointment or point of contention for some developers.
Monetization Still Not Allowed
The largest feedback on the guidelines we received here at the Tavern surrounded what is essentially a blanket ban on commercial interests for block developers. Blocks still cannot hook into a paid service or advertise within the admin. This limitation will obviously turn away many businesses that may have been looking forward to the block directory as a potential avenue for profit. Right now, one-off blocks will need to be built by those with altruistic interests, giving back to the community simply out of the kindness of their hearts.
While there is nothing inherently wrong with wanting to do that, it is not attractive to developers who are primarily focused on putting food on the table. Hobbyists and larger businesses with the resources to give back will be well-suited to add blocks to the directory. However, it will give a lot of developers pause because it is unlikely a good return on investment. Instead, those developers are more likely to submit their blocks to the normal plugin directory with their normal upsell methods. This will only serve to make block discoverability harder for end-users.
This is a missed opportunity to build a well-rounded system that is fair to both users and developers who need to make a living. Whether it is through the plugin tag system or specific guidelines on monetization, we could have built something that made everyone a little happy and a little mad, a compromise that merged a good user interface and experience.
It is not like there have been no proposals. In January, Luke Carbis wrote a detailed outline of how WordPress could provide a middle ground between sustainability (business models) and accessibility (free options) with the upcoming block directory. His fear was that the block directory would be full of blocks without updates in a few years because the completely free model is unsustainable. His proposal was a badge-based system that let users know if a block contained ads, used a freemium model, or required a sign-in to a third-party service.
The current guideline is not set in stone. This is the first version of the block directory. It is not out of the question that the team could change things as the directory grows over time.
No Love for Server-Side Blocks
The block directory guidelines are still heavily geared toward static blocks. PHP must be kept at a minimum and primarily be used to load any necessary scripts and stylesheets. Server-side blocks are not getting much attention at the moment, which may be a limitation of the software.
It would be great to see a way for some server-side blocks to be included in the block directory. For example, a breadcrumbs block would need to rely heavily on PHP to render its output. It is a dynamic block rather than static. This particular block would not be useful until full-site editing lands in WordPress, which is still several months away. However, I am getting the itch to turn an old breadcrumbs plugin of mine into a block. It would be neat to see it listed in the block directory.
There are countless other scenarios. Post lists, product grids, and data pulled from external APIs are all good use cases for one-off blocks.
Dependencies Are Not Allowed
Given the way that WordPress works, it makes sense to ban dependencies on other plugins for any particular block to function. This is an old limitation that is rearing its head again. Every other modern framework uses some sort of dependency management to address this problem.
The block directory has the potential to exacerbate the problem even further. Because plugins coming from this directory will be single blocks, it will often mean that developers are using the same bits of code across multiple projects. For example, an end-user may activate multiple block plugins that rely on the same JavaScript library. Because there is no 100%, sure-fire way to make sure only one instance of this library is loaded, users may be running multiple instances of it on their sites. It is not a new problem, but smaller block plugins mean that users are more likely to install more plugins. It increases the probability of running into this issue.
If there was any sort of basic dependency management for plugin authors to use in WordPress, it would solve a world of problems. Over the years, developers have created methods to minimize the issues stemming from the lack of such a system. However, nothing is foolproof without a standard to follow.
This has also held developers back from building libraries, scripts, and tools that could benefit the entire development community as a whole. Everyone builds their own things in-house, and the block directory is making a promise for more of the same.
