CommentFileSizeAuthor
#20 browser_spellcheck.zip874 bytesemmonsaz
#17 tinymce_tweaks.zip1012 bytesgmclelland
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

davidneedham’s picture

Title: Firefox browser spellchecker + Tinymce disabled by default » In-browser spellchecker disabled by default in TinyMCE
Version: 6.x-2.3 » 7.x-2.x-dev
Component: User interface » Editor - TinyMCE

This is still true for the newest version of Drupal 7 and affects all browsers.

It seems that we must explicitly tell TinyMCE that we want to allow the in-browser spellchecker. TinyMCE only goes out of its way to disable spell-checking when you don't specify the gecko_spellcheck option. Might want to double-check the tinyMCE.init() call - it should look something like this in a normal non-WYIWYG module implementation:

tinyMCE.init({
        mode : "textareas",
        theme : "simple",
        gecko_spellcheck : true
});

(hat tip to Shog9)


So what does this mean for WYSIWYG? I tried to find something resembling this setting in all of WYSIWYG, but I didn't have any luck. If I only knew where to put the gecko_spellcheck setting I could patch this up.

TwoD’s picture

Category: bug » support
Status: Active » Fixed

sites/default/modules/MYMODULE/MYMODULE.info:
We don't have a GUI setting for this yet, but it's possible to enable the setting without hacking Wysiwyg or TinyMCE by creating a small Drupal module (or adding the hook implementation to another custom module, of course).

name = My module
description = Enables the gecko_spellcheck option for TinyMCE via Wysiwyg module.
core = 7.x
dependencies[] = wysiwyg

sites/default/modules/MYMODULE/MYMODULE.module:

/**
 * Implements hook_wysiwyg_editor_settings_alter().
 */
function MYMODULE_wysiwyg_editor_settings_alter(&$settings, $context) {
  if ($context['profile']->editor == 'tinymce') {
    $settings['browser_spellcheck'] = TRUE;
    $settings['gecko_spellcheck'] = TRUE;
    // Any init setting taking a string, boolean, number or array/object holding those types can be overridden/forced here.
  }
}

Once this module has been activated, Wysiwyg will pick up the hook implementation and run the TinyMCE settings object through it before handing things over to the client.

davidneedham’s picture

Category: support » feature
Status: Fixed » Active

TwoD - totally. Hacking modules is bad and the way you suggest is the right way to make changes like this. But shouldn't this be a checkbox within the WYSIWYG module? If I knew where it should go I could write a patch or at least make a decent proposal.

theopend_admin’s picture

Thanks - that worked like a charm! :)

TwoD’s picture

@davindneedham, sorry for the late reply. Yes, that would have been ideal. It could not be done at the time this issue was discussed since the GUI could not be changed per-editor basis. But since #1650416: Allow editor specific changes to be made to the profile settings form is in now, that has changed.

