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 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.

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.

-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!

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: How do I log in as admin?) 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.

@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?

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.

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.

@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.

It's been 1.5 months... Giving it a little bump. :)

Michelle

Now installed on http://d6.project.drupal.org with my first pass at a button configuration. Please comment here with any thoughts or concerns. At this point, there's just a single editor definition and all authenticated users get that. We could eventually get fancy with different editors for different roles, but I think we can start simple...

Great news dww!

I went ahead and did a little test on it, see the result here: http://d6.project.drupal.org/node/544438#comment-2307273

Some observations/suggestions:

• I'm not so sure we should allow H2 tags, imho we should be fine with H3 H4, and perhaps H5, this is nothing critical, but well, it could get messy when we list teasers.
• The preview button would be very handy on the editor.
• A button would also be handy.
• Once we settle on the custom buttons, we should design some iconsfor them .

For the rest, it's working great, and I can't wait to use it on the real site!

It looks good. Just to be able to insert an issue link without to use the characters [ and ], (which are not so easy to reach, in keyboards for some languages) is a step forward.
I agree that it is better to start simple. Different configurations for different roles are the last step, IMO; let's start with something everybody can use. I would even happy if the editor would be kept as it is now.

Awesome! Seems just fine how it is. I don't think we need a button for every little thing. Just the ones that are common and the ones that are a lot of markup to type, like lists.

Michelle

Will I be able to disable it in my profile?

@nevets: BUEditor doesn't have per user settings but, remember, this isn't WYSIWYG. It's just an HTML helper. If you don't like it, don't use it. It doesn't affect the text area in any way unless you actually click on a button.

Michelle

If people really want to disable this for UI reasons they can do so with a browser based userstyle that does a display:none on the whole button set.

@Manuel Garcia #47:

The preview button would be very handy on the editor.

The result of SA-CONTRIB-2009-055 - BUEditor - Cross Site Scripting was fairly lame. I suggested that the maintainer build the preview functionality via an AJAX request, much like http://drupal.org/project/live works. They didn't want to go that route, and instead choose a slightly weird (but still basically secure) approach where the preview button disappears if the text area is loaded with any content that contains the < character. :( Plus, the preview wouldn't render things like [#links] at all. Given these failings, I think the bueditor preview button would be more confusing than it helps. Therefore, if you want to preview, use the preview button you already have. ;)

@nevets #51:

Will I be able to disable it in my profile?

If you write a patch that's accepted by the upstream maintainer to provide this feature. ;) Else, do what greggles says in #53.

I used to scoff at tools like this, being the die-hard CLI user that I am. However, I've installed bueditor on a few others sites where I run project_issue, and I must admit, I've definitely grown to love it. It's so much easier to provide useful (sometimes essential) markup to issue comments, like wrapping stuff in <code> tags (see, ugh, that was 25 keystrokes, could have been 8 and 2 clicks). Definitely a life-saver for making ul or ol lists. You might actually like it once you start using it, and then wonder why you were content to manually type so much HTML for so long. ;)

I just noticed bueditor 6.x-2.0-beta1 is now out, and the release notes of changes from the 6.x-1.* series sounded really nice, so I just gave that a spin on http://d6.project.drupal.org. Among other things, it adds icons for code and blockquote for us, so that's good. ;)

Folks are encouraged try it out again on d6.p.d.o. I'm still trying to get final approval from the rest of the infra team... Also, someone should re-audit the 6.x-2.0-beta1 release to make sure we're not opening ourselves up to any trouble. I don't have time for that audit in the near future, so if folks are interested, please move that part forward without me.

Thanks,
-Derek

I've been playing around with it and its working great on d6.project.drupal.org. There's no preview, so I don't see how this could need a security audit, although I'll try and take a look.

BUE on drupal.org?
Exciting!
About the preview issue, I admit that the solution was confusing but i didn't want to give up the fast html previewing and implementing an xss filter in js would be overkill. I personally use insecure version of preview (js: E.prv(false)) when there is no collaboration in input. That's not the case for d.o. of course.

FYI, BUE does have AJAX previewing(js: E.prvAjax()) that depends on the Ajax markup module. Not using live module because it previews the whole node. BUE needed just an ajaxified check_markup() and that's what Ajax markup has. It performs considerably fast, however unlike the form preview it encourages people to use it frequently, which may not be good regarding the # of hits to the server.

Anyway, i like it simple too.

ps: It will be available for everyone, right?

