I'm taking this on in a different branch. I discovered there's some better ways to handle this that improve the UX considerably and account for the different operators better. It will take a little bit to get it complete for testing but the goal on my end is to convert even the configuration fields to a date type for easier default settings. The date elements are a bit messy in Core and have some bugs to fully support better alternatives but as I've already created a custom date element, I can extend that to account for the fixes so we can have a cleaner UX in the following ways:
- If exposed filter is date only, strip out the extra theming wrapper so we get just a very simple date input without fieldsets and such
- If exposed filter is date + time, take advantage of the 'datetime-local' date element so we still get a simple input but better UX.
There's a few core bugs related to 'datetime-local' that I can provide fixes for through my custom date element. All of this should lead to a better UX and be standardized across different admin themes. Stay tuned!
I'm open to any improvements. If you can do the legwork to figure out what needs to happen to get this to work, I'd be happy to implement. Thanks!
Your patch was calling the DateTimestamp class from the module also. Shouldn't it have been the DateTime? I think thats maybe why its just working for you as is but i think the widget would/should be specific to the date type.
I think we can copy this file: https://git.drupalcode.org/project/date_filter/-/blob/1.0.x/src/Plugin/v... into ours and just change the namespace and then modify https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Plugin/... and then we won't need anything from that module or core datetime module. You can see how the settings are already currently passed into our class currently so we don't need to call a get to field storage in the same way.
Look here: https://git.drupalcode.org/project/date_filter/-/blob/1.0.x/src/Plugin/v...
The date type for custom_field is not at the parent field storage settings and also there are dependencies on the datetime field plugins which we don't need that module and should rely on our own subfield plugins. For these reasons, I think we just need to create our own custom plugin for views that does the same thing. Make sense?
Somewhat related... I created a custom element here https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Element... to handle the "Date only" type. Core's generic datetime element is not semantically correct the way its themed for this case, a random h4 replaces the label which is just wrong. We can incorporate the correct custom_field specific element here also into views and can pass in the storage settings through the custom_field.views.inc. Even the core patch that is referenced in that date_filter module implies the date type from the field storage settings which wouldn't exist in same place there for a sub-field. It shouldn't be a whole lot of effort I don't think to replicate what they did in that module. I'll see if i can get something up to test out soon.
I like this feature however, I don't think this is gonna work depending on date_filter module as there are implications around the field definition settings that aren't gonna match up with the sub-field settings. I'll look into just adding our own logic to bypass the need for that module. I think its always better if we can eliminate extra module dependencies.
Try the patch please.
apmsooner → made their first commit to this issue’s fork.
I'm also on 10.4.7 but havn't been able to reproduce the error. I think it could be triggered from this line: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/src/Plugin/.... I'll address it with a condition check in the patch I'll create for https://www.drupal.org/project/custom_field/issues/3527541 🐛 When adding a long text sub field the max length stays filled in as 255 Active and hopefully that would resolve the issue. If there's any additional steps though that could help make this error consistently reproduced, that would help me verify the fix.
Are 3a & 3b referenced from the same field on level 2? Its a single field that references both types right? If so, You should be able to just create the custom field on level 2 which in this case the target type is gonna be the paragraph and bundle on level 2 and then the source field would be the paragraphs field and you would check both bundles. The mapping would be relevant to the fields on those paragraphs. The only thing im not sure of around translations is the way paragraphs module handles these in child levels. It gets a little weird with paragraphs and multilingual from my experience.
FYI, I'm gonna try to add drush commands this wknd similar to custom_field for this module so it will be easier to test this out locally without having to run update hooks.
Is that 3 levels of paragraphs it sounds like? You're on the right track with starting from deepest and working you're way up. If the paragraphs and their fields are indeed translated, it should just technically work from the testing that I've done. Maybe you could bullet point the hierarchy and field structure so I could understand better? And if you wanted to attach the updater configs that might be helpful.
Try the clone feature and see if that satisfies what you're thinking? You would see it when you add another custom_field. It will show other custom_field instances from any other entity type and it will copy all the storage and widget settings over.
apmsooner → created an issue.
apmsooner → created an issue.
The patch should resolve this issue. Please test and report back.
apmsooner → made their first commit to this issue’s fork.
Subfield values are always limited to single value therefore there it is not possible to select multiple terms. You can have a multi-valued custom field of course but again each subfield within it can only be single as the values are stored in a single table row in the database. If you absolutely need multi-valued terms selection, then you may want to split this out into a separate normal entity reference field.
I'm not able to reproduce this on latest release. Feel free to reopen with steps to reproduce if you're still seeing this issue.
Thanks for the report, I found the issue and its fixed in the dev branch. I will put out a new release later.
Is there anything else u can provide to help me reproduce? Drupal version, anything particular about the setup with the form? Layout builder or paragraphs in the mix?
I was able to reproduce and fix. Please try the dev branch and verify if the update goes through now. Please confirm for me as I will roll out another release for others that may experience the same issue.
in that update in the .install file, you can try adding this extra line right before the save action. If that works, just verify no data loss. I think its just triggering a safety feature in storage settings to prevent data loss although I still havn't been able to reproduce the issue. It could be helpful again if you could share the storage config for that field.
// Update the settings.
$field_storage_config->setSetting('columns', $columns);
$field_storage_config->setSetting('column_changes_handled', TRUE);
$field_storage_config->save();
Hi, i'm not really sure how this failed you. I just tried the update on another installation with 3.1.7, added a bunch of data and then installed 3.1.8 and the update ran just fine. Maybe you can export the config for the field storage that is giving you problems and paste here and perhaps I can take a look. I'm not really sure why it thinks its changing schema in the db, the update is only changing settings. If anyone else has similar issues then maybe we can figure out a way to isolate it but whatever your storage config looks like may give us some clues. You can go to: /admin/config/development/configuration/single/export to get that.
I don't think this is worth doing for the reason that field updates like this should really be handled in an update hook. Noone would (should) ever really perform this on a live site. I can improve the drush commands however to simplify the steps.
Let me dig back into this and try to figure out some better solutions. It's been a while as I've been heads down on updates for the custom_field module but I have time now to get back into this one and make some improvements. I appreciate the suggestions and ideas.
These aren't bad ideas but there's reasoning for the current setup.
- The source field is optional. If no source field is selected, all fields on the entity are available for mapping.
- The target field is required therefore logically put first.
- I don't really want to combine the mappings into the same form as it would require alot of additional ajax and therefore make it way more cumbersome and error prone.
Maybe there's some opportunity for better labels and help text still. I would like to make it more intuitive, just not sure how to communicate best that the source field is really for targeting specific fields from a referenced entity (ie; paragraphs, blocks, etc...). Maybe we change the label to something like "Source from referenced entity" and limit the dropdown to those field types? The whole reasoning for the source field is basically that we have to associate the mappings to the entity with the fields. If the desire is to map from fields on a paragraphs entity, only the fields specific to the paragraph entity should be in the mappings.
Sorry for the delay. I've fixed this issue in the dev branch.
FYI, I'm not ignoring this and I appreciate the patch. I'm gonna hold off on this for the upcoming release and revisit next release as the tokens.inc needs to generally be refactored a bit anyway. Again thank you.
Working as expected for me so calling it good.
apmsooner → created an issue.
This should already be fixed in previous release but dev branch also has some additional logic that should make it more sound as well. Can confirm if this is still an issue in dev at least.
Andreas, this is ready to go. Hoping you can have a chance to review please.
Hi, this is handled through a theme function core. I think you can handle it case by case through your own custom module by targeting the field name like in this example: https://drupal.stackexchange.com/questions/62662/how-to-remove-show-row-.... It's not really something I can support however as it really should be handled in Core as a feature request perhaps.
Al, I'm not on that project anymore and I could also never reproduce the issue on any other projects so I'm of the opinion of just closing the ticket unless you want to wait on anyone else to respond.
apmsooner → created an issue.
apmsooner → created an issue.
Everything is checking out on this feature and working properly so calling it good.
Thanks for the review Jake! I just pushed a commit that should fix the deprecation warning.
Alot of refactoring and cleanup but I think its working really solid now and needs some user testing.
Already handled in this ticket: https://www.drupal.org/project/custom_field/issues/3520895 ✨ Link field type Active .
Feel free to test that ticket out as it has alot of improvements :)
Hi, you may be looking in the wrong place. Below the storage settings where you setup the fields originally, there is a section to configure the widgets. This screenshot is slightly out of date however the dropdown on the left is where you can switch the form element type and there is an option labeled "Hidden". https://www.drupal.org/files/project-images/Screenshot%202023-08-31%20at... →
Hi, this is handled in the widget settings for the field. There's a widget type called 'Hidden' for every field type. On the manage fields page, just scroll to the widget settings section and change the widget type to that and you'll be good to go. There is also a "Hidden" formatter type in the manage display settings if you want to hide its rendering.
Thanks, i'll review and ensure its fixed for next release.
apmsooner → created an issue.
@emilorol,
I would probably just composer remove your local custom_field module and do a git pull of this branch directly into your modules/contrib if your still having problems applying the patch. I just merged dev into this branch that has alot of changes as well. If you use ddev, just do a ddev restart if you pull this branch in and then clear the cache.
Everything is working for me fine. I've made alot of modifications that you'll want to test out and we probably want to lower the phpstan level warnings back down unless you have some solutions to resolve them now. The tests now include this field and getting passes although at some point we will want to expand the tests for everything but anyhow... i'm comfortable with the way this is working.
@emilorol,
From your screenshots, the sub-formatter appears to be working for you so I think your question is answered there no?
As for the filters, no this patch will not address any new filters. I don't really have a solution for select field filters as the field type could be shared across other entity bundles and have different widget settings so there's just not gonna be a way to do that for that reason. Looks like you found a workaround with Grouped filters for now.
I bumped the core min version to 10.3 as thats when the core file changes got introduced. I reverted the one of the dependency injections that would have put a dependency on token module and lastly I fixed the failed test. There's just some dependency injection warnings left but can resolve those later.
apmsooner → made their first commit to this issue’s fork.
Thanks @ressa,
I'll check into the errors you're having on Drupal 11. I had only tested this on 10.4.x and didn't experience any issues like you're describing but nonetheless, i'll see if i can reproduce and patch it up quickly. Should be an easy thing to reconcile.
I added a 5th step to quick start linking to example update hook.
For more clarity: The module itself doesn't import anything. It uses the configuration settings including the defined mappings to copy data from 1 or more fields of same schema type to target field. The "Source field" is optional as its not needed normally unless you need to copy from a entity_reference_revisions field (ie; paragraphs) which in itself is composed of its own entity type/bundle that has its own fields. In your example, you can certainly set the other body field as a "Source field" or you can leave that field empty and that field along with any other (non entity_reference_revisions fields) would be available in the mappings. So you basically can pull data from multiple field properties to fill the target field. I will sort out this bug first and then add a video soon that covers all the steps including the update hook declaration which should hopefully simplify the explanation.
Again, no import is happening, when the update hook runs, it's querying for all entities of the defined entity_type/bundle and does a batch update to the target field from source(s).
Here there is a hardcoded field_name so that won't work...
// @todo Figure out a better way to enforce a 'clean start' when adding
// new field item for whose delta a value already may have been stored
// in the form state (below), as the field item 'remove' button does not
// exist when building the widget element, so we cannot attach
// 'removeItemSubmit' to it.
$triggering_element = $form_state->getTriggeringElement();
if (
is_array($triggering_element)
&& array_key_exists('#name', $triggering_element)
&& $triggering_element['#name'] === 'field_articles_add_more'
) {
// If the delta is not present in the user input, it means it is new or is
// being added again. In both cases, we want to start with an empty
// selection.
// By forcing $entity to NULL, a selection stored in the form state (if
// any) will also be set to NULL hereafter.
$user_input = $form_state->getUserInput();
if (!NestedArray::keyExists($user_input, [$field_name, $delta])) {
$entity = NULL;
}
}
I think we will need to set a variable through like $parents = $form['#parents'] that would get evaluated in the getFormStateKey(). It's normally gonna be empty except when the field is attached to paragraphs. You can ksm($parents) and see for yourself. Ultimately the $form_state_key is wrong when paragraphs are involved as its returning something like this and not accounting for the actual field containing the paragraphs:
array:2 [
0 => "entity_browser_widget"
1 => "paragraph::field_testing:0"
]In my case i have a field named 'field_paragraphs' on the node so itself would have a delta and the field attached to it also has its own delta so not sure if this is an issue also with the widget on regular entity_reference fields also or if we can workaround it somehow. It's complicated... See Media library widget for similar: https://git.drupalcode.org/project/custom_field/-/blob/3.1.x/modules/cus...
It seems to work fine in normal nodes however I found an issue with a custom_field attached to paragraphs.
Steps to reproduce:
- Create a paragraph type and add a custom_field (can clone the config from any other field)
- Set the reference settings and entity browser widget
- Set the custom_field cardinality on paragraph to unlimited
- Add a paragraph field to a node and set that new paragraph type.
- Set the the paragraph field cardinality to unlimited.
- Create a node
- Add a paragraph, add multiple custom fields selecting different entities with entity_browser widget each time (this works)
- PROBLEM - Add a second paragraph, notice the custom_field reference field already has default value from first paragraph > first custom_field > reference (this is wrong).
I think this is gonna be an issue around the parents array and deltas similar to the media library widget that I had challenges with but eventually sorted out. It can get even trickier when there is paragraphs within paragraphs (ughh... please never) but my solution for media_library worked there too.
I ultimately need to expand the unit testing to cover all these various widgets and formatters. Writing those is not something I'm really into. Hopefully as more people use this module, someone will volunteer to help out in these areas. And... if you have any interest in being a maintainer officially for custom_field, just say the word! I welcome and appreciate the help as its alot on a single person ;)
I will probably hold off on the patch for Gin. They are using a sprite for the icons and I'm thinking this might have been just some sort of intentional workaround as they don't have an icon for 'replace' so someone just did something hacky with css. It's not really anything that needs to us back.
Nice on getting rid of the selection mode setting and I agree with you, simplifying to the absolute minimum we need is a good idea. Ajax is REALLY tricky with getting the right deltas and such. I've done alot of it in various other plugins. The media library widget was also very tricky to account for and then you start having to deal with different parent array structures with layout builder and paragraphs and its all the more complicated. Thats why in many places I've ended up just building my own widgets from scratch and doing it my way instead of trying to integrate with other modules where their code is generally unfinished. For instance my versions of viewfield & hierarchical_select both work correctly for multi-values and within paragraphs & layout builder. I can't say the same for the contrib module versions of those. Not trying to be snarky or arrogant or anything.... I'm just a little anal about things not being put out in the wild in broken state.
I was using Gin. I see what you mean now after switching to Claro which btw is a much clunkier UI with the buttons stacking like that. Gin provides inline icons which is way cleaner but its using the same pencil icon for edit and replace buttons with same positioning in the css so one is overlapping the other. It's pretty odd if that was intentional on their part. I'll have to look at trying to patch that for them. So... the buttons are there and functional, just a theming issue with Gin.
Related (again): I've heard there is some discussion going on about dropping support for submodules in contrib modules. (A necessity for project browser, also something related to composer/packaging issues, ...).
So perhaps, since this quite a complicated widget, it might be opportune to not merge it in the main module but release it separate, which should also make it easier to develop the main module without being 'dragged down' by complicated extensions like this and manage their dependencies.
I havn't heard that. I get the reasoning but thats probably an unrealistic thing from happening anytime soon IMO to even worry about. Since we have other sub-modules... I'd just assume probably keep it the way it is unless there is any real substance to this idea actually happening in our lifetime ;)
@andreasderijcke,
The schema is all correct now and I fixed the remove button so its basically pretty functional now from my testing. I also removed the prefix with the cardinality message as its pretty irrelevant in that only 1 can ever be selected. The replace button doesn't show up... not sure if its supposed to and if its a bug with entity_browser module or what the logic is around that as maybe thats some sort of file/image thing only.
I'll leave it to you to refine further but its in a pretty good functional state at least for now.
I modified the logic a bit to get the actual saved value as it was erroring out.