I have successfully installed both WYSIWYG (with CKEditor) and plain CKEditor modules on my local LAMP installation which is an exact copy (backup, minus the SSL) of my production environment.

Upon trying to install either module on my production site, I cannot get ANY wysiwyg editor to display in either the 'appearance settings' of the module or any node add/edit pages.

To clarify, I have performed the following without success:
- installed WYSIWYG (latest stable)
- installed WYSIWYG (latest Dev)
- installed CKEditor library (stable)
- installed CKEditor library (v 3.6+)
- installed CKEditor library (dev)
- installed TinyMCE library
- installed NicEdit library
-- cleared Drupal cache upon each configuration
-- cleared browser [Chrome] cache upon each configuration

I have also performed the other suggested steps of saving all profiles and configurations upon each install.

None of these result in displaying any WYSIWYG editor for any text profile (defaults or newly created).
I have checked with Chrome Dev Tools and do not see any errors being computed in any scripts.
I DO have a placeholder for the editors, all code does seem to load however nothing gets displayed - just an empty div/area

EDIT/UPDATE: I do not have any performance options set. All caching and script aggregation is disabled

CLARIFICATION: Just to clarify, on my local installation (LAMP - exact copy of production) all editors display and work correctly. This issue arises only when configured on my production site (LAMP CentOS).


spoco2’s picture

I too have been having this issue for a little while now. I'm not sure what changed in our environment as they used to show up fine.

Now, nothing.

spoco2’s picture

I just turned off the performance features 'aggregate Javascript pages' and it fixed this issue for me as the tinymce.js file was returning a 206 Partial get error

AlviMurtaza’s picture

1) Go to configurations > Text Formats
2) Create a new text format by clicking on "Add text format"
3) Give it a name and authorization
4) then go to wysiwyg profiles in configurations
5) select TinyMCE 3.5.8 under Editor label (need to install 3.5.8 version of TinyMCE)
6) Click edit >Basic Setup and choose your desired requirements and save.
You can now use your Newly Created Editor

kaipee_s2s’s picture

Version: 7.x-2.x-dev » 7.x-2.2

Just updated to reflect version 7.x-2.2

kaipee_s2s’s picture

This doesn't work as previously mentioned. I know how to create a text format and configure wysiwyg, the problem is that it is not working.

kaipee_s2s’s picture

Issue summary: View changes

Just an update

TwoD’s picture

Status: Active » Postponed (maintainer needs more info)

@sure2sell_admin, you say that all the code seems to load, so I'm assuming all script and stylesheet files from sites/all/libraries/editorname/*, and sites/all/modules/wysiwyg/wysiwyg.js, sites/all/modules/wysiwyg/wysiwyg.init.js as well as those from sites/all/modules/wysiwyg/editors/js/editorname.js are returning HTTP Status 200 OK? Also make sure sites/default/files/wysiwyg_editorname_HASH.js gets created for TinyMCE/CKEditor and contains a global variable.
Please check if your production server has allow_url_fopen enabled. If not, make sure you are using 7.x-2.x-dev.

Make sure your production [web]server has read-access to all files in sites/all/libraries and sites/all/modules so it can inspect libraries for version numbers and aggregate scripts if needed.
Make sure you are using CKEditor 3.x with the stable Wysiwyg versions, only Wysiwyg 7.x-2.x-dev supports CKEditor 4.x yet (only the Full package).
Make sure you are using TinyMCE 3.x with Wysiwyg, TinyMCE 4.x is currently not supported (working on it).
Make sure you are not using ckeditor.module together with Wysiwyg module, they are incompatible and may conflict in odd ways.
Does Wysiwyg correctly detect the version numbers of the editor libraries on the profile overview page?

If you can think of any differences between your local setup and the production server, please list them here.

kaipee_s2s’s picture

@TwoD - apologies for not getting back sooner (things have been a little hectic)

(using TinyMCE 3.5.8)



