[com_fields] Multilanguage: correcting custom fields display in function of item language #18474

infograf768 · 2017-11-02T09:11:37Z

Pull Request for Issue #18396
Issue: An item (article in that case) tagged to ALL languages is displaying all fields tagged to specific languages.

Summary of Changes

When an item is tagged to ALL languages, only display custom fields tagged to ALL languages.

Testing Instructions

Create a multilingual site. 2 Content languages are enough. Here for en-GB and fr-FR
Structure:
===>Categories

===>Articles set as Featured

===> Home menu as Featured Articles menu item for each language.

===> Create some articles custom fields and assign languages, including ALL
For the sake of this demo I added a Media field tagged to ALL and choose the same image for each article.

###Before patch
-----Back-end: when editing an article tagged to ALL languages, we also get the fields tagged to specific languages.

---- Which is also the case in frontend
==> Active language is fr-FR

==>Active language is en-GB

After patch

----- Backend: only fields tagged to ALL languages display in an article tagged to ALL languages.

-----Same in frontend
==> Active language is fr-FR

==>Active language is en-GB

@ajejebrazorf01
@AlexRed
@ggppdk

language

AlexRed · 2017-11-02T09:31:49Z

I have tested this item ✅ successfully on 2ae0954

Patch ok for me

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/18474.}

uruk-hai-21 · 2017-11-02T09:56:24Z

A questions.

Why in backend, the english and french tabs disappear? French and english languages are not a subset of All language?
Why in frontend, when the active language is fr-FR, the Article ALL not shown the custom field fr-FR? French language is not a subset of All language?

infograf768 · 2017-11-02T10:17:04Z

Why in backend, the english and french tabs disappear? French and english languages are not a subset of All language?

Nope, they are not.

Why in frontend, when the active language is fr-FR, the Article ALL not shown the custom field fr-FR? French language is not a subset of All language?

Nope.

Specific languages are not subset of All languages. Language ALL exists only for display.
Setting an item to ALL languages means that this item may display whatever the Active language.
Example: Modules or articles or categories, etc.

In the case of custom fields, their display should depend on the item language itself.
This is why a custom field tagged to ALL languages should display whatever the item language while custom fields tagged to a specific language should only display when the item language is tagged to the same specific language (which in that case corresponds to the active language).

uruk-hai-21 · 2017-11-02T10:33:09Z

A specific language (A) is a subset of all lanuguages (B):

If this is the final change It means that I will continue to use module to filter custom fileds

infograf768 · 2017-11-02T11:00:47Z

Do you want to rather get that?

infograf768 · 2017-11-02T11:10:26Z

If this is what you want, it can be done. It will mean that fields will show depending on the active language and no more on the item language.
In backend, all fields would display when editing for example an article tagged to ALL.

uruk-hai-21 · 2017-11-02T11:14:48Z

exactly, but it is only my opinion, I don't know if this is the right way.

infograf768 · 2017-11-02T11:18:20Z

@AlexRed
@ggppdk
@laoneo

Please give your opinion here.
The code would change this way:
add $app = JFactory::getApplication(); and then further

		if ($app->isAdmin())
		{
			if (JLanguageMultilang::isEnabled() && isset($item->language) && $item->language != '*')
			{
				self::$fieldsCache->setState('filter.language', array('*', $item->language));
			}
		}
		elseif ($app->isSite())
		{
			if (JLanguageMultilang::isEnabled() && isset($item->language))
			{
				$lang = JFactory::getLanguage()->getTag();

				if ($item->language = $lang || $item->language = '*')
				{
					self::$fieldsCache->setState('filter.language', array('*', $lang));
				}
			}
		}

rdeutz · 2017-11-02T11:26:48Z

I think there are arguments for all ways of displaying custom fields, we should be careful and not change behaviour because this can break sites. This needs to be B/C

uruk-hai-21 · 2017-11-02T11:47:46Z

Work for me

laoneo · 2017-11-02T12:01:01Z

I would not filter the fields depending on of the language of this site. The problem is when you edit an article on the front which doesn't belong to the active language, the existing field data get erased of the fields which are not attached to the site language. Was that not the reason why #12656 was made? To have the same field on multiple languages with a translated label?

