I faced with a similar problem. In my case, we are using paragraphs with a select list with really long options. So, the select list visually breaks subforms.
Changes from comment #15 have limited usage. They can't help if your select list wrapper is less than 60rem(my case).
I think that we can solve the issue by providing a display grid on the select list wrapper(class .form-type--select) this change limits the select list to the 1fr width, so it won't overflow. However, this fix provides another issue. The display grid forces select lists to use the full width of the grid column. Hence, a small select list(say their options aren't longer than 5 characters) will take all available space. If we apply 'width: fit-content' straight to the select tag it solves an issue with the small select lists but brings back an issue with the overflow.
I can't recognize a better solution than a display grid for the select lists, but I can't find any CSS trick to apply it only to overflow items.
So for the moment, I can leave only a small tip for people who are faced with the same problem:
- Attach custom CSS library for Claro(if it is used as an administrative theme)
- Provide the display grid styles in the custom library for the wrapper for the select list that overflows.
FYI: The provided solution can trim a text of options. For the moment, it seems like some browsers may have an issue with the text wrapping, so it is better to use libraries for the select list customization.
Here are the updated regular expressions. They are just copied from: https://www.drupal.org/project/video_embed_dailymotion → and https://www.drupal.org/project/video_embed_instagram →
At the moment, I couldn't recognize a better way to fix this than to set a negative margin equal to the scroll position for the balloon items. However, it is a bit ugly solution, and I think there should be a better way to solve it.
Here is a very basic implementation of the feature, but it is already something that anybody can use.
_tarik_ → created an issue.
Looks much better now. Thanks @taraskorpach!
I don't see any other problems problems.
Leaving at RTBC.
The patch version that was prepared for the adding with the composer.
Here is the patch for those who don't want several records for 1 issue in their composer.json
In the commit, I have created the trait which provides a basic logging feature. I have chosen the trait instead of the service as it looks like a less painful method to provide such a feature in the existing code.
@rsych thanks for your patch, it works fine for me, however, it seems to me that we can provide some code changes.
Thanks, the solution works for me as well
Here is the patch adaptation for group 8.x-1.x version
Here diff from the MR 32 for those who won't have a list from commits in composer.json
Also, thanks @auth for his contribution it works like a charm for me.
I faced this problem too. It seems the problem is in the Claro theme, so I have created this issue - https://www.drupal.org/project/drupal/issues/3447611 🐛 Claro theme loses actions for the view bulk operations form Needs review .
It seems to me that there is nothing to change in the DraggableViews module, so I will mark the issue as closed(work as designed).
I have added simple code that will move additional action buttons before the actions array are deleted from the form.
FYI: The changes are compatible with the Drupal 10.2.5
I realized that made a mistake in my previous commit. Here is the correct version of the patch
The diff for PR to avoid adding numerous commits to the composer.json.
I have found an issue with response caching with this patch.
The isDefaultIncludes method checks only if the request contains included parameters from the jsonapi_extras configuration. So, it can cause problems when the one cached response is used for different includes params.
Say, you have an endpoint for an article that uses 3 taxonomy fields (field_tag, field_type, field_category).
The jsonapi_extras is configured to include by default the field_type field. Then if you send the first request with ?include=field_category this response will be cached and applied to the response without the include param or for ?include=field_tag.
So, instead of checking if the request uses default includes we need to check if the request uses ONLY default includes.
Ported the patch for those who are still on Drupal 9
Works fine with 9.5.11
Added property declaration into the ConfigurationHelper class.
_tarik_ → created an issue.
Added to new module release https://www.drupal.org/project/jsonapi_links/releases/1.0.4 →
Added to new module release https://www.drupal.org/project/jsonapi_links/releases/1.0.4 →
The patch looks fine. It only extends the list of supported Drupal core versions.
Don't close this issue as we can get new updates from the bot.
The fixes from this issue were merged into the new 2.x dev version of the module
Changes are ready for review.
- Updated the configuration form to provide the ability to select vocabulary with the spam words;
- Added a service that contains simple logic for working with different sources for the spam words;
- Created the update hook to provide new values for the configuration.
_tarik_ → created an issue.
I have rechecked my code here, so probably the best place for all these changes is the 2.x version of the module. The code from this merge request makes module logic too different to use in 1.x version.
I will create a new development branch and put an updated code version there.
I see the code for this issue was already merged in the scope of this one https://www.drupal.org/project/jsonapi_links/issues/3416149 🐛 JSON:API meta link removal results in empty array, not empty object Fixed
ptmkenny, please don't combine code for different issues in merge requests in the future. I can understand that you had conflicts between these two patches, but it is better to put a combined version into the comments.
Everything works fine, so the issue can be closed. Thanks for your work!
This issue was merged into the module dev version, and everything works fine. So, I don't see any reason to keep it opened.
ptmkenny, thanks for your contribution!
Thanks ihor_allin. The patch in comment #16 works for me.
The changes ready for review
Added changes proposed in the issue description.
Ready for review.
Hi swentel
Thanks for the code review.
I have debugged the code and found that we can use the plugin_settings_edit option from the form state storage as it contains the current field name.
See Drupal\field_ui\Form\EntityDisplayFormBase::multistepSubmit().
Also, I fixed the hardcoded field name in states on line 31 in the Title.php
Hi besek
The problem that you described is related to the VBO. It has been solved in this issue
https://www.drupal.org/project/views_bulk_operations/issues/3391431
🐛
Toggle button state selector too greedy
Fixed
.
So, you can install the dev version of the VBO module. It should help you.
_tarik_ → changed the visibility of the branch 3409308-provide-routemath-tag to active.
_tarik_ → changed the visibility of the branch 3409308-provide-routemath-tag to hidden.
Changes ready for review.
_tarik_ → changed the visibility of the branch 3408925-decoupled-route-support to active.
_tarik_ → changed the visibility of the branch 3408925-decoupled-route-support to hidden.
The changes were pushed and wait for review
Hi, I have faced with the same error on my project. Seems the problem is in the Draggable views module. So, this task can be closed.
I created this one issue to implement fixes -
Notice: Undefined index: field_type in fico_field_options() (line 416 of /var/www/html/web/modules/contrib/fico/fico.module)
🐛
Notice: Undefined index: field_type in fico_field_options() (line 416 of /var/www/html/web/modules/contrib/fico/fico.module)
Active
.
_tarik_ → changed the visibility of the branch 3407717-typeerror-base64decode-argument to active.
_tarik_ → changed the visibility of the branch 3407717-typeerror-base64decode-argument to hidden.
_tarik_ → created an issue.
Hi, I have pushed part of the required changes that provide the ability to use domain path fields on the entity API level.
However, changes for the domain_path_auto aren't finished. We need to cover new code by tests and refactor it.
But that is the start of work on this issue.
Hi quadrexdev
This module is used in one of my projects with JSON:API and has problems mentioned in the task description.
I plan to start work on this in the next few days. Would you mind assigning this issue to me?
I plan to do these steps to fix the problem:
- Create a field item and field widget objects for the domain path.
- Add code for altering base field info for entities that support domain path. I think it will be the same solution as we already have in the path auto module.
- Update the domain path auto module to make its fields available on the entity API level.
+
I have added code into the DomainServiceProvider class that alters the required_cache_contexts array and adds there a "url.county"
_tarik_ → created an issue.
_tarik_ → created an issue.
bbrala
Thanks for your response!
I got your point and updated the pull request now it uses !isset() instead empty().
Also was created a new branch for the 11.x version of Drupal core.
Hi bbrala (#5)
Sure I can do this, but could you a bit clarify what issues we can get with using empty() in this part of the code?
I used it because, in this way, we will skip all cases when data['id'] contains an empty string or any other value that can't be for the uuid
Thanks!
Hi smustgrave (#4)
This problem can be reproduced only if the id attribute wasn't added to the request body. So we can be calm about the module functionality.
_tarik_ → created an issue.
Be aware if plan to use this patch until it is merged into the module.
If the module implements its update with the same number that was used in the patch then this update will be skipped.
As a way to avoid this problem, you can change the update number from 8306 to another like 8201 that probably won't be used in the future.
In the proposed solution I added 2 methods to:
- Get the list of active domains for the entity.
- Get the field name with domain access settings.
The second method is required because if the field for domain access was created automatically it doesn't have the "field_" prefix