🇫🇷France @arousseau

guignonv → credited arousseau → .

We ran into a semi-related issue, when configuring field mapping for an existing external entity type.

$wrapper[method] is not a function

This is linked to the following change record https://www.drupal.org/node/3450770 → which in fact impacts D10.3

I'll update the MR to reflect this change.

arousseau → created an issue.

arousseau → made their first commit to this issue’s fork.

I created a new branch + MR for this simple addition. It should be good to go!

I created a new branch + MR for this simple addition. It should be good to go!

arousseau → changed the visibility of the branch 3314975-add_radio_buttons_widget_2_0_x to hidden.

arousseau → changed the visibility of the branch 3314975-Add_options_buttons_support_2_0_x to active.

arousseau → changed the visibility of the branch 3314975-Add_options_buttons_support_2_0_x to hidden.

arousseau → changed the visibility of the branch 3315187-Add_select_list_widget_2_0_x to hidden.

Merge request !21 is the one for 3.0.x
MR !20 is a fail on my part, when you create a new MR it defaults against the 2.0.x branch. I closed it.

arousseau → created an issue.

This seems to work for me too, thanks.

arousseau → created an issue.

arousseau → created an issue.

Re-roll for 10.3.x

arousseau → changed the visibility of the branch 2839195-10.3.x to hidden.

arousseau → changed the visibility of the branch 2839195-10.3.x to active.

arousseau → changed the visibility of the branch 2839195-10.3.x to hidden.

arousseau → changed the visibility of the branch 10.3.x to hidden.

arousseau → changed the visibility of the branch 2839195-11.x to active.

arousseau → changed the visibility of the branch 2839195-11.x to hidden.

arousseau → made their first commit to this issue’s fork.

Hi eli-t!
Do you think it would be acceptable to remove the \Drupal\jsonapi_reference\Plugin\Field\FieldType\TypedResourceObjectItem::getConstraints call?
As it is, it only returns the AllowedValues constraint, which we do not want/can't provide for performance reasons.

We could have something like this instead https://git.drupalcode.org/issue/jsonapi_reference-3474619/-/commit/057c...

Well this actually looks a bit more complex than anticipated.

If we implement OptionsProviderInterface Drupal adds a \Symfony\Component\Validator\Constraints\Choice to the field.
Which in turns, when validating the entity, calls \Drupal\jsonapi_reference\Plugin\Field\FieldType\TypedResourceObjectItem::getSettableValues

Problem : getSettableValues will only return the first 50 elements that JSON:API provides. There is then a good chance that those results, which aren't filtered using the search attribute used by the field widget, don't contain the value set for the field.

This makes validation fail :/

I'm not sure what would be the best way to handle this, since using pagination to fetch all possible values for the field would be a big hit on performance I would imagine.

Thank you @eli-t

I think we can avoid adding a dedicated widget here !

I created ✨ Use OptionsProviderInterface to allow options widgets usage Active to handle adding the OptionsProviderInterface implementation to the field type.

Once it is merged, we'll only need to add the following to the existing jsonapi_reference_field_widget_info_alter, to allow for the use of radio buttons :

$info['options_buttons']['field_types'][] = 'typed_resource_object';

I created ✨ Use OptionsProviderInterface to allow options widgets usage Active to handle adding the OptionsProviderInterface implementation to the field type.

Once it is merged, we'll only need to add the following to the existing jsonapi_reference_field_widget_info_alter, to allow for the use of a select list :

$info['options_select']['field_types'][] = 'typed_resource_object';

arousseau → created an issue.

I reworked this in order to make use of OptionsProviderInterface as explained in \Drupal\Core\Field\Plugin\Field\FieldWidget\OptionsWidgetBase

I tried to stick to the way things are done in core entity_reference field type.

This should allow the use of hook_options_list_alter to sort the display order of the options too.

This will need an update to reflect changes made in 🐛 Options using the same "search attribute"'s value are not all available Needs review if/when that lands.

Hello @eli-t thanks for this fix. I can confirm it is working.
It does break the two widgets added in #3315187 and #3314975, since the code uses array_flip to build the options for the form element.

I'm not sure how to best fix this. The change in code is simple enough for those two issues, but I suppose it should wait before this one is merged first.

arousseau → created an issue.

arousseau → made their first commit to this issue’s fork.

I added a very basic hook alter implementation. I'm not sure which cache needs to be invalidated (via a hook_update ?) after adding the module handler to the arguments of the 'menu_breadcrumb.breadcrumb.default' service.
As it is, the patch/commit will result in an error if cache is not cleared after it is applied.

arousseau → created an issue.

Hello @sourabhsisodia_ thank you for your answer.
I am able to reproduce this warning, using a "simply test me" install.
Core version is 10.2.4 and Smart Trim is 2.1.1.

You can go to the default /admin/structure/types/manage/article/display page, select the Smart Trim formatter for the body field and click on the cog to access the settings. The settings form displays fine, but a warning is logged in the recent log messages.

Warning: Undefined array key "#type" in Drupal\Core\Form\FormHelper::processStates() (line 211 of /var/lib/tugboat/stm/web/core/lib/Drupal/Core/Form/FormHelper.php)

arousseau → created an issue.

arousseau → created an issue.

arousseau → created an issue.

Using this in one of our project, we ran into a small issue. The order along which the options are displayed by the select list seems to be a bit unpredictable.

This could be easily solved by forcing a sort order on the search attribute. Added a modification to the MR.

arousseau → made their first commit to this issue’s fork.