Add editor: BUEditor

First of all, thanks for trying.

- Any code for BUeditor support should go into Wysiwyg API at this point in time, because major parts of the API can still change without notice.

- Based on what you described here, I think you would need #313497: Allow configuration of advanced editor settings to do it properly, but that issue still needs a lot of work. Currently, we can only do a half-baked implementation like the (very similar) one for markItUp.

- This BUeditor integration must work without BUeditor module. Editor libraries have to be considered as plain JavaScript libraries.

Releasing your code as a separate module will be a pain for users, because that module will end up in compatibility nightmares. So far, Wysiwyg API works, but during the past months, we identified a lot of major issues that still need to be changed. Those mostly apply to editors, which is why I'm discouraging anyone from putting editor support code into a 3rd party module.

Well, when you posted this issue, I googled for "bueditor" and quickly found http://ufku.com/drupal/bueditor/non-drupal - which looks very similar to markItUp

The best way to get the ball rolling is to attach your code to this issue.

I'll have a look at this asap.

This would be great - there are a few things about BUEditor that make it worth using IMO (like not adding unnecessary

and
tags, integration with Linodef etc). Would be happy to test this whenever that'd be helpful :)

The advantage of the BUEditor module for Drupal is the possibility to add custom buttons through an admin settings page. Like you would add/write a WYSIWYG plugin at an admin settings page.

To provide this functionality a separate module like posted in #4 is required (this feature separates the BUEditor Drupal module from most of the other editor modules). WYSIWYG API doesn't provide the required functionality yet.

In process of writing a WYSIWYG plugin for my filter module I'm also in need to add buttons with the help of an admin settings page. Though these buttons are specialized for my needs the functions *could* be useful as button creation tools also in WYSIWYG API core. When i open the respective WIP issue I'll update this post with a link.

@Roi Danton: Hmm. We recently opened the 3.x branch for Wysiwyg, in which we will solve #313497: Allow configuration of advanced editor settings and related issues. That means that each editor will get its own, custom configuration settings (full-blown cockpit) in the long run. I'm not sure - if BUeditor would be supported by Wysiwyg module and this implementation would include support for Wysiwyg's "Drupal plugins" - whether a) one would still need the ability to configure custom buttons at all and b) if a) would be required, whether the editor configuration form could not provide the possibility.

If in case (b) the editor configuration form provides the possibility to execute php functions with a button this would be sufficient (this is what I appreciate on BUEditors Drupal module). To create buttons for my filter module (lists of nodes, fields etc) I'm using the views module and own queries where the site admin sets arguments for each button (certain node types, views etc). These functions are called by clicking on a button and they return Javascript with the required data. The short function in linodef_buttons_bueditor.module makes it clear.

BUEditor FTW... Subscribing.

I did it with one popup window (WYSIWYG plugin) which incorporates buttons which admins can create on a Linodef settings page. However this hasn't much to do with BUEditor itself so I used the WYSIWYG drupal group for further discussions about WYSIWYG plugins.

subscribing

Subscribing, and to throw another curve at this request my ideal use for BUEditor would be for the same input format that works for another WYSIWYG-- that is, I would be able to switch from using TinyMCE to edit a post to using BUEditor, and the input format should not change. Any hope?

Subscribing, since my use case is the same as #16. I want to swap back and forth seamlessly. (This is a classic use case for a structured editor, familiar from the markup world.)

+1 for this feature.

I'd just like the ability to select BUEditor for certain roles.

subscribing.

been using BUEditor with BBCode on a forum for over a year.

Subscribing. +1

Hi, may I ask how I can get BUEditor to work, its very good for a simple editor , especially for a drupal Forum

subscribing

I'd love to see this feature too.

Subscribe. As more add-on modules e.g. http://drupal.org/project/wysiwyg_imageupload start supporting WYSIWYG exclusively, its going to become increasingly important.

The patch introduces all bueditors to wysiwyg as individual editors.

Nice to see you here, ufku!
Thanks for the effort, but one problem I see with this patch that the installation instructions on admin/settings/wysiwyg will be misleading, and it also depends on bueditor.module.
See Sun's comment in #1:

- This BUeditor integration must work without BUeditor module. Editor libraries have to be considered as plain JavaScript libraries.

