🇺🇸United States @apmsooner

Weird that I can't even reproduce the error in config inspector but the patch isn't gonna break anything either way so merging it in and call it fixed. Thanks

Thanks for the patch. Since we're on at least php 8, how about we simplify to:

$value = $entity?->id();

This patch should resolve the fatal error and would output term properties on the custom field entity reference but any fields on them is still a work in progress. Just wanted to post something here as a placeholder that you may be able to get by with until something more complete is figured out.

Noting also that the Wunder patch referenced above is against the graphql module so do we address these issues there or within graphql_compose? It certainly feels at least graphql_compose is more actively maintained but leveraging functions from graphql which seem to be the source of the underlying issues we're seeing.

@almunnings, i'm assuming yes an abstraction may be favorable but also a behavioral setting to how a site wants to handle. I found in the Wunder starter kit that they also have their own patch (https://patch-diff.githubusercontent.com/raw/drupal-graphql/graphql/pull...) that is addressing similar errors but they are just returning NULL which wouldn't be the expected behavior for everyone. I think there perhaps needs to be an underlying global setting that determines if default language fallbacks should be returned everywhere applicable.

Hmm... yeah that is weird. Thanks for the patch, i'll just double check later today that i can reproduce the same warning and verify it fixes and I'll happily merge in. Appreciate the help :)

Working just fine for me!

apmsooner → created an issue.

I sort of know whats going on here but its gonna take some time to see if theres a viable solution. Again, I'd recommend familiarizing with twig and custom templates vs. this token display for such advanced requirements in the meantime. When I find some free time however, i'll see if i can get a patch up for you.

@jaypan,

Please comment here when you get some more feedback. I havn't had to a chance to test this issue as it would take some time to probably replicate your setup it sounds.

Thanks @justcaldwell, glad you're getting use from the module. A new release has been published that includes this fix.

apmsooner → created an issue.

Cool, thanks for the review. This setting works in conjunction with fences module but has no dependency or interaction with it. It basically does the same thing but at the subfield level so you can have full control over the output if desired.

There's a patch now in that issue ^. Just saving manage display wouldn't have resolved it. You would need to actually edit the field settings form in manage display and then save. There's essentially a new fieldset in the field settings there that allows you to set html wrapper tags and classes to the rendered output. It's similar to the fences module but of course for these subfields.

Oh, i see there were warnings in the logs. Just warnings to harmless but just the same, the patch just get rid of those. Ultimately resaving the field settings in manage display will also set the new values to config even if empty.

You should see something like this in config export for the field after resaving:

  field_custom_field:
    type: custom_formatter
    label: above
    settings:
      fields:
        title:
          format_type: string
          wrappers:
            field_wrapper_tag: ''
            field_wrapper_classes: ''
            field_tag: ''
            field_classes: ''
            label_tag: ''
            label_classes: ''

I rolled back to 3.03, added custom field and then updated to 3.1, cleared cache and rendered existing node, resaved, etc... but wasn't able to reproduce. Anyhow, i added a default value in case it isn't set for some reason so please try this patch against 3.1 and clear the cache and see if it resolves for you. Please report back so we can merge in or refactor if necessary.

Thanks for the confirm on wrappers. Subscribe to this bug and I'll get a patch up shortly to test out: https://www.drupal.org/project/custom_field/issues/3501250 🐛 Warning: Undefined array key "wrappers" Active

apmsooner → created an issue.

I'm unsure on this suggested fix. According to docs, renderInIsolation sounds like it should be used as a replacement for deprecated renderPlain(). In this case, it sounds like it could affect the #cache tags: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

The other issue is that renderInIsolation is was introduced in Drupal 10.3 so this wouldn't be backwards compatible. The suggested example for backward compatibility is here: https://www.drupal.org/node/3407994#comment-15540719 →

I'm no expert on layout builder nor caching as it can get a bit complex in these various scenarios but I just want to be careful to not break other things. I think lets keep the dialog open on this issue to help make a confident approach.

