Three flavors of Gutenberg backwards compatibility

This is my attempt at answering an issue I opened in January. Please take my opinions with a grain of salt.

WordPress is known for its commitment to backwards compatibility. It prides itself on functional consistency between major releases, and makes sure actions and filters continue to work as expected.

Gutenberg is big and huge and a significant change for the better. Contributors are working to make Gutenberg as backwards-compatible as possible. However, the reality is that we’ll likely taste three flavors:

  1. It continues to work as expected. For example, an enter_title_here filter continues to modify the title placeholder text in Gutenberg. Similarly, Post Type Supports is still the API for defining which features a Post Type supports.
  2. It doesn’t work but there’s an equivalent alternative. Some of WordPress’ existing architecture doesn’t translate directly into Gutenberg. For instance, media_buttons is the old paradigm for registering a button to insert something into the post content. In Gutenberg, Blocks are the new paradigm. Blocks are added to the post content via the Inserter.
  3. It doesn’t work at all. We want to avoid this as much as possible, but there will be some elements you can customize in the Classic Editor that you simply can’t change in Gutenberg.

The Gutenberg Migration Guide documents many of these specifics. New contributions are always welcome. Generally, compatibility solutions are organically prioritized against identified need, expected impact, and level of effort/possibility.

Ultimately, WordPress remains committed to the ethos of backwards compatibility, even when undertaking such a transformational change as Gutenberg. An amazing amount of effort is going into ensuring WordPress sites continue to work as expected. It’s important to acknowledge, though, that backwards compatibility is fundamentally more difficult than the past. The reality has a certain degree of nuance.

Leave a Reply