Core WP Options Support

[jasonbahl]

We should support queries and mutations for WP Core Options (site settings, etc)

[hughdevore]

@jasonbahl and @CodeProKid , wanted to get your thoughts on how far we should extend this. I'd like to keep parity with core, like so:

http://v2.wp-api.org/reference/settings/

However, it'd also be nice to have some of the things McCue added to the spreadsheet in this repo:

https://github.com/WP-API/wp-api-site-endpoints

Maybe we will just throw the extra stuff in it's own extension like we're doing with everything outside of core.

[jasonbahl]

@hughdevore ya, let's turn our Pizza Party into a chat about this. . .

[jasonbahl]

@hughdevore here's my initial thoughts:

We should definitely start with at least parity with the CORE REST API.

Now, how it should look is where the real questions come in.

We could do queries like:

We could do queries like:

query GetSiteDetailsAndPosts {
    siteName
    siteUrl
    adminColorScheme
    posts { edges { node { id } } }
}

Or we could group fields into like Types / Fields:

query GetSiteDetailsAndPosts {
    generalSettings {
        siteName
        siteUrl
    }
    userPreferences {
         adminColorScheme
    }
    posts { edges { node { id } } }
}

Then again for mutations, we could have rootMutations like:

mutation {
    setAdminColorScheme( color: RED )
    setSiteName( name: "http://site.com" )
}

Or go the nested route, which I think is much more powerful and flexible. . .

mutation {
   updateGeneralSettings( input: {
       siteName: "New Site Name"
       siteUrl: "New Site URL"
   } ) {
        clientMutationId
        generalSettings {
           siteName
           siteUrl
        } 
   }
}

I think we should discuss, as there are potential benefits to both, but I feel like grouping settings (similar to the WP Admin does with Settings Pages) makes a lot of sense.

We could even go a step further and Group them all under "Settings" like so:

query getSettings {
    settings {
        general {
             siteUrl
             siteName
        }
        userPreferences {
            adminColorScheme
        }
    }
}

And mutations could then look like:

mutation updateSettings( $input: SettingsInput ) {
    updateSettings( input: $input ) {
         settings {
             general {
                 siteUrl
                 siteName
             }
            userPreferences {
                adminColorScheme
             }
         } 
     }
}

variables: {
    input: {
        general: {
             siteName: "New Site Name",
             siteUrl: "New Site Url"
        },
        userPreferences: {
             adminColorScheme: RED
        }
    } 
}

I don't see needing full CRUD support for options, as most of the time it's simply updating settings, so I can picture just needing an updateSettings mutation, not a createSetting or deleteSetting. . .but up for discussion if someone has different thoughts on that. . .

=====

Ultimately, after this rant, I'm leaning toward a single (or very few) RootMutations with nested input that allows for various settings to be mutated via the $variables and have the settings be nested/grouped logically so they make sense both when mutating and querying.

Also, by grouping settings, we can make them accessible in different parts of the Graph.

For example, if we have a UserPreferences type, we can easily have it queryable from the Root like so:

query { 
   settings {
      userPreferences {
            adminColorScheme
      }
   }
   users {
       edges {
           node {
                id
                firstName
                lastName
                userPreferences {
                     adminColorScheme
                }
           }
       }
   }
}

[jasonbahl]

addressed by #254

We should add mutations soon too, but we I'm ok if do that as a post 1.0 feature.