mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-05 00:29:48 +03:00
Improvement: Per User Editor Type Setting #108
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @KTSCode on GitHub (May 26, 2016).
I'm using this as a wiki for my entire company, the developers and I would prefer to edit pages in markdown, whereas most of the other departments are not comfortable with markdown and much prefer the WYSIWYG editor.
It would be very useful to allow each user to set which kind of editor they would like to use.
An additional feature that would make this improvement better, would be the auto conversion from HTML to markdown when editing a page in markdown mode.
@bridgeyuwa commented on GitHub (May 29, 2016):
I will also like to add that, students using the system would like to be able to add and edit equations, formulas and Graphs.
I suggest the inclusion of a suitable TinyMCE plugin for Math and Graph
@ssddanbrown commented on GitHub (Jun 3, 2016):
@KTSCode Thanks for the suggestion. I did think about this while developing the markdown editor. My main issue is that there will be a loss of formatting between the two editor options. By nature markdown is very simple so will not fully support all features in the WYSIWYG/HTML editor. Would this potential loss/change of formatting when switching between editors be worth the benefit of per user editor settings?
@bridgeyuwa I'd consider that if there's a suitable high quality & maintained library we can use.
@Tybot204 commented on GitHub (Jun 15, 2016):
@ssddanbrown I think the loss of formatting would not be a huge deal in most cases. Maybe it is worth saving which type of editor was used last on each page and warn the user of potential formatting problems if the previous edit was made from WYSIWYG/HTML and the new editor's settings are set to markdown.
@bridgeyuwa commented on GitHub (Jun 15, 2016):
WIRIS is the best TinyMCE plugin I've come across. It's excellent for equations but lacks graph functionality. And its moderately maintained.. I think it should serve for a start http://www.wiris.com/en/solutions/tinymce
@ssddanbrown commented on GitHub (Jun 15, 2016):
@bridgeyuwa Thanks for the suggestion but, After a quick look, that plugin does not provide a clear open source licence so cannot be incorporated into BookStack.
@KTSCode commented on GitHub (Jul 13, 2016):
@ssddanbrown I agree with @Tybot204 it would definitely be worth it, and a simple warning dialog box or even a warning toast, would be enough to stop anyone from accidentally destroying formatting. The people who use markdown are usually developers or at least understand what potential harm could be caused.
I'm not sure if the license on this repository is OSS enough to allow it to be used, but it claims to preserve the HTML tags that do not have a markdown equivalent. I have not tested it
The main reason I created this issue is, because I often forget to change it back to WYSIWYG after editing pages and no one outside the Development Team will edit anything until it's changed back, even after I told them how to change it. I've had to stop using markdown mode and tell everyone not to use it, because if someone forgets to switch it back, or a 'WYSIWYG User' tries to edit it, at the same time, it makes them not want to since "it looks scary". I'm really trying to get everyone at the company to adopt the use of BookStack as our Wiki. It's only beneficial if everyone is willing and able to edit it.
Fixing this issue would allow the Development Team and I to use/enjoy the markdown feature. Without it having the markdown feature is useless to us.
Lastly I just wanted to thank you @ssddanbrown and everyone else who has contributed to this project, for providing me and my team with a great opensource way of sharing information and maintaining documentation.
@artonragsdale commented on GitHub (Nov 29, 2016):
I would also like to request this feature for similar reasons explained by @KTSCode. IMO it would be ideal to either limit the WYSIWYG editor to Markdown compatible formatting or try to preserve html formatting if necessary.
@patoroco commented on GitHub (Dec 27, 2016):
I'd prefer and WYSIWIG which writes markdown under the hood too.
It's nicer and easy to store in a database (most for search!)
@DDCMI commented on GitHub (Jan 19, 2017):
I would also like to add my voice to this. I would much rather see a scaled down WYSIWYG that could match the markdown so that both could be used and I could implement use with my whole team.
@s0n- commented on GitHub (Aug 11, 2017):
I am coming across this more and more as we use it. We have guys that exclusively use markdown and guys that need wysiwg. Has this been worked in.
@Abijeet commented on GitHub (Jan 14, 2018):
Just putting this here for review - https://nhnent.github.io/tui.editor/
License is fine but this obviously will not meet a lot of the stuff that we do with TinyMCE right now.
@hamen commented on GitHub (Feb 7, 2018):
Hi all, any updates on this? We just started using it and we are very interested in per-user editor setup.
Right now most of the pages created by devs look like plain-text markdown pages due to the WYSISWY default editor (used by the rest of the employees) 😕
@ssddanbrown commented on GitHub (Feb 11, 2018):
No real update right now, I've added some more recent comments more recently on a related issue: #369.
Please 'Thumbs-up' the original top post to show support for this feature as that's taken into consideration when choosing features for a release.
@pth0rn commented on GitHub (Aug 21, 2018):
Would also love this, even as is
@fbatiga commented on GitHub (Dec 30, 2018):
@ssddanbrown hello, any news on this ? any way we can help ?
@fbatiga commented on GitHub (Dec 30, 2018):
@ssddanbrown alternatively would there be a way for developer to switch to a different editor for the Markdown (eg. have github style markdown for example).
@JHenneberg commented on GitHub (May 7, 2019):
I posted my suggestion already in a different issue, but because it is also relevant in this issue I will poste the link here:
https://github.com/BookStackApp/BookStack/issues/842#issuecomment-487932048
@mateja82 commented on GitHub (Oct 21, 2020):
Hi, any chance this is being considered for any time soon? Let me know if we can help, there's a few of us from mh company waiting for it. Thanks
@alexohneander commented on GitHub (Feb 4, 2021):
We have exactly the same problem. The developers want to use Markdown and the graphics are overwhelmed with Markdown. It would be really great if you could select the editor based on the user.
@ssddanbrown commented on GitHub (Feb 5, 2021):
Just to update on this, An "Editor Alignment & Review" is the next major thing on the roadmap of big actions. This will be considered as part of that. These roadmap items do move slowly though.
@armandleopold commented on GitHub (Feb 25, 2022):
Would be really appreciated, keep up the good work Dan ;-)
Thanks
@ssddanbrown commented on GitHub (Apr 24, 2022):
Just to provide an update on this, PR #3387 has now been merged, which allows switching of editor type (If role permissions allow) from within the editor.
The editor type is then saved against the page itself, and uses the system setting as a default.
A preview can be seen here.
There are two choices when moving from WYSIWYG to Markdown:
PR #3387 has been merged and is targeted for the next feature release (Likely v22.04).
While this addition does not address this specific request (A user-level option/default) I think it does alleviate the pain point for this issue in most cases, and fundamentally meet the same goal.
I'd be interesting in hearing people's thoughts as to whether an additional user-level default is needed with this functionality change. While such a setting could be added, it would mean there's essentially three tiers of configuration for this editor option which could be confusing so I'd prefer not to introduce the complexity without strong and clear requirement.
Some may have expected this issue request to mean that a single page may open in markdown for one user, and WYSIWYG for another user (Without additional steps or interruption). This is not really viable within the current environment of BookStack and it's editors without potential problems. While an option could be added for this, for those that accept the consequences, it'd be adding a level of complication I would not really be happy with (At a codebase/logical level and in regards to impacting support/issue-handling).
@ssddanbrown commented on GitHub (May 11, 2022):
With the above mentioned addition (Which has now been released) I'm going to close this off since much of the intent in this thread would have been for editor switching in general, and since we'd need to take a different approach now anyway.
If the user-level default, as mentioned above, is desired, or if there's an alternative request, that can be opened as a new issue.
@Redsandro commented on GitHub (Sep 14, 2022):
This issue has been about different users using different editor types for the same page, and the per page editor switch in PR #3387 doesn't touch that. In fact, I think it makes things more complex and error prone. I understand the complexities and consequences are not desirable for all, but at the same time this solution does not fix the issue for all.
OP mentions colleagues wanting to edit the same page while having strong different MD vs WYSIWYG preferences. Personally I find that when having a family book where we write pages about events, older folks only dare to contribute in WYSIWYG and the younger folks find it frustrating when they can't use MD. I don't see 'my' seniors going through those dialogs.
Perhaps this is not about the editor used, but about the underlying data (ground truth) being MD or HTML, set by the administrator. In MD mode, the WYSIWYG editor needs to be limited to a subset of features equal to that of MD, so that the function set is still friendly towards those not inclined to be tech-savvy. To quote @DDCMI:
Can we reopen this issue? All conversation in this issue prior to #3387 is still open and relevant. I'm not sure it makes sense to open a new issue and lose the historical interest.
Even if this doesn't get picked up anytime soon or at all, at least the dozens of duplicate and related issues that can be found through google still link to this open issue.
@ssddanbrown commented on GitHub (Sep 14, 2022):
@Redsandro I won't re-open this since I believe the intended solution would have addressed the fundamental needs of many in this thread, or at least massively reduced friction, even if not specifically implemented as desired. With the switching functionality added, the context of conversation is now quite different.
Feel free to open a new feature request issue though, but please focus it in the fundamental requirement or user-need you have, and the benefits that would realistically achieve, rather than technical implementation idea/detail as provided above. This would allow exploration of alternatives where possible since, to be honest, it's very unlikely I'd be looking at supporting WYSIWYG/content-format variations any time soon.