If we could use the code from http://ufku.com/drupal/bueditor/non-drupal instead, we'd be able to get around that.

@TwoD
There will no installation instructions for BUEditor because hook_editor does not return any editor info when BUEditor is missing. I think this non-standard behavior is better than a misleading installation instruction.

Since BUEditors are built from scratch, the integration without the module requires custom settings page and lots of efforts.

I think current approach is the only way for BUEditor-wysiwyg integration with the current api of wysiwyg.(without an extra module)

I see your point but I meant the instructions as a whole. It won't be obvious BUEditor is even supported or where to get it from if it's not listed there with the other editors - unless one peeks in the wysiwyg/editors folder or goes to the project pages here.

Yes, without #313497: Allow configuration of advanced editor settings it'll be overly complicated to create those custom settings pages now, but if bueditor.module is required, works on its own and most of it's GUI is used for the settings, one might as well use just that module, right?

I think it's a good thought and it's obviously meant to increase compatibility, but I'm just afraid doing things this way (kind of semi-merging the modules) will confuse users. Wysiwyg module determines where editors appear, but BUEditor modules determine which editors are available and how they are configured, even though Wysiwyg also provides it's basic settings page.

EDIT: I'm not sure this arrangement would work once we start depending on Libraries API, would have to look that up.

Oh btw:

+++ bueditor.inc
@@ -0,0 +1,70 @@
+    'installed version' => '6.x',

Please use a version callback instead of hardcoding the installed version. The callback should check an actual file belonging to the editor to get this info. The string also needs to be precise enough to identify each release or we'd have trouble creating new clientside integration files if BUEditor's API changes.

Powered by Dreditor.

It now uses a version callback but does not look up for a version because it's Drupal 6 and BUEditor 6 API used by wysiwyg stays the same.

if bueditor.module is required, works on its own and most of it's GUI is used for the settings, one might as well use just that module, right?

I think people who want BUEditor in wysiwyg love switching editors on the fly and they want BUeditor also switchable. They probably wouldn't want to give up BUE's GIU while doing this.

I know this integration is hacky and non-standard due to the nature of BUeditor and current wysiwyg API. What I'm providing here is just a workaround for people demanding a solution. I don't want to press for committing such code.

#29 Thanks, this is awesome. I tested it, and it works. In WYSIWYG, it can look like nothing is happening, because after the patch, you don't get BUedit on the editor dropdowns at admin/settings/wysiwyg. But if you delete the editor under operations, then you get it.

* * *

FWIW:

My use case isn't switching back and forth. In my experience, the markup produced by WYSIWYG editors is so cluttered, it's impossible to read. Moreover, if you change the markup, that may have unexpected results when you go back to WYSIWYG.

Rather, my use case is that I have a class of users -- mostly non-technical, by the way -- that has figured out BUedit is more efficient than WYSIWYG, and produces HTML that is much cleaner and more readable, too. Plus, I love adding value by mapping to buttons. But heck, sometimes they do something in long form in Word, and want the option of pasting that in, which CKeditor gives them.

My solution was to give make WYSIWG the editor for the Full HTML format, and BUedit the editor for the Filtered HTML format.

So, thank you thank you thank you, and I encourage the WYSIWG developers, when working on their API, to consider all both visual- and markup-oriented editors.

Subscribing

Seems more important now that d.o is using BUEditor #424400: Use BUEditor on drupal.org

@mgifford Since I saw BUEditor being used on drupal.org while on my iPad, this got my interest (no other WYSIWYG editors seem to work on iPad). The BUEditor module doesn't work exactly how I would like along side WYSIWYG so it would be nice if it were supported.

@benmalen - the BUEditor folks have been quick to respond to my concerns. Great to hear it works on an iPad. I do think there are a lot of advantages to having a small WYSIWYG that the community can control. We're in a good place to make it better.

+1 for BUEditor on Drupal 7

+1

Since there is no other Smiley module for D7 hat I'm aware of, I definitely need this!

++1

@Steel Rat: http://drupal.org/project/smiley

Sorry about that. I was redirected here from the Smiley module since I use BUE.

The last release for 6.x was in June 2011 and I strongly suspect that if this is ever going to happen it'll be in 7.x. So, I'm bumping the version so that this doesn't get lost.

This would be great. It's a terrific editor.