Hey there, thank you for the patch. I will review, test and merge over the weekend. I appreciate the contribution.
No, I was just saying that seems like the structure we can adapt for custom_field.
Sounds like what you're wanting is in the example here: https://git.drupalcode.org/project/ui_icons/-/tree/1.1.x/modules/ui_icon...
Maybe you have a dev or patched version in your code repository? Try doing a composer remove and then fresh composer require with the 4.x version but also FYI I'll be putting out a new version over the weekend also if you wanna wait.
The version gets set by composer when you download so this shouldn't be an issue with custom_field but rather the update manager I suppose in your installation.
apmsooner → made their first commit to this issue’s fork.
Odd, others I know updated that had datetime fields and didn't have any of these issues. I'll have to roll back my own local and try doing some tests to see if I can figure something out for you. Appears that 8007 is indeed an issue.
I think the issue is these update hooks are perhaps competing with each other with the schema changes. If you can get past that issue this way, I'll update the project page with a note for others. I'm planning on putting out a 4.0.1 version over the weekend also so would recommend jumping to that as its basically the same but will support 11.x, has lots of new features and 3.x will no longer be supported.
The timezone column was added in version 3.1.14 so maybe try updating to 3.1.13 first actually.
I wonder if commenting this line out @ line 121 would help?
// Clear cached definitions to ensure we work with the latest data.
$entity_type_manager->clearCachedDefinitions();Attach your field config otherwise prior to pulling in the update and I'll see if I can reproduce the issue and provide a solution.
apmsooner → changed the visibility of the branch 1229568-token-ui-2.0 to hidden.
Maintainers should maintain, not contributors so I can't help here. Closing and moving on.
With all do respect, what I posted was a draft version of a POC that was never intended to be merged as is and since you don't have ability to create a new branch, it would be impossible to do anything with what i worked on given the core dependency. I thought I was pretty clear on that. It's quite trivial to cherry pick bits from one branch into another if there were designated issues to address them to but with over 400 open issues, it's a bit difficult to have a perspective of how you want to isolate parts of what I provided into the current codebase. Token is huge in scope of sites depending on it but the code is very minimal overall and modules depending on it are moving at a much faster pace so thought I'd help push it along.
Anyhow, I can go the contrib module route to provide an alternative token browser as someone suggested. Thanks anyway.
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.