Well this is really odd cause I can't reproduce it but it's a safe fallback anyhow so I'll go ahead and merge it in.

I'll take a look at this over the weekend and see if I can come up with something. Feel free to provide more feedback if you discover anything new as well please. Have a look at https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/custom_fiel... as well for views. I don't know if something extra may need to be factored in for search api specifically.

Thank you for the patch and insight on the wrappers issue. The latter can probably be resolved with just saving the manage display settings as theres a new setting in there but I will resolve it anyway. I will try to get this reviewed and merged in the next day or 2. I know there are other similar deprecations for some of the other field plugins so i will want to take care of them all.

Thank you for the patch. I will try to review tonight and get merged ASAP.

apmsooner → created an issue.

Updated example.

Patch ready to be tested. Just set status to RTBC if its good.

Okay, i was probably thinking about the list options label. Follow this task and I'll have a patch for you: https://www.drupal.org/project/custom_field/issues/3498012 ✨ Add field label token for custom template formatter Active

apmsooner → created an issue.

@giuse69, as I've removed the confusing unused label settings as part of this ticket ( https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active ), as well as enhanced the ability to set the tags you want in the default formatter, I'm thinking any additional features right now for the inline formatter may not make a whole lot of sense. The default formatter with tag support IMO would give you the most flexibility and if you need anything beyond that, I'd recommend getting into customizing the twig templates to your needs.

1. Handling twig support in that field is something I don't want to do. If you're comfortable with twig, you can just copy the field templates from custom_field or even just have a higher level core field template in your custom module or theme that you can customize to your desire. This template formatter for custom field was never really meant to be a full on replacement for theming but more as a solution for simple output.

2. The labels are exposed in the token browser but if you're not seeing them, it may mean that you may have too low of a setting for recursion limit which the default in Drupal core is 3. If you are using paragraphs and such, you sometimes need to increase this to 4 or 5 maybe to get deeper into the tree. I've included a field that applies that in the advanced tokens settings for the custom template formatter that you could try modifying. Just know that increasing the recursion limit loads the tree slower.

Overall, I think going down this tokenized template route might not be the best solution for you and I'd probably recommend customizing your own field templates.

From what I can tell, it doesn't look like Drupal provides a way to translate display page settings. Might be out of luck on that one as I just don't see an option for that.

For #1, Are you translating the configuration page for that I assume?

Thanks, i just pushed up a fix for the extra space. Just get the latest patch and clear cache and should be good.

Other issues...
1. You're saying not the tokens themselves but the text you also put in there? Let me look into that for you as I didn't think of that issue honestly.
2. There are tokens for every label of subfield. It would be like this example: [node:field_testing:value:label]. In the token browser, you should be able to expand the subfield and see label.

ie explained format; [entity_type:field_name:subfield_name:subfield_label]

@giuse69, can you test the new feature in: https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active ?

I've also unset the non-applicable label display setting in formatters like inline. I will then provide a solution for hiding the label in next release to resolve this ticket.

Thanks

Patch available for testing. Recommend clearing cache.

In the formatter settings for the 'default' formatter. Theres a new details element labeled "Style settings" under each field. These settings allow to set the html wrapping element and add additional classes.

Thanks for all the due diligence in this review!

As for the other issue, i'm adding some optional html wrapper logic for the formatters similar to the fences module. In starting that feature, I realized the existing formatter logic was over complicating things and needed to be more like core with the way the plugins get instantiated so I'm simplifying/standardizing the apis on those for cleaner and reduced code.

Thanks for catching that. I've made revisions and ready to review again. Noted other places in the codebase will need similar revisions and those places should be limited to the formatter logic which I'm in the process of refactoring/simplifying logic as part of https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active . Mainly the BaseFormatter.php file handles some logic for entity references so I will take care of it there in that ticket so we can keep the scope of this ticket limited.

Please test patch.

Splitting the noted issue out into its own ticket since this one is already merged. New ticket is: https://www.drupal.org/project/custom_field/issues/3497244 🐛 Translatable subfield access logic not using correct entity object for conditions Active