infograf768 · 2017-11-02T12:32:25Z

@laoneo
That only concerned fields labels and not their content and multilang filtering was not present in code at the time.
Deciding to tag fields by language and then filtering them has changed the situation which is very well described by the original poster in #18396
Basically, in fields.php, filtering is done the same way for site and admin, which was an error.
That's why we get, for an item tagged to ALL, fields tagged to all other languages than the active one or ALL.

result: for example in an article tagged to ALL, one could add a bunch of text in French in a custom field tagged to French and it would still show in French when the article is displayed in the site when en-GB is the active language.

My first solution may not have been the right one but the second proposal solves precisely that issue.

infograf768 · 2017-11-02T12:54:23Z

Also:
Using JText for labels is nevertheless extremely useful, and specially for fields tagged to ALL languages in frontend, but not only, because different languages may be available in backend (specially in multilang) which would require translation depending on the language used by the user.

infograf768 · 2017-11-02T13:03:02Z

Also

The problem is when you edit an article on the front which doesn't belong to the active language, the existing field data get erased of the fields which are not attached to the site language.

I tested here by editing a field set to ALL, therefore unrelated to the Active site language, and I have no issue because the content of the field depends on content entered in the article itself.
Compare this edited with screenshot above

laoneo · 2017-11-03T07:40:44Z

So when you edit on the front the article "French Demo" which has the language fr-FR but the site language is set to de-DE. Will then the fields which belong to fr-FR also appear?

infograf768 · 2017-11-03T08:50:17Z

@laoneo
In native multilang, the French demo article tagged to fr-FR will just not display when site language (active language) is de-DE. This is the basics of multilang. One has to switch to fr-FR to edit it in frontend.
If is was tagged to "ALL" languages, it would display whatever the active language.

infograf768 · 2017-11-03T09:10:29Z

@laoneo
Let me explain again:

This PR (the original code or the one that I also proposed above) does not change the display or not of the custom field tagged to a specific language or ALL when the item language (article as example) has the same language as the custom field.
In that case, a custom field tagged to All will also display for that article.
That is perfectly OK.

The issue concerns ONLY an item/article tagged to ALL.
first proposal (the PR code): only custom fields tagged to ALL will display for an item (article in our case) tagged to ALL.
Second proposal (in my second proposal above): Custom fields tagged to ALL as well as tagged to the same language as the active language ( site language) will display for an article tagged to ALL.

infograf768 · 2017-11-06T16:58:50Z

@laoneo
Sorry to insist, but we do have a bug in multilang with custom fields and we should solve this.

We can't accept displaying in an article tagged to ALL the French tagged custom field when the Active language is English

laoneo · 2017-11-07T07:16:45Z

If it belongs only for the automatic display events, then I would do the language filtering there. Where you have placed it affects all possible calls like getting them for the form, etc.
The display logic can be found here https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L326.

infograf768 · 2017-11-07T11:00:42Z

@laoneo
Got it. would this be OK for you?
Adding after https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L326

		if ($fields)
		{
			$app = Factory::getApplication();

			if ($app->isClient('site') && Multilanguage::isEnabled() && $item->language == '*')
			{
				$lang = $app->getLanguage()->getTag();

				foreach ($fields as $key => $field)
				{
					if ($field->language == '*' || $field->language == $lang)
					{
						continue;
					}

					unset($fields[$key]);
				}
			}
		}

That would display fields tagged to ALL and fields tagged to the active language only when an item is tagged to ALL.

EDIT: also make sure $item has a language

laoneo · 2017-11-07T13:14:12Z

Guess this should work. I'm not so much into the multilanguage stuff as you, but it is the better place to make the language filtering.

infograf768 · 2017-11-07T14:16:08Z

OK. As I guess it is too late for 3.8.2 which is in code freeze, will make a new PR and close this one.
@AlexRed I think we are more inline with general multilang behavior this way than if we only display fields tagged to ALL in items also tagged to ALL.
It is quite easy to not fill the value of a field when editing an item tagged to ALL (which means to not set a default value in the field itself)
@ajejebrazorf01 please follow up. will call you both when PR is ready.

