? ? PR-4.3-dev Pending

User tests: Successful: Unsuccessful:

avatar brianteeman
brianteeman
26 Aug 2022

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

avatar brianteeman brianteeman - change - 26 Aug 2022
Status New Pending
avatar brianteeman brianteeman - open - 26 Aug 2022
avatar joomla-cms-bot joomla-cms-bot - change - 26 Aug 2022
Category Front End com_users
avatar brianteeman brianteeman - change - 26 Aug 2022
Labels Added: ?
avatar crystalenka
crystalenka - comment - 7 Oct 2022

Is this ready for testing?

avatar brianteeman
brianteeman - comment - 7 Oct 2022

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

avatar crystalenka
crystalenka - comment - 7 Oct 2022

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.

avatar crystalenka crystalenka - test_item - 7 Oct 2022 - Tested successfully
avatar alikon
alikon - comment - 8 Oct 2022

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.

avatar alikon alikon - test_item - 8 Oct 2022 - Tested successfully
avatar alikon alikon - change - 8 Oct 2022
Status Pending Ready to Commit
avatar alikon
alikon - comment - 8 Oct 2022

RTC


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

avatar brianteeman
brianteeman - comment - 21 Oct 2022

Anything preventing this bug being merged?

avatar rdeutz rdeutz - change - 23 Oct 2022
Labels Added: ?
avatar HLeithner HLeithner - change - 23 Oct 2022
Status Ready to Commit Fixed in Code Base
Closed_Date 0000-00-00 00:00:00 2022-10-23 11:34:43
Closed_By HLeithner
Labels Added: PR-4.3-dev
avatar HLeithner HLeithner - close - 23 Oct 2022
avatar HLeithner HLeithner - merge - 23 Oct 2022
avatar HLeithner
HLeithner - comment - 23 Oct 2022

thanks

avatar HLeithner
HLeithner - comment - 23 Oct 2022

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

avatar HLeithner
HLeithner - comment - 23 Oct 2022

I added the migration documentation at joomla/Manual#52

avatar brianteeman
brianteeman - comment - 23 Oct 2022

of course its a bug fix

avatar crystalenka
crystalenka - comment - 23 Oct 2022

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.

avatar brianteeman
brianteeman - comment - 23 Oct 2022

@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)

avatar HLeithner
HLeithner - comment - 23 Oct 2022

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

avatar brianteeman
brianteeman - comment - 23 Oct 2022

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.

avatar HLeithner
HLeithner - comment - 23 Oct 2022

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

avatar bembelimen
bembelimen - comment - 23 Oct 2022

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...?

avatar laoneo
laoneo - comment - 23 Oct 2022

@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.

avatar brianteeman
brianteeman - comment - 23 Oct 2022

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

Add a Comment

Login with GitHub to post a comment