kyleleber → created an issue.
kyleleber → created an issue.
This should be included as part of the integration and not of the base module.
kyleleber → created an issue.
kyleleber → created an issue.
kjl16 → created an issue.
The custom configuration form will be going away in a later release as the configuration objects will be managed via block plugins rather than form plugins.
This logic is going to be offloaded to just utilize a block plugin.
This logic is going to be offloaded to just utilize a block plugin.
kjl16 → created an issue. See original summary → .
@drunken monkey,
I am running into a similar need as the original poster, so glad to help out with this one. I've applied the patch from your commit (https://git.drupalcode.org/project/search_api_autocomplete/-/merge_reque...), and there seems to be an issue with the data-autocomplete-appendTo attribute that is being added if i'm understanding things correctly. In core's form-element.html.twig (https://api.drupal.org/api/drupal/core%21modules%21system%21templates%21...), the "form-type-{X}" class isn't being added, but js-form-type-{X} is. Presumably, the form-type-{X} class is being added via a base theme such as classy, which not every theme would declare as a base theme. I was able to at least test things and confirm things looked good on my end by changing
$element['#attributes']['data-autocomplete-appendTo'] = ".form-type-search-api-autocomplete:has(.{$class})";
to
$element['#attributes']['data-autocomplete-appendTo'] = ".js-form-type-search-api-autocomplete:has(.{$class})";
Again, I am not entirely sure if we could rely on the ".js-form-type-{X}" selector depending if folks would have overridden that template. However, I think if we could change the class to something at the core template level, rather than as a core theme level, it could help generalize things.
Let me know what you think or if you see any issues with that approach!
Thanks Drunken Monkey!
Really appreciated.
Thanks for getting back! Sorry for the late reply.
I'm not sure if this would be an acceptable way to handle it in all cases, but I was able to address this for our implementation by tapping into the event's keyCode and disabling the TAB key in the uiAutocomplete.options.select function. Attaching the patch we used.
I definitely see this as needing to get other user's feedback, since like you said, others may rely on this functionality already.
/src/Plugin/diff/Layout/RawHtmlDiffLayout.php contains a protected member $configFactory. The config factory service already exists in DiffLayoutBase.php.
/src/Plugin/diff/Layout/VisualInlineHtml5DiffLayout.php contains a protected member $configFactory. The config factory service already exists in DiffLayoutBase.php.
protected function getDisplayModeOption in (https://git.drupalcode.org/project/diff_plus/-/blob/1.0.x/src/Plugin/dif...) needs proper documentation
protected function getDisplayModeOptions in (https://git.drupalcode.org/project/diff_plus/-/blob/1.0.x/src/Plugin/dif...) needs proper documentation