What did the classic editor leave behind when WordPress moved to blocks?
The classic editor offered no native way for an external tool to read or write content over the web. WordPress filled that gap by shipping a content REST API in core with version 4.7 on 6 December 2016. Any post, page or registered custom type can now be read and written over HTTP at /wp-json/wp/v2/, with no plugin involved. That single addition is what makes remote editing possible on a site you do not host.
Authenticating an external tool was another problem the classic editor never solved. WordPress 5.6 introduced application passwords on 8 December 2020: per-application credentials, separate from the account password, that can be revoked individually without locking the person out. They require HTTPS. Before that release, editing a self-hosted site over the API meant installing an authentication plugin or writing one.
The classic editor stored every post as a single flat HTML blob, which meant structured layouts, reusable content pieces and column arrangements had no standard format that could travel between tools. WordPress 5.0 replaced it with the block editor on 6 December 2018, wrapping each content block in HTML comment markers so external readers can parse layout, not just text. WordPress 5.5 then added a built-in XML sitemap at /wp-sitemap.xml on 11 August 2020, removing yet another task the classic editor left to plugins.
Page-builder layouts stored under protected meta keys are invisible to the REST API, a blind spot inherited from the classic editor era. Any meta field whose key begins with an underscore is treated as protected, and WordPress will not expose it unless a plugin registers it with show_in_rest. A builder that keeps its layout under a key like _elementor_edit_mode is therefore hidden from an API client, even though the live site renders from it.
The practical consequence is that reading post_content is not the same as reading the page.
Three server-side prerequisites must be in place before any external tool can use the REST API reliably:
- Pretty permalinks, or /wp-json/ answers 404 and only ?rest_route= works.
- HTTPS, which application passwords require.
- A user with edit_posts, since the API maps capabilities per post type.