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.
Oh! I didn't realize the adjusted widget option. Okay, i'll strip those additional types back out. It sort of worked for an image upload when i was testing but resulted in error on edit so that may be why.
Sounds good. The isApplicable() should maybe check if there are actually any entity_browser entities and that select field should be required? I noticed also an entity_browser can have an upload widget but it would be irrelevant if the entity_reference target_type is not one of file||image. We don't need to check for the field_type otherwise in isApplicable() as its already defined in the plugin attributes. I havn't played much with entity_browser but i'm sure theres some settings that are irrelevant since we can only ever have 1 selection.
Wow, thanks for all the work towards this. Let me test this out when I get a chance and see how it works and will certainly help get this supported as others have also mentioned wanting this feature. I appreciate the contribution :)
apmsooner → created an issue.
Fixed and already merged in this ticket. https://www.drupal.org/project/custom_field/issues/3518147 🐛 Cannot set both min and max values for numeric fields Active .
Thanks, for simplicity... i added a commit to this ticket that fixes this formatter issue: https://www.drupal.org/project/custom_field/issues/3518147 🐛 Cannot set both min and max values for numeric fields Active so I'll just close this one out when that gets merged.
Try the patch please.
@emilorol,
You can try working with the latest patch. I've mostly adapted cores EntityField implementation (see: core/modules/views/src/Plugin/views/field/EntityField.php) to our new views field plugin: /src/Plugin/views/field/CustomField.php
I havn't handled grouping and theres likely other stuff I've missed when you start messing with multi-lingual and such. The individual formatter settings work fine and the 'Multiple field settings' seems to work correctly.
I think its pretty close but it is quite complicated and can't say for 100% that its correct. It just seems to work at least from what i've tested and provides something solid to build on at this point with some other testing.
@emilorol, its somewhat more functional now but its NOT at all ready. This turned out to be way more complicated of a task than anticipated. I'm continuing to look work on it when i can but don't anticipate this making it into a release anytime real soon at this point.
BTW, you tagged this to version 3.0.3 and there is no further development that is gonna go towards that branch. I'm only keeping it around for people that havn't upgraded. I'd highly recommend upgrading to the 3.1.x version as theres substantial new features and bugfixes.
Hmm, I'm not sure I understand what you are trying to accomplish there with ECA or really how feeds fits into that. I do think in a custom module you can use an EventSubscriber that could manipulate the values on presave which means I suppose just preserving whatever values already exist.
Here's an example of something i did in my own custom module that perhaps you could find useful to adapt. I don't know if this would help or not and maybe Feeds just isn't the right solution for you. I just don't really understand the use case your describing.
<?php
namespace Drupal\nutrition\EventSubscriber;
use Drupal\feeds\Event\EntityEvent;
use Drupal\feeds\Event\FeedsEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
/**
* Subscribe to events from the `feeds` module.
*/
class FeedsEventSubscriber implements EventSubscriberInterface {
/**
* {@inheritDoc}
*/
public static function getSubscribedEvents(): array {
$events = [];
$events[FeedsEvents::PROCESS_ENTITY_PRESAVE][] = 'presave';
return $events;
}
/**
* Acts on presaving an entity.
*
* @param \Drupal\feeds\Event\EntityEvent $event
* The feed event.
*/
public function presave(EntityEvent $event) {
$json = $event->getItem()->get('portions_json');
$values = json_decode($json, TRUE);
$event->getEntity()->get('field_weights')->setValue($values);
}
}
When feeds imports field data, it is always going to write to the complete field table which in this case contains all 10 columns. Whatever column data your source doesn't provide to the feed is indeed going to result in a null value. I don't know any way around that other than to perhaps export your existing data for that field and merge the other csv data into it so everything is there. You may be able to do some trickery with an event subscriber or something but I'm honestly not sure. Maybe you could ask suggestions as well in the #feeds slack channel?
Okay thanks for the report. I'll put together a patch soon for this issue.
apmsooner → created an issue.
Again, this original issue is pointing to a very old branch of the module that is no longer even supported also so I don't want to reopen old threads. It would be best to open support ticket against the actual branch version of the module that you are using assuming you're still having problems so others can possibly help.
Entity reference fields have been supported for quite some time now. @coaston, i've tried to reproduce your issue by adding new column of type entity_reference with target_type => taxonomy_term. I ran update hook via browser and drush and no problems in either case so I'm not sure what else i can tell you. I assume you have latest 3.1.x version of module? What @mrconnerton was pointing out was running the updates through his own custom drush script so I don't think its relevant to your problems unless you're doing the same?
I'm not able to reproduce what you're reporting here and this closed ticket is completely irrelevant to the issue so I don't really want to carry on with this thread.
These functions related to file were introduced in 10.3. These changes would therefore break 10.2 sites. I was holding off on these issues for that reason and deeming a new major version would be necessary.
apmsooner → created an issue.
Thanks for the feedback! It's a tough section to improve given the complexity but happy to hear its at least better.
In the widget settings, every field now has an option for the new "Hidden" widget type. Likewise, in the formatter settings for each field there is also a "Hidden" formatter type.
Thanks! I also updated the description and dependencies as well as the README.md to be consistent with project page.
apmsooner → made their first commit to this issue’s fork.
I will say that the decimal field is really the only one thats exceptionally taller with the extra fields and its probably not particularly common to have anymore than 1 row of fields in most cases. I could be okay with calling it good as is if you're cool with it. I'd like to put out another release tomorrow hopefully since there are several other fixed issues. Hopefully you'll have time.
Thanks
@ressa,
Maybe you can test out this patch with several fields of type decimal for example that would end up with multiple rows. If you feel strongly that this is still a better solution with columns, I can go with it. I'm just a little cautious I guess with not wanting to make it more complex than it already is... but if you still think its an improvement than let me know.
I removed the red danger class and changed the wrapper to a details that defaults to closed when there's data in the field (ie; its locked from editing). The idea being that once the field is locked, it doesn't provide any value really to see whats in the wrappers. Problem i still have though is this columns layout and long form for some field types. I don't think this really works well and I can't really make this work too well with the fields all inline as the variances in field types and layout of the remove button just doesn't work that well IMO. I'm leaning towards really just putting this back into rows but keeping the details element so at least it provides some clear separation and has a closed state by default when there is existing data so it will only look busy on initial setup. Later I could see if I could manipulate the ajax further to always have them closed but each one open as its in focus similar to how the widget settings works. Here is screenshot of the current state that I don't really love for example with decimal types:
The patch needs to be started over against the 3.1x branch. Alot has changed since and I havn't had a chance to revisit this. If not this next release, the one after I should get to it.
apmsooner → created an issue.
Merging this simple feature addition. If there are any issues, create a separate ticket.
This should be good to go if you wanna add review.
The patch should do what you need for now. I'll probably have some broken tests that may need fixing but otherwise it should just work.
Hey there, the rendering already supports a 'hidden' formatter option for all types. We can create also a 'hidden' type widget that could apply to all field types. Is that what you want so you can set the value via javascript or do you want a 'value' type widget in which you are setting via backend? I suppose we could have a single widget that could determine the element type of either hidden|value. Let me know what you think. Its a pretty simple task that I should be able to knock out pretty quickly.
I'm really not loving the columns. Set a sub-field type to 'decimal'. Theres more settings and makes the column really long and undesirable IMO. I just really don't think this is the best solution. I'd prefer to revert back to rows (although keep the other changes). I think the ideal solution would be to figure out a way to not have to submit the full form on ajax requests and preserve the state where we could have these fields in a details that open based on current item being worked on. This would be similar to how the widget settings work.
Thanks for the patch. Merged!
apmsooner → made their first commit to this issue’s fork.