+1 for Markdown support on d.o - I use it for all of my personal sites as well as on g.d.o, and really miss using it on d.o (and more than once I've ended up writing Markdown in my posts and not realizing it until after I've posted it, which can be problematic for issues which can't be edited by mere mortals after posted).

I'm ambivalent about the use of a JavaScript-powered editor - we don't need one on g.d.o, so why here? - but if we're to use one, I prefer [markItUp!](http://drupal.org/project/markitup). Ah, damn… I mean markItUp!.

Not a bikeshed time. Let's concentrate on getting bueditor on for now.

FYI: Dreditor comes with HTML/filter markup autocompletion, as well as d.o node issue URL "autocompletion" (conversion) now. Currently testing @username autocompletion.

Could we at least get the markdown filter on d.o?

Let's get *something* done!

@sun, would it be possible to put the markdown processing into dreditor if we can't get it onto d.o?

BTW, all: @drumm has made it much easier, and the deployment process is much clearer, for d.o deployment. It's no longer a black hole. See http://drupal.org/node/1006562

As mentioned in #60, Dreditor provides autocompletion for HTML markup and some other dynamic things.

Personally, I believe that's the right balance for a technical oriented site like drupal.org. Especially in issue comments, over-formatted comments tend to be more confusing, instead of helpful as intended. Given that even some developers do this, I don't really want to know what end-users would be doing.

Implementing markdown on the client-side would be a larger challenge - while the syntax looks easy, the technical parser is very complex. Also, retrospectively, I've spent lots of time with correcting the resulting formatting of markdown comments (e.g., on g.d.o). Actually, I don't think I've ever written a markdown formatted comment that had the intended formatting after the first form submission. IMHO, the markdown syntax/format has potential, but all of the current parser implementations I've experienced on the net badly need improvement.

I've been very successful with the markdown filter on both my own site and g.d.o. No, it's not perfect. Yes, it's far easier to do *simpler* formatting than with html. I just get tired of all those silly <li></li> Thanks for including autocomplete in dreditor, but it's not really what I want. I want to not do complex html formatting, but rather do simple, readable (with or without markdown) text formatting.

I posted #1224506: Allow markdown on drupal.org comments (with a non-default markdown-tuned input format) with a much simpler goal... Just get markdown deployed.

can somebody please summarize what the problem is with bueditor?

I looked back thru the comments:

mfer said "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?"
MGParisi likes it but doesn't want it on d.o for unspecified reasons.
kiamlaluno said it "created problems with the browser, the theme, the HTML it produced" which I don't understand since it's not a WYSIWYG

Others argued that it's just not needed, that it would make it too easy for users to add lots of markup to their posts, and that they'd prefer markdown instead.

That's all the objections I could find. Anything based on issues with the code of the module itself were old enough that they are likely resolved by now.

Michelle

Edit: That would probably be more readable if I had used list markup but, well, that's just too much of a PITA to type out by hand.

thanks Michelle!

Can somebody set up a dev site so that people can actually try it in a d.o context?

personally I prefer bueditor over e.g. markdown.

It's set up on http://d6.project.drupal.org if you want to try it there.

Michelle

ok, so everybody head over there and report back.

If I don't hear serious complaints, we'll simply try this live since we can actualy just revert it.

Unlike markdown, I think.

Since it's just helping with the HTML that we already have a filter in use for, yes, you can turn it off at any time. Any other markup language, markdown, bbcode, etc, would require a commitment to keep it in use or old posts would look weird.

Michelle

There's no reason that this issue and #1224506: Allow markdown on drupal.org comments (with a non-default markdown-tuned input format) are mutually exclusive. A markdown input filter that is a choice the user makes will work fine.

And the vast majority of markdown markup looks fine without the filter. That's the beauty of it. So with markdown we're not making a permanent commitment either.

The sandbox worked very well for me. This would be *really* useful for documentation work. I hope it's enabled soon.

I tested http://d6.project.drupal.org

Nothing in the editor appears to interfere with accessibility. The editor itself isn't wonderfully accessible, but I think that it would be a good improvement to what we have now.

I have a suggestion for the functionality of the Issue link button:

It'd be easier to use if it would bring up a popup like the URL button does, where you'd paste the full link to the issue, and it would then paste into the text area the appropiate #424400: Use BUEditor on drupal.org code.

Also, perhaps a "Link to comment button" would be handy, though admittedly not used as often as others.

Just entering the comment number, then hitting that button would generate a full link to the anchor of that comment in the current issue, handy for following responses etc.

re: #76:

You can already do:

#424400-76: Use BUEditor on drupal.org and it creates a link to comment #76 in issue #424400, like so:

#424400-76: Use BUEditor on drupal.org

I don't think we need to complicate the bueditor interface for that, but if it's easy to define our own pop-ups, maybe so. Certainly it should just be part of the "Issue link" button, not a whole separate one.

Re: #75: see also #304808: Usability: Add project issue URL filter and #338661: Allow [#XXX] filter to work on non-local databases

Seems like there have been no serious objections since killes last replied asking for feedback. @killes: what's left? Any other blockers here?

no blockers, needs to deployment

Did anyone test whether this is compatible with Dreditor? In case of troubles, please create an issue for Dreditor.

Copy alternative proposal list from http://drupal.org/node/1287784#comment-5056974

Copied list of alternatives from http://drupal.org/node/1287784#comment-5056974 to issue summary, but perhaps I'm too late since this is already RTBC.

Not necessarily too late. You can use Markdown and BUEditor at the same time. You can have an optional WYSIWYG people can use instead of BUEditor, too. Getting BUEditor on here is a good first step but doesn't preclude making use of those other solutions as well.

Michelle

Better links.

Has it really only been 2 1/2 years? WOW Time fly's. I was just thinking about this. I thought we decided that we where going to do this back then. For me its a +1

Hold up. We need a set of deployment steps if we're going to deploy this to drupal.org, ala http://drupal.org/node/528682#summary-deployment Can someone please prepare that? Ideally using a d.o development sandbox (http://d6.project.drupal.org/ seems to be dead).

Also, the issue summary seems to not actually reflect the facts of this issue. It doesn't seem like there's any ambiguity around this at all, and in fact the infrastructure maintainer has signed off on the solution so there's no "Decide on one of the above alternatives, or mark this issue closed (won't fix)." here. Decision's already been made. Can someone fix up the issue summary?

