@thomas.frobieter

Sure, that's completely understandable. But it should be made very clear on the module page that this problem exists in Drupal 11, otherwise every new user might spend hours looking for a solution.

A note and possibly a link to this issue is sufficient in my opinion. Users can then decide for themselves if they want to use our Slick fork or create their own.

Maybe just add another point in the "Broken vs. working library versions." Box?

"All versions: Incompatible for Drupal 11+ (using jQuery >= 4.x). You need to use a modified version of the Slick library, see 🐛 Uncaught TypeError: i.type is not a function when using the Slick Media field formatter Active for details."

RTBC for MR!100

thomas.frobieter → created an issue.

As I said in #9, I don't think the Slick module can do anything about this, because it's a Slick library problem.

The maintainers will have to decide how to proceed.

Allright, here we go: https://github.com/kenwheeler/slick/issues/4316

So the Slick library is incompatible with Drupal 11 / core/jquery (4.x).

Feel free to use our fork to have a quickfix: https://github.com/JPustkuchen/slick

But yeah, this is kind of unfixable for this module without a forked Slick version? There was Google dev active in the official Slick repo and merged some MR, but no idea if this will be fixed anytime soon.

I have the feeling this is about jQuery.

The original line throwing the error is:

$.type is not a function

https://api.jquery.com/jQuery.type/ => deprecated since jQuery 3.3, Drupal 11 core/jquery is on jQuery 4.0.

Further testing: It has nothing todo with the field formatter. The same JS error appears when using slick_views.

thomas.frobieter → created an issue.

@anybody could you please review? Its already tested and works well in Safari.

thomas.frobieter → created an issue.

Works like a charm! We can now see the full message. RTBC.

Looks good!

thomas.frobieter → created an issue.

Done https://www.drupal.org/project/photoswipe/releases/5.0.2 →

I can confirm this is because {% apply spaceless %} wraps basically each SDC.

Personaly I use spaceless not very often, because of such problems. I just fix very specific bugs with it.

So from my point of view it should be removed from most (if not all) of the SDCs?

Maybe {{- -}} / {{~ ~}} are better options if trimming is required, guess those have less impact: https://twig.symfony.com/doc/2.x/templates.html#whitespace-control

thomas.frobieter → created an issue.

Definitely, +1 for this.

Yes, please make this feature happen. Adding attributes to link fields is horrible on frontend.

Yep, look right to me.

You are right @mlncn, this was missing from the module description. Thanks! I've added it.

thomas.frobieter → created an issue.

Maybe @roromedia could provide the affected browser? If I remind corretly, this where a Safari bug, not sure if click is still problematic in iOS Safari.

thomas.frobieter → created an issue.

Another example on the user edit form.

When switching to the classes mentioned in #6 'is-invalid' / 'is-valid' on the input elements, it works well (this time on the user edit form).

With 'needs-validation' class on form, without 'is-valid' / 'is-invalid' class on input:

Without 'needs-validation' class on form, but with 'is-valid' / 'is-invalid' class on input:

My conclusion is: In case of the user edit form, the BS client side validation passes, but the server side validation fails. In this case the 'was-validated' class needs to be removed, and the input classes 'is-valid' / 'is-invalid' needs to be set.

Maybe this just needs to be removed from form.theme:

function validateForm(array &$form, FormStateInterface $form_state) {
  if (!empty($form_state->getErrors())) {
    $form['#attributes']['class'][] = 'was-validated';
  }
}

And the 'was-validated' class should only set using JS, like described here:

(() => {
  'use strict'

  // Fetch all the forms we want to apply custom Bootstrap validation styles to
  const forms = document.querySelectorAll('.needs-validation')

  // Loop over them and prevent submission
  Array.from(forms).forEach(form => {
    form.addEventListener('submit', event => {
      if (!form.checkValidity()) {
        event.preventDefault()
        event.stopPropagation()
      }

      form.classList.add('was-validated')
    }, false)
  })
})()

Also note hat .invalid-feedback never shows up without the 'is-valid' / 'is-invalid' classes (my test case on this was, to try to change your user mail address to an mail address which is already assigned to another account => "The email address bar@foo.com is already taken.").

Also on AJAX forms, the 'was-validated' class should be removed after submission:
"To reset the appearance of the form (for instance, in the case of dynamic form submissions using Ajax), remove the .was-validated class from the
again after submission." (See docs).

