Automattic / Automattic/wp-calypso

Editor: API preloading does not work for Simple Sites

Open
#54,366 2 comments 0 reactions 0 assignees View on GitHub
[Feature] Post/Page Editor Bug Quality Sprint: Week 2
Dominant language
TypeScript
Stars
12.6k
Forks
2k
Avg merge
1d 17h
Merged PRs (30d)
552

Description

## Context

The block editor uses preloading middleware that outputs API responses onto the page as JS objects to prevent the need for an XHR request once the editor is loaded.

WP Core code that defines preload paths (5.7): https://github.com/WordPress/wordpress-develop/blob/c8a4205394819839ee33fad040d24a4fd355cb23/src/wp-admin/edit-form-blocks.php#L46

Gutenberg middleware js: https://github.com/WordPress/gutenberg/blob/3b31957897302c9274afe259e59d1737098d6f8d/packages/api-fetch/src/middlewares/preloading.js

You can see this in action by searching the page source of the editor: the `wp.apiFetch.createPreloadingMiddleware` function takes an object with all of the preloaded API responses for loading data into the editor.

## Bug

Because wpcom API paths are transformed to use public-api.wordpress.com, using our own api middleware, Gutenberg is not able to take advantage of preloading API requests when loading.

For example the `/wp/v2/types?context=edit` path is preloaded. But the API request for Simple Sites is `https://public-api.wordpress.com/wp/v2/sites/{site_id}/types?_envelope=1&context=edit...`, so Gutenberg's preloading middleware is not able to retrieve the response from the JS object printed out in the page source and makes a separate XHR request as the editor loads.

The impact of this is likely a slower time to load the editor (I haven't specifically measured, but strongly suspect making multiple async requests while loading takes longer than preloading the data).

## Possible solutions

A couple routes that could solve this (may need both)

1. Add our own wpcom specific preloading middleware that looks for the public-api paths (similar to the api fetch middleware we already have)
2. Filter `block_editor_preload_paths` (note, changed to `block_editor_rest_api_preload_paths` in WP 5.8) to add public-api specific paths.

Contributor guide

Open the contributing guide

Research direction

Start by comparing the preload paths from wp-admin/edit-form-blocks.php with the public-api paths handled by packages/api-fetch/src/middlewares/preloading.js and the existing wpcom API middleware. Check the block_editor_preload_paths filter, renamed to block_editor_rest_api_preload_paths in WordPress 5.8. Done means Simple Sites can consume the preloaded responses without the extra editor-load XHR requests.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.