If you'd like to try to patch this in, have a look at the ckeditor implementation's settings form callback (mentioned in wysiwyg.api.php and worked on for CKEditor in #746524: No Font Styles for CKeditor).

jordan8037310’s picture

Unfortunately this doesn't seem to be a viable solution for Drupal 6.x for anyone else who wants to give this a shot.

The gecko_spellcheck setting doesn't seem to be in the array for the drupal 6 version, of course when i set it anyways it does not seem to work either...

will keep looking for a solution to auto-turn on spell check in drupal 6.

TwoD’s picture

Wysiwyg module is pretty much the same in D6 and D7, except for a couple of new features in D7.

The setting is not in the array in either version because it's currently not set by Wysiwyg by default. Adding it to the array should work in both versions, if you are using the same TinyMCE version.
Simply change core = 7.x to core = 6.x (and replace MYMODUE with a custom module name everywhere) and the setting should be sent to TinyMCE.

You can verify this by typing Drupal.settings.wysiwyg.configs.tinymce into the browser's JavaScript console or Firebug and look for the gecko_spellcheck property in the settings for each format TinyMCE is assigned to.

If it's not there, the module isn't enabled or the hook is incorrectly named.
If it is there, TinyMCE should pick it up quite easily since all it does is to set the document.body.spellcheck property. If nothing happens, maybe spellchecking is disabled in the browser?

jordan8037310’s picture

Hey TwoD,

Thanks for getting back to me. I realize now that I may have misunderstood what this custom module was trying to accomplish.

What I'm looking for is a way to make the WYSIWYG TinyMCE gui automatically turn on it's spellcheck function, but I do appreciate that this turns on the in browser function. I will leave it enabled for now.

And yes, it does work and did on the first try. I was just looking for the wrong thing unfortunately.

Cheers

shenagarg’s picture

@TwoD: I am using wysiwyg spellcheck. What would be the element inside settings array for that? Any idea please.

tsonye’s picture

#2 works like a charm. Tested via Firefox 23.0.1

gmclelland’s picture

You probably should add the following as well:
$settings['browser_spellcheck'] = TRUE;

see http://www.tinymce.com/wiki.php/Configuration:browser_spellcheck

dkinzer’s picture

setting $settings['browser_spellcheck'] = TRUE; does not work, probably because the version of TinyMCE being used is older.

gmclelland’s picture

It's working for me with TinyMCE 3.5.8

valsgalore’s picture

Until recently, I could right-click on a word in the WYSIWYG editor window to manually enable browser spell-check for that field.
I'm not sure when that changed, but now it is not an option. Does anyone know why that may be and if it's possible for a user to change that?

JKingsnorth’s picture

Issue summary: View changes

We're using #2 with great success =]

ratnesh aarohi’s picture

I am not able to get spellcheck work in tinymce 3.5.8 (after spending hours on it)
The spell check does not show the red underline in the tinymce fullhtml editor window.
However if I switch to HTML version - the red underlines show up!
How can i make spell check work in regular tinymce editor window.

I tried creating the mymodule as per #2 - but that also does not seem to work / help
(maybe i am doing somethign wrong - thought i did create a new folder at sites/all/modules/MYMODULE
and in this folder created the two files as per #2.

one doubt - where do i enable this mymodule? (it does not show up in modules page).

Can somebody give a more detailed step-by-step guide.

gmclelland’s picture

FileSize
1012 bytes

@geniekids Here is what I use for TinyMCE 3.5.8. Hope that helps

ratnesh aarohi’s picture

Issue summary: View changes

Thanks gmclelland
So while i did not use your file - but your post got me to go ahead and create the custom module (my first) as suggested in #2 by TowD.
However it did not work straight away - this is what is working for me.
I had to remove this line

$settings['gecko_spellcheck'] = TRUE;

and Ensure that I include this line
$settings['browser_spellcheck'] = TRUE;
Ensure that in the tinymce setting of buttons and pluggins - "context menu" is unchecked and "spell check" is checked
So now red underline as well as right click suggestions - both working.
Documenting here just in case this helps somebody.

webservant316’s picture

Awesome post. Thank you. I am using wysiwyg with TinyMCE and this eliminates the need for the wysiwyg_spellcheck and the TinyMCE spellcheck plugin.

I was able to use this code in either template.php or a module with equal success.

/*** TINYMCE IN-BROWSER SPELLCHECK ***/
function your_theme_or_custom_module_wysiwyg_editor_settings_alter(&$settings, $context) {
  if ($context['editor']['name'] == 'tinymce') {
    // Firefox spell checker
    $settings['browser_spellcheck'] = TRUE;
    $settings['gecko_spellcheck'] = TRUE;
  }
}
emmonsaz’s picture

FileSize
874 bytes

4 years later and we still need a module for this?! Sigh...

TwoD’s picture

Yes, but that module could also do any number of other settings alterations, does not depend on the Wysiwyg version used, and does not need to change when upgrading the editor (unless its settings changes, as it actually did earlier). Hence, a very low priority for me.

Anyone is welcome to write a patch though, or even create a module which aggregates settings modifications like this and extends the current profile GUI with widgets to modify them.

I'm sorry but a zipfile does not help me at all.

webservant316’s picture

@TwoD how do you think the problem ought to be solved? Seems like overkill to write a whole module to assign two settings. Why not handle it in the wysiwyg module? Maybe you could provide a general way to allow the web admin to simply add their own PHP assignments of whatever nature, kinda like Views does.

TwoD’s picture

@webservant316 Yes, I have something like that in mind. Some (more than now) settings will be available in the GUI "out of the box", along with a section for manually adding values to settings you know the name of (usually easy to find in the editor documentation).

The tricky part is that editors only accept JavaScript types as settings, while we construct them using PHP types on the server. They are then passed down to the clientside integration as a JSON object and then forwarded to each new editor instance. Since editors often require mode complex values than simple strings or numbers, we have to account for that in the intermediate JSON representation.
Most of the work needed to represent JS types like RegExp and Function references are done already, and it can easily be extended if needed. The largest part left is coming up with UI widgets for actually building the value structures, but I'm thinking about just falling back to just a textarea for entering a JSON-like object manually. That's for another issue though.

webservant316’s picture

super. I look forward to that feature and thanks.

NWOM’s picture

#19 worked great! It would be even better if it showed the spellcheck button pressed in though. Currently you have to press it twice to disable it, since by default it shows that it is disabled, even though it is enabled via the custom module.