It wouldn't be too difficult to extend the CustomTableFormatter to do what you're after. You would probably just want to sort on the $items before it gets to this spot: https://git.drupalcode.org/project/custom_field/-/blob/4.0.x/src/Plugin/...
If you wanted to make it configurable, you could add a select field to the settingsForm with options based on the loop at https://git.drupalcode.org/project/custom_field/-/blob/4.0.x/src/Plugin/.... Just note there are some non-sortable sub-field types that might need to be excluded (map, map_string) and some that would need to be converted like dates which you can check for with custom_item->getDataType(). The documentation for all the sub-field types is here: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
If I can find the time, I may consider trying to create this feature as an MR as I could see the merit for its use also.
Marking as a duplicate since the collapsing and such feature is already being considered in the related issue. I'm not going to do anything that limits items however as that would be particularly complex and would really fall on core's way of handling multi-valued fields.
The fields are sortable in the manage display settings. Just open the settings like any other field and every field has a drag handle where it can be reordered. As far as the actual values, there is no setting to sort multi-values in the display. Those have implied sort from whatever the user entered and controlled via the form widget just like any other multi-valued field. You could create a view and do extra sorting on them but there is no such setting.
Does that answer your question?
Subscribe to this one if you're interested in a very enhanced daterange sub-field type. It will be released soon and I will likely post a screenshare to summarize the features as they are pretty extensive.
https://www.drupal.org/project/custom_field/issues/3535322 ✨ Date range field type, widgets, formatters Active
Thanks, I've updated with some of your suggestions with a few caveats:
- I'm keeping step 3 as is because the updater is no longer just for entity_reference_revisions as entity_reference can also be the source entity. The extra language is conditional too because there is no guarantee that either of those field types even exist to map from and therefore the option won't even exist if not.
- The last step #7 is also still very relevant because it is not advisable to ever perform updates like this directly on a production server so the update hook is relevant for deploying in a dev workflow. For small sites where you own the risks, no big deal but for larger sites on hosting providers like Acquia, Pantheon, etc... the extra step here is advised.
Yes, I purposely let 3 stick around for a bit longer honestly to just get a gauge on how many people have made the jump to CORE 11.x and apparently not too many! All relevant docs will be updated when I make 4.x "official" but I will say it should be considered more stable and the way forward. Stay tuned for the next release of that that will include some more desirable features.
@ressa,
Thanks for noting. Just an FYI, the 3.x branch won't be receiving any future commits as the 4.x is recommended and stable and more aligned with standard Drupal form widgets. There is an update hook that will sync all the configuration from 3.x so feel free to give it a shot and I think you will appreciate the enhancements.
I think it should be handled in Address module. Maybe just retitle the issue and move over there as a feature request. Probably will sit in their queue for a while since they havn't released anything since May but maybe someone is interested enough in working on it. I don't personally have a need for it.
Thank you for catching this and providing patch!
apmsooner → made their first commit to this issue’s fork.
apmsooner → created an issue.
apmsooner → created an issue.
Applied fix to dev.
apmsooner → changed the visibility of the branch 3535322-date-range-field to hidden.
I'm not seeing these errors. I can only suggest going into manage fields and resaving your field assuming perhaps something is out of sync in your config. Otherwise, this error should never evaluate to NULL. $allowed_values here in the code is always going to be an array and $index is either gonna return the found key or FALSE. This only suggests to me that the part that is failing for you is perhaps the 'value' key that gets stored in config. So... resave your field settings is my suggestion.
RE: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Plugin/...
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.