EU
Account created on 27 December 2008, almost 17 years ago
  • Web Developer / UI Designer at DROWL.de 
#

Merge Requests

More

Recent comments

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.

Fixed title. Not sure if this is still a thing.

@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.

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.

Originally it is:

<div class="entity-submenu">
</div>

"row gy-equal-x" comes from our template override.

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.

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!

@phjou We could take care of the coding. Are you available to create a new release afterwards?

We discussed this briefly internally, and due to the SDC dependency, a submodule is probably the best solution.

Okay, now empty groups are also hidden in the display configuration, so this fix needs to be modified.

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.

Check this: https://git.drupalcode.org/project/micon/-/blob/2.x/modules/micon_link/src/Plugin/Field/FieldFormatter/MiconLinkFormatter.php?ref_type=heads#L170

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]);
}

The output is correct now: the empty fieldsets have gone, and the tabs still work fine in default/full view mode.

This is probably no longer relevant with the switch to XB. However, we might need something similar for XB blocks.

Okay, something is wrong with the PHP tests, but this is not related to this issue. Fixed.

@jfeltkamp We recently switched from Klaro back to Cookies and as I was about to make some minor adjustments to the design, I noticed that the old class names are still present in 2.0.0-alpha4, while it looks correct in the svelte source file (TheBanner.svelte).

Any ideas?

vs.

To add my results from 🐛 Webform Dialog Modal triggered with a link doesn't work on touch device Active : Instead relying on old mouse events, consider to use 'pointerup' and 'click' (while click is only required to apply preventDefault()).

Here is a Pen to test the events: https://codepen.io/thomas-frobieter/pen/qEdNoEr

Can someone with a Apple touch device please test the 'pointerup click' button? => https://codepen.io/thomas-frobieter/full/qEdNoEr

I have tried on the iOS Simulator and it seems to work well.

If the real device test also works well, I will create a follow up issue.

@thomas.frobieter On an Iphone SE2 18.3.2, Safari:

'pointerup' does not trigger the modal but opens the link
'touchend click' does open the modal when the finger is lifted, which does not really improve the situation much

That's strange. Safari 13.1/13.2 should support pointerup. I think we should debug this, as the pointer event sounds like the cleanest solution to me.

Okay, done, but it is a problem to add the required 'card-img' class on the image within card_media? :/

However, it makes card_media work with the card image overlay.

Everything looks very good and clean to me now!

Alt+P works fine for me. I've added it to the title text of the toggle buttons!

Additionally, I "think" there is already quite a lot in this MR, so perhaps support for Gin for this feature should be part of a follow-up issue, maybe with a bit more generic approach?

+1 for this.

@steveoriol Did you remove the field wrapper? The module adds the photoswipe-gallery class to the field wrappers attributes. The behaviour of wrapping each image in a photoswipe-gallery wrapper is the fallback if no outer photoswipe-gallery wrapper is present.

Okay, I've added CSS + icons. I've also tested and fixed Gin, with its four toolbar styles.

Moved the .toolbar-expand-floating-button into body, because Gin hides #toolbar-administration in some situations.

I haven't checked smaller viewports / mobile yet.

I think we should not use hide(), show() and toggle() as function names in the JS file, as all three are jQuery functions, which is confusing. My naming is certainly not perfect yet either.

I am not sure about the settings.initial_toolbar_padding_top / settings.initial_toolbar_margin_left. What is the purpose of these settings? I am not a big fan of manipulating styles in JS. If possible, we should set classes instead and put the required CSS in admin_toolbar_toggle.css.

@bbruno as lazy-loading is now in core, I think we should instead support that. Could you create a separate issue?

+1 for this. The lazy load module has a lot more options, so maybe someone could implement the support for PSWP as a submodule. But IMO we should only support core lazy loading in the photoswipe module.

Damn, the PSWP version was old for ..reasons. Ran composer update yesterday.. strange. So the feature IS included in the current stable release.

Never mind.. closed.

Oh, I didn't realise that 🐛 Photoswipe formatters are missing image loading setting from core image formatter Active was only a few weeks old. So it just needs a new release?

If this is the case, please close this issue @grevil. Who needs to be triggered to create a new release?

Do you agree to close Support "Lazy-load" module Closed: won't fix also?

Production build 0.71.5 2024