Use BUeditor on drupal.org

I've never understood why we're requiring all our contributors to fuss with HTML markup when a machine could do it so much faster, easier and more reliably.

It's still a markup language, some of use know html, some people different ones. Personally I think it best to stick with a single markup language (my preference is html)

There's no question that this is a markup language, only that some markup languages are arguably more suited to human input. Or perhaps that some people work better in one language and others work better in another.

Couldn't the choice of HTML or Markdown be just a user preference that you set in your profile? Seems like only an implementation issue.

I agree its a language, but its a more simple language and has tools to make the use of it easier and quicker.

If we look at a couple of other large documentation type projects, Trac and Mediawiki, both use a simplified markup language. I think there are compelling reasons, for me its speed.

I used to think the same thing as Nevets, I know HTML so why bother, until I learned Markdown and now its hard to go back, its so easy and fast.

The argument to use a single language is reasonable, such as when a user wants to edit a page and has no clue what Markdown even is, which is why I thinks its worth considering the BU Editor with Markdown addon.

One thing I have noticed this past weekend (I updated around 40 pages) was the inconsistency and sometimes extremely poor use of HTML. Perhaps Markdown + BUEditor would help rectify this.

I agree that we need to make things a bit easier but my #1 reason against something like markdown right now is that if we want to start syncing the d.o pages with coded pages that can be used in a module (with say advanced help module or hopefully a new help system in core), we need to be careful about what is in the source document. Ideally we should be able to have docs that can be viewed in a browser *without* any filtering. Drupal filters on output, not input, so something written in markdown, or any other filter, is stored that way and then when displayed directly in a regular browser it will not be properly marked up.

Now, I'm not saying we can't work with or around this, and honestly we need to, since I think we will only get easy image inclusion by using a filter probably. I'm hesitant to start adding filters though until we figure out how that effects other downstream uses of the handbook pages and how we can compensate for that.

All that said, I would love to add BUeditor sooner rather than later since that is not a filter, but an HTML helper, and will make using HTML easier and more consistent.

Thanks for clarifying those points, I think BU Editor will be great, certainly it will make my life a little less hectic!

Just want to give my +1 on BUEditor. In addition to the HTML tags, we can probably use buttons to easily add en and em dashes etc. with just one-click.

@#7, good point, Ctrl+0151 gets pretty tired after a few thousand times :)

-1 on BUEditor, sorry but BUEditor could really cause havok with the revision system. Moving things around (removing white spaces and such) will cause the revision system to show up as all types of crazy behavior.

If you don't know HTML, then you shouldn't be on the Doc Team, and you Probably shouldnt be using Drupal!

Sorry, why will BUEditor "play havoc" with the revision system?

Its not about knowing HTML, its about speed and giving authors a productivity tool.

One can use Drupal without knowing HTML or any other language and its not really our place to be making judgements on who qualifies.

I know its a basic editor, but generally these editors do formatting. Adding a extra space in HTML will come up in the revision as a changed line. If BUEditor will not interfere with this, and that the compare options within the version control is still valid after its deployment then I would have no opposition to it.

However, the Comment system's do not even have a editor to them! Why should we worry about the Doc Team having an editor when we should be pushing for a editor in other places on the website? Places that everyone uses. Such as comments!

Anyways the list of requests that the Web Master has must be huge. I went through the documentation queue, and there was other requests for features. Eventually threads like this fall down the list never to be seen again.

In the end, I would rather have many other features added to the site before adding BUEditor. Like API Comments, or the ability to subscribe and follow changes made to documents that you flag.

-1 to BUEditor (I stick with my vote)... I just dont want to add to the webmasters task list for a item that is relatively unimportant.

@MGParisi
I have a feeling that you have not used or know what BUEditor is. It's not a WYSIWYG editor. It's a plain textarea editor aiming to facilitate code writing. Please see http://drupal.org/project/bueditor and please try it out at http://ufku.com/drupal/bueditor/demo then read your comments again ;-) With regards to the HTML-knowledge thingee. It does not matter if one does not know HTML... Lines and paragraphs break automatically, web page addresses and e-mail addresses turn into links automatically and project issue numbers (ex. [#12345]) turn into links automatically. Every person/contributor has his/her own expertise. If we stumble upon people who can help with information architecture, or probably someone with a great eye for spelling, grammar or can help implement the style guide better, etc. then they're very much welcome. Every individual has his/her place and equally contributes to the Drupal Docs, html or not.

Forum posts and issue comments do not need an editor—seldom are they long, complex documents requiring headings, lists, footnotes and so on.

The argument is strait forward—make it easier for those without knowledge to markup such documents and make it quicker for those of us who do this on a regular basis.

