Closed dd32 closed 1 year ago
Code looks good - is there an example we can test where someone has extended the providers?
The best example is the unit test included, and the code included in the PR description.
My only concern with the changes to class instantiation might conflict with someone who has previously set this up.
That's a valid concern, however, it's pretty awkward to extend them at present to the point that this shouldn't break any existing implementations of that. They'd have to be including their own replacement class in the two_factor_providers
array, and as it's currently keyed by the classname, couldn't "transparently replace" a core provider without modifying code, AFAIK.
I also can't find any plugins in the directory that extend the core providers: https://wpdirectory.net/search/01GX87VBAWAPCCA0RXEY3HY7G0
What?
This PR allows for the classname of a provider to differ from it's "key" that's used within the application. This was spurred by an attempt to simply extend a core provider with a custom one to override certain functions (instead of #545 ).
This has resulted in several changes:
Two_Factor_Provider::get_key()
which returns the providers 'key', which defaults to the class name as present.get_instance()
from each individual provider and moving it to the abstractTwo_Factor_Provider
, each provider had a slightly different one, and the usage of__CLASS__
meant children of the provider had to override theget_instance()
method as well.Why?
This allows for users of the plugin to overload a provider with a custom variant of the provider, without having to register an entirely new provider and migrate users over to it.
For example:
How?
By allowing the classname to be filtered, external code can overload core providers with customisations without needing to duplicate the entire provider.
Testing Instructions
npm run test
Screenshots or screencast
Changelog Entry
Added - Better compatibility to allow overloading core Two Factor providers without duplicating the entire provider.