Replaced [username] with Jeff Burnz.

@webchick:

Also, the issue summary seems to not actually reflect the facts of this issue. ... Decision's already been made. Can someone fix up the issue summary?

Sure; I'll remove my changes.

EDIT: Okay, it's back to the original.

Just as an update, I spun up http://bueditor-drupal.redesign.devdrupal.org/ (user/pass: drupal/drupal), downloaded BUEditor and enabled it. No other configuration's been done.

If someone wants to own bringing this home, ping me in IRC and I'll give you the uid 1 pass. It's fun to impersonate Dries!

I would be happy to do it, but I fear I maybe more trouble then Im worth, but Ill ping you on IRC!

Im on the case, will have the process soon:)

Oops

Here is the BUEditor Export if you want to try it out on a test site. Its rather basic :)

It supports the basic image, href, Bold, Italic, Underline, Strike through, Ordered List, Unordered List, Headings, Block Quote, Code, and teaser breaks. It does not support height and width on images (as I was not certain this was supported with the new image filter).

I think more would be nice but right now a simple solution would get people to use it and decide what more they wanted! Its easy to add and remove buttons. I dont have much as far as graphics for the buttons.

I did not remove the preview or help buttons. The preview buttons will have to go as it requires additional AJax libraries.

We can use the defualt image settings instead as that supports addition height, width and image in the filter.

You can try this on any d6 server and see if it works...
Procedure for setting it up is simple
Setup is now simple:

Administer ->Site Configuration->BUEditor
Import "bueditor.buttons.txt" Title: "HTML Basic" Directory (leave blank) Editor Code: Paste and copy Export Above. Press Import
check to see if changes to BBCode -> "HTML Basic" where made
Assign all roles to BBCode for "HTML Basic" and none as alternative.
Goto Permissions and set BUEditor Module -> Administrator bueditor (execute PHP) to thoose ADMINS you want to give it to (suggest none?)

-------------------
There was some great ideas like issue number and other markup we can include. I have no Icons to set it up. The current setup is on the dev server.

duplicate

Also set up user: bananas/bananas if people want to test what's there now.

My only observation is that those default icons are ugly as hell. :\

Not to scope creep this too much, but are there other skins we could use by chance that would maybe be a little less jarring?

Also, this still needs an issue summary.

These are the ones I often use: http://drupal.org/node/205921

Per MGParisi, I did:

* cd /files
* mkdir bueditor-icons
* cd bueditor-icons
* wget http://drupal.org/files/ico_bueditor+.zip
* unzip ico_bueditor+.zip
* Go to admin/settings/bueditor/2, expand "Editor paths", and change "Directory of editor icons" to "%FILES/bueditor-icons"

That gives this, which definitely looks much better:

Still some jankiness to clean up there though:

- What's up with "teaserbr.png"?
- The order of the icons is very strange. I would expect B / I to be at the beginning, link / image after that, etc.
- MGparisi noted we're missing a button for <code>.

I updated the icons and have added a new code one and a blank (spacer) square.

They are located in the same icons thread http://drupal.org/node/205921

I think the code one looks good:)

Also fixed the missing button, just needed to change the name of the image from teaserbr.png -> ico_teaser.png

Currently the process just includes
uploading the images to a folder ("custom-icon-path") under files
changing the image path to %FILES/custom-icon-path
update the one missing icon from "teaserbr.png" to "ico_teaser.png"

Next Ill add a code icon (if you think that would be nice) and some spacers

Nice, this is looking pretty great now!

How can we review it?

Once I get the BUEditor+ icons installed webchick will be able to decide how we can get people to test it out. It really is nice, it is a great HTML Helper editor, as in its not a WYSIWYG editor but more an HTML editor.

haha, I think ufku knows that; he's the author of BUEditor. :D

ufku: You can try it out at http://bueditor-drupal.redesign.devdrupal.org/ (drupal/drupal at Apache prompt, then bananas/bananas)

1. Administer ->Site Configuration->BUEditor
2. Import "HTML.Basic.bueditor.txt" Title: "HTML Basic" Directory (leave blank) Editor Code: Paste and copy Export Above.
3. Press Import
4. Check to see if changes to BBCode -> "HTML Basic" where made
5. Assign all roles to BBCode for "HTML Basic" and none as alternative.
6. Goto Permissions and set BUEditor Module -> Administrator bueditor (execute PHP) to thoose ADMINS you want to give it to (suggest none?)
7. Install New Icons
1. cd /files
2. mkdir bueditor-icons
3. cd bueditor-icons
4. wget http://drupal.org/files/ico_bueditor+.zip
5. unzip ico_bueditor+.zip
6. Go to admin/settings/bueditor/2, expand "Editor paths", and
7. Change "Directory of editor icons" to "%FILES/bueditor-icons"
8. Uploading the images to a folder ("custom-icon-path") under files
9. Changing the image path to %FILES/custom-icon-path
   update the one missing icon from "teaserbr.png" to "ico_teaser.png"
