(filed for tracking)
I'd left the question deliberately vague trying to create a generic "How do you submit patches" documentation bit.
I actually have a series of patches in git, pulled from gerrit as specified in the download section. The patches are currently based on 7e5b4d13b9 (master as of writing this).
This is about extending $wgOpenIDConsumerForce to be able to specify an OpenIDProvider instead of just a flat URL. This is useful if the provider varies by username and you wish to display the login form like the builtin providers.
If you specify $wgOpenIDConsumerForce as a string it continues to behave as before (tested). If you don't specify $wgOpenIDConsumerForce it continues to behave as before (tested). If you specify an OpenIDProvider, e.g. $wgOpenIDConsumerForce = new OpenIDProvider('wp', 'www.wordpress-site.com', 'Wordpress-site.com Username', 'http://www.wordpress-site.com/author/{username}/' ); it will display a login form asking for the username; skips rendering other providers' forms. (tested and using)
In the last case (or a future one with a specified list of providers, instead of just the one) the generic provider 'openid' (arbitrary url) may not be present. To handle this I removed the special case logic in
OpenIDProvider::getLoginFormHTML skin/openid.js
The special case used to, for the provider 'openid', name the field 'openid_url' instead of "openid_provider_param_$id". There is now a hidden input 'openid_url' always present and the 'openid' provider is treated the same as everything else.
I tried to test the code paths that were effected by the change I made after each patch. There are quite a few options though so there is a chance that I missed one that would be a confounding factor. To ease review I tried to break it into several logically distinct patches that stepped in the right direction.
UnwashedMeme (talk)21:49, 22 January 2013
Version: master
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=19346