apmsooner → created an issue.

@jurgenhaas,

..the custom field, which is not translatable, does not show

It seems to be the correct logic as is no? If there is no default language entity and you're creating a translation in another language, why would you want to expose a form field that is NOT translatable? Would the solution not to be just make it translatable? Otherwise, as soon as you create the translation in default language, it would replace values for any other translation anyway. In this case I would think you'd also have the "hide non-translatable fields" setting checked in the content translation settings. Admittedly, I don't think I've ever understood why that setting exists in content translation settings as why would you ever expose the form field in non-default languages if the field is NOT translatable. Maybe you can help me understand what I'm missing though ;)

I'm honestly not sure how the field value "has changed" logic is factored. I don't know of anything in the field api that determines that so assume perhaps theres something in ECA that is doing that evaluation. As for your sidenote in that comment, that shouldn't be the case in having to have a unique value. There's no conditions in the custom field module that require uniqueness. You could set multiple values with all the exact same values so not sure why that would be a problem in ECA rule. I really still unfortunately don't have experience with ECA though either. I guess I'd have to get a visual also of the use case for populating a custom field from tokens.

I don't know that we make that change. The dropdown field should never have been there honestly as it doesn't even make sense to possibly have an "Above" setting where the label is always supposed to be inline. I think we should definitely hide that field as it just won't make sense. We could possibly add another checkbox I guess for each subfield specifically for that formatter type. I think its probably not too common of a need though. I've got some other work I'm doing for formatters so let me knock that stuff out first and can revisit this request later. I think i'll change this category though to feature request as its not really a bug, the main setting works... it's just confusing to have the other one serving no purpose.

The only place I see "show labels" is for the "Inline" formatter. Is that what you are referring to? The subfield label settings for that aren't even evaluated for that formatter type and I should remove those. The "show labels" setting for that is the only thing thats evaluated. If thats what you're seeing, I'll update the logic to hide that unused setting in the subfields. It only really applies to the default formatter which is what is commonly used.

I'm not sure what you mean with the general option of "show labels". I don't know of that setting. Are you referring to the Label display field in the manage display page for each field? That setting is specifically for each subfield whereas the other one I think you are referring to is for the main field itself. For instance if you have a custom_field called "Contact", the main label dropdown is for that label whereas the subfield labels might be related to for example: Name, Phone, E-mail, etc...

Thanks for all the help in testing this. Please follow this other new feature that I'm working on if its of interest to you. I'll have something to test for it soon that I would appreciate your review: https://www.drupal.org/project/custom_field/issues/3496708 ✨ Formatter wrapper tags, classes, etc. Active

I havn't tested for that behavior. Do other fields work that way with paragraphs? I would think the overall field value would kick in that way but not 100% for sure I guess.

I made the subfields default checked because if the field itself is marked translatable then its assumed at least one of the subfields should be checked or else you're gonna end up with just a field label and some undesirable behavior if the field is also required. But I can reverse that default and force the administrator to make sound decisions on the settings. And yes, i think the proper behavior is to also sync on translation save to inherit default language value if a field is untranslatable. That way if you needed to do a bulk update on entities, the behavior would be consistent across all translations. I just updated patch if you want to retest. Once you let me know its good, i will merge into dev. Thanks!

I think now it just behaves like core does so it can be assumed that the box being unchecked means the same as core which is values will sync from default language. In my testing, the value will sync from default entity value only when the subfield is unchecked. It will sync on default language entity save and translation entity save but the translation entity save will NEVER overwrite values on the default language entity. I could add help text to the field that explains this but core doesn't have that and I don't want to clutter up the form more if it's generally understood. Let me know if you think it is indeed necessary and can do that. Also, were you able to test the patch and verify it works as expected now?

The attached patch SHOULD work for you but answer the question above as I made the assumption in the code that we would just always set value from default language if the subfield is marked non-translatable (even if it has preexisting value). Let me know please. Thanks!

