[bootstrap] Add support for the Off-canvas dialog used by Settings Tray and Layout Builder

Currently, no. Will this likely happen anytime soon, no. Patches are certainly welcome.

Re-adding the workaround mentioned in #2825778: Issue with Settings Tray(outside_in) core module

Go to Administration -> Appearance -> Your Enabled Theme Settings -> JavaScript tab under Bootstrap Settings -> Modals, and disable "Enable Bootstrap Modals".

Settings Tray will work.
It does definitely need some CSS work.

This css files to fix the outside-in style.

As stated in #2, please create a patch against the 8.x-3.x branch.

Furthermore, disabling the modal isn't an acceptable "solution". Obviously there needs to be some changes made to some JS files for this to work properly.

I am not very experienced with Bootstrap modals but here's what I have found.

The AJAX request itself works just fine and modal content (the one coming from Outside-in module) successfully loads into the browser. The error happens when JavaScript tries to fire off that modal content and actually present it as a dialogue box.

Bootstrap overrides ./core/misc/dialog/dialog.js with its own file. In particular, it overrides the definition of Drupal.dialog. It becomes (it's only a fraction of the whole definition):

    var dialog = {
      open: false,
      returnValue: void(0),
      show: function () {
        openDialog({show: false});
      },
      showModal: function () {
        openDialog({show: true});
      },
      close: closeDialog
    };

    return dialog;

where openDialog() in turn actually fires Bootstrap native $(...).modal(). So it actually gives {show: false} to bootstrap .modal() when the dialog is not in modal mode (native Drupal dialog.js distinguishes between modal & non-modal). Reading Bootstrap docs on show argument:

Shows the modal when initialized.

So Bootstrap theme explicitly asks Bootstrap not to show the dialog if it's not in modal mode. That's an error. In both cases (modal & non-modal) the show should be true.

In fact, the outside-in module does send the ajax response requesting non-modal dialog. Here's a snippet from Drupal\outside_in\Ajax\OpenOffCanvasDialogCommand:

public function __construct($title, $content, array $dialog_options = [], $settings = NULL) {
    parent::__construct('#drupal-offcanvas', $title, $content, $dialog_options, $settings);
    $this->dialogOptions['modal'] = FALSE;
    ...
  }

Since Boostrap framework does not distinguish between modal and non-modal dialogs, I think the solution is to simply show dialog in both cases.

I attach the patch. With this patch the outside in works as intended. I simply remove the {show: true/false;} setting since show is true by default in boostrap framework.

Sorry, forgot to switch the issue status.

Hi bucefal91,
Thank you for the detailed description.

After applied the patch there's a new error in console

Uncaught TypeError: $element.dialog is not a function(…)

i think there's another issue with it.

Hi!

Indeed I overlooked that part. Frankly, the best I could come up with is still rather crappy. Here's the issue: Drupal core does its dialogs via jQuery UI. Bootstrap does its dialogs via its own JS. Since Drupal is extensible, JS event must be fired whenever something important happens with a dialog (such as "dialog has just opened" or "dialog has just closed"). See bootstrap/js/misc/dialog.js or its ./core/misc/dialog/dialog.js counterpart for an example of those events (where they are triggered).

Since there are events, apparently, sooner than later there will be somebody (some code) that wants to listen to them. outside_in module actually does listen (see ./core/modules/outside_in/js/offcanvas.js). And here comes the bad news: apparently, the outside_in JavaScript that reacts to the event expects the dialog to be "cooked" on jQuery UI and it invokes various jQuery UI functions, but the dialog is "cooked" on Bootstrap modal.js and as you can guess none of the offcanvas.js event listeners work as intended for this reason :)

That's why you observe the error in your console. There is no real fix to it: it's just API (architectural) discrepancy. Drupal core dialog is jQuery UI and Bootstrap overrides it to its own modal.js implementation. You can't glue these 2 entirely different implementations unless Drupal core gives some interface of JS dialog and ability to implement that interface for themes/modules. Then the event listeners would work with actual implementation through that interface instead of directing pulling strings of jQuery UI.