A simple example is a document list with 30+ items. Coding this by hand is not hard, for me, however even I chose to do this in my desktop editor with its code completion tools. BUEditor would have made this a snap for anyone.

The other issues you raise are valid, being able to flag content would be great, however this is better addressed as a redesign issue and is not relevant to this issue.

@JohnNoc pretty much summed up my thoughts on this. :-) @MGParisi, everyone with a D.o account is "on the doc team" now, in the sense that they can edit most pages. Providing tools to make it easier for folks, all folks, to contribute is one of the major goals for our project. Knowing HTML is a huge barrier for some, and an unnecessary one, when we have tools to ease that.

At this point, I consider the next step for this to be to get a review of BUeditor for inclusion on Drupal.org. I'm not sure if this is something that will get postponed for the redesign, especially since there is still talk of splitting the docs into its own subsite.

There are a number of things that will need to be addressed before we could deploy it, even if we get infra's OK to proceed:
- Provide ability to enable/disable per user. Some old skool folks will not want it, so they should be able to turn it off. (I haven't played with BUeditor recently, so I don't know if this is part of the module already.)
- Decide which content types this should appear on (book, page, project?).
- Figure out exactly which buttons we want and what they will do.
- Write documentation about editing pages with the new toolbar.

Moving to webmasters queue and changing title.

I have not made a security review just saying that BUeditor is fine w/ me. To clarify, it's a HTML helper, not a WYSYWIG editor. Phew! :)

If we really want to lower the barrier to entry *and* ease versionning at the same time, we should really move to a non-HTML text format, like Markdown or Textile and deploy a Wysiwym editor like Markitup (http://markitup.jaysalvat.com/examples/markdown/).

The truth is: HTML is hard to write and even harder to read, and tends to lead to ugly diffs between revisions.

I've already explained why I am currently -1 on markdown (or other markups) in comment #5 (#424400: Use BUeditor on drupal.org) and I don't see a solution for this coming clear in the *near* future. OTOH, BUeditor doesn't lock us in to or change anything, since it is just HTML which we have already, so we can always move to another method later if it makes sense. BUeditor is a solution that we can implement *now* that will make things easier for a *lot* of people. Please do not go down the rabbit hole of markup in this issue and keep it on topic for BUeditor.

+1 for bueditor for me! I use it on all my sites and even my non technical users are able to use it just fine. I love that it's just plain HTML so you don't need to worry about posts showing up strange if you change years down the road. And it's not a WYSIWYG so it stays out of the way. Because of that, I don't think an option to turn it off is really necessary. It's just a bar of buttons. If you don't want to use it, it does nothing.

FWIW, if I have a large document to make for d.o, I will create a new post on my site, use BUEditor with it, and then copy it over here. This would be saving some steps. :)

Michelle

I have been using BUEditor on my site for a few years and it has not had a problem/conflict with revisions and display using Diff module. It is a nice, simple helper that providers clean HTML output.

I'm a BUEditor user but, when someone comes to d.o is what what we want them to see? Sure, it's not a WYSIWYG. But, what will the impression be for users if d.o is the showcase and we use this html helper?

I don't know the answer. Should be find out and find out if it matters?

@add1sun I haven't thought through it but wouldn't out current system for code/php tags need post processing already? And, what about project issue numbers being turned into links? Can we use the data as is for what you propose in #5?

Why would a new user care that there's an HTML helper to make it easier to create doc pages? I'm not seeing any connection here.

Michelle

That we use what's the proper and not a broken overhyped editor?

Maybe when said new users sees it they'll think, hey I don't actually need that broken over hyped editor after all, this is much better ;)

I am with add1sun here: First a plan needs to be developed. Maybe we could install it on our d6 test site. I am not opposed to installing it in general.

I'd also love to have BUEditor on d.o. As mentioned it's only a non-wysiwyg HTML helper, and has zero effect on existing code (on the wysiwyg-helper side it "does" have a cool preview button that layers a rendered version of the HTML - just for preview to make sure there's no errors or that it looks as intended... you toggle it back off before editing again). Like Michelle, I write everything on my own site first, using BUEditor, largely because it drives me batty having to type basic HTML over and over while I'm trying to focus on the content.

If possible, I'd like to have BUEditor on the d.o forum as well, where I spend a lot of time answering support issues. Right now I resort to a Firefox extension to add a toolbar, but it's not ideal.

BUEditor has role based control built in, though it wouldn't hurt to add an option for a user to toggle BUEditor on or off based on preference... though it could be added later if needed.

One thing is I think we could use some better default buttons for it (some of the default ones are blurry)... I always replace the buttons when I use it with some I extracted from TinyMCE and other editors... since we can't use those, we should find some GPL buttons to use instead. If no one knows a good icon set for this, then let me know and I will make some from scratch (I'm a designer). If so, let me know the full set of buttons that will be needed for d.o, and any specific requirements.

