User Registration Captcha

[brianteeman]

Pull Request for Issue #21921 .

Summary of Changes

Moves the captcha to the end of the form. This had already been done for contacts and content

Testing Instructions

1. Enable recaptcha
2. set the captcha in global config
3. enable user registration
4. create custom user fields for registration
5. check the registration form on the front end - captcha displayed
6. disable captcha in global config
7. check the registration form on the front end - no captcha displayed
8. enable captcha in the users component
9. check the registration form on the front end - captcha displayed

Actual result BEFORE applying this Pull Request

the captcha is rendered after the default fields but before any custom fields

Expected result AFTER applying this Pull Request

the captcha is rendered at the end of the form

[crystalenka]

Is this ready for testing?

[brianteeman]

Is this ready for testing?

of course. its not a draft - just no one seems interested in testing it and would prefer to complain about the bug

[crystalenka]

I have tested this item ✅ successfully on 75e0fbe

Works as expected - CAPTCHA shown before custom fields before the PR, and shown after custom fields after the PR was applied. Thanks!

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38604.}

[alikon]

I have tested this item ✅ successfully on 75e0fbe

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38604.}

[alikon]

RTC

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38604.}

[brianteeman]

Anything preventing this bug being merged?

[HLeithner]

thanks

[HLeithner]

Thanks, I rebased this on 4.3 because it's not a bugfix.

[HLeithner]

I added the migration documentation at joomla/Manual#52

[brianteeman]

of course its a bug fix

[crystalenka]

Would agree this is a bug fix rather than a feature. Captcha should always be rendered right before submit. Even if it wasn't technically "broken" it was a usability bug.

[brianteeman]

@crystalenka seems that @HLeithner thinks anything that doesn't spit out an error message is not a bug even if it doesnt do what it says it will do. another example #38953 (comment)

[HLeithner]

it's not me alone that thinks like this but if you need to blame a person then pick me happy with it.

[brianteeman]

Well you are the only one who commented so if anyone else does they are anonymous and it would be impossible for me to know.

The fact still remains that "you" are not being consistent in deciding what is a bug and what is a feature. It just depends on who created the pr.

Looks like we are returning to the bad old days where functionality that doesn't work is never fixed because to fix it is a new feature. And only code from "real" developers is acceptable in this elitist world.

Even when code is contributed specifically at the request of one of these "real" developers it is ignored because the wrong type of person contributed it.

[HLeithner]

Doesn't matter who provided the PR, maybe you noticed that this PR has been merged already and about 40 other PRs this weekend from various people so please stop attacking me and tell me that I prefer some persons more then other.

thanks

[bembelimen]

Looks like we are returning to the bad old days where functionality that doesn't work is never fixed because to fix it is a new feature. And only code from "real" developers is acceptable in this elitist world.

I just checked the PR and for me it looks like the code is fixed...?

[laoneo]

@brianteeman you can also add me to the list of persons who are cautious about merging pr's into a patch branch. Patch releases are really there to stabilize a minor version and should only receive bug fixes (mainly regressions) and not cosmetic stuff. This doesn't mean that they are not relevant, but they should be added to a .0 version where people expect a different behavior, especially in the UI. This is common software development practice and not something Harald and I have invented.

[brianteeman]

This was not a cosmetic fix. This was a bug fix. This should have been fixed in 4.2