I now used a dirty workarounded to quickfix this, by removing "needs-validtion" from the form entirely and and set the 'is-invalid' class on the input_classes using:
attributes.hasClass('error') ? 'is-invalid'

thomas.frobieter → created an issue.

Perfect, looks good!

All green, RTBC!

thomas.frobieter → created an issue.

Good idea, especially translated field names are very confusing for site administrators.

thomas.frobieter → created an issue.

Removed the label wrapper. The classes are correct.

thomas.frobieter → made their first commit to this issue’s fork.

thomas.frobieter → created an issue.

That's for good reasons, because on the right side nobody saw it, it's the most used functionality (content) and now it's close to the content. Definitely much better position.

Okay, and what makes the top position on the left closer to the content then the top position of the right column?

Sorry. But I still don't see any benefit on the current position. Also its hacky shit to make this MENU look like a button group. One simple Claro or GIN Update could destroy this faky look.

I also think you're talking about the admin quicklinks.

Possible, I never used the dashboard and I don't have any quicklinks here.

@thomas.frobieter it's an improvement at least, even if not huge, it's better.

Yes, and that is the point on which we disagree. If they are inline buttons, it becomes much more difficult to find the right point, because then you not only have to read list points downwards, but also to the right.

The block was also originally on the right, not on the left above the content, which was certainly the better solution.

Simply styling the links as (inline) buttons is not much of an improvement IMO. It makes it even harder to find the right content type.

Maybe a good idea is to place a drop button in the top right corner (like the Add Content button in the DROWL wiki, or the Save buttons in the entity forms).

thomas.frobieter → created an issue.

thomas.frobieter → created an issue.

thomas.frobieter → created an issue.

@lrwebks: Pushed alot of changes, so ensure to pull this before you start.

Trigger me when the nested array is implemented so I can finish the menu implementation.

I only tested with entity entries, not markdown file content. So there may be other things to work out in the template.

The "content" render array in the project-wiki-entry.html.twig is somewhat unusual, as it has no fields as children. You may want to discuss this with @anybody. I am not sure how to proceed there. The problem is that I can't extract certain fields from the content and print them separately (like author or submitted).

thomas.frobieter → created an issue.

@lrwebks: To proceed here we need to implement the nesting logic first.

The goal is to have a nested list like this:

<ul>
    <li>
        <a href="#products">Products</a>
        <ul>
            <li><a href="#hats">Hats</a></li>
            <li><a href="#scarfs">Scarfs</a></li>
            <li><a href="#gloves">Gloves</a></li>
        </ul>
    </li>
    <li>
        <a href="#employees">Employees</a>
        <ul>
            <li><a href="#sam">Sam</a></li>
            <li><a href="#sarah">Sarah</a></li>
            <li><a href="#john">John</a></li>
            <li><a href="#marie">Marie</a></li>
        </ul>
    </li>
    <li><a href="#contact">Contact</a></li>
</ul>

So basically the same as Drupal menus. Here is the Twig example of how we (I) will print the menu in the Twig template: https://git.drupalcode.org/project/gin/-/blob/8.x-3.x/templates/navigati...

So a nested wiki list item entry needs to have a "#parent" key, which is the item id of the parent item. The child items should be in a "children" array in the parent item (what Drupal menus call "below").

I don't think we need a separate list for this. For the wiki article list (the full article list), we simply loop through the array, including the nested "children" arrays, and print it as a flat list.

If it is easy for you to provide a separate flattened array for the full article list, I am fine with that. In this case it could be "items" (flat list) and "items_nested".

It seems that List.js does not support nested lists: https://github.com/javve/list.js/issues/505

So ... this is a problem. If I remember correctly, we did not have many alternatives left.

The different sizes validation icons were an Bootstrap SASS misconfiguration on my side, so thats not a problem (they use a calculation for the input fields background-size and a fixed pixel value for the selects - in case somebody else runs into this..).

But the coupon code field (right side in the screenshot) is a thing. Some classes on the input SDC reflect its error state:

<input autocomplete="new-password" data-drupal-selector="edit-sidebar-coupon-redemption-form-code" type="text" id="edit-sidebar-coupon-redemption-form-code--ENE8T-eQybQ" name="sidebar[coupon_redemption][form][code]" value="" size="60" maxlength="128" class="form-textfield error form-control" aria-invalid="true" data-component-id="radix:input" data-once="coupon-redemption-code">

