All I'm trying to achieve, which I can't believe it is still so difficult, especially since D6 was released over a year ago now, is to have a wysiwyg editor which allows the user to upload an image and insert it inline, and then resize it and float the damn thing left or right. It is really quite laughable that drupal doesn't do this out-of-the-box with the core upload module and whatever editor is chosen.

Anyway, I have the wysiwyg API installed, and I like nicEdit. I've tried fckeditor and tinymce, and I did not like them - what you see in the text area is not what you see once the node is saved - NiceEdit was far more accurate without having to mess around with css and other settings. The rest of the supported editors are even worse.

For uploading images I've tried:
· filefield + imagefield + filefield insert
· imagepicker

The problem is that the 'insert image' button doesn't work on either of these modules with NicEdit enabled.
If I disable NicEdit, then the html for the image is inserted, but this is far too clumsy for a production site.

So, who/what is to blame?
Is it the editors which aren't allowing the insertion?
Is it because the wysiwyg API module isn't working properly?
Is it because filefield insert and imagepicker aren't inserting in a proper manner?

Most importantly, can anyone give me a combination that actually WORKS?
wysiwyg API + [which editor?] + [which image uploader?]


Members fund testing for the Drupal project. Drupal Association Learn more


TwoD’s picture

Status: Fixed » Active

The modules filefield, imagefield and filefield insert are designed to work with textareas only and do not check to see if they've been 'replaced' by a WYSIWYG editor. (Which is why they work if you temporarily disable the editor.) EDIT: Looks like I was wrong about filefield insert, it does support Wysiwyg module.

The imagepicker module seems to have an "odd" way to attempt to insert content into the active editor. Imagepicker correctly detects if Wysiwyg module is enabled but not if it's actually in use on the field in question, and it does not use our API. You might get it to work with FCKeditor and maybe with TinyMCE on node body fields.

You might want to try Image Assist (currently works with TinyMCE) or IMCE (adds a "Browse" button to the image dialog in TinyMCE or FCKeditor).

Image Assist uses the Image module to handle images, meaning each image file is associated with a node for metadata, tagging, description etc.

IMCE treats images as regular files. IMCE module itself usually works with textareas only, but is extended to work with Wysiwyg module by IMCE Wysiwyg bridge.

-Anti-’s picture

Thanks for your reply.

I like IMCE for myself, but it is too complex for the average user.

I was trying to stay away from image + image assist because it seems
the future of adding images/media will probably be through cck methods.
I don't personally like the idea of each image needing a node either.

OK, so, have I got this right:

NicEdit needs to be patched to allow scripts to add content into the text area. And although 'filefield insert' uses the wysiwyg API, this module can't do anything about that particular problem. So, in conclusion I should forget about using NicEdit, because it is not likely to ever be compatible with 'filefield insert'. Further, since TinyMCE *does* somehow magically work with 'filefield insert', I should use that instead even though it is is not the best choice of editor.

Is that an accurate appraisal of the situation as it stands?

Another question: Does anyone think this ridiculously stupid situation EVER be fixed? I mean, how many YEARS has wordpress being allowing users to easily upload images and video and insert them inline? It's just insane that Drupal can't do this yet. IMO, Drupal should never have won any awards, solely on the basis of this deficiency!
Harsh, yes, but this is an extremely frustrating barrier to creating usable, media-rich sites.

TwoD’s picture

Status: Active » Fixed

Yes, a small patch adding the .insert() method to our NicEdit implementation would be enough, had 'filefield insert' 'imagepicker' properly used the wrapping API. All we could do about that would be submitting patches for those modules and hope they get accepted.

Yes, you'll have to stick to using TinyMCE (or FCKeditor) since that is what the filefield insert imagepicker module supports to some extent.

EDIT: I was looking at the code for imagepicker and not filefield -insert. Filefield insert just needs the patch mentioned above to work.

Why image handling has not been put in Core earlier you'll have to ask the Core team. It has been done in D7, see #371374: Add ImageCache UI Core.

