REST API: Custom settings endpoint

[youknowriad]

We need to persist different settings in different places of the Gutenberg Editor. Does it make sense to create a generic endpoint performing get/set_option?

We need it for:

• Persisting layout config Save editor UI configuration to be persistent across reloads #450
• Persisting recent blocks Inserter: sort blocks by recency #888

cc @nylen

[swissspidy]

If it's just GET/POST for simple options, why not use the existing REST API endpoint for that?

[youknowriad]

@swissspidy I was not aware of such endpoint, I must have missed it? Can't seem to find it in the REST API docs?

[swissspidy]

@youknowriad here's the link to the docs: https://developer.wordpress.org/rest-api/reference/settings/. Registered settings can be fetched/saved using that endpoint.

[youknowriad]

Oh thanks for the clarification, I thought this endpoint would return only the settings mentioned in the docs.

So if I understand correctly, we'd need to register our settings using this right? https://codex.wordpress.org/Function_Reference/register_setting

The settings API seems more suited towards generating Admin Pages, is it ok to skip generating admin pages for those?

[swissspidy]

Although the Settings API itself is meant for adding fields to admin pages (using add_settings_field() et al), register_setting() is specifically for adding and validating options and does not add anything to admin pages by itself. It's the recommended way to register settings for use with the REST API.

See https://make.wordpress.org/core/2016/10/26/registering-your-settings-in-wordpress-4-7/

Think of that function as a way to register a setting for the REST API, nothing else.

[youknowriad]

Awesome, thanks, this is really helpful. Will unblock some issues

[nylen]

We can't use wp/v2/settings for this because it requires admin privileges to both read and write settings.

[youknowriad]

And I think the settings we need to store should be per user. We need a user preferences endpoint.

[nylen]

Yes, good point. We could try a register_meta set up to integrate with the users endpoints. If permissions are an issue (we probably don't want this data to be publicly readable) then we can write a custom endpoint that still stores the data in a user meta value.

[notnownikki]

We need an endpoint like this for #1859, did we come to a conclusion on this? I'm happy to start on a user preferences endpoint. (Because, I kinda need it to progress 😄 )

[nylen]

The conclusion is that we need a user preferences endpoint 😄 Feel free to give it a shot.

[westonruter]

@nylen should we create a new gutenberg/v1 namespace to put all of the endpoints we need for developing blocks? This can be an interim location while we wait on them getting added to wp/v2 or whatever namespace we determine they'll live in, for example the logo block in #1851 could eventually use a logo endpoint under a customize/v1 namespace. It would seem like we should not get development on the blocks held up for lack of the requisite endpoints being in core.

[nylen]

Yes, our endpoints should live in gutenberg/v1 for now.

See also https://core.trac.wordpress.org/ticket/40919 which we can incorporate to provide a way to call the endpoints we need.

[nylen]

Removing "Core REST API Task" as this is something we can implement for ourselves for now.

[mtias]

The label is mostly meant to gather all the issues that need API work, regardless of where it is done.

[notnownikki]

I reopened #1948 . There are discussions going on around userSettings which might give us what we need, but if not, that PR is there.

[BE-Webdesign]

Do we 100% need to persist this to server? I think using the new storePersist middleware on our redux store would be fine. It would mean this wouldn't work across devices, but I don't think that would be the worst thing ever?

[notnownikki]

I guess not 100%, but it would be nice if we were able to store data at a user level rather than a device+browser level.

[joehoyle]

The label is mostly meant to gather all the issues that need API work, regardless of where it is done.

It might make sense to rename the label, it's specifically "Core REST API" right now.

[danielbachhuber]

Is this issue actionable at this point, or can it be closed?

[danielbachhuber]

It looks like the first issue was solved with localStorage: #2568