can this Issue please be answered as its open for a Week having Stauts "New"?

This seams to be a feature request and it seams this involves the profile plugin? Usually it should be possible using an override or using an dedicated plugin that do the complete form. I'm not sure what we should ship as core default.

@zero-24 the problem is that if you enable captcha it appears immediately below the registration form and if you then enable the user profile plugin (or similar) this appears below the captcha with the form submit buttons at the very end. The correct thing would be for the captcha to always be positioned next to submit buttons. I have tried to do this myself for a site of mine that is effected but failed.

thanks @zero-24 and @brianteeman for your Comments.

Yes with the default but it should be possible to override that here: https://github.com/joomla/joomla-cms/blob/staging/components/com_users/views/registration/tmpl/default.php#L24-L53 by catching the type captcha and move it down. But I'm not sure if we should do something like this in the detault.

sorry @zero-24 that doesnt make any sense to me

There is no reason for the captcha to ever be anywhere other than immediately before the submit button

Well this way I would also move it down on any site that uses custom plugins and thier own captcha field (with type captcha) etc.

We can do a option but we all hate new options too and it would make it even more complex too.

we all hate new options

i like (new and old) Options ... if they are helpful :-)

To consistently put the captcha next to submit buttons either JForm has to arbitrarily resort form fields (bad idea) or you add logic to layouts to explicitly exclude rendering the captcha field from being rendered with any of the group based rendering ((foreach ($form->getFieldset($name) as $field) { $form->renderField($field); } type stuff) and explicitly render the captcha field at the end of the form (ugly idea but less bad).

The basic problem boils down to if you aren't manually rendering every form field (which you should avoid doing in the first place because you make it impossible for plugins to dynamically alter forms to add new fields without those same plugins requiring new layout overrides to add these fields), form fields are rendered in the order they exist in the form definition, and this includes the alterations plugins make to the form.

Surely the cause of the problem is that the captcha field is always rendered before any other additional fields

I am "guessing" thats because the plugins are loaded alphabetically by type and then by the ordering which can only be set within a plugin type

So it's not about JForm arbitrarily resorting form fields but about setting the order that plugins are loaded correctly

It's not even plugin ordering. It's the order in which the fieldsets are defined in the form, for this particular form at least. If the profile plugin prepended its fieldset to the form instead of appending, you would have all of its fields at the beginning of the form (even before the fields from the base form XML definition).

To make this particular layout render with the captcha at the end of the form, which includes accounting for any possible plugin manipulations, you would have to skip the captcha field when rendering the default fieldset and manually render it after rendering every other field/fieldset, or the profile plugin would have to be altered to add its fields to the default fieldset before the captcha field (and it would only "fix" this profile plugin, you still have the problem if other plugins are altering the form).

any news on this topic? getting massive problems with a client because of this issue... should we try @zero-24 suggestion catching the captcha type and moving it down in the meantime?

Hi, I am Dhananjay Rayate a contributor to OpenForce 2022. I would like to work on this issue. I would be making a PR as soon as I am done with resolving the issue. Thank you

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features, therefore this issue will not be fixed in Joomla 3.

For Joomla 4 @brianteeman has created a pull request with a fix, see #38604 . Many thanks. Please test.

Closing as having a pull request.