10. change <!--break--> Icon to "ico_teaser.png"
11. change Bold Content to "<b>%TEXT%</b>"
12. Insert new button "Quote", "<blockquote>%TEXT%</blockquote>", and "ico_quote.png"
13. Change order of Icons to Bold, Italic, Strikeout, Heading 2, Heading 3, Heading 4, Quote, Code, Indent, Justify Left, Justify Center, Justify Right, Justify Block, Insert/edit image, Insert/edit link, Ordered list..., Unordered list..., Teaser break, Preview textarea, Gethelp on buttons.
14. Save

I need to know what version of Drupal D.O. runs, and then I can install it and test my procedure locally to ensure its correct! If its correct I can then fix up the above any way you want it, and submit my final proposal/procedure. Sorry UFKU, didnt know, great work on BU... I have fallen in love with it the more I use it:)

It's D6. I don't know specific point release but I would guess the latest.

Michelle

chagelog.txt says it's 6.22

Ok tested every button in a forum post, here is what I found...
Italics works
Bold Works
Strike through fails
Links work
H2, H3, andH4 works
All of the Aligns fai...
Bock Quote works,
Indent fails
and image works including image size, though image alt needs testing.

TESTED! Use attached file!

1. Install BUEditor in modules directory
2. Enable BUEditor in modules
3. Administer ->Site Configuration->BUEditor
4. Import "HTML.Basic.bueditor_.txt" by filling in Title: "HTML Basic" Directory (leave blank) Editor Code: Paste and copy text file Above.
5. Press Import
6. Check to see if changes to BBCode -> "HTML Basic" where made
7. Goto /admin/settings/bueditor
8. Assign all roles to BBCode for "HTML Basic" and none as alternative.
9. Goto Permissions and set BUEditor Module -> Administrator bueditor (execute PHP) to thoose ADMINS you want to give it to (suggest none?)
10. Install New Icons
1. cd /files
2. mkdir bueditor-icons
3. cd bueditor-icons
4. wget http://drupal.org/files/ico_bueditor+.zip
5. unzip ico_bueditor+.zip
6. Go to admin/settings/bueditor/2, expand "Editor paths", and
7. Change "Directory of editor icons" to "%FILES/bueditor-icons"
11. Save and PARTY!

Edit- Small Clarification and small change in file name. Tested 2 times on 2 local servers. Need 3rd party to test install procedures!

<review spelling="nazi" grammar="nazi"> system("perl -pi -e 's/where/were/g' $comments_by_MGParisi"); </review>

@MGParisi: Instead of new comments with nearly identical deployment steps (which are going to be confusing when we actually deploy this live) can you just update the issue summary with the accurate deployment steps needed to get this done? Thanks!

Screen Shot For Issue Update and Upgrade Status

Removed by request of webchick.

Final Proposal

link to file

removed must fix

Awesome!! Thanks for the nice summary.

There is one more thing that I'd love to pursue, if I can scope creep this just a touch.

We recently rolled out image support for filtered HTML, with the caveat that any referenced images must be local to d.o to prevent HTTPS mixed content errors, CSRF attacks, etc. However, the button for adding a new image asks for an "Image URL". That's almost certainly going to mean people enter http://skitch.com/blah/blah or similar, which will end up as a red "X". Confusing.

Is it possible to pre-populate this field with "http://drupal.org/files/" so that people hopefully understand this?

<3 to see progress here guys, awesome!

@webchick it should definetly be possible - not sure the average user will get what that means but that's a different story.

Perhaps we should get more of a button that when you upload an image to an issue /documentation book page and you click the button it'd insert the attatched image inline? I guess it's the time to dream of things like this right?

Here is the current button code:

js:
var form = [
 {name: 'src', title: 'Image URL', required: true, suffix: E.imce.button('attr_src')},
 {name: 'width', title: 'Width x Height', suffix: ' x ', getnext: true, attributes: {size: 3}},
 {name: 'height', attributes: {size: 3}},
 {name: 'alt', title: 'Alternative text', required: true}
];
E.tagDialog('img', form, {title: 'Insert/edit image'});

Also see http://drupalcode.org/project/bueditor.git/blob_plain/refs/heads/7.x-1.x... and jump to "TIPS AND TRICKS" for more info that may help someone who knows js.

Michelle

As long as we're dreaming, why not have a browsable pick-list of the available image files already uploaded to the /files/ directory? Since it is invalid to enter any url that doesn't point to an image file inside that directory, the effective choice boils down to a picklist anyways.

Do you have any idea how many image files are there to pick from?

I said I was dreaming, okay?

Also, it might help slow down the explosive growth of files in that directory, if people could pick one rather than uploading what may very will be a duplicate.

IMCE is the only program that I know that does that, and it will grind the issue to an halt... But yes BBEditor supports IMCE.

