com_fields custom field in com_user does not respond to setFieldAttribute in frontend

[stutteringp0et]

plugin.zip

Steps to reproduce the issue

1. Create a custom field for com_users
2. Create a user plugin with the onContentPrepareForm method. Within that method, attempt to make any change to your custom field using $form->setFieldAttribute('fieldname','class','hello','com_fields');
3. edit a user profile in /administrator - your altered field will have a 'hello' class.
4. log in as that user and edit your profile in the front end - your field will not reflect the class change.

Expected result

Field is altered in the frontend and the backend

Actual result

field is only altered in the backend

System information (as much as possible)

J3.8.1, fresh install, mariadb, PHP7.1-FPM, and I had a hamburger for dinner last night...it was delicious.

Additional comments

I have executed print_r($form->getFieldXML($field,'com_fields')['class']); before and after I made the change and the xml reflects the change - but the output doesn't. I've tried several types of changes, just to be sure I see what I think I'm seeing and the result is always the same - it works in the backend but not the frontend.

One interesting bit - when I $form->removeField('fieldname','com_fields') - the field doesn't disappear -
it moves to the bottom of the fieldgroup. I thought that was very odd.

[stutteringp0et]

<?php
defined('_JEXEC') or die;
jimport('joomla.plugin.plugin');
class plgSystemPlugin extends JPlugin {   
    public function onContentPrepareForm($form, $data) {
	if (!($form instanceof JForm))
	{
	    $this->_subject->setError('JERROR_NOT_A_FORM');

	    return false;
	}

	// Check we are manipulating a valid form.
	$name = $form->getName();

	if (!in_array($name, array('com_admin.profile', 'com_users.user', 'com_users.profile', 'com_users.registration')))
	{
	    return true;
	}
		
	$form->setFieldAttribute('fieldname','class','hello','com_fields');
    }
}

[stutteringp0et]

This is fun - it occurred to me to trigger a log when the FieldsHelper::prepareForm method was executed. Adding error_log('prepareForm'.microtime()); to the method gave this result in the frontend:

PHP message: prepareForm0.75458500 1509635643
PHP message: prepareForm0.77258000 1509635643

The FormHelper::prepareForm method is being executed twice.

I get this log in the backend:

PHP message: prepareForm0.28052000 1509636249

Something in the frontend is causing FieldsHelper::prepareForm to execute twice.

[stutteringp0et]

debug_backtrace shows that in the frontend it's being executed in:

        (
            [file] => /var/www/html/jcb/libraries/joomla/event/event.php
            [line] => 70
            [function] => onContentPrepareForm
            [class] => PlgSystemFields
            [type] => ->
        )```
and in
```Array
        (
            [file] => /var/www/html/jcb/components/com_users/views/profile/view.html.php
            [line] => 50
            [function] => getForm
            [class] => UsersModelProfile
            [type] => ->
        )```

But in the backend, it's only being executed in:
```Array
        (
            [file] => /var/www/html/jcb/libraries/joomla/event/event.php
            [line] => 70
            [function] => onContentPrepareForm
            [class] => PlgSystemFields
            [type] => ->
        )```

[Quy]

It could be related to this PR #18211. If yes, please test and submit your result.

[stutteringp0et]

Thanks @Quy - that's the exact change I just tested! Commenting out those two lines resolved the issue double processForm issue - but I was beginning to test for side effects.

[stutteringp0et]

I'll keep an eye on that issue while I continue to investigate mine. If I determine that to be the fix, I'll close this issue.

[stutteringp0et]

My testing is complete, PR #18211 solves this issue. I'll drop a note over there. Thanks again @Quy for making that connection!