Reviewed and confirmed good by @nicxvan so merging.
Fix is applied to: https://www.drupal.org/project/custom_field/issues/3542508 📌 Migrate .tokens.inc to OOP hooks. Active
apmsooner → created an issue.
apmsooner → created an issue.
Okay, that makes sense. We can perhaps add setting to handle this and maybe its possible with #states or custom js.
This is already supported. Just go to the form display settings and change the wrapper to details and uncheck the box "Show open by default?"
apmsooner → created an issue.
Looking at the LoadEntityRef action plugin here: https://git.drupalcode.org/project/eca/-/blob/3.0.x/modules/content/src/..., I don't really see how this is gonna work with any tokens. The code looks to make implications that its a regular entity reference field with defined structure that custom_field doesn't match up to. I would post this issue in the ECA slack channel with the link above and your issue as I believe this action plugin would need to be modified to support custom_field references. I'm gonna close this out as there's not really anything else I can do to support this.
Honestly, it could/should probably be removed as the original intent was to just initialize the extra properties. This is one of those areas where we could probably benefit from some extra test coverage and contributors with advanced knowledge of TypedDataManager inner workings ;)
You can see full list of available tokens in the help section: /admin/help/token
In your case, it appears you need to replace :value with :entity
Try that please and update the ticket.
I upped the limit to 250. You can use the patch.
Okay, I think the core limit might be 100 so I can change ours to match that with a patch for now. Changing the status of the issue to task since its still not really a bug and again if your reference count exceeds 100 at some point, there's not much I can do for you as I really can't recommend these widget types in this case.
The patch should fix all cases. Please update status if you concur after testing.
I would recommend an autocomplete widget as an alternative or you could also try enabling the custom_field_entity_browser sub-module if you wanted to go that route where you have more control with a view to select items from.
For #4, Yeah, core entity reference option widgets also have a limit but we could improve this with settings (within reason) and notification around the limit. I'm currently in process of refactoring the form widgets though that will be available in 4.x version so I don't really want to add new settings prior to that. I don't know exactly what you mean on #5.
FYI, i don't know how many items you have available to references but options widgets have to have some sort of limit or you could have a considerable performance hit in the form. The field settings form itself could be unusable without some sort of reasonable limits in place as there is an underlying default value form that uses the same widget so we can't just allow loading of an unlimited number.
Oh! i see now, thanks for the followup.
Curios what the issue was? Just need a cache clear or something?
Please provide more details around your field/views configuration that triggered this error.
Thanks for the report and yes you are correct. The flex widget logic just needs to change as I restructured the form to standardize the value part for when timezone is enabled. It should be an easy fix and I'll provide a patch shortly.
It's purposefully limited on those widgets to prevent performance issues. Anything over 50 or arguably even less should be using an autocomplete widget.
Noting that the bug I'm reporting is not the same as https://www.drupal.org/project/drupal/issues/3528329 🐛 Impossible to set default value when creating a new media field Active . The issue I'm reporting originated with core 11.2 with field settings form moving to a modal.
apmsooner → created an issue.
Perfect. Thank you!
apmsooner → created an issue.
apmsooner → created an issue.
I don't have time yet to create test but just wanted to get some code up for proposal what I think is a useful feature and get feedback on the idea.
apmsooner → created an issue.
apmsooner → created an issue.
There shouldn't be any special rendering functions needed here but views can be finicky about what it considers empty as there's all sorts of rewrite options and some displays react differently. I would probably need to see your config for all this to figure it out. Hit me up in slack if you want. Drupal.org commenting is really poor for attaching anything...
I'm not able to reproduce this issue. Every scenario I've tested there is no markup if the view is empty. You seem to have a few other modules in the mix like Entity Extra Field that perhaps is doing contributing? I don't really have an answer for you if I can't reproduce it and I don't use that other module.
This is working as it should now and good to be merged.
The fix for the formatter settings was minor and I was able to reproduce the issue myself and verify settings are saving for both formatters so calling this good and merging it!
FYI, there's an issue that got discovered with the subfield formatter settings not saving in table/flipped table. I addressed it in this ticket and will be merged to dev soon: https://www.drupal.org/project/custom_field/issues/3530753 ✨ Add ability to ignore timezone for a date subfield Active .
@coaston, I just committed a fix for settings not saving.
Oh i see, the formatter settings aren't being saved for some reason. Okay let me see whats going on there and I'll followup back up.
Pushing to 4.x branch to account for field settings refactor.
It would be great if you could create a documentation page with a full example.
apmsooner → made their first commit to this issue’s fork.
Oh good! I figured that was all that was needed. It will get simpler in 4.x as the array of settings will be flattened out and easier to work with. Just be aware of that when that version rolls out.
Added credit. @ressa, the best way to support my efforts is to help test issues. Theres a few that I could use some help testing out that will really benefit the next release if you can assist:
https://www.drupal.org/project/custom_field/issues/3530753
✨
Add ability to ignore timezone for a date subfield
Active
https://www.drupal.org/project/custom_field/issues/3539115
✨
Provide support for Views Entity Reference Filter (VERF)
Active
I'm not 100% sure as I havn't tried it myself but would assume you would use the setSettings() method to define the columns/field_settings as it would be in configs? https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Field%21B...
I would probably create a regular field first and look at the field configs to see if you can make it work from that as an example. If you figure it out, feel free to create a documentation page. Also, be aware that I'm working on a 4.x version that is going to completely refactor the form settings into more of the "drupal" way of handling so the config structure is inevitable going to change.
@benstallings,
Thanks for your work on this! Please just fix the new phpcs and phpstan warnings introduced from this code for now and I'll try to do a full review as soon as I can get to it.
Thanks
I don't think we need that module as a dependency. If this is just a views filter than we can create a custom version of that for our needs. We would just need to create that here: https://git.drupalcode.org/project/custom_field/-/tree/3.1.x/src/Plugin/... and modify the filter type here: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/custom_fiel...
I can take a look at it when I get more time but open to patches if you wanna take a stab at it first.
Merged. Thanks for the patch.
apmsooner → made their first commit to this issue’s fork.
Merged. Thank you!
Thanks for the report and the patch but please rather create an issue fork and open an MR and I'll review.
@coaston,
I'm working on this for you but it would be really helpful if you would join the #custom-field slack channel to correspond. Can you do that?
Join the Drupal #custom-field slack channel.
Thanks Ben. It's merged!
apmsooner → made their first commit to this issue’s fork.