User tests: Successful: Unsuccessful:
Pull Request for Issue #21921 .
Moves the captcha to the end of the form. This had already been done for contacts and content
the captcha is rendered after the default fields but before any custom fields
the captcha is rendered at the end of the form
Status | New | ⇒ | Pending |
Category | ⇒ | Front End com_users |
Labels |
Added:
?
|
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
I have tested this item
Works as expected - CAPTCHA shown before custom fields before the PR, and shown after custom fields after the PR was applied. Thanks!
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
Anything preventing this bug being merged?
Labels |
Added:
?
|
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
|
thanks
Thanks, I rebased this on 4.3 because it's not a bugfix.
I added the migration documentation at joomla/Manual#52
of course its a bug fix
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.
@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)
it's not me alone that thinks like this but if you need to blame a person then pick me happy with it.
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.
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
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...?
@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.
This was not a cosmetic fix. This was a bug fix. This should have been fixed in 4.2
Is this ready for testing?