Make Smileys work with WYSIWYG editors

Confirmed. Clicking smileys is not working with WYSIWYG API + jWYSIWYG.

Nor with ckeditor module

yes, i hope this can be integrated with CKeditor. Nothing happened when clicking on smileys with CKeditor enabled.

I also searching for this feature....

if anyone could bring an hotfix for this bug, it will be nice..

Here's a hotfix.
It's not the best WYSIWYG approach, but it'll take care of inserting the smiley into almost all of the editors supported by Wysiwyg module. As the editor implementations in Wysiwyg module are updated, the code in the patch will work with them as well without requiring modifications to this module.

For an improved WYSIWYG experience, this module could also implement an editor-independent "Drupal plugin" for Wywiwyg module. It could take care of replacing the smiley "tag" with a placeholder image for WYSIWYG mode, and back again to a tag for source/non-editor mode. That would currently require a button for insertion into the editor toolbar, but we're looking into removing that requirement.

The patch doesn't work when using FCKeditor. You first need to disable the wysiwyg-editor, click on the textarea to focus it and from then on, it'll work.
It's an improvement, but still not really handy if people first need to disable the editor, click the textarea and then reenable the editor for the smileys to work when clicked.

I assume this is because the FCKeditor doesn't focus the text-area on startup or something. So the patch is ok, but for it to work better, I assume the WYSIWYG-module needs some changes.

It however does work when you choose TinyMCE! So thumbs up and thank you for that! :)

I re-tested using FCKeditor and Wysiwyg 2.x-dev (and FF in Ubuntu and IE in XP), and I can click an icon to insert the smiley without touching the editor, right after the page is loaded.
The insert() method does not rely on the editor being focused as it grabs the editor instance directly (based on the field id) and passes it whatever is to be inserted. As long as the editor's API has had time to fully initialized this should not be a problem.

As someone who literally types the emoticon rather than using a button, I hope that any integration means the :) XD ;) etc all still work when typed into a WYSIWYG.

Michelle

Yes they would.

If the integration would be implemented as a Drupal plugin; any existing text-versions of (:) XD ;) etc) would be temporarily replaced with the corresponding images when the editor is activated.
If the functionality of the original emoticon-fieldset is kept, clicking the images there would still insert the text-variant (as it does with the above patch), they won't immediately be replaced with icons. (Content inserted via insert() is not sent via the Drupal plugins as they too use it and we don't want endless loops.) Emoticons you manually type into the WYSIWYG area will also not be replaced with icons immediately (Drupal plugins do currently not react on changed content either).
When the editor is disabled (manually or during form submission), all image-versions of the emoticons are converted back to their text-versions for normal database storage.
If you re-enable the editor (or go back and edit the node/comment) you're back at the first part again where any text-emoticons already existing in the content are converted to 'placeholder' images.

It's theoretically possible to have things work the MSN-Live-messenger-way where as soon as you type ;) it'll also be converted to a placeholder image (which you can delete with backspace), but that's currently not possible in a cross-editor way. We're looking at expanding the Drupal plugin 'feature frame' for Wysiwyg 3, and then it might be possible for them to 'listen' for and react to 'content changed' events.

#5 not working in my case.
I have CKEditor + WYSIWYG.
Maybe reason is that CKEditor workarea looses focus when i click open smileys window??

Uploading screen one more time

Resovled. Installed dev instead of alpha5.

@mrówek, please disable script optimization/aggregation when posting where an error occurs, there's no way for anyone to know which real file and line the line from the aggregated file corresponds to. Anyway, I was now able to reproduce the error, but only on comments.

Like I said above, when an editor is enabled it doesn't matter if it has focus or not when the .insert() method is called. However, the textareaFocussed variable defaults to 'edit-body', even when there is no node body field in the document. Since I used the textareFocussed variable to check for an editor instance, that check will fail when using Smileys on a comment body since textareaFocussed doesn't actually point to that field. When the check fails, the code for a regular textarea ends up being used instaed, but that throws an error when an editor is active.

So, to fix this I let the textareaFocussed variable be updated to reflect whichever textarea actually received the smiliey.
That also simplified check for TinyMCE support (without Wysiwyg module). And it also makes the check catch cases where the field is not 'edit-body' or 'edit-comment' but is still allowed to have smilies.

WYSIWYG + TinyMCE works with Smileys without a patch.

A big thank you to TwoD for this patch. It works perfectly with CKEditor 3.3.1.
I'm really happy!

6.x-1.x-dev does not work with WYMEditor.

#12 is not working on Chrome when the page is just refreshed.

Nevermind my issue with WYMEditor, I hadn't realized the patch in #12 wasn't committed in dev.

it's work in firefox (both patches)!!

I know that there's solutions already provided but here's another patch that worked for me to get ckeditor working. Just thought I'd share :)

Hmm, this one didn't work for me. Just clicking the smiley does indeed add the text ":)" to the post but then it's simply displayed as text, rather then as a smiley. If I drag a smiley into the post it duplicates the smiley and also adds the additional broken HTML ":smile:" width="19" />"

working.
but since ckeditor adds the   for the spaces near to the smily text the smiley input formats breaks.

any Idea?

[Added code tag so the HTML markup shows up]

I think using insertText instead of insertHtml may fix that?