🇺🇸United States @apmsooner

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:

1. Create a paragraph type and add a custom_field (can clone the config from any other field)
2. Set the reference settings and entity browser widget
3. Set the custom_field cardinality on paragraph to unlimited
4. Add a paragraph field to a node and set that new paragraph type.
5. Set the the paragraph field cardinality to unlimited.
6. Create a node
7. Add a paragraph, add multiple custom fields selecting different entities with entity_browser widget each time (this works)
8. 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.

Update example.

Update example.

Add hidden widget 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.

Here's some more styling options with button classes to make them standout. This is a screenshot of gin theme. Feedback appreciated.

We could move the "Add another" button above the storage fields like screenshot. Maybe rename it to "Add field" or "Add column"? Thoughts on the machine name title? Is "Column name" intuitive or suggest something else?

The ordering of elements follows the same order as other fields. You can edit any other field type and see the same order. There's really only so much i can do with manipulating that anyway as there are multiple form sections that are merged into 1. Storage settings is a completely different subform from field settings (where the widgets are). So, I'm afraid its probably gonna have to stay as is for consistency.

You can test out the patch. For now, i just hardcoded a style using css grid. The ordering of elements is controlled by core. I didn't touch any of that yet as I really don't want to deter too much from default core behavior but play around with whats in there for now. I did also change the machine name field title to be more descriptive of its purpose and shortened the description to take less space in column layout.

Let me revisit and test out some of these suggestions and see if I can talk myself into them. At the very minimum i think we can strip away the outer fieldset and wrap the storage fields in fieldsets to provide some separation between them but I'll try the columns suggestion as well and will see if it can make better sense. Thanks

From my perspective, if you are not using it for multiple values, you're using it wrong. Sort of like the saying "if all you have is a hammer, everything looks like a nail".

I need to have a clearer module description perhaps because the impression you got here is completely wrong. I will soon be posting some videos that explain the Drupal field api in detail with how data is stored and you will then understand that this module is not just for multi-valued fields. It's essentially a correction to how content is commonly modeled in Drupal that leads to huge performance problems and database bloat.

Reworked the output. See if this works for you.

Closing this as I don't believe it makes sense to integrate Tagify with this module but feel free to comment back if you have any additional questions and I'll help as best as possible. Thanks

Assuming you've already been following this guide: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → , you probably want to extend the EntityReferenceAutocompleteWidget.php file.

I'm not familiar with the Tagify module, it looks pretty cool however I'm not sure it would be so useful as a custom_field widget considering these subfields are only ever going to allow a single value.

You might notice that the widget settings are in sync with the storage settings. When you tab out of the machine name field assuming you changed the value, you'll notice the widget settings get updated also with that new name as the machine name of storage is essentially the key for the field settings. Similarly when you change the field type in storage, the corresponding available widget types and settings get replaced. Perhaps moving storage settings back into its own configuration management page would be the best option but there would have to be alot of logic rework to make that happen and I'm a 1 man show maintaining this module. Hopefully it gets more popular and some other developers will consider contributing help :)

1. The order already matches what you're requesting
2. I don't want to set "Allowed number of values" to unlimited because I disagree that is what the user always wants and the default core behavior for fields is limit of 1. I have several use cases myself where a single item custom field makes sense to store like fields together in a single row.
3. The machine name issue is addressed here: https://www.drupal.org/project/custom_field/issues/3515457 📌 Hide machine-name-suffix field Active
4. I'm not crazy about turning the storage settings into columns. I for instance have a nutrition field with over 20 subfields and horizontal scrolling would have to happen in that case which would get really messy particularly when adding a new field. I was considering wrapping each one in a collapsible details element but the problem is after adding a field, I would want to set the open state for that new field and when core decided to merge storage and field settings into a single form, it's required me to trigger a click to the save button to make all this work together and update the default values settings and therefore I can't persist any temp values for setting the focus. For now, there's just not a whole lot better options. BTW, thats the same reason theres a default value programmatically set for the machine name. Ajax is REALLY hard to manipulate basically and Drupal's form structure here is a little less than ideal after they merged everything.
5. I've also set the size to machine name field to 20 in this ticket: The machine name issue is addressed here: https://www.drupal.org/project/custom_field/issues/3515457 📌 Hide machine-name-suffix field Active

I appreciate the suggestions and please keep them coming. I know the storage settings form can seem a little overwhelming and perhaps we can continue to improve but considering its a one time setup really, I'd like to spend more time at least for now on new widgets and such.

@ressa,

I've removed the javascript aspect from this machine name type field as its just not really working right particularly with the dynamic parts of this form. This just always exposes the name field for all of them and eliminates the empty suffix that was causing unwanted space. Try the patch please and add a review.

Thanks!

I think its ultimately because these new elements are being added via ajax though and the javascript for the machine name field is not acting right perhaps after the ajax trigger. I will look deeper into this when i get a chance to see if i can figure out where its getting lost as I agree with you that the presentation is not desirable and consistent.

It shouldn't be hidden, it should be fixed in core. The suffix is what contains the label and edit button in place of the input field. The javascript appears to faulty on that core element which is causing an empty suffix.

This machine name suffix is a core thing i guess and I do believe there's a bug in core with multiple machine name fields in the same form. I think we could track down a core issue for this and fix it there, then it should get reflected here. Thats why the first field acts like a typical machine name field and the subsequent fields look different. I assume theres some javascript involved in core that needs some attention.

I don't think thats the issue cause the loop was just going over the settings which is configuration but anyhow its fixed and merged. Thanks!

Its a mystery to me how to get to the error but the patch should at least fix it if you can try out and report back please.

What kind of entity is this field attached to or is it being used in layout builder or something?