Having that said, there's always a dirty way to get job done - is there ever no such dirty way? :) I simply slightly overwrite the ./core/modules/outside_in/js/offcanvas.js so the dialog is not requested in "off canvas" but as a normal modal dialog (which it is, in fact, because it renders as a modal dialog and not aside (offcanvas) as in Batrik theme). And that way the conflicting code no longer runs its event listeners (because it actually reacts only if the dialog is in "offcanvas") and consequently the error disappears from the console.

So basically I solved this very specific JS error, but probably many will come here and there because of this architectural difference (jQuery UI vs Bootstrap modal.js implementations). Yet it's the best we can do.

After deploying this patch on another Drupal instance I saw that in the 2nd Drupal instance my outside_in.js override was included before the original one (coming from outside_in module). So I had to recode a little bit how Bootstrap handles libraries in order to make sure my file goes after the original one.

The interdiff.txt is against #9.

apparently, the outside_in JavaScript that reacts to the event expects the dialog to be "cooked" on jQuery UI and it invokes various jQuery UI functions

That's really, really horrible news... but honestly not entirely unexpected considering that many (core) just "assume" that a site will be using jQuery UI.

So, we have a few options:

1. Push back with a core issue saying that they're assuming way too much regarding jQuery UI (which I'm more in favor of as I created the above related issue).
2. Completely override all of outsite_in JS code so it'll work with Bootstrap (which I'm really not in favor of as it'll put a burden on this project).
3. Do the same as above, but as a separate (standalone) project.

Regardless, this is an experimental project, so I'm postponing on the above revelations/issues.

Yep, of course #2 & #3 from your list is a short-looking way to solve it. Though good luck with your ticket against Settings Tray core module :) As far as my experience tells, it may take awfully huge amount of time to get a resolution on it.

At least for now we have a patch that dirty solves the issue.

Settings Tray is going to play a very big and important role in the following time.
See what it can do: https://www.youtube.com/watch?v=vr-AqQmLoGs&t=11s
Having the support for it to come out of bootstrap theme, will many bootstrap subthemes a lot.
I will be adding the solution in my subtheme not in the bootstrap theme.

I know what it can do. That isn't the point. The point is that it is an experimental module. Meaning that all these "issues" with contrib (like this base theme) are issues that need to be solved by core itself before it can be properly accepted as a "stable" module. It's like trying to chase the alphas of Bootstrap 4; it just doesn't work.

That is why they put them as experimental in the first place, to see where the bugs are. If it turns out we need to do some work here, then we'll do it. However, the more we can push back to core so they can abstract the module enough so it works within established APIs, the better for everyone, not just this project.

No one from core has yet even commented on the core issue I created. I'm not saying we aren't going to support it, just that we need to figure out the right way to proceed.

Got that Mark.
Agree with you.
I will follow with your issue #2830882: Introduce Drupal.offCanvas, mirrored after Drupal.dialog, to avoid Settings Tray using Drupal.Dialog in unintended ways

Rewarded :)

Adding related issues.
I am working on patch to make it easier for themes like Bootstrap support the module #2830882-45: Introduce Drupal.offCanvas, mirrored after Drupal.dialog, to avoid Settings Tray using Drupal.Dialog in unintended ways
But these would need to be fixed.

I'm fairly certain that #2831237: Bootstrap modal does not work well with jQuery UI dialog will take care of this issue. If it doesn't, then please re-open with a relevant patch.

Noted

@markcarver this is much closer now that #2831237: Bootstrap modal does not work well with jQuery UI dialog. thanks for that!
This probably a lot closer to working now but still some styling work.

Now the off-canvas dialog is under core/misc and module can use and are starting to. Settings Tray is no longer experimental. Also Layout Builder is using the dialog.

I don't have time to upload a patch now but just to open again as known problem

As Layout Builder starts actually being used, it would be nice to get this issue addressed.
Unchecking the 'Enable Bootstrap Modals' box does make Layout Builder usable again, but users shouldn't be expected to do this.
Are you still waiting for some sort of core fix, or should the CSS just be fixed bootstrap-side?

Are you still waiting for some sort of core fix, or should the CSS just be fixed bootstrap-side?

