🇺🇸United States @apmsooner

apmsooner → created an issue.

This ended up being a non-issue after attaching the actual library needed.

The problem is here: https://git.drupalcode.org/project/eca/-/blob/3.0.x/modules/form/src/Plu...

The element types are hardcoded and we have some custom ones to work around the core datetime elements that have bugs and inaccurate html in their templates. I've posted to eca channel in slack to see if theres a way to get other element types recognized.

In the eca interface, i set this as the field name: field_card[0][start_date][value]

In that file above, I locally added 'custom_field_datetime_date' to the switch statement with other dates and it works. I don't think Jurgen would want to hardcode all sorts of other element types though as a fix so need to see if there's some other ideas to best handle.

The help text is misleading:

The input name of the form field. This is mostly found in the "name" attribute of an form element. For submit buttons within content forms: Use "submit" for the labeled "Save" button, and "preview" for the labeled "Preview" button.
This field supports tokens.

If you have a subfield named 'value', it works fine to set a value that way from the input name but any other property name doesn't work. This leads me to believe there is some sort of implication in the ECA logic that assumes everything has 'value' has its main property perhaps. I'll reach out to Jurgen and see if he can advise further.

It's stored the same as your example (2023-03-01T00:00:00). I don't quite know how ECA's setting of the default value works with the form widgets. It seems to work fine on setting a simple string value but not really sure the difference with the date field widgets and the ECA input. I'll research further but I don't have an answer for you now other than to confirm the datetime is being stored just like standard fields.

Honestly, you might get better support in the ECA slack channel for this. I just don't really have enough of my own resources to know the ins and outs of other module setups and that one is a bit complex.

I honestly don't have enough experience with ECA to reproduce this. If there is config you can share or screenshare perhaps that depicts the setup, I will try to replicate and help you.

Thank you for testing.

I can't reproduce your issue and not sure I understand the modified code fix screenshot. That doesn't match the actual patch here: https://git.drupalcode.org/project/custom_field/-/merge_requests/192.diff so not sure if you are doing something in addition to the patch or what but the code is definitely working on my end for the fallback value. Maybe reapply the patch and clear cache or something and make sure you don't have any manually modified files in the module.

I tested your suggestion and it does improve the selection flow without error so I'll open an MR for this to resolve. Thanks!

I'll look into this as an improvement. The datetime type expects a string so I assume you're typing the key instead like 0, 1?

No, they are supposed to be used if they are set. I just tested again and verified that myself. Can you shared screenshots of exactly where you are seeing this?

You need to edit the field in: /admin/structure/types/manage/{e.g. article}/fields

The field settings section at the bottom has all subfields field settings. Are you saying the one for image there doesn't have that particular field but has the others? I assure you its there, I'm looking at my own settings and see it there. Without a screenshot of the actual custom field settings or specific details of your setup, I really can't help you. You can also ping me in the #custom-field slack channel and we can more easily share details. Drupal.org is unfortunately awful for sharing images and such.

Its in the field settings section at bottom where you added the fields to the entity type originally. I don't really know what else to tell you. It's definitely there and I have no idea of your setup as you seem to be showing a screenshot of some other image settings form.

We have no such functionality of "folders". Maybe you're expecting something from this module that we don't integrate with: https://www.drupal.org/project/media_folders → or some other module but otherwise I have no idea what you're referring to.

Thats really not enough info for anyone to help you with. I'm assuming maybe you're not seeing the tokens under 'File' and thats not a bug with this module but rather a default recursion limit on the token browser of level 3 that won't let you go any deeper. There is a 'template' display formatter for the field type that has options to increase the depth where you can see deeper nested tokens just to get a view of everything.

apmsooner → created an issue.

Try the patch which makes the form element labels in display optional and therefore use the field settings label (which is translatable) as fallback. Let me know if this works for you.

I wonder if for now I could look at making the label optional in the form display settings so it uses the fallback from the field settings form which is translatable?

Ahh, I think I understand and it seems this is a known limitation that is a work in progress in Core here: https://www.drupal.org/project/drupal/issues/2546212 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review . I havn't tested the patch. Which version of core are you on?

