options - Retrieve my custom settings in the settings API endpoint

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() {
      register_setting(
        'coopedia_settings_group', // option_group
        'coopedia_settings', // option_name
        array(
          '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
          this.setState({
            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": ";,
  "email": "benoit+32@******",
  "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:

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.

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() {
      register_setting(
        'coopedia_settings_group', // option_group
        'coopedia_settings', // option_name
        array(
          '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
          this.setState({
            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:

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.

• options
• settings-api

Share Improve this question edited Apr 9, 2021 at 10:48 Balessan asked Apr 8, 2021 at 23:10 BalessanBalessan 17311 silver badge1111 bronze badges 4

• 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

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 0

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.