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.
I fully support the purpose of this module: when having a lot of fields, the core drupal approach without coding is to add one table per field and this has a significant impact on performances on large site (also making the DB not manageable with hundreds of tables), and using caching mechanisms is a workaround and need (a lot of) storage. To retrieve an entity, joining N tables is much slower than retrieving N columns from the same table in relational database, even if the N tables have indexes
So the possibiity to add common fields as properties to the base table is very useful.
Thanks to the maintainer :)
Hi, I am referring not only to the default value but in general to the list values. I explain in more details:
- create a new custom field with a text "subfield"
- now edit the custom field for a specific content type: in the edit tab set it to translatable
- then select the type of the subfield and choose "select list" or "radios"
- then create some key/value options in the settings
Now I expect to be able to translates those keys and values into other languages but I can't in the "Translate content fields" tab neither going to the configuration/regional/content-language menu.
Have I been more clear now?
thanks a lot for your prompt feedbacks :)
Giuse
Thanks a lot @Andril, very clear! A question: having the values specified of a list/radio/selection specified in that way, make the options labels not translatable?
I am very interested in this module since it seems the only that tries to finally overcome the Drupal 7+ DB choice of having one table per field, that for many (> 1000) entities with tens of fields each not sensible...
There are very interesting possible extensions of this module:including entity reference - I've seen that there is already an open task -, using a view to extract possible labels/values, and so on...
So I am following :)
cheers