I'm not sure what you mean. Are you asking how the flexbox dropdown options would get translated ie; "1 column", "2 columns", etc..? If so, those would be handled in the /admin/config/regional/translate section. You would need to enable interface translations module. Id that doesn't answer your question, please provide more info or screenshare perhaps because I'm unsure of what is missing for you.

The manage form display settings label takes priority over default label. You should set that translated value and expect that for the form element label. Can you verify that works for you?

A little bit of cleanup but otherwise, works well and merged. Thanks!

Calling it good and fixed.

Thanks for the fix. FYI, next time you can also set the status on these tickets to "Needs review" and the maintainers and others will know its ready to be tested. It's merged now.

Yes, thank you for the contribution.

Yeah its a little tricky to even try to plugin it into UI patterns and generally I don't think we need to with our own SDC formatter because the data would pretty much already be structured on its own and in most cases wouldn't really need to be bundled with other fields to make a component but even if you needed to, you could just pull the whole field in like now. UI patterns is basically operating at the entity level and combining fields to make a component and with custom field, we can just go deeper into the properties in what I "think" would be simpler and certainly more performant way.

@mortona2k,

Those other modules only work at the field level so while you can use a whole custom field rendered value in a slot, those modules can't do anything at the property level as they are unaware of the subfield formatter plugin system. An SDC display formatter for custom_field module means you could set specific sub-fields as slots. It basically means we can treat the field itself as a component source vs. an entity like for example if you were alternatively assigning fields from a paragraph entity into slots.

apmsooner → created an issue.

This patch should do it. Please review.

Ahh, yeah you're right. Looks like we need to add a custom #element_validate to the formElement() in CustomWidgetBase.php similar to what they did for the media library widget: https://www.drupal.org/project/drupal/issues/3160238 🐛 Media Library widget produces "This value should not be null" error when field is required Fixed

Added an extra test for a daterange subfield that has extra columns to ensure no exceptions will be thrown with the additional logic for looping through all the schema columns.

apmsooner → created an issue.

No problem and thanks for the confirmation! Ultimately i need more test coverage to catch these issues but I just havn't had a chance to get it all done.

FYI, I also opened a core issue that your team might be interested in for making custom fields more viable for larger scale projects if you're interested in following/researching: https://www.drupal.org/project/drupal/issues/3562484 →

Thanks

Hey there, i'm not ignoring this. I'm just a little busy with other priorities but just wanted to let you know I should be able to get this into next release when I get a chance to review/test.

Thanks

This was already resolved in https://www.drupal.org/project/custom_field/issues/3559626 🐛 TypeError: Unsupported operand types: null + array in Drupal\custom_field_linkit\Plugin\CustomField\FieldWidget\LinkitWidget->massageFormValue() Active . Update to latest version and you should be good to go.

apmsooner → created an issue.

apmsooner → created an issue.

Gin extends claro and the issue is also in Claro but the problem isn't paragraphs in this case. I think the problem turns out to not be fixable. A details element within a table cell can break out of the table cell in narrow regions cause the browser doesn't know how to size the details element when its expanded. My suggested fix worked in chrome but not in safari & firefox. I'll double check the issue you referenced but I'm pretty sure there isn't a fix for this unfortunately.

Okay thanks, I will close this issue then and wait for these modules to mature a little more. I appreciate the support.

Thank you for the confirmation and all the great feedback! A new release will be going out over the weekend so look out for that and now that you're on 4.x, you might dig deeper into all the new features related to date fields as well as the new daterange field. There's some pretty advanced functionality in the widget/formatter settings you might find useful :)

AI core 2.0 still has it's own field_widget_actions plugin which is why I was asking. See: https://git.drupalcode.org/project/ai/-/tree/2.0.x/modules/field_widget_...

This fix doesn't quite work in other browsers like safari. I still think its the right fix in part some additional styling perhaps in outer wrapper may need a 100% width set or something.

@swentel, are you still able to test this out today? I would like to put out a new release over the weekend and while i'm pretty sure I've fixed this bug, you're testing would instill some additional confidence. Thanks

apmsooner → created an issue.

I'll take a look at this when I get a chance but for now I'll need you to resolve all the coding standards warnings: https://git.drupalcode.org/issue/custom_field-3550507/-/jobs/7556727