Wysiwyg module's API is still in an early state, which is why the 'API' part was dropped from the name. We intend to change a lot of that for Wysiwyg 3.x and D7 (and probably backport most of it for 2.x and D6). That will hopefully make a lot more modules implement the API in a proper way and somewhat remedy the situation.

-Anti-’s picture

Status: Active » Fixed

Thanks for the reply and clarification.

TwoD’s picture

Title: 'insert image' not supported? » Add insert method.
Version: 6.x-2.0 » 6.x-2.x-dev
Component: Miscellaneous » Editor - nicEdit
Category: support » feature
Status: Fixed » Postponed
1.97 KB

Here's a patch to add "insert" support for nicEdit. Passes manual tests in IE 8 and FF 3.5, but not yet tested with the actual filefield insert module.
NicEdit uses a div tag to wrap the editing area, making it a bit tricky to get and replace the selection so I tried a slightly unusual approach after consulting's compatibility tables.
It should work in all major browsers, but Konqueror probably won't be able to insert HTML comments (Konqueror just crashes when initializing the Wysiwyg scripts anyway so we've locked it out).

Note: the patch was made using 6.x-2.x-dev and should really be re-rolled against 7.x-3.x-dev and applied there first, then backported. 3.x-dev needs some more work before that will be done though.

-Anti-’s picture

Wow... Thanks for your work on this.
I was trying my best to suffer with TinyMCE, but really wasn't very happy.


sime’s picture

Thanks ++. Patch works as advised.

This is great because I tried the following wysiwygs as an alternative to TinyMCE/FCKEditor but none of them seem to support the insert routine and hence are not compatible with Insert module:
wymeditor, openWYSIWYG, markitup, jWYSIWYG

sime’s picture

TwoD, if you were to create a patch that adds the .insert() method to WYMeditor (6.x-2) you can bill me for your time (or alternatively request a chipin donation to the Wysiwyg project). I don't need this to be committed, I'm happy to manage the patch for my own purposes.

sime’s picture

Alright, I actually looked closer and I could do this myself if I find the time. Offer stands though.

sime’s picture

oops, worked it out, went to make a patch and it turns out my version of wysiwyg is older - WYMeditor has the required code to do insert in DRUPAL-6--2 branch.

-Anti-’s picture

Can I ask what attracts you to wymeditor, over nicedit or tinyMCE?

sime’s picture

I like the emphasis on meaning, so for clients who wish to establish a tight style guide it's great.

I also like that it uses jquery, it's consistent with where I spend my time as far as JavaScript goes. (I don't know if nicedit is in jquery, so forgive my ignorance if so).

I like nicedit for user comments, light and simple.

But what inevitably happens is one of these tools lacks a feature the client wants and I'm forced to use TinyMCE anyway!

TwoD’s picture

Status: Postponed » Needs review

I need someone to help me test the patch in #5. I don't have Safari so I can't confirm that part is working at all (code is adapted from an example I found while searching for cross-browser insert issues).

All help appreciated, thanks!

sun’s picture

More or less re-rolled.

sun’s picture