But 'aria-invalid' should be false.

The CSS selector for the invalid marker is:

.was-validated .form-control:invalid, .form-control.is-invalid {}

So I think 'is-invalid' should be set on the input.

But this won't work either, because:

.was-validated .form-control:valid, .form-control.is-valid

(green checkmark)

overrides the .is-invalid selector.

As of the docs, this is due to this:

• To reset the appearance of the form (for instance, in the case of dynamic form submissions using Ajax), remove the .was-validated class from the
  again after submission.
• As a fallback, .is-invalid and .is-valid classes may be used instead of the pseudo-classes for server-side validation. They do not require a .was-validated parent class.

https://getbootstrap.com/docs/5.3/forms/validation/#how-it-works

The coupon code submission triggers an AJAX update of the form, so as I understand it, the "was-validated" class should be removed then? Or should it be removed in general, as server-side validation is the default in Drupal? Of course "was-validated" is set by the BS JS, so "needs-validation" should be removed in case of server-side validation.

Without the was-validated class on the form and with the is-invalid class on the input, everything seems fine.

Added further informations (tested in a fresh simplytext installation).

I can confirm the shown issue and difference. This fix restores the error details for the browser console and helps a lot debugging these errors.

thomas.frobieter → created an issue.

Here is a dirty (CSS) workaround to prevent (end)users from running into this. Otherwise the user will see an error message in the PSWP layer.

// Quickfix for the missing Photoswipe / PSWP SVG support
// Make the link not clickable.
// See: https://www.drupal.org/project/photoswipe/issues/3294118
a.photoswipe:has(.no-image-style),
a.photoswipe:has(img[src*=".svg"]) {
  pointer-events: none;
}

With the patch everything works perfectly fine in the admin forms & on frontend. The field description is rendered separately as usual.

So RTBC from my side.

Very hard to work around this issue without the patch if the rendered description markup is included in #suffix and of course, it looks completely broken. So it would be very nice to have this merged & released soon.

Not a pro regarding css, but the css still contains the cdn url for me, or am I simply looking wrong? Looking at the header "style" section:

Sure, we can't remove this, we can only override it in our CSS file. If you look in the dev consoles network tab, you should not see any images loaded from the libs CDN.

@anybody State API, conditional fields. If "enable controls" is true, the "show 360 logo" option is hidden.

But... auum, @grevil this seems wrong? The 360° logo setting depends on the autoplay setting. If autoplay is true, the 360 logo will never appear. So if autoplay is true => hide the "show 360 logo" option.

And yes, without custom code there is nothing we can do here. From my point of view it is fine to set this to 'not fixed'.

Because "lozad.js" works out of the box, we should use this: https://codesandbox.io/p/sandbox/js-cloudimage-360-view-examples-8iukcn

Double-checked that images are actually loaded (even when autoplay is off). This is the case, so we need to fix this.

So, I think we're done here. Someone pls review!

Its not possible to use HTML5 native lazy loading, because the module just passes a list of images through 'data-image-list-x'.

The library supports lazy loading with third party libraries:

Lazy loading is not included into js-cloudimage-360-view by default. There are well thought libraries to achieve that. If you enable lazy loading in the configuration, you need to add an additional library like lazysizes, yall.js (Yet Another Lazy Loader), lozad.js to handle it.

See: https://github.com/scaleflex/js-cloudimage-360-view?tab=readme-ov-file#-...

So I think this needs another boolean option in the field formatter. If true we need to attach one of the libraries and set data-lazyload="true" as further attribute (+ data-lazyload-selector according to the lazy load library we choose).

This is the default behaviour of the library, so I don't think we should change it (in the Drupal module), nor should we spend time on it @Anybody?

Seems the trouble was indeed caused by our older fixes.

Yes, I thought so too. I've already tested this, but removing the changes didn't change anything.

I also looked for settings in the text format, but didn't find anything related o.O ... I'll check again.

The new version is already out ;)

thomas.frobieter → created an issue.

All other templates in 4.x are fine.

@grevil Please reassign me to this issue once 📌 Add missing important options to the field formatter Fixed is fixed so I can check that all images are now served locally.

Okay, so the images are used, but we currently miss some options to enable the controls etc: 📌 Add missing important options to the field formatter Fixed

thomas.frobieter → created an issue.

thomas.frobieter → created an issue.