maybe this can be fixed with css. Does it never show up, or can you scroll up to see it? what browser/os are you using? maybe we can make it sticky but at the top. The issue is, that some browsers recently tried to be “creative” and moved the browser bar to the bottom.
Browsers are Firefox & Chrome in Android on a Motorola phone. Same thing happens with Discourse app.
The button bar is always there, it is just underneath a pop-up menu whenever the selection is in the 1st 3 lines visible in the text box.
A workaround is to insert 3 CR/LF (carriage return/linefeed) before the 1st text. Then delete those extras before posting.,
yeah I just tested it. I get what you mean. its super annoying. But I think bars at the bottom are even worse. And also I need to research how to do this and I dont get paid for it. But probably there is a cleaner way to do it. I bet other projects have the same problem and there is a standardized solution. But as I said I have other priorities. Sorry to be so frank
The workaround is viable, merely inconvenient.
There’s probably a mobile CSS approach for this annoyance. I’ll just have to hunt it down.
Adding a lot of code for this special case would not be a great use of your time & attention. (Plus it adds overhead.) Thank you for sharing your projects with community. It has been very generous of you.
ok thank you very much for the report. I just fixed it
Just a tip, rails adds the method
.present? in a few ruby classes which is better than comparing with empty strings. It works with arrays and strings mostly.
.empty? which is opposite of the
I removed this button on purpose because images need to be uploaded through the editor. But I just discovered the file selection menu does not popup on android firefox for some reason. To investigate this i have to install remote debugging. So it will take some time to fix. Until then just use the advanced editor to upload images.
EDIT: actually it works perfectly fine. It was just not opening because I denied the app camera access before. So you can just use the same image upload button that you would use on desktop. look at the screenshot that I uploaded to test it if you are confused:
I want to enable only Bold, Italic, Link and Image upload option inside the toolbar how can i do that?
I will add an option to configure it once its done.
Means there is no work around for this? Can i not edit the config file for the ckeditor that you have used inside the plugin?
Are you going to make it work with other plugins like w.g. Image Annotation, BB markup, etc?
Okay let me clarify something: when I talk about “things not working” i just mean they dont get rendered in the wysiwyg input window. Everything still works in the final post. this editor is just a different way to create markdown at the moment. Its still markdown coming out at the end. From my perspective “html only” is the way to go in the future. Markdown, bbcode etc. is a thing of the past that delivers an overly complex user experience. But obviously I am not going to implement every single bbcode feature or custom plugin. Because I dont get any benefits from this. First and foremost I care about my use case. But I also care about simplifying the UX of Discourse for others as well. If you like markdown, bbcode and all these “tags” in your editor then maybe this is not the right thing for you.
I would also like this discussion to become more constructive. I would be glad to hear about the use cases and reasons why people want to use a wysiwyg editor instead of the current one. I am also interested to hear what benefits you expect from this and what goals you want to achieve?
Maybe that can lead us somewhere. “can you do all these random things? …(for free)” is not helpful.
Switching to HTML and not supporting markdown will make all posts created in HTML uneditable once your plugin is turned off. Is this correct?
@spirobel although I personally don’t use your plugin I admire it’s functionality and salute you for your great effort!
Although I can agree on bbcode being a legacy syntax, the notion that markdown is a thing of the past is incorrect from my perspective - quite the opposite, the basic feature set is here to stay for a long time.
The main two reasons are;
- Format by typing - you can correctly format text simply by typing away which makes it easy to focus and type productively
- Readable even when not rendered - the basic markdown syntax is instinctively readable as raw text which is very handy for many reasons.
It is when you try to extend markdown features (images, tables etc.) I think it tends to falter and sometimes break down due to illegible syntax which is cumbersome to type.
In my view, the best editors offers a type of hybrid solution;
- Basic syntax formatting renders inline while still rendering the syntax characters in edit mode.
- Extended features (images, tables etc) should obviously also render when in edit mode, and perhaps not be represented by the the actual syntax characters on screen. Perhaps, dare I say, they should be considered as plugins and be stored in a format most fitting the data type.
Thank you very much for your comment!
I understand what you mean. But I still disagree. In the long run powerusers are better served with shortcuts. For example there could be a shortcut for italics. So you could press the shortcut while still typing away. The shortcut might even be something like CTRL+* so its almost like using markdown.
Regarding 2. I can say that html is also readable because its always rendered (in the browser) and if you look at a piece of html in a texteditor you can also read it. Okay, markdown might look a bit more pretty, but only if you stick to very basic features and then it does not matter anyhow.
The hybrid solution is sadly not feasible. One of the reasons I drank the html only koolaid is because it allows me to focus on building a user interface instead of getting a phd in computer linguistics while debugging language parser bugs. The idea is to reduce the technical debt not add onto it.
In the end I can understand very well where you are coming from. I also read the scripture on markdown. But to me, the html only paradigm is more convincing for what I am about to do. I also realize there is no point in converting people that really like markdown. They should stick with the editor like it is now. But I think there is a different crowd that might be interested in going a different route. This plugin is also way more than just the wysiwyg editor. I have this vision to use discourse to build software that enables people to collectively edit structured data without needing to learn a markup language. If you look at big projects like wikipedia or wiktionary and all the formalities that are involved in contributing to those I see so much wasted potential. I want to change that. And if I want to change that, I need to take the collaborative features of discourse while throwing away this concept of needing a markup language to enter data into the system.
I understand why it was used in discourse in the first place and the reasons are really good. But my goals are different, so I also follow a different paradigm.
Great Plugin, @spirobel! This is what our very non-techy users need and I think that it will grease the wheels of our site markedly. Thank you for the time and effort that you have put into it. I’ve noticed a couple of issues that may be helpful
Clash with Shared Edits
I’ve just installed both this and Discourse Shared Edits. Somewhat unsurprisingly, they clash a little bit. But it looks like it might be in a fixable way. Would you consider looking at making them compatible? Personally, I see them as both being indispensable into the future.
What happens is that when I Shared Edit a post using the Basic Editor, the existing text in the post is wiped and can only be retrieved by rolling back the edit.
@mentions not giving suggestions
Discourse Basic Editor seems to break @mentioning partially. When I try to mention you here, I get this:
When I activate Basic Editor, the suggestions no longer occur. This is also the case if I click Advanced Editing.
yes. This is still very much work in progress. The mentions are on my list. I haven’t looked at shared editing yet, but its certainly possible to implement it. But possibly it will not happen by ensuring compatibility with the shared edits plugin. The change that basic editor introduces is quite significant, so it will most likely need to be a solution inside of the basic editor.
Have you spoken with @sam about it? He might be interested in the possibility and is sure to give sage advice.