I did read this post: Serialized settings in rest api and while I am actually convinced the answer is what I need, I cannot make it work.

What I am trying to achieve is to get my own settings retrieved when calling the /wp-json/wp/v2/settings/ endpoint.

My settings are registered as:

 public function __construct() {
      add_action( 'init', array( $this, 'coopedia_settings_init' ) );
      add_action( 'rest_api_init', array( $this, 'coopedia_settings_init' ) );

public function coopedia_settings_init() {
        'coopedia_settings_group', // option_group
        'coopedia_settings', // option_name
          'show_in_rest' => array(
            'schema' => array(
              'type'       => 'object',
              'properties' => array(
                'identity_provider_uri' => array(
                    'type' => 'string',
                'classifications_uri' => array(
                    'type' => 'string',
          'sanitize_callback' => array($this, 'coopedia_settings_sanitize'),

Updating and registering the settings actually works, they are displayed in my settings page and saved properly.

But then, when calling the endpoint inside a Gutenberg block using the following syntax:

 async componentDidMount() {
    console.log("fetching datatatata");
    wp.api.loadPromise.then(async () => {
      this.settings = new wp.api.models.Settings();
      if (false === this.state.isAPILoaded) {
        this.settings.fetch().then((response) => {
          // Push the coopedia settings classification website in state
            classifications_uri: response.classifications_uri,
            isAPILoaded: true,

The call to this.settings.fetch() is executed (I checked that on the network tab), but I only get the default ones:

  "title": "coopedia-test",
  "description": "Just another WordPress site",
  "url": "http://coopediatest.local",
  "email": "benoit+32@******.com",
  "timezone": "",
  "date_format": "F j, Y",
  "time_format": "g:i a",
  "start_of_week": 1,
  "language": "en_US",
  "use_smilies": true,
  "default_category": 1,
  "default_post_format": "0",
  "posts_per_page": 10,
  "default_ping_status": "open",
  "default_comment_status": "open"

Here is a screenshot of the network call and the response object from the inspector:

Screenshot of the network call

What am I missing here ? By the way the documentation is unclear regarding the possibilities to extend default endpoints, neither the usable wp.* objects in the new Gutenberg meta blocks.

  • That response.classifications_uri should be response.coopedia_settings.classifications_uri and try console.log( response ); before calling this.setState(), and check the browser's console to inspect the response object - is coopedia_settings really not in the list? And, "calling the endpoint inside a Gutenberg block" - can we see your edit function or when/where exactly you call wp.api.loadPromise? But if the coopedia_settings option is properly made available in the REST API, then that option would supposedly be in the response object.
    – Sally CJ
    Commented Apr 9, 2021 at 4:15
  • It's not part of the response object, that's what's weird. As far as I get it, it's supposed to work out of the box.
    – Balessan
    Commented Apr 9, 2021 at 7:22
  • @SallyCJ added screenshot of the network call, as you can see my settings is not there. It is present in the database, and accessible through the associated settings page. The gutenberg block I am working on is a sidebar menu component displayed when editing a post. It is properly loaded and the call is executed.
    – Balessan
    Commented Apr 9, 2021 at 7:29
  • In that case, then try enabling debugging, then add something like error_log( __METHOD__ . ' called' ); into the coopedia_settings_init() method, and then (open the post edit page in a new tab and) check the debug.log file and see if that "<method> called" exists in the log file. And I'm saying that the method may not be being called.. or if that isn't the case, then perhaps a plugin/code is unregistering or removing the custom setting?
    – Sally CJ
    Commented Apr 9, 2021 at 13:11

1 Answer 1


I had a similar problem and I landed here.

I'm not sure if time fixed this, but I've tried the code, and works as expected coopedia_settings: null is present in the fetch response.

The only case I can think of is: If the class that calls rest_api_init is initialized in an action that comes after rest_api_loaded was called, it would register for the Settings page but it would not register for the API.

In my case, creating a class directly in the plugin initialization works as expected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.