You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a thread specifically to collect feedback regarding issues and limitations of the new WYSIWYG editor, introduced in BookStack v24.10, during its beta phase which starts as of BookStack v25.05. This follows on from thread #5245.
This below list will be continuously updated from feedback to form a full listing to be worked on.
Please only report issues where not already in this list.
Generally our goal is to match the existing TinyMCE based editor as close as possible.
Known Issues
Switching editor to new editor with bold text can lead to double-bold. ref.
Text formats can carry across to below non-formatted existing lines. ref
One thing that I recently added to our instance was the PDF embedding script - I haven't tried to modify the script to function on the new editor, but there is currently no way to embed a PDF into the page. Maybe their file import/export feature? though I haven't tried this.
Another thing that we like to use (though I will note, it's not officially supported, but with a small code tweak, you can add the functionality to the original wysiwyg editor) is the alphabet bullet list. While I understand it's not officially supported, the sheer capabilities of tinymce allow extended customization that BookStack does not include out of the box.
Lexical does not currently support more than 3 out of the box solutions as sited in this issue. facebook/lexical#6327
Lastly, assuming that the choice to add lexical is inevitable regardless of issues, can we look into including more out of the box functions through their addons and plugins? Such as dragon naturally speaking,
PDFs could technically be embedded via iframe/embed/object elements, which we do support in the new editor. This is something we could make easier (like we do for adding video attachments), but official support for that is outside the scope of this thread. I have not yet exposed any internals for customization/extensibility, that is probably something I start to plan out later in this beta stage, to emulate some of the common abilities of the TinyMCE editor.
As above in regards to extensibility, although some of this may be achievable via css and external customization (especially as this is just a visual/style difference to ordered lists, which we do support). I wouldn't consider too much about what Lexical supports for the reasons stated in the next point.
I would not look to add more for the sake of it showing in lexical examples or the list of available modules. If there's reason to add something that can be raised via it's own worth/need, otherwise the scope will remain limited. With lexical, what you might see in their example is not things we have, or can directly, use. I have forked some core parts of the editor. All of the UI, many of the format types and much of the behaviour has been written custom from scratch by me, to emulate our existing editor as best as possible while not having to rely on the same frameworks/libraries (like React) which they use within their ready-provided implementations. I've also made customizations to the core elements as part of our fork. This is quite a different and extensive approach compared to what we had with TinyMCE, giving us more control (at the cost of maintenance and effort), but it does mean that much of what you may see elsewhere with lexical is irrelevant, at least relative to how you might have previously referred to TinyMCE guidance for prior options/customization/extension since we worked upon a standard provided library as-is there.
Since this is still in "beta", are feature requests possible ?
inline code (perhaps its already possible)
de code button as one of the default buttons ? (or make this a setting?)
Our use case includes allot of system paths, code snippets and configuration examples, therefor we use it way more then for example aligning center/right/justify.
@svennd Inline code is already possible via a button in the overflow of the inline formats menu (or alternatively via shortcut):
The purpose of the current phase is to match the existing editor, I'm not looking to move things around or add features but we can think about that in the future after the default editor switch has occurred.
Hey Dan, I just found a styling bug (at least to my eyes it's a bug):
If you make a regular paragraph bold, in the old editor, the font-weight is "bold".
But if you switch to the new WYSIWYG beta, if you save the page marked as bold, the font-weight is "bolder", which IMO doesn't look as nice.
I understand the issue of font editing has been addressed, and while I personally don't have an issue with custom css, the omission of a font and font size selector in the editing toolbar/ribbon threw me at first and I don't doubt has put a lot of potential users off. Surely more important to be easily accessible than bold, italic, and underline buttons, the keyboard shortcuts of which are much more widely known than how to import a custom font or change its size in CSS. If compatibility is the issue, im sure a selection of standard websafe fonts would be adequate.
@PancakeZik Just as a warning, the double/extra bold will be addressed for the next patch release, but existing saved content may stay double-bold until re-edited & saved in the editor (should fix itself when content is opened in editor).
BookStack version: v26.03.2 Editor: New WYSIWYG editor (wysiwyg2024 / Lexical)
Issue:
When writing content in the new WYSIWYG editor and exporting a page as Markdown, the resulting .md file contains <span style="white-space: pre-wrap;"> tags wrapping regular paragraph text. These tags are not rendered by any standard Markdown viewer and pollute the exported content.
Steps to reproduce:
Create a page using the new WYSIWYG editor
Write a simple paragraph
Export as Markdown
Open the .md file — every paragraph text is wrapped in <span style="white-space: pre-wrap;">...</span>
Expected behavior:
Plain Markdown paragraphs with no HTML span tags.
Note:
This appears to be introduced by the Lexical editor storing white-space: pre-wrap as inline style on text nodes. The old TinyMCE editor did not produce this output.
Use the table icon in the top bar (not the one in the pop-up)
Select Cell Properties / Cell type = Header cell
@ssddanbrown I think there should be an easier / more accessible way to do that, or even better, make it the default. In my opinion, having a header row is the more common use case for tables, no?
The first edit of a page does not set the format correctly.
Only if you start typing the format "paragraph" is selected.
You also cannot change the format to anything else without typing first. If you set it in the drop-down to let's say a call-out, then this is ignored, and as you start typing, "paragraph" is still set automatically.
It is impossible to break out of ordered and unordered lists unless you are on the last empty item.
Use cases are to split existing lists into two separate ones, which is virtually impossible without manual copy and paste, or reformatting all the list items manually again.
There does not seem to be an intended shortcut to go to the table popup menu(?). However, if you select some text and hit the tab key, you're suddenly in that pop-up and can tab through the options (see focus border) and also activate one. I have not found any way to abort and move focus away from the popup with the keyboard only.
Moving the cursor between cells is awkward in some cases. For example, using up and down arrows to move between cells results in the cursor jumping to the beginning and end of the cell content, respectively.
This is different from the old editor and most other editors I'm used to, which try to keep the "rough" location of the cursor. For example, if you put the cursor in the middle of the two text fragments "ABC ABC", it is expected that it stays there when you move the cursor up and down between cells.
The behavior gets worse once you start adding more formatting to table cells. For example, if you add an unordered list, it is basically impossible to move from the list to the first line of the cell with the up arrow key.
In the same way, it is impossible in this example to move to the last bullet point from the second to last one, using the down arrow. The last item always is skipped and the cursor moved to the next cell below (you can briefly see that in the beginning of the GIF).
@Gortus I feel your concern may be better suited to its own request for the ability to customize editor shortcuts as you suggested. Ctrl+K was used just because it's very common for links (including in this GitHub editor).
Activity
joshhcd commentedon May 29, 2025
One thing that I recently added to our instance was the PDF embedding script - I haven't tried to modify the script to function on the new editor, but there is currently no way to embed a PDF into the page. Maybe their file import/export feature? though I haven't tried this.
Another thing that we like to use (though I will note, it's not officially supported, but with a small code tweak, you can add the functionality to the original wysiwyg editor) is the alphabet bullet list. While I understand it's not officially supported, the sheer capabilities of tinymce allow extended customization that BookStack does not include out of the box.
Lexical does not currently support more than 3 out of the box solutions as sited in this issue.
facebook/lexical#6327
ssddanbrown commentedon May 29, 2025
@joshhcd
PDFs could technically be embedded via iframe/embed/object elements, which we do support in the new editor. This is something we could make easier (like we do for adding video attachments), but official support for that is outside the scope of this thread. I have not yet exposed any internals for customization/extensibility, that is probably something I start to plan out later in this beta stage, to emulate some of the common abilities of the TinyMCE editor.
As above in regards to extensibility, although some of this may be achievable via css and external customization (especially as this is just a visual/style difference to ordered lists, which we do support). I wouldn't consider too much about what Lexical supports for the reasons stated in the next point.
I would not look to add more for the sake of it showing in lexical examples or the list of available modules. If there's reason to add something that can be raised via it's own worth/need, otherwise the scope will remain limited. With lexical, what you might see in their example is not things we have, or can directly, use. I have forked some core parts of the editor. All of the UI, many of the format types and much of the behaviour has been written custom from scratch by me, to emulate our existing editor as best as possible while not having to rely on the same frameworks/libraries (like React) which they use within their ready-provided implementations. I've also made customizations to the core elements as part of our fork. This is quite a different and extensive approach compared to what we had with TinyMCE, giving us more control (at the cost of maintenance and effort), but it does mean that much of what you may see elsewhere with lexical is irrelevant, at least relative to how you might have previously referred to TinyMCE guidance for prior options/customization/extension since we worked upon a standard provided library as-is there.
svennd commentedon Jun 3, 2025
Since this is still in "beta", are feature requests possible ?
Our use case includes allot of system paths, code snippets and configuration examples, therefor we use it way more then for example aligning center/right/justify.
ssddanbrown commentedon Jun 4, 2025
@svennd Inline code is already possible via a button in the overflow of the inline formats menu (or alternatively via shortcut):
The purpose of the current phase is to match the existing editor, I'm not looking to move things around or add features but we can think about that in the future after the default editor switch has occurred.
PancakeZik commentedon Jun 6, 2025
Hey Dan, I just found a styling bug (at least to my eyes it's a bug):
If you make a regular paragraph bold, in the old editor, the font-weight is "bold".
But if you switch to the new WYSIWYG beta, if you save the page marked as bold, the font-weight is "bolder", which IMO doesn't look as nice.
Details
New editor:
Old editor:
virtadpt commentedon Jun 7, 2025
A thing that has now gotten in my way more times than not using the new editor:
The fix has been to go back to the old editor because it keeps tripping me up taking notes in class.
AGARES2101 commentedon Jun 7, 2025
Issue with Video Editing in BookStack (New WYSIWYG vs Old WYSIWYG)
Details
Problem Description
When adding a video in BookStack using the New WYSIWYG editor, I encounter the following limitations:
In contrast, the Old WYSIWYG editor allows:
Steps to Reproduce the Issue
Expected Behavior
The editor should allow:
Current Behavior (New WYSIWYG)
annie-things commentedon Jun 10, 2025
I understand the issue of font editing has been addressed, and while I personally don't have an issue with custom css, the omission of a font and font size selector in the editing toolbar/ribbon threw me at first and I don't doubt has put a lot of potential users off. Surely more important to be easily accessible than bold, italic, and underline buttons, the keyboard shortcuts of which are much more widely known than how to import a custom font or change its size in CSS. If compatibility is the issue, im sure a selection of standard websafe fonts would be adequate.
ssddanbrown commentedon Jun 13, 2025
Thanks @PancakeZik @virtadpt @AGARES2101, Have added these to be tested and addressed.
@annie-things Thanks for the input but that's outside the scope of this thread. There a prior related issues in #3330 and #1148.
ssddanbrown commentedon Jun 14, 2025
@PancakeZik Just as a warning, the double/extra bold will be addressed for the next patch release, but existing saved content may stay double-bold until re-edited & saved in the editor (should fix itself when content is opened in editor).
23 remaining items
balta1980 commentedon Feb 7, 2026
There is no way to format first row as title row
balta1980 commentedon Feb 7, 2026
In page edit mode, new diagrams made on tool draw.io does not refresh when edited, only refresh after you move another item.
bedeberger commentedon Mar 31, 2026
BookStack version: v26.03.2
Editor: New WYSIWYG editor (wysiwyg2024 / Lexical)
Issue:
When writing content in the new WYSIWYG editor and exporting a page as Markdown, the resulting
.mdfile contains<span style="white-space: pre-wrap;">tags wrapping regular paragraph text. These tags are not rendered by any standard Markdown viewer and pollute the exported content.Steps to reproduce:
.mdfile — every paragraph text is wrapped in<span style="white-space: pre-wrap;">...</span>Expected behavior:
Plain Markdown paragraphs with no HTML span tags.
Note:
This appears to be introduced by the Lexical editor storing
white-space: pre-wrapas inline style on text nodes. The old TinyMCE editor did not produce this output.ptrqn commentedon Apr 10, 2026
There is an alignment option in this menu. Centering works for me.
ptrqn commentedon Apr 10, 2026
@ssddanbrown I think there should be an easier / more accessible way to do that, or even better, make it the default. In my opinion, having a header row is the more common use case for tables, no?
ptrqn commentedon Apr 10, 2026
The table pop-up obscures other pop-ups, in particular the link pop-up of links in the last row.
I think content pop-ups should take precedence (z-index) over the table pop-up.
ptrqn commentedon Apr 10, 2026
The first edit of a page does not set the format correctly.
Only if you start typing the format "paragraph" is selected.
You also cannot change the format to anything else without typing first. If you set it in the drop-down to let's say a call-out, then this is ignored, and as you start typing, "paragraph" is still set automatically.
ptrqn commentedon Apr 10, 2026
It is impossible to break out of ordered and unordered lists unless you are on the last empty item.
Use cases are to split existing lists into two separate ones, which is virtually impossible without manual copy and paste, or reformatting all the list items manually again.
ptrqn commentedon Apr 10, 2026
There does not seem to be an intended shortcut to go to the table popup menu(?). However, if you select some text and hit the
tabkey, you're suddenly in that pop-up and cantabthrough the options (see focus border) and also activate one. I have not found any way to abort and move focus away from the popup with the keyboard only.ptrqn commentedon Apr 10, 2026
Moving the cursor between cells is awkward in some cases. For example, using up and down arrows to move between cells results in the cursor jumping to the beginning and end of the cell content, respectively.
This is different from the old editor and most other editors I'm used to, which try to keep the "rough" location of the cursor. For example, if you put the cursor in the middle of the two text fragments "ABC ABC", it is expected that it stays there when you move the cursor up and down between cells.
The behavior gets worse once you start adding more formatting to table cells. For example, if you add an unordered list, it is basically impossible to move from the list to the first line of the cell with the up arrow key.
In the same way, it is impossible in this example to move to the last bullet point from the second to last one, using the down arrow. The last item always is skipped and the cursor moved to the next cell below (you can briefly see that in the beginning of the GIF).
ssddanbrown commentedon Apr 28, 2026
BookStack is now managed on Codeberg.
As part of this change, we're closing all existing GitHub issues and pull requests.
You'll instead find this issue on Codeberg here:
https://codeberg.org/bookstack/bookstack/issues/5631
Any further discussion for this will now be done on Codeberg.
Therefore this GitHub thread will be locked.
ssddanbrown commentedon May 4, 2026
Thanks @ptrqn @bedeberger @balta1980 @TritonB7 @nadegr @shartcarbuncle @akolotilov
I've added the raised issues to https://codeberg.org/bookstack/bookstack/issues/5631 to be looked at in the next patch of fixes, aimed for the next feature release.
@Gortus I feel your concern may be better suited to its own request for the ability to customize editor shortcuts as you suggested. Ctrl+K was used just because it's very common for links (including in this GitHub editor).