jQuery.extend(Drupal.settings, {"basePath":"\/","pathPrefix":"","ajaxPageState":{"theme":"{mytheme}","theme_token":"Hb_oGFTzRtBZYP5c_Qm0d3JaN3EqarxEDJc0vy2bUuA","js": sites\/all\/modules\/wysiwyg\/wysiwyg.js

allow_url_fopen is enabled

ckeditor.module is not installed

WYSIWYG show TinyMCE in green with the correct version number.

I presume all of the above are correct?

I cannot think of any differences between my local server and production. I would probably need to go through each configuration file individually to compare them.

This is what the editor textarea looks like : http://i.imgur.com/Gwy7nyb.png

Drupal Musician’s picture

Version: 7.x-2.2 » 6.x-2.4

I am experiencing this issue as well with Drupal 6. TinyMCE and Ckeditor no longer display anywhere on the site. The option to enable/disable rich text also does not display either. This is a new development within the past week. During that time no changes were made to the site.

I have reinstalled WYSIWYG, updated TinyMCE to 3.5.8 and investigated possible jquery conflicts.

kaipee_s2s’s picture

Just an update (kind of on this issue).

I have managed to successfully install the CKeditor module (not for WYSIWYG API) - I will test WYSIWYG later when I have more time.

As previously noted, everything worked perfectly fine on my development environment but not on production. After some playing around, I figured out it was due to file/dir permissions with the archive that is downloaded from the CKeditor site. By default they are mostly 600 and 700, which Drupal doesn't seem to like.

The reason it worked on Dev Env was because I always download a fresh copy of the site and need to chmod all files/dirs to 644 755 because of my local setup. This meant the CKeditor file/dir also got the correct permissions.
However, when moving to production I always uploaded the vanilla package straight from CKeditor (so as to remove any testing changes) - which meant the production site was always running 600 700 permissions.

I will also test this at some time with the WYSIWYG API, currently I cannot because both WYSIWYG and CKeditor don't work well together - and as I have CKeditor installed and in use, I need to wait until I can freely switch the modules.

TwoD’s picture

@kaipee_s2s permissions does sound like a likely cause. The webserver needs to be allowed to serve the library files to the client, not just read them locally, which may be an issue if only the owner is allowed to read them. If you're uploading via FTP, the server may be configured to automatically change permissions on files so they can be accessed and served by the web server (common on shared hosting), but that may sometimes be different for custom servers.
It is correct that using wysiwyg.module and ckeditor.module together will cause odd things to happen, since they may both try to load the library and attach an editor to the same field.

@Drupal Musician, When the option to disable/enable rich-text is missing, it's usually a good indication the scripts are not running at all. This can happen if they are simply not being downloaded correctly anymore, a syntax error was introduced somewhere which caused the browser to stop executing scripts, or Drupal's script aggregation failed to combine the scripts while keeping the syntax valid. The last case often happens because one or more of the aggregated scripts are missing semi-colons or were for some reason not readable at the time of the creation of the aggregated file(s). Cache expiration of the aggregated files may in some instances be an automatic process during cron runs (some caching modules do this to not accidentally serve outdated scripts even though no change was detected). This is usually accompanied by script errors in the browser's JavaScript console, which you should be able to see.

An alternative is that some folder permissions were changed so Wysiwyg is no longer able to detect the installed libraries, at which point it will not try to attach them, but it will try to indicate library problems on the profile overview page.

Drupal Musician’s picture

Thanks for the further explanation. I checked my error console and found that a javascript for Views slideshow was throwing an error. After disabling it WYSIWYG is back functioning.

pinkonomy’s picture

I tried to make Tinymce work/appear only after I installed the 3.5.8 version (version 4 didn't work) .

TwoD’s picture

@pinkonomy, TinyMCE 4 changed a couple of things and I'm working on a patch in a different issue.

Jeroen94’s picture

I tried to install TinyMCE 4.0.2 in Drupal 7.19, but it didn't work. Therefore, I successfully downloaded TinyMCE 3.5.8 and changed my WYSIWYG profiles (I connected Roles and Text formats before, so they're okay). When I wanted to add a new Article, I noticed that the 'body' field was just a blanc space: I can't type in it anymore and there are no buttons. What must I do to fix this?

pinkonomy’s picture

@memopoezie:You should add buttons.To do so,go to Configuration >VWysiwyg profiles >Filtered HTML/Full HTML>Buttons and Plugins .There you can add the Buttons you want.Hope that makes sense.

pinkonomy’s picture

Issue summary: View changes


Bent Aarup’s picture

It could be that you have changed the language away from English under wysiwyg "Basic setup". This will cause a 404 error on the page as only english (en.js) comes with TinyMCE 3.5.8 by default installation. Just switch the language back to English, and you'll be fine.

Elucidesign’s picture

You're running 7.x dev wysiwyg and maybe MCE ... whatever.

You have no console errors, but ALL you see is a New empty bar above the text editor, so you know wysiwyg is working, and anyway you've added editors to the wysiwyg configuration, and their paths are correct.

Configuration >VWysiwyg profiles >Filtered HTML/Full HTML>Buttons and Plugins

But don't mind that this obvious to every other developer here.
Besides it's fun to get Bug reports from newbies who don't know what's wrong, but know they don't see anything.

Just Sayin'

kaipee_s2s’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

Moved to closed to prevent further pointless rants.
Issue was a simple file/dir permissions issue