Make field form more intuitive and compact

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.

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 :)

Thanks for a fast reply as always! And it's so great that the machine name streamlining was fixed in the other issue, thanks for that.

Order of elements

About the order of elements, that's not what I see in a fresh installation. The "General settings" are sandwiched in between "Custom field items (machine+name/type) and "Form element|Settings|Check Empty" Or do you see something else?

Fresh install:

Unlimited by default

Please don't get overly focused on the wording, when I write "Always", replace with "95%". This module is for multivalue fields after all, right? I would even take it a step further, and set the default to "Unlimited" and LOCK it at that :)

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".

We should set sane defaults, accommodating the majority of use cases, and since in the majority use cases, the user wants "Unlimited" we should respect that, and make it easier for them by making that the default, so they don't need to tediously revisit the form, just to update this setting, because they forgot it.

I am curious though, what you mean with this, and if it is in the form or display ... maybe you can share an image, or visualize it some other way?
".... a single item custom field makes sense to store like fields together in a single row."

Display sub-fields inline, side-by-side

Since the elements are inline-block's they will align themselves and break into a new line automatically after five elements, and not require scrolling, I think that looks pretty good, and would be more user friendly.

"Technical Stuff"

About the other solutions you mention, I know too little about PHP, Ajax, and JavaScript for any meaningful input, like moving storage settings back into its own configuration management page, sadly ... I do trust that it's not easy :) (Could HTMX → be used?)

Ideally, the top "Custom fields item" section and bottom "Form element|Settings|Check empty" section were combined in a single configuration item. But probably -- as you write -- a more fundamental refactoring moving storage to its own config page is needed ...

I hope you find more co-maintainers. You could consider creating a "Looking for co-maintainers" issue, and specify the required proficiency and plans and hopes for the module?

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.

I based it on this sentence, straight from the top of the project description:

Defines a new Custom Field field type that lets you create simple inline multiple-value fields without having to use referenced entities.

I did consider re-wording it, and not including some of those comments, since they may de-rail the main point of this issue, which seemed to have happened ... In reality, whether it is "Unlimited" or not is a minor detail in this issue, and more of a side note, and I have updated the Issue Summary.

That aside, I left comments about the main point (re-structuring the elements) and I hope you have time to look at them, later.

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

Sounds great, thanks. Though, before spending any time on "Order of elements", we should make sure we are on the same page, and what you see after a fresh install. Please compare the two images -- do you see my suggestion in the Issue Summary, or the image in comment #8?

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.

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.

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?

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

This looks great, thanks for creating an MR so quickly.

* Column name
I think I prefer each sub-field header to use "Machine name" (not "Column name"), since most users will probably understand that concept from elsewhere in Drupal.

* Help text under each sub-field
About the help text below the machine name field, what do you think about this?
"Unique name, made of only letters, numbers, or underscores. Will be transformed into human readable form automatically, and used as field name."

* Add another
Great suggestion about placing the "Add another" button at the top, above the sub-fields, since that will make it immediately clearer what to do as a user, and separate it from the "Allowed number of values" below.

Maybe we can incorporate the word "sub-field", like it is used on the project page?

"A single Custom Field can have many sub-fields [...]"

Those are also the words I use -- like "field" for the "parent" ("Journal") and "sub-field" for the items under that parent ("Journal name", "Journal comment", etc.).

To make it clear what the button does, and at the same time teach the user what different things are called, it could be named "Add sub-field"?

* Styling

About styling, I also initially thought about colouring the "Remove" button with a "danger" colour, but maybe it gets too busy? The user already needs to focus on selecting the correct "Type", so maybe the current grey colour is fine?

I also thought perhaps the "Add sub-field" button could be green, to make it pop, and also signal something positive, creating new things ... but maybe this would also get too busy, and the current grey colour is all right?

Looking forward to hear your thoughts, thanks for your efforts so far, I really appreciate it.

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.

* Structure
Could arranging the sub-fields in rows work? (see image below)

* Help text under each sub-field (#1)
Instead of repeating the identical help text under all of "Machine name" fields, we could instead show once, as an info text, right under the "Add sub-field" button, with some context added?

"Machine name: A unique name, made of only letters, numbers, or underscores. Will be transformed into human readable form automatically, and used as field name."

* Machine name (#2)
"Machine name" is a well known Drupal concept, and would work well, in my opinion (#1 in image)
https://www.drupal.org/docs/develop/user-interface-standards/machine-name →

* "Add sub-field"
Good to see this got added, thanks!

* Styling (#3)
I am not a fan of the red for "Remove", I think it draws too much attention.

About your thoughts, it's difficult for me to visualize ... perhaps you can make a rough sketch in GIMP, or some other way?

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:

@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 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

I agree, the decimal field does look tall. But like you, I also think that it is probably not that common, and also that in most cases, there will be less than six sub-fields, so they will usually all be in a single row anyway.

Another reason for my proposal was also to get better separation between elements, since it looked like the "Remove" button could belong to the element above, and having sub-fields in columns definitely fixes that.

So I do think it's a clear improvement, in that it makes the form a lot shorter, and improves separation of elements. Thanks for being open to my suggestion, and ready to try out different solutions, and persevering.