🇫🇷France @arousseau

A patch working for D10.4 containing only the one line fix. Could be of use to someone.

Added a note about specifying a provider property, when adding a menu link via the plugin manager.

Without this an error occurs upon editing the link in the menu ui.

Added a note about specifying a provider property, when adding a menu link via the plugin manager.

The MR applies cleanly to 1.4 and the warning is displayed on /admin/people/permissions. Looks ready.

I was able to reproduce this issue on a fresh install of search_api 1.38.0 and search_api_solr 4.3.8, using the "Search API (tag-based)" and "Search API (time and tag-based)" caching methods.

MR 63 applies cleanly and fixes the issue (the view does not display stale results anymore).

The fix looks simple enough and works.

I was able to reproduce the problem following the given steps.
The MR applies cleanly and the database stored value is used as default (in the "character_length" field for example).

This is working as intended and since the password policy entity is only used to retrieve and update the constraint, it looks safe to merge.

This is working correctly and the "_pk_id" cookie duration follows the value set in the "Cookie duration" field, added to the settings form.
The "_pk_sess" cookie duration is left untouched as it should (30 min default).

This is working as advertised, a "Secure cookies" checkbox is added to the settings form, and the "Secure" attribute is correctly set to true on the "_pk_id" and "_pk_sess" cookies used by Matomo.

The module is not working in its current form, due in part to this change record → and to an issue with the "translation" field that is currently being worked on 🐛 content_translation_entity_extra_field_info is obsolete Needs work

I came across another problem for which I created another issue 🐛 MergeRemoteStructure calls ParagraphsWidget::isApplicable for all field types indiscriminately Active

Attached is an attempt to address those problems (it currently requires clearing the cache, to take the new hooks into account).

Finally the bug in #3070595-13: Add experimental support for paragraphs → is linked to the fact that the module stores the widget being used by the paragraph field in a "conflictWidget" property, on the field item list object which accidentally (I think) calls \Drupal\Core\Field\FieldItemListInterface::__set() and causes it to be added to the field's value. Which in turns makes the validation fail upon submitting the entity form.
I am not sure of the best way to fix this and obtain the list of fields actually being displayed by the paragraph widget.

The MR applies to 2.0-beta8.

I was able to verify that the "current" query parameter appended to the login link's url, still varies correctly on page change.

The MR applies cleanly to 2.1.3 and the image works as expected, using the render array and lazy loading.

I tested the changes from this MR on the latest 2.0.1

Displaying a simple test block with a hard-coded cache max-age of 36, the header went from :
cache-control
max-age=36, public

to :
cache-control
max-age=0, must-revalidate, public, s-maxage=36

Works as advertised.

arousseau → created an issue.

Leaving an empty string in the target_type setting may cause problems in some cases 🐛 MergeRemoteStructure calls ParagraphsWidget::isApplicable for all field types indiscriminately Active

arousseau → created an issue.

Hi! It seems the webform_iban_field is missing the change to core_version_requirement to make it compatible with Drupal 11

arousseau → created an issue. See original summary → .

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.