While Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. is a critical tool for keeping in sync for project status and priorities, it has proven to be an ineffective platform to engage in detailed, long-lived discourse around complex engineering problems.
Inspired by other open source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects like React, Yarn, Rust… we started experimenting with a new RFC (Request For Comments) process in the Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository in order to propose, discuss and adopt technical solutions for these big features or complex technical challenges.
The Block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. registration RFC
The first open RFC in the Gutenberg repository concerns the Block Registration API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. and intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project.
The block registration API is the most important API in the block editor with a lot of technical challenges. Its implementation should fulfill a number of requirements:
- Fetching the available block types through REST APIs.
- Fetching block objects from posts through REST APIs.
- This API should be backward compatible with what we have at the moment.
- It should be possible to statically analyze a block type in order to support advanced use-cases like the block discovery required by the Block Directory project.
- It should not require a build tool compilation step (e.g. Babel, Webpack) to author code which would be referenced in a block type definition.
- It should allow to dynamically load (“lazy-load”) block types, or parts of block type definitions. In practical terms, it means that the editor should be able to be loaded without enqueuing all the assets (scripts and styles) of all block types. What it needs is the basic metadata (
icon, etc…) to start with. It should be fine to defer loading all other code (
This RFC has already received a lot of feedback and technical explorations already started to clarify feasibility already started but I’d like to encourage everyone to chime-in and share thoughts.
What type of features/problems should be submitted as RFCs
All ideas/PRs/proposals require discussions before moving to implementation. When the proposed changes are small then a GitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue is fine but in addition to the block registration API, all the features and technical problems with impact across different areas of the code base, new patterns for extensibility APIs, technical problems that are hard to solve without making compromises are good candidates for RFCs.
Some examples for the Gutenberg project include:
- The Block Registration API.
- The Block Invalidation and Deprecation handling.
- Block areas storage mechanism and widgets migration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies..
- Block Bahaviour reuse (colors, alignments…).
- Responsive Image Handling and Block Alignment awareness in nested contexts.
- Editor Styles.
The RFC workflow
The flow to propose a new RFC is the following:
- Create a RFC document for your proposal.
- Submit a pull request to the Gutenberg repository (markdown file added to the `docs/rfc` folder).
- Discuss and incorporate feedback into the PR
- After discussions in the weekly meetings, RFCs may or may not be accepted.
- If the RFC is accepted, the PR is merged.
Accepted RFCs means the proposed feature is approved for implementation. Once implemented, the RFC becomes the de-facto documentation for it.
What makes a good RFC document
A good RFC document can be broken into the following sections:
- Description of the problems solved by the RFC
- Current status and previous attempts
- Solution Proposal
- Unsolved Problems
Who can submit an RFC
Anyone can submit an RFC.
We’re looking forward to start receiving RFC proposals!