[#37472] - [5.2] Fix multiple rendering calls on custom field
- Pending
- Medium
- Build: 4.1-dev
- # 37472
- Diff
- korenevskiy:Fix-quantity-times-rendering-for-call-one-customfield
User tests: Successful: Unsuccessful:
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.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
| Labels |
Added:
?
|
||
| Category | Front End Plugins | ⇒ | Administration com_fields Front End Plugins |
Hello Richard. I have completed the description
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.
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?
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
| Labels |
Added:
?
|
||
| Category | Front End Plugins Administration com_fields | ⇒ | Front End Plugins |
| Labels |
Added:
PBF
Removed: ? |
||
| Category | Front End Plugins | ⇒ | Administration com_fields Front End Plugins |
And what does the PBF hash tag mean?
And what does the
PBFhash 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.
And how do I create another PR on the FieldsHelper.php file?
But the new PR is not related to the topic of this PR. But since the current PR will change the code of this FieldsHelper.php file and make a shift in the number of lines. That new PR may conflict with the current PR, due to the fact that the amendments affect the same code.
@korenevskiy Normally you create a new branch for each PR, based on the target branch of the upstream repository (= this here)
P.S. In case of this PR you have done it right and have created a separate branch. For the new PR just make another branch based on your 4.1-dev branch and not of the one from this PR here.
This pull requests has automatically rebased to 4.2-dev.
This pull requests has been automatically converted to the PSR-12 coding standard.
| Labels |
Added:
?
|
||
| Labels |
Added:
?
Removed: ? |
||
| Category | Front End Plugins Administration com_fields | ⇒ | Administration com_admin SQL Postgresql com_config com_fields com_finder Language & Strings JavaScript Repository NPM Change Front End com_contact com_users Installation |
| Labels |
Removed:
?
|
||
| Labels |
Added:
Language Change
NPM Resource Changed
Removed: PBF |
||
| Labels |
Added:
PR-4.3-dev
|
||
| Category | Front End Administration com_fields com_admin SQL Postgresql com_config com_finder Language & Strings JavaScript Repository NPM Change com_contact com_users Installation | ⇒ | Administration com_admin com_config com_fields com_finder Language & Strings JavaScript Repository NPM Change Front End com_contact com_users Installation |
| Category | Front End Administration com_fields com_admin com_config com_finder Language & Strings JavaScript Repository NPM Change com_contact com_users Installation | ⇒ | Administration com_admin com_fields com_finder Language & Strings JavaScript Repository NPM Change Front End com_contact com_users Installation |
| Category | Front End Administration com_fields com_admin com_finder Language & Strings JavaScript Repository NPM Change com_contact com_users Installation | ⇒ | Administration com_fields Language & Strings JavaScript Repository NPM Change Front End com_contact com_finder com_users Installation |
| Category | Front End Administration com_fields com_finder Language & Strings JavaScript Repository NPM Change com_contact com_users Installation | ⇒ | Administration com_fields JavaScript Repository NPM Change Front End com_contact com_users Installation Language & Strings |
| Category | Front End Administration com_fields Language & Strings JavaScript Repository NPM Change com_contact com_users Installation | ⇒ | Administration com_fields JavaScript Repository NPM Change Front End com_users Installation Language & Strings |
| Category | Front End Administration com_fields Language & Strings JavaScript Repository NPM Change com_users Installation | ⇒ | Administration com_fields JavaScript Repository NPM Change Front End com_users Installation Language & Strings Libraries Plugins |
| Category | Front End Administration com_fields Language & Strings JavaScript Repository NPM Change com_users Installation Libraries Plugins | ⇒ | Administration com_fields Front End com_users Installation Language & Strings Libraries Plugins |
| Labels |
Removed:
NPM Resource Changed
|
||
| Category | Front End Administration com_fields Language & Strings com_users Installation Libraries Plugins | ⇒ | Administration com_fields Installation Language & Strings Libraries Front End Plugins |
| Category | Front End Administration com_fields Language & Strings Installation Libraries Plugins | ⇒ | Administration com_fields Installation Language & Strings Front End Plugins |
| Category | Front End Administration com_fields Language & Strings Installation Plugins | ⇒ | Administration com_fields Front End Plugins |
| Labels |
Removed:
Language Change
|
||
obuisard
- | Title |
|
||||||
@HLeithner Is it possible to transfer this PR to Joomla 5 ?
| Labels |
Added:
bug
Removed: ? |
||
This pull request has been automatically rebased to 4.4-dev.
Transfer this PR to Joomla 5
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.
| Title |
|
||||||
| Title |
|
||||||
This pull request has been automatically rebased to 5.2-dev.
| Title |
|
||||||
@korenevskiy Can you please fix the conflict?
| Labels |
Added:
PR-4.4-dev
PR-5.2-dev
Removed: PR-4.3-dev |
||
I don’t see any testing instructions in the description of this PR.