We discussed this patch and figured that it's basically like $.supports, and ideally, we'd be using a similar design - perhaps even literally the same, keeping the code forward-compatible ($.supports only exists from jQuery 1.3 onwards, but that doesn't prevent us from stacking something onto $)

sun’s picture

errr, sorry - last comment was actually meant for #497654: Drupal plugin buttons disabled in WebKit based browsers

This patch looks good, and it's only hold off by missing cross-browser tests. If no one steps up, we'll let the masses "test". :P

sun’s picture

Status: Needs review » Fixed

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dreamdust’s picture

Title: Add insert method. » Add nicEdit insert method.
Version: 6.x-2.x-dev » 6.x-2.1
Status: Closed (fixed) » Needs work

The insert method does not set the caret *after* your inserted text. This is what the user expects, as if you insert something in the middle of a paragraph you want to be able to continue typing without clicking to where you left off.

dreamdust’s picture

Category: feature » bug

In addition to the insert method not inserting before caret, it doesn't insert at the caret at all in Safari/Chrome.

dreamdust’s picture

It doesn't insert at caret in Opera 10, but at the beginning.

gabor_h’s picture


The patch in #5 calls editingArea.focus() only if document.selection is true.
I think focus is always needed, not only in this case. I have seen text inserted outside of the textarea when editingArea.focus() is not called.

TwoD’s picture

@gabor_h, can you find steps to reproduce that issue?
If so, I'd be happy to confirm such a change does indeed fix the problem you describe.

@dreamlust, I haven't yet found a way to reliably control the caret position after an insert (the way it's done now), and I haven't found much specs on where the caret is supposed to be. Browsers seem free to control this themselves.
I've tested with Safari, Chromium (Ubuntu) and Opera (11) as well and they all inserted the content, though some left the caret before it.
I don't have Opera 10 to test with, so if anyone can help me debug the insert-at-beginning issue, I'd appreciate it a lot. I could not reproduce that in Opera 11.

gabor_h’s picture

Hi TwoD,

1. Let's use the node edit form as an example. Let's assume that nicEdit has been set up to appear in the body area. Let's use Firefox.
2. Add a special button to this form that executes the code of the insert() method found in nicedit.js. The purpose of this button is to insert some text in the editor area.
3. Load the node edit page, click in the editor area (so that it has focus), and then click the special insert button. The text will be inserted correctly in the editor area.
4. Click outside of the editor area (click on an empty space or in a text field) so that the editor does not have the focus. Click the special insert button. The text will not be inserted in the editor area, the text will be inserted after the button as if the text would be part of the HTML page.

Please let me know if more clarification is needed.

I think you may use any other way to execute insert(), not only a button as described above, the important thing is to call insert() when the editor has no focus.

TwoD’s picture

Yep, I can reproduce that.
The problem is that when moving the focus call up there, inserting something in an editor without focus means it ends up at the beginning of the contents. I think most people would expect it to be inserted at the end instead.

I've been testing a few workarounds and the easiest and most reliable solution appears to be to loop through the parent nodes of the selection's/range's common ancestor node and see if one of them is the editing area itself.
If not so, the content to be inserted is simply appended to the editing area.

It's getting late here and I've not had time to test it in all major browsers yet (IE will need some special treatment), so I'll not create a patch yet.

This still leaves the (lesser) issue of the caret ending up before the inserted content...

EDIT: Missed a "not" above.

TwoD’s picture

Status: Needs work » Needs review
2.98 KB

The code I ended up with removed the focus() call completely and replaced it with some logic to check if the caret is actually inside the editing area or not. If so, paste the contents and move the caret after it, if not, just append the contents.
Same logic repeated for both types of selection/range APIs.

I've tested this in IE 8 on XP, Safari on Ubuntu via WINE, Opera 11 on Ubuntu, Chromium on Ubuntu and Chrome on XP, and they all behave the same way. If caret was inside the editing area at insert time the caret is moved after the inserted content, otherwise it just appends the content to the editing area.

One note: NicEdit plugins with buttons triggering insert() MUST call event.preventDefault() and possibly also event.stopPropagation or set event.cancelBubble = true (if available) in the mouseClick callback. Otherwise the button itself will gain focus and no caret will be visible in the editing area in some browsers.

EDIT: I forgot to mention that it'd be great if someone can test this in IE9. It has support for much of the standard selection API but not all so I'd like to know how this works there.

TwoD’s picture

Issue summary: View changes
Status: Needs review » Fixed

  • Commit ed235c7 on 6.x-2.x by TwoD:
    - #594322 by TwoD: Fixed caret position after inserting content in...
  • Commit f6f378e on 7.x-2.x by TwoD:
    - #594322 by TwoD: Fixed caret position after inserting content in...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

gabor_h’s picture

Thank you, TwoD