GraphQL for Pods Settings Page Fields

See supported data types at https://docs.pods.io/code/wpgraphql-integration/

Settings pages are not supported.

See WPGraphQL filters for adding additional data. https://www.wpgraphql.com/filters

Thank you for quick response Paul. Firstly Kudos for your great plugin for other promising features. But Graphql is now very common now a day for modern apps while using wordpress as a headless backend.

The https://docs.pods.io/code/wpgraphql-integration/ I checked, mentioned “Coming Soon support for Settings Page” https://pods-pro.skc.dev/downloads/wpgraphql-integration/ , got its in development. Any idea when its planned to provide that important function?

I see WPGraphQL filters link, thanks, but in Pods Settings Page fields case, the fields are being created dynamically in database, not a fixed name/code portion on which I can apply some filters or things.

Can you please provide a sample hook code portion, at least a pseudo code, how I can attach the newly created fields via pods to capture in graphql?

• This reply was modified 7 months, 2 weeks ago by Shashank Shekhar.

It is not imminent. Arbitrary exposure of data from options requires security checks.

The Pods settings follow a standard format stored in wp_options table where the key is the Pod / Settings Page name followed by an underscore followed by the field name.

get_option( 'podname_fieldname' );

Thank you for the hint Paul, I will look and try doing it with some code meanwhile.
Will be hoping although this important thing will be built in the Pods in near time when possible.

There are many examples at https://www.wpgraphql.com/recipes

For example https://www.wpgraphql.com/recipes/list-of-key-values where value1 value2 value3 would be the get_option() calls and the field name is listOfKeyValues.

https://www.wpgraphql.com/recipes/add-field-to-output-urls-for-sitemap and s basically the same thing but field name allUrls.

Thanks and best of luck with the recipes.

Votes for feature prioritization can be cast via Friends of Pods.

In the meantime, the recipes above will require one to two lines to be modified to accommodate the requirement.

Thank you very much much Paul.
I also was checking (although may be you have already checked), as per the official wpgraphql guide: https://www.wpgraphql.com/docs/settings#registering-custom-settings

function register_my_setting() {
    $args = [
      'type' => 'string',
      'sanitize_callback' => 'sanitize_text_field',
      'default' => NULL,
      'show_in_graphql' => true, // This tells WPGraphQL to show this setting in the Schema
    ];
    register_setting( 'my_options_group', 'my_option_name', $args );
}

add_action( 'init', 'register_my_setting' );

If Pods plugin be registering its fields group and fields with ‘show_in_graphql’ => true while saving configurations, the wordpress will be itself handle its security and access, and the group with fields be accessible with graphql query:

{
  myOptionsGroupSettings {
    myOptionName
  }
}

https://www.wpgraphql.com/docs/settings#site-settings-by-settings-group
The mentioned links says that, I am not aware for deep data-format or compatibility with Pods plugin if any, as you know better being the plugin author, but looking on this it seems may be a small tweak in saving ‘setting page’ settings by Pods plugin may make it work self (handling permission/security by wp self further).

Thanks for the notes.
The challenge with providing a generic UI for settings access is that WP does not handle any access controls in that registration by default. It would expose the setting to unauthenticated users. Adding user interface which includes access controls per-field takes time and testing, as any oversight in generic registration or implications of its use would potentially expose things that tend to be in the options table… authentication keys etc.