Folks. ;) We are not derailing this 2+ year old issue on a media browser. Feel free to file a follow-up, though. The point of #110 is a minor UI enhancement to hopefully save on duplicate support requests.

Very true, let's get this done! =)

Right; I agree. Disk space is cheap; time and webchick-brain-power isn't. :-)

When I first saw this patch, I really wanted an option to disable BUeditor (some flag in your user profile or something). After trying it out, I realized that it's only 5 extra kb of resources to download and it doesn't take over the text field like other WYSIWYG editors do.

Looks really good - should help some people :)

I actually find it great for some html, and I have been writing HTML before IE4 came out...

P.S. Read my earlier posts... Life really throws some curve balls!

@cweagans: That's what I love about it. It doesn't get in your way. It just sits there ready to help if you need it and doesn't bother you none if you don't. :) And it's a great time saver when writing lists.

Michelle

I suggest using the library bue.min.all.js instead of bue.min.default.js.
With an extra 7kb we get:

• Indent(TAB), unindent(Shift TAB) and auto indent(ENTER) in the textarea. This enhances readability a lot.
• Ctrl shortcuts. Accesskeys turn into ctrl shortcuts.
• Tag auto completion. Closing tags are automatically inserted during typing.
• Auto list item. Additional li tags can be inserted by just pressing Enter when the cursor is at the end of a list item.
• Find & Replace in textarea
• Cross-browser undo-redo

As per the default value of image src, the "value" property can be used such that;
{name: 'src', title: 'Image URL', required: true, value: '/files/'}

Also noticed that current active editor uses some old button code including deprecated functions (starting with eDef) of 1.x branch. MGParisi, can you build the editor based on the "Default" that comes with 2.x branch?

Tag auto completion. Closing tags are automatically inserted during typing.

I'm personally -1 for this feature. I find it annoying and intrusive.

Auto list item. Additional li tags can be inserted by just pressing Enter when the cursor is at the end of a list item.

So how do I type a multi-paragraph list item? Do I have to use shift-enter? Type some garbage, left-arrow over it, hit enter, then delete the garbage?

Cross-browser undo-redo

I already have cross-browser undo. It's called "Ctrl-Z" and works (at least) in Firefox (Linux) and Internet Explorer (Windows). In fact, I just used it when I inadvertently pasted the wrong text into the preceding paragraph.

edit nm, misread the post prior.

Some of #122 sounds nice but I think we should avoid adding anything that affects how the text area is used when the bar is not clicked on. The major selling point here is that the helper bar can be ignored by those who don't want to use it and d.o text entering will go on as normal for them. If we break that compromise, we get into bikeshedding territory when we are so close to having this enabled. :)

Michelle

Yeah, let's stick with default rather than all, I think. The current behaviour has been signed off on, even by people who despise WYSIWYGs. More fanciness might shift the tide.

I'm personally -1 for this feature. I find it annoying and intrusive.

Each feature is in a separate file. So we can create a new minified sum of selected features.

So how do I type a multi-paragraph list item? Do I have to use shift-enter? Type some garbage, left-arrow over it, hit enter, then delete the garbage?

Enter works only at the very end of the list item after the closing tag, not in between the tags.

I already have cross-browser undo. It's called "Ctrl-Z" and works (at least) in Firefox (Linux) and Internet Explorer (Windows). In fact, I just used it when I inadvertently pasted the wrong text into the preceding paragraph.

Textarea history is broken(lost or misbehaving) in some browsers when the value is set by javascript, e.g. by bueditor buttons. OTH, IE and Safari does not support per-textarea history. They provide a global history including all form fields. SO when you Ctrl-z in a textarea in IE you may undo the changes you've just made to the previous text field.
AFAIK, Firefox is the only one that supports both per-textarea history and javascirpt value history.
Anyway it's also a separate library that we can omit.

Yeah, I'd say just leave it as is - we don't need all that extra stuff. If textarea history is broken in some browsers, it's a bug in that browser and not our job to fix by emulating undo history in javascript.

Enter works only at the very end of the list item after the closing tag, not in between the tags.

Okay; sounds useful. (I can still think of cases where it would be annoying, but they are edge cases to be sure.)

Textarea history is broken(lost or misbehaving) in some browsers when the value is set by javascript, e.g. by bueditor buttons.

So does this library restore the otherwise-broken functionality? In other words, will I still be able to use Ctrl-Z for "Undo" or will I have to click on a bueditor button instead?

We may also have unneeded libraries(IMCE?) in default.min.js. For reference, here is the list of library files.

So does this library restore the otherwise-broken functionality? In other words, will I still be able to use Ctrl-Z for "Undo" or will I have to click on a bueditor button instead?

