User tests: Successful: Unsuccessful:
Pull Request for Issue #28800 .
The patch improve Captcha plugins.
Now it can use a real events, and people stop confusing onDisplay
(etc) callback with event.
How this work.
Here added a new event onCaptchaSetup
and an Interface for CaptchaProvider
class.
While this event the plugin should register own CaptchaProvider
class in CaptchaRegistry
.
The system will retrieve the requested Captcha type from that registry and call required methods, that defined by CaptchaProviderInterface
This is fully backward compatible.
Looking for feedback.
If all good we can do the same for Editor and its Buttons.
Techicaly now one plugin can provide multiple captcha, however for now the global configuration done per plugin.
But this can be extended in future, when need.
Apply patch, remove administrator/cache/autoload_psr4.php
Enable recaptcha_invisible
and make sure it works.
Testing B/C:
Enable older recaptcha
and make sure it works.
All works
All works
Please select:
Category | ⇒ | Libraries Front End Plugins |
Status | New | ⇒ | Pending |
Sure, will update later.
Probably leave that for another PR. I'm waiting for the Editors, EditorsXtd version
Labels |
Added:
?
PR-4.3-dev
|
Category | Libraries Front End Plugins | ⇒ | Libraries Front End Plugins Unit Tests |
Labels |
Added:
?
|
Why do you don't you just use plugin events and plugins, instead of having a registry, etc.? From my understanding I just want to dispatch an event and the result contains the captcha. Why all these extra classes? I would also deprecate the Captcha class as it is only an unnecessary static singleton.
Why do you don't you just use plugin events and plugins
That what I am doing
From my understanding I just want to dispatch an event and the result contains the captcha.
No, that wrong. You cannot have it in that way, the event will be displatched for ALL installed captcha.
I would also deprecate the Captcha
This class to "rule them all", cannot be trashed.
@laoneo the registry concept is the correct approach not only for the Captcha but also for the Editor and the Auth plugins. All these plugins, as they are right now, dispatching events within an event which architecturally is wrong. What @Fedik is doing here is normalising to single event (if I understand the code correctly, haven't step through though) which is the right thing
So it means you can never have multiple captchas on one site?
So it means you can never have multiple captchas on one site?
No, you should be able to, as you can have multiple Editors, etc. The issue that Fedik is fixing here is that all these plugins basically used to be direct callbacks up to 3.x. J4 everything was converted to events but in reality the events were wrappers to the same methods (eg Editor->init()). The registry acts as event delegation, which imo is a good approach and a solid concept that will lead to less buggy code
hmhm, please look the code. That to much to explain
You can have many captcha, and many differen captchas on same page (one capctha per captcha field).
But you cannot use onDisplay
event. Please follow linked issue.
I would also deprecate the Captcha
On second thought, maybe we could, and use Registry directly (or merge Captcha and CaptchaRegistry to single class).
But we do not have a clear way to access a "shared" class instance.
$registry = Factory::getContainer()->get(CaptchaRegistry::class);
$captcha = $registry->get('potato_captcha');
echo $captcha->display();
So maybe in joomla 8
Look on the Captcha class as a comfortable helper.
Labels |
Added:
PR-4.4-dev
Removed: PR-4.3-dev |
I guess it is better to rebase this pr to the 5.0-dev branch, as it will get more attention for new features. Thanks for understanding.
Labels |
Added:
PR-5.0-dev
Removed: PR-4.4-dev |
Labels |
Added:
?
|
Title |
|
Labels |
Added:
Feature
Removed: ? |
Title |
|
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-08-21 07:44:48 |
Closed_By | ⇒ | HLeithner |
thanks
@Fedik could you also move the captcha plugin to service providers, like #39639