Provide Social Auth settings in configuration form

Thanks for the patch!

1. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,108 @@
   +<?php
   +
   +/**
   + * @file
   + * Contains \Drupal\social_auth\Form\SocialAuthSettingsForm.
   + */
   +
   

   I think we have not removed this kind of comments in the code yet, but I have seen that it's not longer necessary. Core modules don't have a @file comment in their classes anymore

2. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,108 @@
   +use Drupal\Component\Utility\SafeMarkup;
   

   Should we use SafeMarkup? It is deprecated, so I don't know if it is recommendable to use it

3. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,108 @@
   +    return [
   +      'social_auth.settings',
   +    ];
   +  }
   

   I think we should return only a string, so the child can do something like:

   return [
   parent::getEditableConfigNames(),
   'module.settings'
   ]

We should allow to redirect back to the page where they started the login process.

I agree, we should specify to leave it in blank if site builders want to redirect to where the process started.

1. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,99 @@
   +    return 'social_auth.settings';
   

   Sorry for the last comment. Return an array as most modules do. Implementers will need to do something like return parent::getEditableConfigNames() + ['module.settings'];

2. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,99 @@
   +        $options[$key] = SafeMarkup::checkPlain($role_object->get('label'));
   

   The new patch do not include SafeMarkup at the top, but has this code which will produce an error

To test if your form works. You can change the code of the settings form of any implementer (e.g. Social Auth Twitter). Instead of extending ConfigFormBase, you need to extend from the new SocialAuthSettingsForm. Plus, in getEditableConfigName() you should do something like return parent::getEditableConfigNames() + ['module.settings'];

1. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,101 @@
   +    $form['module_settings'] = array(
   ...
   +    $form['module_settings']['post_login_path'] = array(
   ...
   +    $form['module_settings']['redirect_user_form'] = array(
   ... among others
   

   Please change 'module_settings' to 'social_auth'

2. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,101 @@
   +      '#title' => $this->t('Social Auth configurations'),
   

   I'd say "Social Auth settings"

3. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,101 @@
   +    foreach ($roles as $key => $role_object) {
   +      if ($key != 'anonymous' && $key != 'authenticated') {
   +        $options[$key] = \Drupal\Component\Utility\Html::escape($role_object->get('label'));
   +      }
   +    }
   

   Instead, implement an use statement above and don't use (\) before Drupal

I didn't check the functionality yet. I hope you tested if configurations are saved

Thanks @denutkarsh,

1. +++ b/config/install/social_auth.settings.yml
   @@ -1 +1,5 @@
   +post_login_path: user
   +redirect_user_form: 0
   +disable_admin_login: 1
   +disabled_roles: []
   

   We will need a schema.yml file and use true/false instead of 1/0

2. +++ b/config/install/social_auth.settings.yml
   @@ -1 +1,5 @@
   +post_login_path: user
   +redirect_user_form: 0
   +disable_admin_login: 1
   +disabled_roles: []
   

   Since these are new settings added, we'll need to add a hook_update_n() function for sites which update the module and add the same values as default.

3. +++ b/src/Form/SocialAuthSettingsForm.php
   @@ -0,0 +1,102 @@
   +use Drupal\Core\Form\ConfigFormBase;
   +use Drupal\Core\Form\FormStateInterface;
   +use Drupal\Component\Utility\Html;
   

   Sort them alphabetically

Also, we need to update https://github.com/drupalsocialinitiative/social_api_examples/tree/8.x-1.x/social_auth_example after patch is commited

Thanks for the patch. We are almost there.

1. +++ b/config/install/social_auth.settings.yml
   @@ -1 +1,5 @@
   +redirect_user_form: 0
   +disable_admin_login: 1
   

   We should change these two to true and false values

2. +++ b/config/schema/social_auth.schema.yml
   @@ -0,0 +1,16 @@
   +    redirect_user_form:
   +      type: integer
   +      label: 'Redirects to Drupal user form after the user is created if checked.'
   +    disable_admin_login:
   +      type: integer
   +      label: 'Allows to Disable Social Auth login for administrator'
   

   As a consequence of the previous change, they will be "boolean" type

3. +++ b/social_auth.module
   @@ -22,3 +22,15 @@ function social_auth_theme() {
   +  $config->set('post_login_path', 'user')->save();
   +  $config->set('redirect_user_form', 0)->save();
   

   Because $this is returned in set method, we can do something like
   $config->set($key1, $value1)
   ->set($key2, $value2)
   ->save();

Thanks! I've committed the patch with some changes

1. +++ b/config/schema/social_auth.schema.yml
   index 192f606..783ab08 100644
   --- a/social_auth.module
   
   --- a/social_auth.module
   +++ b/social_auth.module
   
   +++ b/social_auth.module
   +++ b/social_auth.module
   @@ -22,3 +22,16 @@ function social_auth_theme() {
   
   @@ -22,3 +22,16 @@ function social_auth_theme() {
    function social_auth_preprocess_login_with(&$variables) {
      $variables['base_path'] = base_path();
    }
   +
   +/**
   + * Implements hook_update_N().
   + */
   +function social_auth_update_8001(&$sandbox) {
   

   Sorry, I didn't notice this hook was created in social_auth.module. I moved it to social_auth.install

2. +++ b/social_auth.module
   @@ -22,3 +22,16 @@ function social_auth_theme() {
   +  $config->set('post_login_path', 'user')
   +         ->set('redirect_user_form', FALSE)
   +         ->set('disable_admin_login', TRUE)
   +         ->set('disabled_roles', array())
   +         ->save();
   

   For coding standards, the last 3 set() and the save() methods has to be indented with only 2 spaces more than $config

It seems we can now focus on #2821853: Provide Social Auth settings: functionality

@denutkarsh, I think it's better to fix #2821853: Provide Social Auth settings: functionality first, so site builders don't get confused if their settings don't work