Thank you for catching that! I've updated to account for the auto collapse logic only being applied when default wrapper setting is closed.
And... yes this would need to be a followup feature. I'm for the idea also but I think it could be a little complicated as we would need to narrow the allowed types and how they are output as well as figure how to account for unsaved items as we're not dealing with entities as in the case of paragraphs.
Furthermore it would be nice if we could optionally select a (text) property of the custom_field field that functions as the details label, instead of
Item (1), Item (2), etc...
But I guess that should be a followup issue?
@svendecabooter,
I've fixed the issue you noted and also styling for the button where text was wrapping. Please retest and also if you don't mind testing the "autocollapse" setting as well. Just uncheck the "Show open by default?" setting to see that.
Thanks
@berdir,
I was just knocking it out cause it has to be in a new version anyway because of the core 11.3 dependency and it was pretty out of date and hard to follow without being properly typed and such.
There is a validation error for the new datetime advanced formatter that ill fix and push up to this later but probably unrelated to the issues you’re having.
Thanks, im not seeing any additional ajax issues but let me know if there’s more to the configuration I should test or any custom field related errors in the logs.
Here's the patch to fix the issue. You may need to clear cache but it should work now just fine. Please update the ticket accordingly if this fixes it for you.
Thanks for the info. Ill find the issue and make a patch tonight or in the morning.
The sub-fields have their own plugin system for valid reasons but extending them are simple: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
That being said, there shouldn’t be much need for widgets beyond what is provided particularly when next release is out that will introduce some new date field features.
Hi,
The standard field widgets are not a one to one adaptation for this module and in most cases I’ve tried to avoid extra dependencies and handle my own way when i can simply do it better. IEF is a little more complex however so will have to look at this when i get time. Im aware of the composer issues and a stable 4.x version will be released next week that will resolve that.
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 ;)