Yes it defines a new history for the textarea. Undo can be bound to Ctrl-Z or an undo button can be defined that has the Ctrl-Z shortcut. (Browser's default is suppressed).

Okay, I'm convinced.

+1 for the "undo/redo" functionality, as long as it is bound to Ctrl-Z so that it fixes behavior that might otherwise be broken by other parts of bueditor.

(And thanks to ufku for zen-like patience while answering my questions!)

We may also have unneeded libraries(IMCE?) in default.min.js. For reference, here is the list of library files.

Can you separate the list into three categories, please?

1. Libraries which implement features we all have agreed are desirable.
2. Libraries which implement features regarding which we are undecided or of mixed opinion.
3. Libraries which implement features that are not wanted or needed at this time.

Guys, wait: let's get this deployed first. THEN we can go through and add other things as needed.

1- Decided: markup, popup, misc (These are required for Image/Link dialogs)
2- Undecided: preview, ctrl-shortcuts, undo-redo, auto-li, tab-indent, autocomplete
3- Unwanted: imce, find&replace

I've moved preview to undecided because it always displays Full HTML and not usable in non-empty textareas. OTH, ajax preview which is aware of input filters requires an additional module.

@cweagans: I don't see how our continued discussion here is in any way delaying deployment. Neither I nor ufku have the requisite permission to deploy, nor have we changed the issue status, nor have we lobbied the infrastructure team to postpone this project.

On the other hand, If discussion of configuration details should be moved to a separate issue, I'd be happy to open one.

@ufku: I proposed that "ctrl-shortcuts" and "undo-redo" be moved from 2: Undecided to 1: Decided.

It's derailing the conversation that's relevant to deploying the initial set of features - I think a new issue about discussing potential additions to bueditor would be a good place for this discussion.

fixed header

Set input format to filtered HTML

derailing the conversation that's relevant to deploying the initial set of features

What conversation? As far as I know, we're still waiting for MGParisi to figure out how to pre-populate the URL field with http://drupal.org/files/.

Nevertheless, opened #1302972: Decide on a specific set of libraries, extensions, and icons for BUEditor as used on drupal.org

I'd add it to the issue summary but I see that I lack permission to do so.

EDIT: Okay; so added. You can put back the working demo, now.

I guess I did not appropriately respond here, as I did in IRC. I was unaware that task had been added to the issue however I am PERSONALLY, unable to add the drupal.org/files to the textbox. I think ufku or another individual might be able to shed some light on if we can do this within a reasonable timeline.).

Need to unassign, then.

FWIW, he said in #122:

As per the default value of image src, the "value" property can be used such that;
{name: 'src', title: 'Image URL', required: true, value: '/files/'}

Also in that comment, in case you missed it:

Also noticed that current active editor uses some old button code including deprecated functions (starting with eDef) of 1.x branch. MGParisi, can you build the editor based on the "Default" that comes with 2.x branch?

Michelle

So sounds like this is still needs work. Once again, if anyone wants to help with configuration, ping me on IRC and I can get you the uid 1 pass. Thanks for bringing it this far, MGParisi!

I will go back and update the code on the sandbox to the new general code. I will attempt to do what Michelle suggests and see if I can get it to work. Thanks Michelle for the hints. I can get to work on it asap. The undo/redo function would be widely accepted if its not a large javascript file and if it can be implemented in a short time. Or we can implement the version without it, and if someone wants to be aggressive we can get that functionality up quickly.

woops assigned back to me.

Updated! And the Image now gives the path. Thank you FWIW!

Added subtask.

Changed input file to include latest updates! WOOHOO!

I just tested this out on the test server.

For me, this editor is fine -- I don't need to disable it, in other words (I don't care much for WYSIWYG editors, because I am more efficient at typing HTML myself, and if I type HTML into the WYSIYWG, it decides I really wanted it to be escaped as <strong;> etc.)

But I question whether this editor is much use for someone who doesn't already know HTML. As a test, I went over to the test server and started typing an issue comment (the editor is turned on there).

I clicked the bullet list button, and it entered:

<ul>
  <li></li>
</ul>

With my cursor ready to type one list item. Which is fine for me, but if I didn't know HTML, it didn't give me any help to create a new list item (and there is no other help on the screen).

That's just one example... As the contents of the box are still HTML, I'm just not convinced it is much of a help for non-HTML-savvy users, which is what the issue summary says is the purpose of this change. Wouldn't it be better to put in a light-weight WYSIWYG editor (with the ability to disable it)?

@#145 by on October 7, 2011 at 10:49pm:

it didn't give me any help to create a new list item (and there is no other help on the screen).

See Item number 4 on Remaining Tasks for #1302972

Just to clarify...

I am trying to imagine these use cases:

a) I'm a new contributor to the Community Docs. I get to a Docs page that needs some editing. I click Edit. I don't know HTML, and am faced with a page that is full of HTML tags.

The BUEditor does not do anything to address that situation. This user is still facing the same barrier as before to editing the page.

b) I'm me or MGParisi - I know HTML really well. I find this new toolbar from the editor and try some of it out.

Cool! The BUEditor is great for this situation. It gives me some shortcuts to typing that are very helpful.

c) Back to the person in (a). I click "Add new page". Somewhere in the page I'm writing, I want to create a bullet list. I click the bullet list button. (see previous comment from me above).

The BUEditor will not necessarily help me create a bullet list. It might if I've been somewhat exposed to HTML and can recognize the LI items and create a second item the same as the first one the editor creates. But after that one I'm on my own to figure it out.

---

My conclusion: Change the issue summary so it says it will make people who know HTML more efficient, and then this editor does fit the bill. I'm informed by webchick and MGParisi that this editor is the closest we are going to get to WYSIWYG on d.o, so let's get it in... but let's not say it's going to seriously lower the barrier for people to be able to contribute to docs pages.

