I've built a very rough but functional BUEditor integration module. So far I've tested it with 3 input formats and 3 different editors. I'd like to contribute this after some cleanup, but I'm not sure how it fits into wysiwyg or BUEditor.
I've built it as an additional module rather than a wysiwyg contrib because it required a hook_form_alter function to achieve the settings I was after. Also, the BUEditor is packaged as a standalone Drupal module, and it didn't make sense to drop it right into the wysiwyg folder. And, BUEditor provides a complex UI for creating and importing multiple button sets that I didn't want to duplicate.
BUEditor can provide multiple button set presets. The hook adds an additional fieldset with a select control to choose the BUEditor preset to use for the selected input format. For example, if you click "edit" on the BBCode input format wysiwyg profile, you can select from the editor presets created on BUEditor's admin pages and choose the "BBCode" editor.
The hook_form_alter is too specific to dump into wysiwyg's codebase, but at this point I think it's necessary. I couldn't find any other way to add a simple "select" control to the settings page. The settings and plugins interface for wysiwyg is (so far) not very well documented and seems quite convoluted. Please tell me there's a way to add more than checkboxes in a way that somehow resembles the Form API!
Should I:
Stay with the standalone "bridge" module route?
Try to merge with the BUEditor project?
Find a solution to the settings problem and eliminate the hook_form_alter and produce a patch for wysiwyg?
Thanks!
Comment | File | Size | Author |
---|---|---|---|
#29 | wysiwyg_bueditor6.patch | 3.32 KB | ufku |
#25 | wysiwyg_bueditor6.patch | 3.01 KB | ufku |
#4 | wysiwyg_bueditor.zip | 2.83 KB | criznach |
Comments
Comment #1
sunFirst 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.
Comment #2
criznach CreditAttribution: criznach commentedThanks. I feel like I've not only tried, but I have a functional solution that could be useful to others. I'm using my work at http://www.montanakitesports.com, combined with better_formats and tinymce for admin users. It works with multiple instances per page, and multiple BUEditor presets. I've also been able to integrate g2image pretty painlessly. I wrote my own JS detach code for BUEditor, since there was none before.
My experiences mostly agree with points 1 and 2. Point 3 is difficult, because BUEditor appears to be designed primarily as a Drupal module. I've written the author of BUEditor, asking for his thoughts. But... I'm not personally prepared to invest the time coding, coordinating, and negotiating to make a standalone BUEditor without the module. And from what I've read, I'm not sure the author is either... Someone please prove me wrong.
So it looks like at this point there may be an impasse between these two modules. Hopefully what I've built will be helpful to someone until this passes. I'll most likely clean this up and release it as a standalone module rather than debate with two maintainers about where it belongs.
As for editor settings... After looking under the hood of wysiwyg's settings and plugins form for a few hours and still having only a basic understanding of what's going on, I wonder why a hook_form_alter or hook_settings style hook using Form API has not been implemented? Can you provide some insight into the current implementation, and maybe I can invest some time in helping with a solution?
Comment #3
criznach CreditAttribution: criznach commentedOk, I've read the entire "advanced editor settings" thread, and see that this is a work in progress. That still doesn't solve the BUEditor as a module question. I've joined the Wywiwyg group on GDO and will watch this issue. Please let me know if there's anything I can do moving forward.
Comment #4
criznach CreditAttribution: criznach commentedI'm attaching my current work if you're curious... To use it, download and enable the stable release of BUEditor 6.x-1.2. At this point, it must be the packaged version for version detection to work properly. Set all of it's role presets to "none" to avoid conflicts. Then you can configure BUEditor inside of the Wysiwyg admin UI. Click the "edit" link to select which BUEditor preset is used. I'm not currently checking for deleted profiles, input formats, etc, so use it with caution.
Comment #5
sunReleasing 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.
Comment #6
sunComment #7
criznach CreditAttribution: criznach commentedYes, #5 is how I invoke the editor, but I'm relying on the admin interface from the module rather than trying to re-create it inside of wysiwyg.
Comment #8
sunI'll have a look at this asap.
Comment #9
scottrigbyThis 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 :)
Comment #10
Roi Danton CreditAttribution: Roi Danton commentedThe 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.
Comment #11
sun@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.
Comment #12
Roi Danton CreditAttribution: Roi Danton commentedIf 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.
Comment #13
RobLoachBUEditor FTW... Subscribing.
Comment #14
Roi Danton CreditAttribution: Roi Danton commentedI 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.
Comment #15
that0n3guy CreditAttribution: that0n3guy commentedsubscribing
Comment #16
mlncn CreditAttribution: mlncn commentedSubscribing, 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?
Comment #17
shunting CreditAttribution: shunting commentedSubscribing, 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.)
Comment #18
JaredAM CreditAttribution: JaredAM commented+1 for this feature.
I'd just like the ability to select BUEditor for certain roles.
Comment #19
rv0 CreditAttribution: rv0 commentedsubscribing.
been using BUEditor with BBCode on a forum for over a year.
Comment #20
ilfelice CreditAttribution: ilfelice commentedSubscribing. +1
Comment #21
zooki CreditAttribution: zooki commentedHi, may I ask how I can get BUEditor to work, its very good for a simple editor , especially for a drupal Forum
Comment #22
yan CreditAttribution: yan commentedsubscribing
Comment #23
jrsinclair CreditAttribution: jrsinclair commentedI'd love to see this feature too.
Comment #24
a_c_m CreditAttribution: a_c_m commentedSubscribe. As more add-on modules e.g. http://drupal.org/project/wysiwyg_imageupload start supporting WYSIWYG exclusively, its going to become increasingly important.
Comment #25
ufku CreditAttribution: ufku commentedThe patch introduces all bueditors to wysiwyg as individual editors.
Comment #26
TwoDNice 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:
If we could use the code from http://ufku.com/drupal/bueditor/non-drupal instead, we'd be able to get around that.
Comment #27
ufku CreditAttribution: ufku commented@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)
Comment #28
TwoDI 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:
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.
Comment #29
ufku CreditAttribution: ufku commentedIt 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.
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.
Comment #30
shunting CreditAttribution: shunting commented#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.
Comment #31
crea CreditAttribution: crea commentedSubscribing
Comment #32
mgiffordSeems more important now that d.o is using BUEditor #424400: Use BUEditor on drupal.org
Comment #33
benmalen CreditAttribution: benmalen commented@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.
Comment #34
mgifford@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.
Comment #35
criznach CreditAttribution: criznach commentedI haven't looked at this issue in detail since I wrote the original code, but I suspect it might be possible to create a reusable PHP library for the UI elements, that could be common between the BUEditor module and the WYSIWYG module (with standalone BUEditor).
WYSIWYG integration vs bueditor.module is important on sites where admins can create HTML content, and general users can uses BBCode or other simple markup. Using the Better Formats module, one can assign editors to roles.
I still disagree that editor integrations should be part of WYSIWYG API. This creates issues like this one, where it takes years to agree on how to do something. It would be nice if one could simply USE the API to expose new editors.
Comment #36
cindyr CreditAttribution: cindyr commented+1 for BUEditor on Drupal 7
Comment #37
fasdalf@fasdalf.ru CreditAttribution: fasdalf@fasdalf.ru commented+1
Comment #38
Steel Rat CreditAttribution: Steel Rat commentedSince there is no other Smiley module for D7 hat I'm aware of, I definitely need this!
++1
Comment #39
rv0 CreditAttribution: rv0 commented@Steel Rat: http://drupal.org/project/smiley
Comment #40
Steel Rat CreditAttribution: Steel Rat commentedSorry about that. I was redirected here from the Smiley module since I use BUE.
Comment #41
mvcThe 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.
Comment #42
mgiffordThis would be great. It's a terrific editor.