infograf768 · 2017-11-08T09:44:45Z

@laoneo
while I was going to delete this PR and create a new one with the code above (which works fine for articles and contacts, I wanted to test how custom fields behave for user.

I found out that their display is independent of the display method in
https://github.com/joomla/joomla-cms/blob/staging/plugins/system/fields/fields.php#L304
as deleting the whole method there has no impact.

they do show (without language filtering, even after my patch which code is added in that method) in registration and site edit profile.

Values can be entered for edit profile in frontend, but NOT for a registration where inputs are greyed.

Where shall I look for the language filtering for these?
Why are they greyed but still display when registration?

Screenshot when editing profile in frontend

Screenshot when registration

laoneo · 2017-11-08T09:53:09Z

The problem is with users, that it is based on the form and makes some weird stuff here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/views/profile/tmpl/default_custom.php to display the form fields instead of rendering them as every other extension does. Probably here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/models/profile.php#L126 or here https://github.com/joomla/joomla-cms/blob/staging/components/com_users/models/profile.php#L182 you can set the language of the user and then the form should only load the fields with the right language.

The fields are probably grayed out because of permissions.

infograf768 · 2017-11-08T09:58:23Z

@laoneo Will look for lang filtering.

The fields are probably grayed out because of permissions.

Nope. Fields were set to Public. I changed that to Guest and same result.

ghost · 2017-11-08T10:26:55Z

@infograf768 if you set Permission of Field to "Allowed" it isn't greyed out anymore:

infograf768 · 2017-11-08T10:43:14Z

Thanks @franz-wohlkoenig mixed permissions and access...

@laoneo
I can solve the issue for lang filtering User fields in frontend, but I have to do the patch in fields helper in the getFields() method.

		if ($context == 'com_users.user')
		{
			$app = JFactory::getApplication();

			if ($app->isClient('site') && JLanguageMultilang::isEnabled())
			{
				$lang = $app->getLanguage()->getTag();
				self::$fieldsCache->setState('filter.language', array('*', $lang));
			}
		}

this will work for registration as well as profile.
Could not find a simpler way.

laoneo · 2017-11-08T10:55:01Z

@infograf768 didn't test it, but you should be able to set the language on the passed data and you should be fine, no need to do such a workaround.

infograf768 · 2017-11-08T17:37:44Z

Indeed, I obtain the correct results if I add in models/profile.php
in the loadFormData() or getData() methods

		if (JLanguageMultilang::isEnabled() && empty($data->language))
		{
			$data->language = JFactory::getLanguage()->getTag();
		}

the problem is that it is OK when editing a profile but does not work for registration...

laoneo · 2017-11-08T18:39:33Z

I can have a look on the profile issue when the rest is done. Lets try to do it in different steps.

infograf768 · 2017-11-08T19:45:45Z

ok, will do.

infograf768 · 2017-11-09T07:42:44Z

Closing this PR in favor of #18536

infograf768 · 2017-11-09T14:27:58Z

@@ajejebrazorf01
Please test #18536

matiaio · 2018-05-28T09:16:36Z

Hello infograf768,

exactly this Problem persists on Custom-Fields for User-Registrations-Form:
I have 3x Languages on my Site and 3x Custom-Fields for each Language in Frontend, but all 3x Custom-Fields are showing on website on User-Registration Form.
It should shows just one Custom-Field for User-Registration per Language.
How can i fix this?

Best Regards

ghost · 2018-05-28T09:22:44Z

@matiaio Comments on closed Issues didn't get much Notice. Please ask help on the forums. This repository concerns in first Place Joomla-Core coding, thanks.

infograf768 · 2018-05-28T10:03:15Z

@matiaio
This is a known issue. See #18743 and why we closed that PR.

matiaio · 2018-05-28T14:09:42Z

so this issue it will be included into a new Joomla! update? or should i modify some php files in my Website?

matiaio · 2018-05-28T14:10:03Z

@infograf768

matiaio · 2018-05-28T14:12:54Z

@infograf768 i am asking again, because i never used github. sorry

infograf768 · 2018-05-28T14:59:47Z

#18743 was closed. It means that the specific code to solve your issue will not be included in Joomla.

[fix] Multilanguage: correcting custom fields display in function of

2ae0954

language

joomla-cms-bot added the PR-staging label Nov 2, 2017

infograf768 mentioned this pull request Nov 2, 2017

Custom fields in multi language website #18396

Closed

infograf768 changed the title ~~[fix] Multilanguage: correcting custom fields display in function of item language~~ [fix] [com_fields] Multilanguage: correcting custom fields display in function of item language Nov 7, 2017

joomla-cms-bot changed the title ~~[fix] [com_fields] Multilanguage: correcting custom fields display in function of item language~~ [com_fields] Multilanguage: correcting custom fields display in function of item language Nov 7, 2017

joomla-cms-bot added PR-staging and removed PR-staging labels Nov 7, 2017

infograf768 mentioned this pull request Nov 9, 2017

[com_fields] Multilanguage: fixing display of fields when the item concerned is set to ALL #18536

Merged

infograf768 closed this Nov 9, 2017

infograf768 mentioned this pull request Nov 20, 2017

[com_fields] Multilanguage: fixing display of User fields in profile depending on Active language #18743

Closed

infograf768 deleted the customfields_multilang branch November 24, 2017 18:12

[com_fields] Multilanguage: correcting custom fields display in function of item language #18474

[com_fields] Multilanguage: correcting custom fields display in function of item language #18474

Conversation

infograf768 commented Nov 2, 2017 • edited by joomla-cms-bot Loading

Summary of Changes

Testing Instructions

After patch

AlexRed commented Nov 2, 2017

uruk-hai-21 commented Nov 2, 2017

infograf768 commented Nov 2, 2017 • edited Loading

uruk-hai-21 commented Nov 2, 2017

infograf768 commented Nov 2, 2017

infograf768 commented Nov 2, 2017

uruk-hai-21 commented Nov 2, 2017

infograf768 commented Nov 2, 2017

rdeutz commented Nov 2, 2017

uruk-hai-21 commented Nov 2, 2017

laoneo commented Nov 2, 2017

infograf768 commented Nov 2, 2017 • edited Loading

infograf768 commented Nov 2, 2017

infograf768 commented Nov 2, 2017

laoneo commented Nov 3, 2017

infograf768 commented Nov 3, 2017 • edited Loading

infograf768 commented Nov 3, 2017 • edited Loading

infograf768 commented Nov 6, 2017

laoneo commented Nov 7, 2017

infograf768 commented Nov 7, 2017 • edited Loading

laoneo commented Nov 7, 2017

infograf768 commented Nov 7, 2017

infograf768 commented Nov 8, 2017

laoneo commented Nov 8, 2017

infograf768 commented Nov 8, 2017

ghost commented Nov 8, 2017 • edited by ghost Loading

infograf768 commented Nov 8, 2017 • edited Loading

laoneo commented Nov 8, 2017

infograf768 commented Nov 8, 2017 • edited Loading

laoneo commented Nov 8, 2017

infograf768 commented Nov 8, 2017

infograf768 commented Nov 9, 2017

infograf768 commented Nov 9, 2017

matiaio commented May 28, 2018

ghost commented May 28, 2018

infograf768 commented May 28, 2018

matiaio commented May 28, 2018

matiaio commented May 28, 2018

matiaio commented May 28, 2018

infograf768 commented May 28, 2018

infograf768 commented Nov 2, 2017 •

edited by joomla-cms-bot

Loading

infograf768 commented Nov 2, 2017 •

edited

Loading

infograf768 commented Nov 2, 2017 •

edited

Loading

infograf768 commented Nov 3, 2017 •

edited

Loading

infograf768 commented Nov 3, 2017 •

edited

Loading

infograf768 commented Nov 7, 2017 •

edited

Loading

ghost commented Nov 8, 2017 •

edited by ghost

Loading

infograf768 commented Nov 8, 2017 •

edited

Loading

infograf768 commented Nov 8, 2017 •

edited

Loading