Uh oh. Are these known bugs?

a) I seem to have lost the Input Format radio buttons (but maybe that's because this banana user has no rights to anything but Filtered HTML? Yes, that's probably it. It would be good to have a testing user with higher rights so we could see what happens on the input formats with more tags allowed.).

b) I went to a doc page and clicked Edit. The buttons were all screwed up (see screen shot attached).
http://bueditor-drupal.redesign.devdrupal.org/node/645792/edit

Oh, this is probably a server problem. Now I'm getting "cannot connect to server". Anyway, filing here just in case...

and tagging...

The buttons being screwed up are a glitch on the stagingvm atm. Working on it with the infra team. Stay tuned.

And I agree that it took some 100+ comments to come to the consensus about BUEditor as a path forward, so we should stay the course. :) Having buttons for "B" / "I" / "U" is still way more user-friendly than "Oh you want to make your text bold? HAHAHAHAHA. LEARN HTML, NOOB." which is the UX we currently have. :)

And might as well knock this out of the review queue until stagingvm is fixed.

sorry, I got the wrong tag up there.

Oh, well that was fast. We're back in business again!

This officially addresses all of my concerns, though in testing it I'm not sure the pre-population of the image URL will be enough to avoid confusion around the image filter. :\ And the cursor appears at the beginning rather than the end of the URL, which is probably not as easy to fix. We might want to drop it after all.. sorry MGParisi. ;( But let's see what others say.

Also, set up user/pass jn2/jn2 so you can test as a higher-level user with multiple input formats. Spoiler alert: the toolbar doesn't change. :)

Cross-post.

Added Testing Info

@jhodgdon: You're supposed to highlight the text you want formatted first, then click the button. If you just click the button in an empty space, yeah, you get empty HTML.

Michelle

For now, I'm happy with pre-populating the field.

In a perfect world, the mandatory prefix would be shown in front of the user-editable field, rather than included in the user-editable field.

But I'm happy to address that little featurebug in a separate follow-up issue.

Cursor can be moved to the end by setting the onfocus attribute:
{name: 'src', title: 'Image URL', required: true, value: 'http://drupal.org/files/', attributes: {onfocus: "_=this.value;this.value='';this.value=_;"}}

/me hugs ufku!
SO nice to have the lead developer on hand when you're learning how to use a new tool!

I just stumbled upon this issue-- this is awsome. Lots of great progress on d.o lately.

Here's a couple of handy buttons I use for quick linking to drupal.org projects and issues:

Project:

js:
var project = prompt('Drupal.org Project Name', '');
var code = '<a href="http://drupal.org/project/' + project + '">' + project + '</a>';
E.replaceSelection(code);

And issues:

js:
var issue = prompt('Drupal.org Issue Number', '');
var code = '[#' + issue + ']';
E.replaceSelection(code);

For button iconsI just use a tiny versions of druplicon:

@#162 by WorldFallz on October 8, 2011 at 3:26pm:

Here's a couple of handy buttons I use for quick linking to drupal.org projects and issues:

Thanks! But we're trying to save such fine-tuning for later.

Please discuss on #1302972: Decide on a specific set of libraries, extensions, and icons for BUEditor as used on drupal.org.

Right now the Status is needs review, Webchick has fixed the issue with the images disappearing. Will this be an issue moving forword.

As Pillars suggested we should wait to implement the two features he added. I am all for it, and it is actually easy to do later, but I have some contextual concerns that need to be addressed.

I will add the image cursor fix within a day or two, and then I will ask for a final review. I will also look at the process for D.O. Implementations again to make sure we did everything.

I think people will be very happy when this goes live. A few will be very shocked and worried that it will be in the way, then they will see it doesnt change anything for them...

#160 is implemented

adding details for jn2 user.

sub. Hit me up on IRC if you want a tester.

Deployed by Killes, Files where moved.

Thanks Michelle for bringing this to my attention, Thanks Webchick for the tons of effort put in, thanks Killes for the hours it took to put it on D.O. and thanks too dww for his quick help and effort on this issue. All of the above put in allot of time to get this up and working, and I appreciate all the help. Now that I have gone through the issue once, the next one I adopt will be much easier:) Also thanks to UTFK for writing the module and helping in setting it up, pillars and well so many more.

Now the only thing left to say is NEXT!

Please send feedback and lets get to work on #1302972: Decide on a specific set of libraries, extensions, and icons for BUEditor as used on drupal.org

Woohoo!

Great job, MGParisi! :)

(OK, this toolbar is kind of fun. :P)

Just checking out the images Button :)
And found out it only works with alt text.
As acccessible as it is, it got me wondering for a while.

• Increased image src input size.
• Disabled IMCE support
• Enabled Ctrl shortcuts
• Enabled history and bound undo-redo to Ctrl-Z and Ctrl-Y

I think we also need a button for php code as it is used frequently on d.o.
@MGParisi, can you find/create a php icon that fits into the current set?

Are we keeping the preview button? Note that it is incapable of displaying filtered html such as code or php-code. It displays pure html which might be inconsistent with what the user gets after form submission. Also it won't work on textareas that has already html in it.

