Wysiwyg-editor: Toolbar sizing is broken in 3.1

[inssein]

According to the release notes:

Fixed 'toolbarButtons' option to be responsive to editor size, not viewport size as it was

However, in our application, at the largest size (960px), it is showing the toolbarButtonsSM, which makes toolbar customizations pretty difficult.

[cauethenorio]

Same here, we need custom break points to decide which toolbar layout to use.

For instance:

{
    // editor options
    toolbarButtons: {
        // will be used when editor width is 500px or smaller
        '500': {
            moreText: {
                buttons: ['bold', 'italic', 'formatOLSimple', 'formatUL', 'paragraphFormat'],
                buttonsVisible: 2,
            },
            moreRich: {
                buttons: ['insertImage', 'insertVideo', 'insertLink', 'insertTable', 'documentLinkButton'],
                buttonsVisible: 2,
            }
        },
        // will be used when editor width wider than 500px
        'bigger': [
            ['bold', 'italic', 'formatOLSimple', 'formatUL', 'paragraphFormat'],
            ['insertImage', 'insertVideo', 'insertLink', 'insertTable', 'documentLinkButton']
        ]
    }
}

[inssein]

From dealing with support, it doesn't look like this is going to get resolved. For the interim, I wrote this to return the functionality to be same as pre Froala 3.1. This has a high chance of breaking in newer versions, so use it with caution:

const originalHelpers = FroalaEditor.MODULES.helpers;

FroalaEditor.MODULES.helpers = function() {
  const helpers = originalHelpers.apply(this, arguments);

  helpers.screenSize = function() {
    if (window.innerWidth >= 1200) {
      return FroalaEditor.LG;
    }

    if (window.innerWidth >= 992) {
      return FroalaEditor.MD;
    }

    if (window.innerWidth >= 768) {
      return FroalaEditor.SM;
    }

    return FroalaEditor.XS;
  };

  return helpers;
};

[vpekarek]

I changed screenSize fn like this:

function screenSize() {
  try {
    var width = editor.$el.width();

    if (width < screenSm) {
      return FroalaEditor.XS;
    }

    if (width >= screenSm && width < screenMd) {
      return FroalaEditor.SM;
    }

    if (width >= screenMd && width < screenLg) {
      return FroalaEditor.MD;
    }

    if (width >= screenLg) {
      return FroalaEditor.LG;
    }
  } catch (ex) {
    return FroalaEditor.LG;
  }
}

Because you have access to instance of editor beeing initialized, you can use its element width.

Currently talking with support. Hope they will improve it a little.

EDIT: You must edit function in froala_editor.js to have access to current instance of editor. Better to modifi all helper fn tu have access to current instance.

[phroggar]

The change to use the editor-width is absolutely good imo. As the screen/windowsize is not really useful when deciding about the toolbar.

We have identified 2 problems and try to push a change/fix via support ticket:

1. The width needs to come from the active instance of froala (currently the first instance is used, which causes trouble when having multiple instances on screen with differing widths) - https://jsfiddle.net/x3g1cra5/1/

2. The thresholds are currently still using values from a window/screen gridsystem and should either be drastically reduced to fit real-life editor usecases or better: be adjustable.

So currently it is:

• toolbarButtons for large devices (≥ 1200px)
• toolbarButtonsMD for medium devices (≥ 992px)
• toolbarButtonsSM for small devices (≥ 768px)
• toolbarButtonsXS for extra small devices (< 768px)

but the sizes have not been adjusted to work with "editor width" and would be much more useful like this:

• toolbarButtons for large EDITOR (≥ 840px)
• toolbarButtonsMD for medium EDITOR (≥ 640px)
• toolbarButtonsSM for small EDITOR (≥ 480px)
• toolbarButtonsXS for extra small EDITOR (< 480px)

[allanedk]

but the sizes have not been adjusted to work with "editor width" and would be much more useful like this:

I agree on this. And IMO this change should have been marked as a breaking change in the release notes.

Using the editor width as breakpoints has made the feature unusable on my site. The smallest breakpoint (XS) is always used, even on a large device. The editor is newer wider than 768px because the page is using (Bootstrap) grid to show/hide more columns the depending on the screen/viewport size.

Did anyone find a lasting solution to this (i.e. without tweaking the source code)?

[vpekarek]

You can use this code for @inssein reply here.

You don't need to modify source code, and I think you can still access editor instance in arguments. But not sure. Using the EDITOR width was not working well in resizing the window. So I return to window.innerWidth. It is not best solution, but don't have time to fix it. Mostly because we pay a lot for this product, and their support sucks.

[allanedk]

Okay. I misunderstood and thought that it required a change in the source code.

I just tried @inssein code and it works.

Thanks a lot.