hi apmsooner, I was checking daily this thread so this update is welcome.
I can confirm that with the patch I don't get the fatal error any more, but as you say, fields values with deep reference are still not shown.
Thanks
Ok, I will wait for a possible solution :)
thanks!
works! thanks
About #2, I can confirm you that I can't see any token for the subfield names, even with 5 levels depth. The practical example: a paragraph with a custom_field "CF" with a integer select list subfield named "status" that has value = 0 and label= "NO".
Here are the tokens and their outputs:
[paragraph:CF] =>
status
NO
[paragraph:CF:status] => 0
[paragraph:CF:status:label] => NO
[paragraph:CF:status:value] => 0
so no token contains the string "status" that is the name of the subfield (except for "paragraph:CF" but that contains all the custom field, not just the subfield name).
With the basic template, [status:label] outputs "status" as needed.
Any idea?
thanks
Hi Andy, for #1... ok, Drupal effectively does not allow to translate display settings so my request is not easy. maybe allowing twig support in the template? That would greatly enhance flexibility of the advanced template, also enabling translation.
About #2, I mean the labels that represent the name of the subfield, not the labels/values corresponding to the raw values. I didn't find any token for the names of the subfields, the same output obtained with [:label] with basic template.
Hi Andy, it works for me with just a small typo: when the label is shown when using the default formatter, an extra space/blank is added before the colon, like "label : value".
As a side note not directly related to this issue but to the formatter in general:
-) the custom formatter cannot be translated and it should be since we can write words in the template (both basic and advanced).
-) in the advanced template, I couldn't find a way to show the label of the subfield (I found no token for that), should it be added?
Thanks
Giuse
Yes, sorry I didn't say it earlier: it's in the inline formatter. I'd like to be able to show the label of a subfield and not the label of another one, so I'd prefer that the subfield labels are evaluated instead of the general one.
Hi, there are 3 places in Manage Display about showing labels:
1) the label settings for the overall field => no problem
2) the "show labels?" settings in the format of the overall fields - this is the one that is used to display or not the labels of ALL the subfields
3) the "label display" setting for each subfield, and one of the possible values is "hidden".
Now the problem is the inconsistency between the values of 2) with the values of the 3)s.
is it more clear now?
thanks
You are right: other fields have the same issue with paragraph, so it must be a paragraph issue.
For me this MR is ok!
have you seen also #15 🐛 Subfield translation option - behave as core Drupal fields Active ?
Also: when creating a translation for the first time, translatable fields values should be filled in with the values from the default language entty (now they are empty, at least in a paragraph).
Just a small problem: as default, "User may translate this field" is checked for subfield, it should be unchecked.
Yes, it works!
You can avoid adding the help text, as drupal core does not say it either.
Just a question: you sync also on translation entity save otherwise hidden&translatable fields would be overriden...? Hidden&translatable fields cannot be altered in non default language form, so I was wondering why you sync them, but probably it's necessary as well :)
Hi, I think the presave should be applied when we are in the default language, not the opposite: untranslatable fields are edited only in default language, when the new value must be synchronized to all translations; current implementation requires the user to edit each translation to have the new values applied to the translation itself, while it should be immediately synchronized when the default language entity is edited.
About overriding, I agree with you that is better to always apply it, you might add a warning in the form that changing translatable state to NO after having inserted values will propagate the value to all versions.
cheers and Happy New Year
Hi, non translatable core fields actually have a different out-of-the-box behavior: they are modified in a single point/record and their value is shown in every language.
When this is applied to a custom field subfield a big issue appears: when the macro-field translation is created, the value is copied into the translation but if the value is later changed in the default language, the translation will keep showing previous value that is wrong.
For me this is a blocker issue to use this new feature of custom field.
Maybe a hook to replicate non translatable values / hidden values to all translations whenever custom field is edited in the default language can be a solution?
thanks
You are right Andy, with a situation starting from scratch it works. Instead, I made modifications to a paragraph that contained a custom field adding another custom field, setting values to the second one, translating, then removing the previous one, etc.
In summary, I am now in the situation where editing a translation, the untraslatable subfields consistently are and remain NULL.
I don't know if I can exactly reproduce the steps that led to having null values in the untranslatable subfield of the translated custom field, sorry.
What is sure is that when a subfield is set to NULL and is not translatable, then following edits of the macro-field leave it as NULL: I think that is "normal" since the untranslatable subfields are set just in the creation of the translation and not checked/reacquired in editing, correct?
Hi @apmsooner, well, imho there is no direct comparison with normal Drupal fields since it does not have (unfortunately) subfields.
I think that if the "user may translate" option is checked, means that the overall custom field is translatable, so maybe checking also subfield is consistent, then the admin may uncheck some subfield is the translation applies only partially (i.e. to some and not all subfield).
So I am thinking something like the following:
-) first load of the form: nothing is checked
-) the admin checks overall translation => automatically all subfields are checked as translatable.
-) the admin unchecks some subfield => no automatic action occurs
-) the admin uncheck overall translation => automatically all subfields are unchecked, to keep the situation consistent.
How does it sound?
thanks for keeping on improving this module
You're great! It works with a couple of issues:
- language translation of taxonomy terms with Hierarchical formatter seems not to work here (always taxo term in default language is shown) but I think it's a problem of the formatter and not of this thread.
- when used with flexbox formatter (not stacked), the series of selection boxes have a white space below the label that is not present in other subfield (like a select list) so the selection boxes are not aligned.
cheers
Giuse
works for me!
thanks
In Administration > Configuration > Region and language, you can set a vocabulary as translatable and de-select the name as a translatable field, leaving other fields translatable. Why do you say it is not possibile?
That is useful for example for acronyms, where the acronyms itself must not be translated, while its long form and description are translatable.
Hi, this is the complete scenario:
-) a content type with a paragraph field (entity reference revisions with reference type = Paragraph). This content type is set to Translatable while the paragraph field not (as required).
-) The paragraph type has a non translatable field and a translatable field - just a plain text field, let's call it "para name".
Now:
-) if I uncheck "Hide non translatable fields" in the content type => all fields appear when translating the content type. Correct.
-) If I check "Hide non translatable fields" in the content type => nothing of the paragraph appears when translating, neither the "Para name" sub-field. Issue.
If you need more details or tests, I am available.
thanks
Giuse
Hi Andy, will you explicitly write here when the patch is ready for testing?
works for me, thanks
Hi Andy, I try to re-explain.
Scenario:
- an article ART which has a field paragraph P, P IS translatable
- P has two fields:
- a custom field CF in P, where CF is NOT translatable
- a subfield SF in CF that is an entity reference field to a taxonomy term.
- an entity reference field ER to a taxonomy term (exactly the same as SF).
- taxonomy terms ARE translatable and have translations.
Now let's display ART:
- CF is displayed with the taxonomy name always in the original language - WRONG
- ER is displayed with the taxonomy name in current language - CORRECT.
So the same entity reference field is not being translated when it is used inside a custom field.
That happens in custom field not only using advanced template as formatters but also using default formatters.
Have I been able to explain the issue more clearly?
If you have questions, do not hesitate.
thanks again
Ok, I will wait. Let me just add that, as I wrote in
https://www.drupal.org/project/custom_field/issues/3476033
✨
Support not just values in custom template
Active
, for me the issue is not on subfields but on the custom field itself: when I try to use a custom field in a view of taxonomy terms in a multilingual site, it never works correctly: either it does not show anything, or it throws a PHP error, or it messes up the query and unrequested taxonomy terms show up.
While if I use directly its subfields in the view, the result is correct, just without the chance of selecting tokens or formatters.
Thanks for your precious work
Sorry since I made a mistake in the description of the scenario:
- the paragraph IS translatable
- the custom field in the paragraph is NOT translatable (since it does not have to be translated because...)
- ...the sub-field in the custom field is an entity reference to a taxonomy term (here's why is not translatable)
- the referenced taxonomy term IS translatable and HAS translations.
Effect: the referenced taxonomy term is not shown translated.
I find it wrong since if I use directly an entity reference field instead of the custom field with the entity reference inside as a subfield, the translation works.
thanks
Hi, thanks but I am referring to another case:
- the custom field is in a paragraph type that is marked as non translatable, since the user should not be able to translate it;
- the subfield of the custom field is an entity reference to a taxonomy term that IS translatable and has translations.
The custom field in the paragraph should show the name of the referenced taxonomy term translated in current language, instead the name in the original language is always shown.
Could you please confirm the issue in this case?
thanks
Yes, but CSHS does not fit for large taxonomies since it loads all the vocabulary terms and send them to the browser, the selection does not involve ajax loading while navigating the hierarchy.
giuse69 → created an issue.
By the way, if the machine name of the field is long ("field" è 21 chars) => the table for field revisions si created with a wrong name, like "taxonomy_term_r_19e0ilkckkfulo"
Hi, I had cleared the cache. The scenario is as follows:
-) one vocabulary "country"
-) another vocabulary "area", where there is a custom field "items" with unlimited values. Its subfields are: "item" that is a reference to "country" and "inclusion" that is the type of inclusion of the country in that area.
-) a view on country vocabulary to show in which areas a country is. Contextual filter = term id, relationship = "Relate each Taxonomy term with a field_area_items_item set to the taxonomy term".
-) Showing field "Taxonomy term: Items" gives no output and there is no PHP error - first problem.
-) Showing field "Taxonomy term: Items:inclusion" throws PHP exception "Uncaught PHP Exception InvalidArgumentException: "Field field_area_items is unknown." at /web/core/lib/Drupal/Core/Entity/ContentEntityBase.php line 616" - second problem.
Let me know if you need more info.
thanks
Giuse
hi, so far patch 74 does not work throwing php exception of field unknown
Hi, the issue is not about subfields, It is for the overall custom field when used in a view for taxonomy terms with relationship. i hoped my last description was clear about that but maybe not.
Anyway ok for a new thread but the issue is differenti, let me know if I can change the title/description of the new one or you want me to open another one.
Cheers
Hi @apmsooner, I made a new and simple test with a clean scenario to describe how you can reproduce the issue. I don't think it's an edge case.
2 Vocabularies
VOC1: country
VOC2: organization with a custom field "items" to include countries belonging to the organization, subfields are:
-) "item" = entity reference to taxonomy term - country
-) "type= a string for type of participation to the organization
View
A simple view on taxonomy term country to show how many orgs the country belongs to
-) Contextual filter: Taxonomy term: Term ID
-) Relationship: field items of organization (Taxonomy term using field_organization_items_item)
Fields to be shown:
-) Name (of the organization) using the relationship
-) Subfield of the custom field items:item
-) Subfield of the custom field items:type
This works. BUT if I use the overall custom field Items (default or any formatter) instead of the two subfields, nothing is shown.
Could you please look at this?
thanks a lot!
@apmsooner: you are right, the views subfield issue is not important and I can use the overall custom field, but I can't make the overall custom field work in a specific scenario: a view on taxonomy terms where the custom field is multivalued and each instance includes a text or integer subfield AND an entity reference subfield referring to taxonomy terms as well. The view uses a relationships to connect terms of one vocabulary to terms of another vocabulary.
If I pick up individually the two subfields to be shown in the view, their raw values are correctly shown (and no choice of formatters but no problem as you say).
If I pick up the overall custom field, nothing is shown, even with default formatter. If I set the custom field to use the relationship, all related terms are shown (too many records as the join wouldn't be working correctly).
I made this test several times and on a couple of views of this type with same results.
Anything I can further test or you can check this particular situation?
thanks!
With the new fix, it works for taxonomy in entity display, but I still don't see the formatters menu choice to appear in views when picking a subfield as field in the view
it seems to work great when the custom field is belonging to a node, it seems not to work (no token avilable) when the custom field is belonging to a taxonomy term, maybe it needs to be extended to taxonomy?
ok, the usage of formatters defined in the subfield definition is infact a cross request, see also https://www.drupal.org/project/custom_field/issues/3473418 ✨ Subfield types list_string, list_integer Active
yes, I am available to test when ready
Hi, it works great as a formatter in the Display of an entity - thanks!, it does not appear when the subfield is used in a view.
cheers
Ok, I hope this feature request can be implemented since I am using extensively Custom Field and where there are taxonomy term references that need to be displayed in their hierarchy path, I cannot use the Custom Field :)
thanks a lot in advance
cheers
Hi, yes, the approach for images adding new tokens seems very good to me. Besedes references, also select list should be added to display labels isof values.
thanks!
Hi @Sourav_Paul, additional fields to a taxonomy term are correctly hidden in the translation tab/form. Just for my understanding, what you found is that the problem lies in a part of Drupal that you cannot fix?
Hi, and at least having the option of displaying the label of the (sub)field instead of its value (so something like a formatter option that reads the labels from the settings of the custom field) would be possible?
thanks
I updated the module to RC4 but I can't seem that it is solved: I created a subfield (in a custom field) with integer as storage and labels mapping in the form for the different values.
The display and the form display are correct and show the labels instead of the integer (but it was like that already in RC3), in views the integer value is displayed and not the label.
Anything I have to configure specifically for that?
thanks!
Giuse
You are right, it was a problem on my side. Sorry
I am also very interested in this and available to test when the patch is ready
ok, thanks EVA is another option but... it's a contributed module with 32 open bugs... I have been a Joomla site builder for 15 years and had to complement it with a CCK to have the needed features for sites that are not just blogs... And I suffered from usual problems of additional components: compatibility issues when the core platform evolves, long term support not guaranteed (especially if open source) and so on.
So I am evaluating Drupal for a possible switch but using only long-term components, so the core and the few very popular contributed models that have a long history of active development and are well backed up by maintainers, I wouldn't start a new adventure relying on additions that maybe in one year do not work anymore with next versions of Drupal since they are abandoned.
ok, so the solution seems to me: if a content type needs to display a view of related entities, do NOT use the content view (display view) for it but use a view (even for a single content instance) since the view can pass arguments to another view to show related entities.
Am I correct? thanks!
Hi Jaypan and thanks, could you please elaborate on that? The generic scenario is the following:
- N parent entities;
- N*M children entities, where each child points to its parent with a reference field;
- a view of children to be filtered to display only the children of a specific parent.
The problem: how can the view receive/get the id of the parent which is being displayed to add/attach the list of children
- using just core Drupal
- without having to add another reference field to the parent to store the parent id and then pass it to the view, since the display of the parent is aware of its id and so there should be a way to let this argument arrive to the view so that the view can filter just the related children?
Thanks again
Giuse
Hi Ressa and thanks, actually that's what I did: I put a reference field in children pointing to their parent and setup a view of children. The contextual filter of the view needs to receive the id of the parent and here I'd expect that there is a way for the parent to set a field that invokes the view while passing it its own id automatically.
Instead, the only way I found is to add a reference field to the parent and to set its value to the id of the parent (so twice the same value in every entity) to be saved individually for every instance of the parent... That is not being able to invoke a view with a dynamic value (e.g. using tokens).
I don't know if I explained it better now.
thanks :)
Giuse
I am available for testing but I am not a Drupal developer, sorry....
ok... but instead of error 500 we should get an error in admin syaing that, don't you agree?
cheers
thanks
Yes, the new version fully works!
For naming alignment, in the main edit form (not the translate one), "key/value" should be replaced with "value/label".
Are you going to make a rc5 release?
cheers
Giuse
I applied the patch (changed the type "string" into label) and now a for for translation does appear in "translate content fields" but with 3 problems:
-) I think the naming should be changed: current "keys" are what are written into the DB so maybe they should be called "values", while current "values" are the labels that appear in the front end and are translatable so probably those should be called "labels"
-) the translation is too deeply nested: custom field settings > settings > custom field > settings > settings > allowed values list > allowed values list > value
-) some texts are not translatable: the label of the subfield, the help text of the subfield, the empty option string of the subfield
I am available for further testing of this very useful module.
cheers
Giuse
Hi, with the fix the fatal error does not appear anymore but using this module on a custom entity type (created with ECK) still does not work:
-) first time that the status module is enabled in the configuration / content authoring, after hitting save the select base route radio options disappear.
-) saving again the select base route re-appear (first problem).
-) clicking on the "manage base fields" does not open a page to add custom base fields but redirects to ECK administration page where you can just enable/disable the standard base field.
thanks
Giuse
Maybe I'm saying something stupid since I am not a Drupal programmer, but would it be possible to define the text list fields as lists at the beginning of the process instead of later as "formatter" so that Drupal intercept the labels as translatable?
just my 1 cent :)
When defining a standard "list (text)" field, you set the labels/values options and labels ARE directly translatable in the "translate content fields".
In custom_field module, defining the sub-field just as text and setting it to be a list, makes the labels (keys in custom_field module) not translatable. This is the issue I wanted to raise.