[4.4] Fix multiple rendering calls on custom field

[korenevskiy]

When opening a user's page with an article and any custom field. This same field is rendered 2 times. I repeat. One field in the article is rendered 2 times. This issue has been studied. When the field is rendered 2 times, only 1 result is shown on the site, and 2 render result is meaningless. At the same time, All subscriptions of render events called by the dispatcher are also executed 2 times. Thus, it is not possible to write a user data handler without using crutches and props to avoid double processing of the field object.
For example, if you develop a new field with processing data from forms received from the user. Then such data processing needs to be subscribed to the plugin method

PlgFieldsNewForm->onCustomFieldsPrepareField($context, $item, $field)

But this method will be called 2 times.
My correction allows you to make 1 render for one field call. While maintaining backward compatibility.

This correction does not matter for static data output. But this amendment is of great importance for the output of dynamic data in user fields of articles. This can be useful when creating a complex graph field with a lot of data in one field. Or a feedback field. But in order for feedback to work in a complex field, it is required to render exactly as many times as it will be displayed on the site.

Rendering occurs when the method is called

FieldsHelper::getFields($context, $item);

When calling this method, dispatcher subscriptions are called

FieldsPlugin->onCustomFieldsBeforePrepareField($context, $item, &$field)
FieldsPlugin->onCustomFieldsPrepareField($context, $item, &$field)
FieldsPlugin->onCustomFieldsAfterPrepareField($context, $item, $field, &$value)

Accordingly, for one field, all these methods will be called twice.

However, this happens in the 2 places indicated below

PlgSystemFields->display($context, $item, $params, $displayType)
PlgSystemFields->onContentPrepare($context, $item)

This fix allows you to use the same render in both calls to these methods.

The text has been supplemented thanks to Richard's comments.
We need to create this plugin in the /plugins/fields/newmyfield folder with the class inherited from Joomla\Component\Fields\Administrator\Plugin\FieldsPlugin.
In this plugin we create methods onCustomFieldsPrepareField($context, $item, &$field)

use Joomla\Component\Fields\Administrator\Plugin;
use Joomla\CMS\Factory;
class PlgFieldsNewMyField extends FieldsPlugin {
	public function onCustomFieldsPrepareField($context, $item, &$field){
		if($field->type!='newmyfield')
			return parent::onCustomFieldsPrepareField($context, $item, $field);
		static $counter;
		if(is_null($counter))
			$counter = 0;
		Factory::getApplication()->enqueueMessage('Counter Rendering field:'.$field->type.'  counter:'.++$counter );	

		return parent::onCustomFieldsPrepareField($context, $item, $field);
	}
}

Thanks to this test, it is clear that the new amendment calls this method once. Without new corrections, this method was previously called 2 times for one field. You can also place a counter for the test in the rendering file.
/plugins/fields/newmyfield/tmpl/newmyfield.php - this is the layout file for the field.
inside this file we will place a similar counter with a message call.
Factory::getApplication()->enqueueMessage('Counter Rendering field:'.$field->type.' counter:'.++$counter );

in the message call, you need to specify $counter. Since if the messages are completely identical, then 1 message will be displayed instead of 2x. In order to accurately see the number of message calls, we must specify a different text in the message each time. The sequence number in the message will change the text. and the message will be displayed to the number of calls.

Should I blow up all the plugin methods in a row to test the number of calls? But if it is required, we can prescribe a similar example of code for methods.

FieldsPlugin->onCustomFieldsBeforePrepareField($context, $item, &$field) 
FieldsPlugin->onCustomFieldsAfterPrepareField($context, $item, $field, &$value)

But I think one method is enough for the test.

Also at the end I added a plugin event call once without multiple calls in to FOREACH.

Factory::getApplication()->triggerEvent('onCustomFieldsContentPrepare', [$context, $item, &$item->jcfields]);

This will also allow you to change the value of the fields from the beginning of the list after passing all the results.

[richard67]

I don’t see any testing instructions in the description of this PR.

[korenevskiy]

Hello Richard. I have completed the description

[korenevskiy]

I have little experience in writing tests. But it will take me a long time and I will need to study the test classes. Perhaps I will consult here. But so far I have managed to find the error and issue a correction.

[richard67]

I did not mean to write unit test or something like that. I meant to write testing instructions for human testers in the description of this PR. There were the headings for these tests in the description template which you get when you create a new PR, but you have removed them. Do you think we had them there for nothing?

[korenevskiy]

Do you think we had them there for nothing?

You are right, I am aware of the seriousness of these names. I am aware of the importance of the project for many participants. I was tired, and since I don't know the language well, I'm writing a description through a translator. I was wrong, I will definitely improve in the future.
I have completed the description

[korenevskiy]

And what does the PBF hash tag mean?

[richard67]

And what does the PBF hash tag mean?

Pizza, Bugs and Fun. At Joomls day USA there was such an event, and we flagged a bunch of PRs with that label so people test them. The label will be removed in a few days.

[korenevskiy]

@laoneo Please check.

[korenevskiy]

@HLeithner Is it possible to transfer this PR to Joomla 5 ?

[HLeithner]

This pull request has been automatically rebased to 4.4-dev.

[korenevskiy]

Transfer this PR to Joomla 5

[Septdir]

It is not correct to do this in the dislpay plugin method.
In fact, an object without jcfields can get there;
Either incorrect for a given context or parameters. For example, they were changed before the trigger was called.