Unable to add additional fields in Drupal 10.2

Thanks for the report. I'll see if i can reproduce and provide a fix ASAP. I assume you tried clearing cache and still no resolve?

Also, what version of drupal core are you on?

Thanks for the quick response. I'm on Drupal 10.2.3, but was experiencing it with 10.2.2 as well!
Yep, cache clears, cron runs, etc. No dice in fixing it!

Updating the issue summary with that info.

Okay thank you. I'll figure it out today. The merged forms in 10.2 created a complicated UX.

Can you please try this patch and run updates? Please let me know if this resolves or not. I believe the new entity_reference field type settings just aren't getting picked up.

I rolled back my local to alpha 1, added some fields, then upgraded to alpha 2 and I still can't reproduce this issue. Clearing the cache got the new entity reference field to show up and I can still administer the fields with no problem. Can you also check error logs or verify if there is any other modules or styles... Try the patch please otherwise and see if there is any different result. I don't want other users to be experiencing this but I can't currently verify that its an issue for everyone.

Thanks for all the quick responses on stuff!

Prefacing all of this, I did just see the note in the 3.0.0-alpha1 release regarding the "Field settings". Seems like this is known wonkiness, so maybe this is an issue more about "how to interact with the field settings form in 10.2 right now" since it is buggy with this module.

https://www.drupal.org/project/custom_field/issues/3400256 🐛 Fatal error with Drupal 10.2.x Fixed

Field storage is working but due to combined storage/field settings in same form, the field will have to be reopened to manage field settings as there is currently not a method of keeping the 2 in sync in same form via ajax. That will have to be addressed in a later release.

--
Alrighty, I applied the patch you provided, but didn't fix! So I spent a bit of time on this today to try and replicate against a few cases, and then see what's actually happening in the UI.

Using completely fresh Drupal 10 installs (standard profile with Composer create-project), I tried both Drupal 10.1 and 10.2. For each, I installed their respective Custom Field versions (latest of each).

1. Drupal 10.1.8: Works great, as expected.
2. Drupal 10.2.3: Never able to add another "sub-field" of Custom Field.

Zero error logs or console logs on either of these

Diving into #2 above a bit more, here's what I've noticed and I think is the issue I'm seeing:
Both of these elements exist in the field settings form for my Custom Field instance:

• <fieldset data-drupal-selector="edit-field-storage-subform-settings-items" ...
• <input data-drupal-selector="edit-field-storage-subform-settings-actions-add" type="submit" ...

Both of those elements have Drupal #states applied to them (I think in src/Plugin/Field/FieldType/CustomItem.php), only being visible with this condition:

'#states' => [
  'visible' => [
    'select[data-id="custom-field-storage-clone"]' => ['value' => ''],
  ]
],

However, that "custom-field-storage-clone" element doesn't exist on this form, so these elements never display!

So, if I simply inspect element in the browser and un-hide it, I'm able to add and modify fields!
So it seems like behind-the-scenes this is still all working correctly, but might simply be an issue of hidden fields when they shouldn't be hidden?

On this 'items' array: https://git.drupalcode.org/project/custom_field/-/blame/3.0.0-alpha2/src...

Can you try adding another property: "#parents" => $parents

I think that might be the issue.

No dice, applying that change didn't seem to have any affect.

Once thing I do notice is on line 236 in that file, $sources always seems to be empty for me.
This makes the following if-check never pass, so that "clone" element doesn't exist, which then makes the fieldset + "add another" input also not display (since the #states mentioned in previous post)

https://git.drupalcode.org/project/custom_field/-/blame/3.0.0-alpha2/src...

I haven't dove into what that `getExistingCustomFieldStorageOptions` method actually does yet.

Screenshot attached with a few things:

1. This one isn't "barebones Drupal", but exact same thing on fresh install too
2. Applied the #parents suggestion from above
3. Applied the patch from above
4. New field, only configured a single "Label" type to start
5. Printing out $has_data, $storage, $sources, and $element from line 238 in file mentioned above.

Hopefully that helps with a bit of additional context!

$sources will be empty if there are no other custom fields on other entities to clone from. That function is responsible for populating that array. I'll backtrack through the changes and figure it out. I think thats probably why the test might be failing too. Thanks for the additional feedback. They made it screwy with merging the forms together so its ultimately just a #states issue at this point.

Try this new patch please.

Sorry... this one should work!

Heck yeah, this is getting closer!
I think this just about solves it. The fieldset now appears so I can see the field settings that were previously hidden.

However, the "Add Another" button below that fieldset (<input data-drupal-selector="edit-field-storage-subform-settings-actions-add" type="submit" ...) still isn't appearing. I imagine it's just another tweak to the #states since they were the same underlying issue. 🐛

I just realized you're using the gin theme. Let me install that and see if i can reproduce. Are you using chrome browser or something else?

apmsooner → closed merge request !39