Right, thanks for that, I completely read over that comment earlier.
The MR applies fine, and testing it with a Drupal-to-Drupal setup (using simple_oauth on the IdP side), this seems to work perfectly.
Two things that I encounter:
1. The client secret is still required to be filled in. Any text will work, since it is not actually used.
2. The MR does break other clients implementing OpenIDConnectClientBase, e.g. openid_connect_windows_aad:
```
ArgumentCountError: Too few arguments to function Drupal\openid_connect\Plugin\OpenIDConnectClientBase::__construct(), 11 passed in /var/www/html/docroot/modules/contrib/openid_connect_windows_aad/src/Plugin/OpenIDConnectClient/WindowsAad.php on line 65 and exactly 12 expected in Drupal\openid_connect\Plugin\OpenIDConnectClientBase->__construct() (line 143 of modules/contrib/openid_connect/src/Plugin/OpenIDConnectClientBase.php).
```
Thanks for the work on this MR, I am looking for PKCE support.
Agreed with comment #40: why is the abstract class changed? There is a bunch of implementations for OpenID Connect clients that implement this class, e.g. the ever so popular openid_connect_windows_aad module (see https://git.drupalcode.org/project/openid_connect_windows_aad/-/blob/24e...). These changes will break all those implementations.
Changes pushed to MR.
I will create a merge request for the changes.
Martijn Houtman → created an issue.
For me, it was the permission hardening that was setting the simpletest directory to 0555. Simply adding this to default.settings.php worked:
```
$settings['skip_permissions_hardening'] = TRUE;
```
I know this is a very old ticket, but I ran into this message this week, and found out it was due to a field that was added to the index, while the bundle that the field belongs to was excluded from being indexed. I think this happened to us due to a faulty git merge, but I think it might also happen if you add the field first, and then after exclude the bundle that the field belongs to. Saving the field list again will remove the field, as it should, but as long as you do not re-save the field list, the error seems to pop up.
Related ticket: https://www.drupal.org/project/search_api/issues/2769759#comment-15217836 🐛 Could not retrieve data definition for field / Column 'server_id' cannot be null Closed: cannot reproduce
I know this is a very old ticket, but I ran into this message this week, and found out it was due to a field that was added to the index, while the bundle that the field belongs to was excluded from being indexed. I think this happened to us due to a faulty git merge, but I think it might also happen if you add the field first, and then after exclude the bundle that the field belongs to. Saving the field list again will remove the field, as it should, but as long as you do not re-save the field list, the error seems to pop up.
Looking at https://www.drupal.org/project/domain_simple_sitemap/issues/3251227 ✨ Make compatible with simple_sitemap 4.0 & domain_entity Fixed patch #34, it seems that patch already rewrites the code in such a way, that it applies to all entity types, therefor making the above patch obsolete.
Confirmed this is happening on several of our sites as well. Thanks for catching this, it took me some time to find out the conflict module was the culprit.
Confirmed patch #10 fixes the issue.