@thomas.frobieter: FYI: Regularly a select or radio is used to choose the variation and that one has the "selected" functionality. So maybe things should be handled differently, when the rendered entity is used?
I think there should be some kind of "selected" indicator on the selected entity in this case without having to modify templates?
Maybe that means a different (inheriting or wrapping) template should be used?
I agree, but I don't think its up to us to invent new classes on this template. Furthermore "selected" is a technical property, which simply is required to make the select work corretly.
I'm not sure where else this template might be used. The file name tells me that it doesn't just render “Swatches.”
Done. It's still not perfect without the default classes, but, as I said, that's outside the scope of this issue IMO.
There is no class added by default: https://git.drupalcode.org/project/commerce/-/blob/3.x/modules/product/t...
So this formatter class does not make sense.
Adding proper classes is not part of this issue.
Lets add it to the docblock instead.
Just noticed broken elements on a customer page because of this. Could someone provide a patch please?
@gausarts: Sadly using AJAX on views does NOT fix it.
Without the patch it is still broken, due to the reasons given in the issue summary. Could you please reopen the issue?
My 2 cent for the Twig template:
name: vidstack-error-placeholder.html.twig
Markup:
<div class="vidstack-error-placeholder">
{{ message }}
</div>
Not sure about adding default styles.. it would be nice to have this PLACEHOLDER with aspect ratio 16 by 9.
.vidstack-error-placeholder{
display: flex;
align-items: center;
justify-content: center;
padding: 1rem;
aspect-ratio: 16/9;
background-color: rgba(0,0,0,0.1);
}
I am unable to reproduce this problem with Drupal 11.2.5.
We have used this module for several years across all the listed Drupal versions.
Are you sure this isn't a theme bug?
Further information on this (thx to @doxigo) https://drupal.slack.com/archives/C072JMEPUS1/p1760772286959109
For those who don't use Slack:
This seems to be the cause: https://www.drupal.org/project/drupal/issues/3531905 🐛 Validation error on optional properties. Active
Try adding 'null' as a type (along with string or whatever else) to your prop (@mherchel)I am not very confortable promoting this workaround. There is a root cause to fix somewhere, maybe on SDC level (the issue shared by @mherchel), maybe on Canvas level (my bet), which will allow us to keep the SDC definitions clean.
As a general statement, we, SDC authors, themes owners, don't have to mess our component definitions to please the display building tools (SDC display, UI Patterns, Canvas, Display Builder...). If those tools do something weird or wrong, it must be fixed on their side. Our SDCs must care only about design implementation. (@pdureau)
I did some research on this topic:
https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/annotated-example-componentyml →
=> See the 'quaternary' prop: Is it required to add a enum list when using 'string' or null? If so, this needs to be fixed in Radix iteself?
https://www.drupal.org/project/ui_patterns/issues/3490873#comment-15914195 →
=> Maybe check how the ui_patterns module fixed this
Same here, unable to install Canvas :/
BTW, wouldn't it be better if the Canvas (installation) ignores failing/incompatible SDCs and simply log a warning about them?
Confirmed, Canvas cannot be installed due to this issue when using Search API Pages.
Disable script-based lazy load at Blazy UI > No JavaScript > Lazy load.
Disable Lightbox option. Ignore if you are sure no enabled lightbox.
Both already turned off, Views Ajax is required.
I am basically wondered why blazy/observer is still loaded 🤔 Couldn't figure out yet whats causing it. But anyway, the effort here is probably not in proportion to the return.
Yes, fine, depending on your needs and Core Web Vitals challenge awareness, it is very well facilitated. It is not overhead when you are actually using Blazy features. That is the point of contribs, to fill in the room left open by core.
Sure (: But this is about optimizing our default project configuration, and I would prefer to 'opt in' to the required features for individual projects rather than doing this 'clean-up' (not only for Blazy) for each project. This doesn't mean disabling everything blindly. As I said, we use native lazy loading by default and, luckily, don't need to support IE11 anymore.
And to be clear, I don't want to demonize Blazy or anything like that. I am very grateful for Blazy and Slick. We have been using both modules for many years.
Thank you so much for your help! I will add information here if I find out what causes the 'unnecessary' libraries to be loaded.
Oh man, I completely forgot about the Blazy UI settings page -_- My bad, sorry.
So now we have reduced the amount of scripts by around 50%, that's great, thank you!
The dblazy scripts are required for Slick:
<script src="/modules/contrib/blazy/js/dblazy.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.once.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.sanitizer.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.dom.min.js?t4fk1i"></script>But I am not sure about the rest, is there anything left we can easily remove? If not, I will turn on aggregation and we are done here 😅
<script src="/modules/contrib/blazy/js/base/blazy.base.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.dataset.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.viewport.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.xlazy.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/plugin/blazy.observer.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/base/blazy.drupal.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/blazy.compat.min.js?t4fk1i"></script>
<script src="/modules/contrib/blazy/js/base/io/bio.ajax.min.js?t4fk1i"></script>
Since we have switched to native (image) lazy loading, we mostly need Blazy as a dependency of Slick, so we aim to reduce the overhead as much as possible by default.
thomas.frobieter → created an issue. See original summary → .
Confirming RTBC. Can we merge this and maybe tag a new release maybe? The last is from Feb 2025 :/
Some unrelated PHP Unit tests are failing. However, its merged. I'll create new release.
We don't use the block management page as much as we used to. We use Paragraphs (including Block-Reference-Paragraphs) much more frequently.
I still think it's a good idea for sites with many block configurations, but others might also use Paragraphs or the Layout Builder instead.
I am therefore happy to close this thread if nobody else is interested!
I can confirm the preprocess: false fix works! Thanks!! +1 for the suggestions.
Example usage: Use the 'before-show' step event to trigger the required clicks to make anything visible (e.g. a submenu trail or an expandable element) before the tip is shown on something inside this originally hidden element.
@thomas.frobieter and me in the issue summary meant thomas.frobieter and anybody, since this offer was posted by anybody. 😉
Right :D Thank you both!
I encountered a similar issue. We also have a separate 'field_caption' field on 'Media Image', and this field is n/a in the 'PhotoSwipe-Caption' dropdown menu. Using the token [media:field_caption] does not work either.
The formatter is Photoswipe Responsive.
If we stick with Vidstack, this issue will need further work (see GitHub issue).
It's pointless passing our custom options to data-controls because it only accepts TRUE or FALSE. The media player web component either has or does not have data-controls, but it never prints any value in this data attribute.
Furthermore, it seems that we cannot add any classes to the media player element itself. Therefore, we are also unable to add formatter classes for our custom control behaviour. The attributes/classes set in buildThemeAttributes() are only added to the original elements (video/iframe). The supported attributes are passed to the Vidstack media player component.
Therefore, if we proceed, we need to figure out how to set custom classes on the media player or add a custom wrapper where we can safely add our custom classes.
Done. I'll create a new release.
It seems that GIN (or the core dialog.js) already prevents scrolling when the dialogue is open. Therefore, this fix is no longer required.
I will remove the Javascript file and the corresponding CSS code.
@phjou Bump (: Please add me to the maintainers.
Works well, thx!
Originally it is:
<div class="entity-submenu">
</div>
"row gy-equal-x" comes from our template override.
thomas.frobieter → created an issue.
Okay, the form actions are docked on the regular entity browser forms. Not the multistep forms, as this require additional work.
Thoughts on the multistep forms:
- The selected item list shouldn't be docked because the docked section can become very tall. If it should be docked, it needs to be collapsible (collapsed by default) maybe with a counter of the selected items, so that the user can see that the selection has succeeded. Alternative ideas: Display the selected items either above the item list or as a collapsible sidebar (in this case, the modal would need to be wider)
- The 'Use selected' and 'Hide selected' buttons should be located in the same form actions wrapper as the 'Select entities' button, so that we have one single docked bar.
thomas.frobieter → made their first commit to this issue’s fork.
thomas.frobieter → made their first commit to this issue’s fork.
Sounds good. +1 RTBC.
thomas.frobieter → created an issue.
This would be so much more useful if it also worked with the "Remote video" media type.
Indeed, but that's up to the library :/
I have created an Github Issue: https://github.com/dimsemenov/photoswipe-video-plugin/issues/10
Demo: https://codepen.io/makshh/pen/ONMVMm
https://github.com/dimsemenov/photoswipe-video-plugin
@Anybody is there any interest in this? It's been a few months since i initially submitted this.
Definitely! We would suggest labeling the submodules as “experimental” for the time being and including them in the next release.
RTBC from my side. Seems to work pretty well with the patch.
I set this to 'needs work' because the tests still need to be added?
I can also add you as maintainer if you want to?
@phjou That would be great, thank you!
thomas.frobieter → created an issue.
thomas.frobieter → made their first commit to this issue’s fork.
We no longer support Layout Builder.
@phjou We could take care of the coding. Are you available to create a new release afterwards?
I can no longer see any problems, it works perfectly again!
We discussed this briefly internally, and due to the SDC dependency, a submodule is probably the best solution.
thomas.frobieter → created an issue.
Okay, now empty groups are also hidden in the display configuration, so this fix needs to be modified.
Okay all done and tested.
micon_linkit and micon_linkit_attributes are form field widgets, not display formatters. So, as far as I can see, this is the only formatter with this logic.
Okay I got the cause, but this needs a backend programmer.
Inside the foreach I printed:
kint($title);
kint($item);
kint($item->title);
Result:
So from my point of view it needs to be something like this:
if ($title && !empty($item['#title'])) {
$item['#title'] = $this->token->replace($item['#title'], [$entity_type => $entity]);
} elseif ($title) {
$item['#title'] = $this->token->replace($title, [$entity_type => $entity]);
}
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
trackleft2 → credited thomas.frobieter → .
Okay, this was simply a outdated CSS file path in the libraries file. Fixed → .
The output is correct now: the empty fieldsets have gone, and the tabs still work fine in default/full view mode.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
This is probably no longer relevant with the switch to XB. However, we might need something similar for XB blocks.
The pages are back online — thanks a lot (:
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
Okay, there is a possible solution in
🐛
Inconsistent `attributes` handling
Active
:
https://www.drupal.org/project/radix/issues/3482516#comment-15838105
🐛
Inconsistent `attributes` handling
Active
Changes were made, but then removed in later iterations? https://git.drupalcode.org/project/radix/-/commit/ae826d7d29215d9d00fe3619d8af2c50da8407e4#cadf8086764711dda116d902e75dc698eaa4ed1e
Possibly a duplicate of 📌 Feedbacks about SDC components Active .
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
Okay, something is wrong with the PHP tests, but this is not related to this issue. Fixed.
Done! I'm waiting for the pipeline to create a new release.