Hmm, ok i'll post this to other issue.

@ufku, looks like there's already a code button...do we need anything different? Seems like it works:

<?php

echo 'Hello world!';

I created the code icon, isn't it sexy!

Thanks for getting this live.

• I love it!
• And I love it!
• And I love it some more!

Ok, I know, didn't really need a list there but I've been waiting so long for point and click lists that I got excited. :)

Michelle

@cweagans, there is also highlighted php code which is widely used.

  $foo = 'bar'; // Foo = bar

Love it!!!

Thanx for all the hard work everyone! Have there been any thoughts, discussion, or perhaps a new issue already filed about adding a browse/attach button in the "Insert/edit image" pop-up? If such a thing was implemented, people wouldn't have to scroll up-n-down all the time in order to reach the "File attachments" section + it would feel like less steps are required to add an image.

#1302972: Decide on a specific set of libraries, extensions, and icons for BUEditor as used on drupal.org

Upgraded to BUEditor 2 with focus on images to end of url

...minor edit to reflect actual capitalization in the editor's name ;)

This is great for usability, but it has introduced accessibility issues - #1306752: Accessibility problems with the BUEditor

Now that it's been rolled out, hopefully we can get them fixed up quickly.

How did I not see this issue until now (I was even searching around drupal.org for terms like "WYSIWYG drupal.org implementation" and "jQuery WYSIWYG drupal issue" and "drupal text format WYSIWYG"...

I guess WYSIWYG was the term that was throwing me off, because BU isn't technically a WYSIWYG... it's like the backend of a WYSIWYG :)

Is there a way to turn this off buried in my user account settings somewhere? If not, is that doable?

Also, the close widgets for the "windows" are on the wrong side.

...the close widgets for the "windows" are on the wrong side.

Do you mean the "x" button on the image/link popups? If so, I see it on the top right. Do you see it elsewhere (?) or perhaps you are a Mac user and would prefer it on the top left instead?

perhaps you are a Mac user and would prefer it on the top left instead?

Bingo. A personal pet peeve, seeing close buttons on the right/wrong (as opposed to left/right) side of non-OS-standard windows/tabs/etc. See also Firefox, Chrome and Opera; Sublime Text, Eclipse, NetBeans and so on; various Lightbox-ish scripts for the web; Adobe CS5 (oh God, I wish Apple would come out with its own iWork-like graphics apps and put those bloated pieces of garbage out of their misery); and pretty much every other "multi-platform" program (AKA Windows- and/or Linux-centric, but with a token Mac release) out there.

AND ALSO DRUPAL 7'S OVERLAY. But that's actually pretty far down the list of reasons I hate D7's overlay, at any rate.

Should I ever be required to write something like that, I'm gonna include a simple switch which checks for the host OS and puts the close widget on the correct friggin' side if it looks like an Apple OS of some sort.

Aah, good healthy rant. Feel free to ignore it. Still wouldn't mind being able to hide that button bar, though, if it's not too much trouble.

Probably should be submitted as a feature request for the bueditor module, but you can always hide it for yourself with some browser custom css using #bue-ui-0 {display: none;}.

Please let me know if there is any ongoing work on the dev site, bueditor-drupal.redesign.devdrupal.org. Space is sometimes tight on the dev servers, so we do need to clean things up. Dev site removal is permanent, with no backups.

@drumm, we actually stopped using it long ago because of the problems in the file system. It is safe to remove.

Done

changing issue title back

BUEditor makes it very easy to lose your work. I'm a good typist (as developers typically are or become), and for me the productivity gained by BUEditor is dwarfed by the productivity and reliability lost with it: BUEditor breaks the browser's ability to page back and forth without losing your half-finished text in the textareas. This becomes a major issue when combined with Dreditor (#1351700: Prevent tabbing out of the comment textarea).

It's not uncommon to lose your input on the Web, and I've trained myself to always copy longer input text to the clipboard before clicking any button or performing any risky action, but d.o used to be safe in this respect. On many days I spend a couple of hours on d.o, and with such an important tool, the difference between being able to use it confidently or to constantly fear losing your work is HUGE!

Just now I've lost over an hour's worth of intensive work on a post where I explored and documented a core bug, by inadvertently hitting Tab (and Backspace to undo the tab)...

I've opened #1351642: Major UX issue: BUEditor clears the text area in the BUEditor queue, but I think we need to be aware of this issue in this context here as well. Hopefully it can be fixed in BUEditor and deployed on d.o, otherwise I'd join #183 and ask for a way to disable BUEditor in my account.

While I completely feel you Hans, this issue here was about implementing BUeditor in d.o. This was done, so this issue here is (long) fixed and closed. We can follow up any problems in separate issues - no need to re-open this one here.

Besides the issue you created in order to find a proper solution for the problem (if possible), I'd also open another about implementing a way to allow *optional* disabling the editor on a per-user basis. Reason being that we might never be able to solve the problem, but I'm sure the setting would be relatively easy to implement.

I created a new issue for the data loss problem: #2070841: BUEditor wipes textfield content when back button is pressed.

fixing typo in summary.