Migrate WordPress settings requests to apiFetch #3768

Activity

1. Arukuen

   self-assigned this

   on Oct 19, 2026
2. bfintal commented on Oct 21, 2026

   

   bfintal

   on Oct 21, 2026

   Contributor

   More actions

   Changes requested for #3769 and premium #412.

   What is already in good shape

   • The old wp.api / models.Settings calls are gone in both pull requests.
   • A successful save still posts the same data to /wp/v2/settings.
   • The editor and welcome scripts now depend on wp-api-fetch.

   What to fix

   1. The v2 migration popup can open for an Editor, then get stuck.

   src/plugins/v2-migration-popup/index.js used to read /wp/v2/settings. Only an administrator (manage_options) can read that, so an Editor never saw the popup.

   It now calls fetchSettings(), which reads /stackable/v3/settings/. Anyone who can edit posts can read that, so the popup can open.

   Save still posts to /wp/v2/settings. An Editor gets 403 (not allowed).

   In src/plugins/v2-migration-popup/migration-popover.js the spinner turns off only when the save succeeds. On 403 the popup stays busy and the page does not reload.

   Use the same permission for the read and the save. If this person cannot save WordPress settings, do not open the popup. Turn the spinner off when the save fails.

   2. Use one save function.

   fetchSettings in src/util/admin.js is the one place that reads settings. Saving is copied in about twenty files as apiFetch({ path: '/wp/v2/settings', method: 'POST', data }), plus four copies in the premium pull request (color-schemes, preset-controls, and welcome/icons.js).

   Add saveSettings next to fetchSettings and call that from each place.

   3. When a save fails, handle it.

   Global colors, typography, block styles, and the premium preset and icon saves do not handle a failed post. The console gets an unhandled error, and a busy indicator that only clears after success stays on. Clear that busy state when the save fails too.