Settings' REST API Tab

[leepeterson]

Confused why Pods Settings UI has a REST API tab if it isn't supported. Will it ever support REST API integration? I can understand not supporting certain types of content within Pods Settings, but how about generalized fields such as text, textarea, number, etc?

[sc0ttkclark]

Good question, probably an oversight that it shows for that pod type.

But looking forward, what would you expect for a rest api endpoint to provide for a settings pod?

[jimtrue]

There is an official Settings REST API schema https://developer.wordpress.org/rest-api/reference/settings/

[jimtrue]

Never mind, I'm an idiot, that's the WP Settings. I'm not finding anything on options

[jimtrue]

This is the table of what is supported by the WP REST API implemention: https://developer.wordpress.org/rest-api/reference/. Options API doesn't seem to be included

[leepeterson]

@sc0ttkclark First and foremost, I'd expect Settings Pod types to support general options fields @jimtrue referenced at /rest-api/reference/settings/ such as title, description, timezone, etc. Pods' goal of extending core WP functionality would fall in line with such an expectation.

But beyond core WP settings, helpful additions to the Settings REST API might be controlling settings not yet accessible via Pods' Settings UI: constants generally set in config files, wherever those may live depending on the site's build decisions (I use env variables called from config files like application.php living inside /config/ with production.php, staging.php and development.php living inside /config/environments/).

Pods constants like PODS_ALTERNATIVE_CACHE and similar are those I'm referring to. In fact, I've often wished I had remote access to control Pods Settings via REST API since I manage sites quite frequently via Paw, a macOS app made for API creation which also offers a side benefit of making API requests against any API using any methods desired.

However, given the flexible nature of Pods Settings panels, it does seem like creating a REST API for them would become a monumental task. Managing Fields, Labels and Admin UI inputs would be expected; options like write access and depth within the REST API tab. Once you dive into the options offered within the Admin UI Style dropdown, though, things become a bit murky.

I think this may signify a logic shift in goals intended for Pods Settings types. Perhaps better left for another discussion entirely, but one idea that comes to mind is moving the capability of being able to use Settings screens for CPT tables to a different type entirely: CPT UI. Retain the existing "Normal Settings Form" and either deprecate the "Custom Hook" option from within the dropdown (keeping it as a programmatic choice) or move that as well to another type.

I, for one, have found the Settings type a bit confusing, not only at first, but even now when choosing "Post Type UI". I've yet to dig into docs for it, but it just doesn't make a lot of sense to me, especially with its previous/next navigation in the sidebar.

Anyway, probably best left for another discussion :)

That probably covers the high level expectations for a Pods Settings REST API: WP Core Settings; Pods Settings. The former making most sense; the latter being an offbeat thought.

[jimtrue]

If you create a Settings page in Pods, from my viewpoint, that should be available through the REST API through endpoints enabled and managed to open up the Options API to RESTful methods in WP Core. That needs to be addressed first: enhancing the REST API implementation to adoption Options (especially since their entire customizer runs on that). That is what we would hook into, since we're not building our own REST API implementation -- we're tying into an existing implementation that is well supported by the WP Community.

[leepeterson]

@jimtrue Trying to follow that... are you saying Pods should pave the way to WP core's Options REST API? If so, I fully agree with that notion. Much the same as with @sc0ttkclark's Fields API should pave the way for metadata management in WP core.

[jimtrue]

Yes, but we can't get any traction on that without buy-in from WP Core. This needs to be approached from a WP Core perspective. That's where the REST API implementation needs to be driven for Options. That's what we would build on top of like we did with the rest of our REST API implementation.

[leepeterson]

@sc0ttkclark thoughts on above? Anything I can do to help?

[puntaschoice]

Hi - I've come at this from WP Forums looking to have Settings PODS visible as a REST API (or GraphQL) endpoint (Since version 3.8), so as to be able to gain access to the data / settings externally, and in my case, then use those settings to action the response of the software pulling and then writing back. For example, ability to let a user select default post category and image that then means my Python script can read these settings via a REST API call, and then when creating new POST's use those settings in the API Post/Patch calls. For now, these are hard coding into the Python script with the WP ID's.

[uw-bkozura]

Hello! I have also come from the WP Forums to have Settings PODS visible as a REST API endpoint.

My particular use case is for frequently updated content that may need to be updated sitewide. For instance, we have frequent promotions for our products, and currently we pass that data through a json file and then pricing, promo codes, marketing language, etc are updated on the corresponding product pages. Additionally, the json is accessible for other applications to grab the current promotion data, so only one file controls multiple campaigns across platforms. We would like to be able to have a simple settings page for non-technical marketing team members to be able to update as needed.