I started looking a little bit under the hood and there are problems. I can't tell you what they are, but the right people know about them now... ;)

I have used BUEditor, I like it, dont want it on the site... but the majority speaks, as it should! I am not upset about it, and I hope others are not upset because I voice a opposite view.

I don't see what is the pro of using BUEditor in Drupal, when people could use the HTML editor they prefer on their own PC; it would be really WYSIWYG, and it would be a lot more powerful than BUEditor, which does not come out with some useful button pre-sets. If I have to use it just to have balanced HTML tags, I would prefer to not have it at all.

KiamLaLuno, but that makes the assumption that the user has an HTML editor... which is not always the case.

Then, to not take the assumption the user has a HTML editor, we should be using something that causes compatibility problems, and other problems.
I tried many WYSIWYG editor modules, including BUEditor (which is not WYSIWYG), and all of them created problems with the browser, the theme, the HTML it produced. After using them for about a week, I uninstalled them, and returned to use the plain text area my browser gives me.

If I would need a solution to edit HTML directly from a browser, there are some plugins I could install for my preferred browser. In that way, I would not even need a HTML editor.

Well, those are *not* the issues here, but for respective issue queues, I think the general consensus is BU editor is used widely and has few issues for the majority of users, I have a never had a serious problem over the several years I've been using it on many sites, and because its an HTML helper there are no issues with inserting unwanted markup, it really is the best type of solution.

edit, ops re-read and forgot the ** bit...

@KiamLaLuno: The nice thing about BUEditor is you don't have to use it if you don't like it. If it gets implemented on d.o, just ignore it. It doesn't do anything unless you actually click a button on it.

Like jmburnz, I've been using it for years without a single problem. I would love to use it here. This was marked postponed 2 months ago due to mysterious "problems". I'm guessing a security issue from the way it was worded. But there hasn't been a new BUEditor release since then. I really hope whatever the problem is gets taken care of soon so we can move forward with this.

Michelle

+1 for BUE editor.
All most all sites I use and probably others use has some sort of editor EXCEPT drupal.org
This absence breaks the normal end user or user behavior when it comes to typing.

Only thing BUE editor lacks is a PASTE button but that is a small issue.

Now that SA-CONTRIB-2009-055 - BUEditor - Cross Site Scripting is released, we can reconsider this...

I've been using BUEditor on a few other sites and mostly love it. The only UI downside is that when tabbing through fields to get to the text area you care about, you have to tab through each button, which basically makes this kind of tabbing useless, but that's not the end of the world. And, given the win of being able to select text and click a button to format that as a ul or blockquote or whatever, I'd be willing to live with it. So, +1 from me for installing it here.

The tabbing issue is a major one for me. Can a user switch buedir off in his preferences?

Not at this time -- bueditor is currently just role based -- specific roles can get specific sets of bueditor buttons. It'd be nice if there were personal preferences for this, but that's probably a discussion better suited for the bueditor issue queue than here...

Wouldn't #429684: Add editor: BUEditor and Wysiwyg/Bueditor fix this?

waiting with excitement :-)

oh great - drupal.org is finally facing the same problems like all the other 200,000+ Drupal sites out there. ;)

From my developer/sanity perspective, BUeditor is a no-go. However, there's a very promising alternative: markItUp. Both are pseudo-editors, just providing customizable buttons to inject markup into a textarea. markItUp has little in common with MarkDown - except the fact that it can also be configured to output MarkDown syntax instead of HTML. By default, markItUp generates/injects HTML markup.

True is that using Wysiwyg module would probably resolve this issue for all users, since some could use no editor (and don't load one), some a pseudo-editor, and some others maybe even a real wysiwyg-editor. However, I would only consider the upcoming 3.x version as an option, which will still take some time.

We are not going with a non-html markup method.

I see no reason to postpone this proposal to use real software in favor of proposed vaporware at some point in the future. bueditor doesn't screw with the markup, it just makes it easier to compose HTML. If/when something better exists, we can revisit this in a new issue...

If we are going to use an editor, then I am in favor of BUeditor.

Ok, it looks like we just need to install this. So, we should pop it on scratch.d.o first? Moving to infra to get this done.

I absolutely can't wait for this. Willing to be "ginny pig" if necessary.

Btw, it would be nice if we could add some custom buttons for adding links to issue numbers, for example.