rajkp

EditorMonkey is neither intrusive nor a bitch to uninstall.

1) Use the link provided in the plugin description to deactivate EM and remove it from the database.

2) Reset “Use rich editor” from your User Profile page.

That was easy. What do people find so hard about that?

The hard way:
1) Deactive the plugin.
2) Reset “Use rich editor” in the Options > Writing page.
3) Reset “Use rich editor” in the User Profile page (per user setting).
4) *OPTIONAL* Go into the database and remove any option begin editormonkey_ or em_.

As you can see, EM creates its own settings so as not to interfere with the other settings.

[Edited: namecalling is uncalled-for and contra the regs].

1) Deactivate using the uninstall link in the plugin description, not the “Deactivate” link provided by WordPress. This will run the EM uninstall script, which will remove all of the plugin’s settings from the database and reset using the (built-in) rich editor by default (for new users).

2) Go to your user profile page and select “Use rich editor.”

3) Done.

Actually, EditorMonkey has included an uninstall script for quite some time now, and this is mentioned on the website and in the readme file…

This plugin MAKES ONLY 2 CHANGES:
– it turns off using the built-in wysiwyg editor by default for all users (global/admin setting)
– it turns off the per-user built-in wysiwyg editor…

And that’s it. All the other “changes” are restricted to editormonkey.
EditorMonkey uses a different version of TinyMCE than WP does, and so it keeps a separate copy.

To uninstall:
1) Deactivate plugin.
2) Reset “Use rich editor by default” from the Options > Writing page.
3) Reset “Use rich editor” in the User Profile page.
4) *OPTIONAL* Go into the database and delete all fields that begin with em_ or editormonkey_.

EditorMonkey offers 3 spell-checking options: client-side (ieSpell/SpellBound), server-side (SpellerPages aspell), and 3rd-party (Jacuba). All of these have been integrated into the editor.

It should be fairly easy to copy over these features to Xinha or the normal WordPress 2.0+ install. For the latter, copy the jacuba and/or spellerpages plugins from the editormonkey/tinymce/plugins directory. You’ll need to add these to the tiny_mce_gzip.php file in the wp-includes directory of your WordPress install.

1) Reupload the TinyMCE 2.0.3 stuff to the folder you used above.
2) Change the tiny_mce_gzip.php file in the scripts folder to include just:
tinymce.init(
// blah stuff here
)

You’ll need to figure out what to replace blah with, but you can just cut and paste for the most part from the sample pages at MoxieCode.

Unfortunately, the JS version of TinyMCE is significantly slower than the GZIP’ed version, so be prepared for longer loading times.

You won’t be able to use the tiny_mce_gzip.php file provided in WordPress b/c TinyMCE 2.0.3 requires a newer tiny_mce_gzip.php file, which works a different way, largely b/c 2.0.3 is structurally different from 2.0-2.0.2 and should really be called 2.1 or something.

If you download the EditorMonkey plugin, you can extract some of the plugins to use with TinyMCE 2.0.3. This will be necessary for some plugins like the WordPress, as the plugin architecture changed. You’ll have to wait until next week though, when a version of EM support 2.0.3 is released with the new TinyMCE plugins.

When reinstalling EditorMonkey after reinstalling WordPress from scratch, you may encounter this problem b/c the database in which EditorMonkey’s options are stored isn’t cleared out.

So after upgrading, make sure to check up on all the settings in the options>editormonkey page before you use it in the post editing page.

Also, keeping EditorMonkey activated during the upgrade process may/will severely f*ck with the upgrade.

How is it that you can’t upgrade WordPress through FTP?

Anyways…the problem with EditorMonkey is that you don’t have the proper file permissions for the editor directories. You need to chmod the editormonkey/fckeditor/ or editormonkey/tinymce/ directories to 777 using an FTP or SSH program. Once you get things working, you can then change the permissions to whatever else works (usually 666, 644, or the ilk).

However…if you can’t upgrade WordPress until it’s updated in C-Panel, you won’t be able to change the file permissions so that you can use EditorMonkey.

There is already a function for this in the inline-uploading.php file. You can just copy that function.

And no, EditorMonkey wouldn’t fully solve the upload problem. It doesn’t support uploading in the versions that are compatible with WordPress 1.5; the same is true of its multi-user capabilities.

Since you’re getting this in both the built-in editor and in EditorMonkey, which uses FCKeditor and a more recent version of TinyMCE, I suspect the problem is your browser.

Take a look at the Javascript console to see what errors are thrown when you open the popup window.

However, it could also be that TinyMCE isn’t working for you in compressed mode. In the latest version of EditorMonkey, you can choose not to use a compression version of TinyMCE. In older versions, just change tiny_mce_gzip.php to tiny_mce.js. There’s only one instance of this in the file, so you can just do a search&replace for it.

The extra filter call is put in by the WordPress plugin. In recent versions of EditorMonkey, the filter call in the WordPress plugin has been removed.

If anyone is still interested in this topic, you can try the phpSpell hack for my WYSIWYG plugin. phpSpell is a MySQL/PHP only plugin, so no aspell needed.

Alternatively, you could find a way to incorporate Jacuba, though your client may not be interested, since Jacuba does spell checking via their server.

Pointing this one out as well, though it focuses primarily on editing posts:

EditorMonkey

chmod 666, 766, or 777.

EditorMonkey comes close to fitting the bill, though you’ll have to modify the configuration a bit to add left to right support.

However, all the browser-based WYSIWYG editors (FCKeditor, TinyMCE, Xinha/htmlArea) require that a language be installed on your computer to edit content in that language, since they don’t have control over the content area’s language (your browser/computer does).

Hey guys, the problem isn’t ChenPress, it’s the MCPUK connector that ChenPress uses by default. The connector is buggy and incomplete, which is why it was dropped from the official FCK distribution.

Just switch to the default connector…