I think i've got the logic worked out in a presave hook now that syncs the values. I have a question though, if a subfield is unchecked for translatable meaning the field won't be displayed in non-default languages, should we ALWAYS copy and set the value from the default language? What if the subfield was at one time checked as translatable and has an existing value, but then later you uncheck the box and its no longer translatable. When saving the default language entity, should we override the existing value when it was translatable or retain it? I'm thinking we should maybe override it always but wanted to get your thoughts.

Okay, thanks for the additional info. Let me see what i can come up with.

apmsooner → created an issue.

Yes, thats how core fields work. When you create a translation, the entity is cloned from the default language. I'm not sure the best way to resolve the current situation other than just unlocking the ability to edit the translated fields, setting the values and then locking back up. Paragraph entities can get really tricky with multi-lingual but as the node is cloned during translation creation, so are the paragraphs (assuming they are also marked as translatable) and their fields. Once the translation is created for the node, you're pretty much locked into it as a separate node. If this makes sense and sounds like the issue, let me know so we can close this bug as I really believe the way its coded is in line with how core fields work.

I tested this before the release and I tested just now and I'm not able to reproduce. I marked 2 subfields as "non-translatable". Created node in english with the set values and then created a spanish version of the node where the 2 fields were hidden. I checked the database and the spanish version indeed shows the english records as the values. I'm not sure if maybe you have some different language settings or permissions or something but I don't know how to help since I can't reproduce.

This new feature is available now in 3.0.3 release.

This is good to go. I'm merging it in and creating a new release as the last one had a minor regression bug that broke the preview in image widget.

@giuse69, see attached screenshot for what i'm thinking on this. The checkbox would be visible if the parent checkbox on field is checked. Question I have, should the default state be checked or unchecked for new fields? I'm thinking unchecked to keep in line with how Drupal normal fields work.

There's nothing I can do to fix this. There are so few sites on 1.x/2.x that its not worth my time to put forth the effort and I've marked 2.x as no longer supported due to such significant changes in Core dependencies. As I said, 3.x has been available for quite some time and many have upgraded from 2.x (including myself) without issue. I can only suggest updating in smaller version steps to get to a point of successful update. Otherwise, you can patch your own site by probably just removing the EntityReferenceNormalizer file and service declaration (see custom_field.services.yml) to get past the error and than add it back in.

Add viewfield and hierarchical select.

Add viewfield.

The translations are working just fine in the widget as well as the formatter in my testing. The widget now supports views to control the 1st level of hierarchy although in most cases, the default formatter should be sufficient as we're only fetching the terms for each level to help with performance.

The 3.x version has been out for quite a while and 2.x should be able to update to it. Seems like a couple cache clears should get the service.yml recognized with the arguments being passed in. Perhaps make sure you've updated to the highest minor version of 2.x for this module and highest core supported and run all updates. Then maybe try 3.x. Otherwise, not sure how to help you as i can't really support 2.x anymore with so few users on it at this point and such differences between the versions.

This is first draft if you want to test out the patch. There's a few hardcoded styles just to get something visually appealing that I'll refactor but functionally... I think it's working really well. In the field settings, you'll see the new "Hierarchical select widget" as an option. Just use the default reference method for now as I haven't looked at the views option. There will be a couple extra settings at the bottom of the form:

- Force deepest level
- Show level labels

I think the descriptions are self explanatory. Try it out and let me know how it works for you. It should support multi-lingual and work fine in paragraphs as well.

I'm not going to integrate with SHS module. I don't particularly like the limitations with a single bundle requirement and I think theres a little too much going on with the approach not to mention the number of unresolved issues is concerning to me. I think I can create a much simpler alternative that serves the same basic need. Stay tuned.

Try the patch and let me know if that works for you.

apmsooner → made their first commit to this issue’s fork.

Marking fixed as these issues are addressed and fixed in this other ticket. It will be included in the next release: https://www.drupal.org/project/custom_field/issues/3492977 ✨ New subfield type 'Viewfield' like viewfield module Active . Feel free to test that new feature if you like introduced in that ticket.

apmsooner → created an issue.

Update