Closing this as it's already now supported in the custom_field module as of 4 months ago. Anyone needing this can just install latest version of custom_field.

I assume the 'multiple' property you are talking about is somehow here https://git.drupalcode.org/project/ai/-/blob/2.0.x/modules/field_widget_... but it's only mentioned in the comment. I'm not sure what exactly this means nor do I guess I understand why there is still a field_widget_actions sub-module under ai and which to use? I'm doing my best to follow the intent around all these modules but I'm honestly pretty confused with whats doing what. It would be helpful to have a real example of a multi-valued field widget action with single button as I believe it should be by default. Otherwise, it just seems like something that is not supported.

Thanks for the response. None of those examples actually show a multi-valued field unfortunately. The tags input in that example is still a single form element. Based on what you're saying, it sounds like the default behavior needs to be overwritten in the plugin to make it work. I'll have to see if this actually works how I'm expecting after I look through the code and see where this is set.

The issue is fixed in https://www.drupal.org/project/custom_field/issues/3558244 → but is only going to apply to the 4.x version which i recommend you update to as 3.x is no longer going to receive updates. A new 4.x release will also be coming end of week if you wanna wait it out.

Noting that I didn't touch existing enhancers that ship with the module but it would be my recommendation to apply the 'field_types' attribute to the ones that only make sense with certain types (DateTimeEnhancer, UrlLinkEnhancer, ListFieldEnhancer) for example.

No problem, and since you tested and confirmed the other patch worked for you I went ahead and gave you contribution credit. Thanks

Try the fix here: https://www.drupal.org/project/custom_field/issues/3558244 → or the dev version where the fix has already been merged. I believe that is likely going to address your issue.

Added screenshots for before and after. Note that its prevalent issue when content region for the form is narrower than normal as in the case of when screen is resized and/or additional elements take up space like vertical navbar or when fieldgroup module is used to wrap fields in vertical tabs.

apmsooner → created an issue.

Okay @swentel,

1. I had to move the logic out of 8005 to a new update 10003 as it needed to run after 8007 which added the extra __timezone column.
2. I refactored the addExtraColumns() function to support multiple instances of the same subfield type on a field so now the db truncation/restoration only happens once.

I've tested this with multiple datetime subfields on various custom fields on multiple entity types with varying cardinality and the updates now do what they are supposed to and data is restored properly. You should be able to update now to latest 4.x with this patch without issue. Please let me know how it goes and thank you for all the feedback!

I modified the patch slightly as the linkit attributes should have been merged in outside the other attributes as they are only needed for a linkit formatter that we don't even use but either way, the issue is fixed and merged into dev. Thanks for the report and followups.

Ahh okay, thanks for the additional info. I will spend some more time on this today and see if I can come up with an actual fix then. Adding/removing columns to fields has always been a black hole of trial and error for alot of devs but I'll figure this thing out soon.

Okay, thanks. It's an easy fix so I will merge this in today when I get a chance to test myself.

Hi, please try the patch in this issue as i think it might already be resolved: https://www.drupal.org/project/custom_field/issues/3558244 →

And actually step 1 can be: ddev composer require drupal/custom_field:3.1.13 cause the next field update is in 3.1.14 where the conflict is happening.

@swentel,

Theres a weird thing going on between the updates that's causing 8005 to fail when the other updates try to run. I'm not really sure how to fix them so they run in sequence so the only immediate solution I can provide you is to first just install the update for 8005 which is in version 3.1.8 and then you should be able to advance to the latest 4.x version and run the additional updates without issue.

Steps assuming you have ddev installed locally but you will need to deploy each step separately

1. ddev composer require drupal/custom_field:3.1.8
2. ddev drush updb
3. ^ installs update 8005 only
4. deploy
5. ddev composer require 'drupal/custom_field:^4.0'
6. ddev drush updb
7. ^ installs all other updates
8. deploy

Let me know please if this gets you past the issue and I'll note this for others. I'm not sure otherwise how to prevent the failure and want to make sure you can at least move forward. Thanks

apmsooner → created an issue.

Hey there, thank you for the patch. I will review, test and merge over the weekend. I appreciate the contribution.

Thanks for the report and testing.