#2831237: Bootstrap modal does not work well with jQuery UI dialog should have taken care of the majority of the functional [JS] issues with dialogs/modals.

Any remaining issues are likely to be mostly stylistic in nature, which can be addressed in this issue.

Personally, I have little to no vested interest in fixing this at this time.

I, nor any of my clients, use the layout builder as it only came out as "stable" well after these sites were constructed.

With my maintainer hat on though, I understand the desire to have this functionality supported "out-of-the-box" with this base theme.

I'm not opposed to committing improvements for this feature, but the work will need to be done by others for the time being.

Most, if not all, of my contrib work is currently focused on #2554199: Bootstrap 4 right now; which takes precedence over a relatively new Drupal feature.

I will provide reviews when I am able.

I, nor any of my clients, use the layout builder as it only came out as "stable" well after these sites were constructed.

Layout builder is "stable" now... :)

When I am disabling modal from theme settings modal not working for the authenticated user but working fine for the .admin user.
I have added

dependencies:
    - core/jquery
    - core/drupal.dialog.ajax

Now I am Getting a bootstrap undefined error.
Javscript loading in this order for authenticate user

<script src="/themes/contrib/bootstrap/js/misc/dialog.ajax.js?q96y1s"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@3.4.1/dist/js/bootstrap.js" integrity="sha256-29KjXnLtx9a95INIGpEvHDiqV/qydH2bBx0xcznuA6I=" crossorigin="anonymous"></script>

Is there any fix for this?

I came here after searching for issues with Drupal's core Layout Builder not working when using custom theme.

What I found to work in the end was to reposition <js-bottom-placeholder token="{{ placeholder_token }}"> in my html.html.twig template so that it was a direct child of <body> tag.

Here's what my corrected web/themes/custom/ecfp/templates/layout/html.html.twig template looks like with the above change:

<!DOCTYPE html>
<html{{ html_attributes }}>
  <head>
    <head-placeholder token="{{ placeholder_token }}">
    <title>{{ head_title|safe_join(' | ') }}</title>
    <css-placeholder token="{{ placeholder_token }}">
    <js-placeholder token="{{ placeholder_token }}">
  </head>
  <body{{ attributes }}>
    <div class="site">
    {#
      Keyboard navigation/accessibility link to main content section in
      page.html.twig.
    #}
    <a href="#main-content" class="visually-hidden focusable">
      {{ 'Skip to main content'|t }}
    </a>
    {{ page_top }}
    {{ page }}
    {{ page_bottom }}

    </div>
    <js-bottom-placeholder token="{{ placeholder_token }}">
  </body>
</html>

The <js-bottom-placeholder token="{{ placeholder_token }}"> is where Drupal puts some of the js files used for layout builder, inside a <script></script> tag enclosure. The above change in the template ensures that this <script></script> tag enclosure is a direct child of <body> so that Drupal js can find it.

This fix also meant that related JS errors seen in the web brower's Console were no longer occurring ( Uncaught TypeError: Cannot read ... , Uncaught TypeError: Cannot set ... )

Credit:

My comment about this on the helpful answer to How to fix Uncaught TypeError in Drupal 8 core Javascript

This might help some of you (hope so). It may also help others, like me, who landed on this issue after a search about Drupal Core Layout Builder broken or partially working (as in my case), whereby the pencil/pen widget in a circle did not show on hovering over a block.

I'm using Drupal 9.1 where this solution above worked. Once again, posting here to share the situation and where I got it to work. Thank you!

#27 is working for me.....

My html.html.twig code structure was:

      <js-bottom-placeholder token="{{ placeholder_token }}">
    </div>
  </body>
</html>

I updated my html.html.twig file with code :

      </div>
    <js-bottom-placeholder token="{{ placeholder_token }}">
  </body>
</html>

It means JS bottom palceholder code <js-bottom-placeholder token="{{ placeholder_token }}"> must be place before </body> tag

It looks like the template change was made with a commit on Sep 26, 2015 marked under issue #2565675: [Chase core] Use placeholders to include JS/css/... in html.html.twig. Check any subtheme template overrides in case you need to update your templates there.