Just an FYI, but WYSIWYG can't detect the latest CKeditor build, instead throwing the error "The version of CKEditor could not be detected.". However, going back down to 3.5.3 works fine.



Status:Active» Fixed

This was already fixed in the latest dev snapshot.

This was already fixed in the latest dev snapshot.

The patch was committed to master (7.x-2.x), 6.x-2.x and 5.x-2.x which correspond to each -dev snapshot.
The current x.x-3.x branches are not used.

Drupal canot detect installed ckeditor.

@KentK, that does not help at all.
Which version of Wysiwyg are you using? You need an up-to-date -dev snapshot or it won't recognize the editor, as stated above.

I have the same problem. It's not working. When I use 7.x-2.0 of WYSIWYG it cannot detect it. When I use 7.x-2.0-dev it does detect it, but i cant assign the editor to a profile. All i get is a white screen or it goes back to the WYSIWYG profiles page but nothing has happened/changed.

Edit: Fixed it myself. Was a horrible error on my part.

@Filimonov, can you tell what have you done to resolve your problem ?
I've got the same problem - dev version can detect CKEditor, but I cannot change profile - I got blank page after saving

I've given up on CKeditor. Everyone says it works and then it doesn't. Tried every conceivable configuration and it doesn't appear in any of the text fields. I found a youtube link with a person that used TinyMCE and edited one line of code. It has worked great every since. I'll have to find it again if anyone is interested. I was so excited the WYSIWYG editor was working that I lost the video link.

I'm surprised so many are having problems getting CKEditor to work.

@drupaljohngo, getting CKEditor and TinyMCE to work via the latest Wysiwyg module (-dev for CKEditor's latest releases) doesn't require changing a single line of code. I'd be very interested in seeing which line was modified, where and why. If file modifications are needed to make the editors appear, that should be reported as a bug in our issue queue.

I'm offerring to personally help debugging sites where CKEditor's latest versions do not work, but please note that I'm doing this in my spare time so there might be a delay before I can get to your case. Drop me a line via my contact form if you're intersted. (If you've already tried that but got no reply, please try again. Yesterday I noticed a misconfigured filter in my mail client might have trashed mails from the contact form.)

I just today downloaded WYSIWYG 6.x-2.3 and CKEditor 3.6. I went to the WYSIWYG admin page, and it gives me the "The version of CKEditor could not be detected." error. I have verified that the ckeditor.js file is in the correct location (sites/all/libraries/ckeditor/ckeditor.js) and is world-readable.

Ah... I see from above that only the DEV versions of WYSIWYG have this fix. A new release would be helpful. :)

I'm not a programmer, so excuse my ignorance, please. I installed all, Drupal 7.0, WYSIWYG 7.x-2.0, and CKeditor 3.6 this past weekend (May 14 and 15, 2011) and had the problem indicated by the issue title. How come? Today I installed the CKEditor 3.5.3, as suggested, and it indeed "works fine". Is the "dev snapshot" a file that's part of the CKeditor file set, WYSIWYG module or the Drupal installation? What do I have to do to make the latest CKeditor recognized? I haven't seen any patch or reference to the problem on the CKeditor. Perhaps I haven't spent enough time looking. I've noticed there are other modules/apps that are not recognized by the new releases of Drupal, e.g. PHP. Is this a recurring problem with new releases?

WYSIWYG 6.x-2.3 also cannot detect ckeditor 3.5.4 for me. I'm very reluctant to use a DEV release on a production site with non-sophisticated users... I had no problems detecting ckeditor 3.5.3 in the same location, or tinyMCE.

I see jhodgdon just beat me by six minutes, while I was composing my questions. So, the "dev snapshot" refers to the development version of the software, doesn't it?

I guess I did right by resisting the temptation to install the 3.5.4 and went straight to the 3.53 as suggested. Saved some time and frustration. :-)

The 'dev snapshot' is referring to the development release version of the WYSIWYG module. If you cannot patch or use dev version of WYSIWIG simply use an older release of the CKEditor library. http://ckeditor.com/download/releases (3.5.3 or later)

@dazimon, that's a bit off topic for this issue, but I'd suggest you look at IMCE and its companion IMCE Wysiwyg bridge.

EDIT: posted the above before I noriced you removed the question.

@jhodgdon, the -dev snapshots of Wysiwyg's main branches are just as stable as the official releases, if not even more stable. There are currently very few differences between -devs and 6.x-2.3 or 7.x-2.0. The only change to the CKEditor implementation was the fix for the version check being incompatible with CKEditor's latest releases. (A very simple fix.)
The big [and potentionally unstable] changes and new features are developed in separate branches based of the master branch (7.x-2.x), such as the sort_buttons and xhtml_callback branches.

Thanks for the pointers TwoD! I'm just groping around for the first time. I just checked back and remembered that the IMCE is what led me to all the way to the CKeditor.

I came across this thread when I tried to use wysiwyg v7.x-2.0 with ckeditor v3.6

As stated earlier, it looks like EugenMayer has already identified the root cause of this and corrected on the development path (http://drupalcode.org/project/wysiwyg.git/commitdiff/26b4887).

In Summary, it looks like wysiwg reads in 140 characters per line (up to 8 lines) of ckeditor.js and expects to find the version string. However, after ckeditor v3.5.3 (specifically v3.5.4 and v3.6, and newer) , the version id is found further in the line (greater than 140 chars).

The fix promoted by Eugen increases the max number of characters read from 140 to 500 which currently allows the inclusion of the location of the ckeditor version id to be located and identified.

It looks like the length argument is optional for fgets, but I guess there could be a performance hit/trade off/compatibility issue, if removed.

if for some reason a user does not want to install the development branch, It looks like the change could be made manually to the installed version of wysiwg in ./wysiwyg/editors/ckeditor.inc file by changing line 67 (v7.x-2.0) to read in 500 instead of 140 chars like so, it seems to work for me:

@@ -67,7 +67,7 @@ function wysiwyg_ckeditor_version($editor) {
$library = fopen($library, 'r');
$max_lines = 8;
- while ($max_lines && $line = fgets($library, 140)) {
+ while ($max_lines && $line = fgets($library, 500)) {

// version:'CKEditor 3.0 SVN',revision:'3665'
// version:'3.0 RC',revision:'3753'
// version:'3.0.1',revision:'4391'

@windtrekker, yes, the patch is exactly that simple.

Issue tags:+wysiwyg, +ckeditor

I got the qame trouble ! ....
Perhaps an idea :
ckeditor 3.6 is defined ===> version:'3.6',revision:'6902',_
In Wysiwyg
function wysiwyg_ckeditor_version($editor) {
$library = $editor['library path'] . '/ckeditor.js';
if (!file_exists($library)) {
$library = fopen($library, 'r');
$max_lines = 8;
while ($max_lines && $line = fgets($library, 140)) {
// version:'CKEditor 3.0 SVN',revision:'3665'
// version:'3.0 RC',revision:'3753'
// version:'3.0.1',revision:'4391'
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@', $line, $version)) {
// Version numbers need to have three parts since 3.0.1.
$version[1] = preg_replace('/^(\d+)\.(\d+)$/', '${1}.${2}.0', $version[1]);
return $version[1] . '.' . $version[2];
version number is tested with 3 parts ! ...

Issue tags:-wysiwyg, -ckeditor

@klebar, The version number parts is not a problem, we expand one or two part numbers to three parts to be able to compare them with versions like 3.5.4.
Just use the -dev version until a new release is made, it's been proven to work and only has very minor differences to the official release.

Also, the wysiwyg and ckeditor keywords are already represented by the project and component fields.


Well I made the mistake of installing the (non dev) version of the module. When that didn't work I deleted it through FTP (didnt switch it off first in the modules menu). Then I installed the dev module and I think it inherited some settings or something so it didn't work. Then I reinstalled the old version. Switched it on, saved, switched it off again, saved again and then deleted it. Then I reinstalled the dev version and it worked.

I, too, ran into the white screen issue on the WYSIWYG configuration page after upgrading to the latest dev version. If you're having trouble using CKeditor 3.6 or running into the white screen on the WYSIWYG configuration stage, try these steps:

  1. Disable the WYSIWYG module on your site. I also disabled IMCE and IMCE WYSIWYG Bridge just to be sure.
  2. Uninstall the WYSIWYG module. You'll have to uninstall IMCE WYSIWYG if you've got it installed. Note that you'll lose your WYSIWYG configurations when you uninstall. This was on a dev site for me, so not a problem.
  3. Replace the wysiwyg directory in your sites/all/modules folder with the latest development snapshot. (Download it by clicking the appropriate link in the Development Releases table at the bottom of http://drupal.org/project/wysiwyg.)
  4. Re-enable the WYSIWYG module.

After doing those steps, everything works great with the dev release of WYSIWYG.

@Filimonov, scottrouse, The official releases and -dev versions are identical as far as settings and database schemas are concerned. Only minor fixes have been applied to the -devs since the last release so swapping back and forth are not a problem (at this point, but that might change later.)

Replacing an official release with a -dev release should never be a problem. If database changes are required, an upgrade path will be included in the same commit including the code change requiring it. Always run update.php after updating to -devs from official releases (or older -devs). If update.php indicates that there's a new schema version to installl, it will no longer be possible to downgrade to an official release without uninstalling first. If update.php says no updates are needed, it should be safe to switch back to an official release without uninstalling. Worst case scenario simply means the editor won't load and you'll have to delete and recreate the editor profiles.

Make sure NO requests are made to the site after you've removed the Wysiwyg folder and before uploading the new one! Failure to do so may cause WSODs or other strange problems (config paths not working etc). That should fix itself by clearing Drupal's cache alone after uploading the new Wysiwyg.

If you upgrade/install using drush, don't forget to run drush cc all afterwards, just in case.

i downloaded today the latest dev version of WYSIWYG and now ckeditor gets lost because it doesn't recognize ckeditor 3.6 any more.

@andros, it does recognize CKEditor 3.6, I've been using it all day.
Does the installation instructions sav "version not recognized" or "not installed".

The same here: it says "The version of CKEditor could not be detected." and "Not installed"
It worked flawlessly until the update to the latest dev version.

Ok, I found the culprit! Instead of upgrading to the latest dev version, Drupal downgraded it to 2.0 stable. Just manually upgraded the module to the actual latest dev version and voila, CKEditor is there again!

Wysiwyg 7.x-2.0 stable is not able to detect CKEditor 3.6. It does not read far enough into the main JavaScript file to find the version number, which has been fixed by simply increasing the read length in Wysiwyg 7.x-2.x-dev. This was changed in ckeditor.inc, which has had no changes since.

...manually upgraded the module to the actual latest dev...

What do you mean by this? In which way did you upgrade to the latest dev and it didn't work?

I'm saying it *DID* work!
I know 7.x-2.0 stable doesn't detect CKEditor 3.6, that's why I sticked with the 7.x-2.x-dev version a couple of weeks ago IIRC, but yesterday Drupal, as I said, instead of updating to the latest 7.x-2.x-dev, installed the 7.x-2.0 version (don't know why...) during the update process.
So I disabled the module, deleted the sites/all/modules/wysiwyg directory, copied the 7.x-2.x-dev one, and ran the update.php script. CKEditor now works perfectly.
I just wanted to point out that the update mechanism (admin/modules/update) had a fault somewhere and give a hint to those who supposedly had my same problem.

Ah, I see.
I don't have much experience with the Update Manager so I can't tell why it thought 2.0 was newer than 2.x-dev.
I don't see any updates for Wysiwyg with 2.x-dev installed now so I can't test it either.

windtrekker, thanks. I liked your solution and edited ckeditor.inc.

I changed line 68 to 200 from 140 characters - and I'm in like flint with CKEditor

--> while ($max_lines && $line = fgets($library, 200)) {

Ok, I found the culprit! Instead of upgrading to the latest dev version, Drupal downgraded it to 2.0 stable. Just manually upgraded the module to the actual latest dev version and voila, CKEditor is there again!

Same here, i was absolutely convinced that i loaded dev version, but now it is the 2.0 installed!

I don't have much experience with the Update Manager so I can't tell why it thought 2.0 was newer than 2.x-dev.

If it's anything like Update Status, it'll prioritise the last stable release over a -dev version. Which seems like a fairly sane thing to do. It's almost always the case that a -dev release will be newer than the last stable, as they'll contain code that is still in development and nobody's willing to swear is safe yet. Hence the general principle of not using a -dev release on a production site.

Dear module mantainers,
This kind of issue with a major WYSIWYG Editor might not seem like a *critical* bug, but it seems like the community disagrees. Downloading both WYSIWYG and CKEditor and finding out it doesn't work is frustrating. If this kind of issue ever comes up, please consider patching and uploading an updated module. It doesn't need to rush all of the other bugfixes or new features, it just needs to addres this kind of incompatibilty. The Drupal developers around the world will surely rejoice.


I use D6 and WYSIWYG 6.x-2.3, however I think this will work for D7 and WYSIWYG 7.x-2.0 as well.

Regexp used to find out the version of CKEditor look like this:
@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@

Look at the beginning of the group catching revision number:

there is ?: which would work in JavaScript Regex and means to skip this match [http://www.javascriptkit.com/javatutors/redev2.shtml]. This is correct as we want to have only the revision number in match number 2, instead of whole 'revision:XXXX' string.

However the modifier ?: does not work in POSIX Regex, which PHP uses. According my research there is no way to skip a match in POSIX Regex.

So my solution is to get rid of ?: and use $version[3] as revision number.

if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(.+revision:\'([\d]+))?@', $line, $version)) {
// Version numbers need to have three parts since 3.0.1.
$version[1] = preg_replace('/^(\d+)\.(\d+)$/', '${1}.${2}.0', $version[1]);
$version[1] . '.' . $version[3];

Having this code I get proper version of CKEditor:


I'm new to drupal and I'm running D7.2
I'm just starting in playing drupal, I installed WYSIWYG and CKEditor 3.6 and it doesn't work. I get back to CKEditor 3.5.3 and TADAH ... it works.
I know zero about php java and so on but I can edit text file: is there any way to use CKE 3.6 by editing some file? If yes, please tell me the file name and the folder where it shuold be. plz be patient as I know 0 or even less :)
Ciao & danke

To use my solution (I don't say it's the best):
1. open ~/sites/default/modules/wysiwyg/editors/ckeditor.inc
2. go to line 72
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@ ', $line, $version)) {
change this to
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(.+revision:\'([\d]+))?@', $line, $version)) {
3. go to line 76
return $version[1] . '.' . $version[2];
change this to
return $version[1] . '.' . $version[3];


Hi JD,
according to your suggestion I changed

function wysiwyg_ckeditor_version($editor) {
$library = $editor['library path'] . '/ckeditor.js';
  if (!
file_exists($library)) {
$library = fopen($library, 'r');
$max_lines = 8;
  while (
$max_lines && $line = fgets($library, 140)) {
// version:'CKEditor 3.0 SVN',revision:'3665'
    // version:'3.0 RC',revision:'3753'
    // version:'3.0.1',revision:'4391'
//CBif (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@', $line, $version)) {
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(.+revision:\'([\d]+))?@', $line, $version)) {
// Version numbers need to have three parts since 3.0.1.
$version[1] = preg_replace('/^(\d+)\.(\d+)$/', '${1}.${2}.0', $version[1]);
//CB  return $version[1] . '.' . $version[2];
return $version[1] . '.' . $version[3];

But I still got the same error than before:
The version of CKEditor could not be detected.

My ckeditor.inc file is located in this folder:

Could be that D7.2 VS D6.X has something else different related to this ?

Ok, no problem, I don't wanna bore U too much, ThX a lot 4 ur help and I hope it will be fixed by Lord DRUPAL in the future.


there is also one more issue with WYSIWYG and CKE :).

//while ($max_lines && $line = fgets($library, 140)) {
while ($max_lines && $line = fgets($library, 500)) {

There has been a patch solving this and I thought they already included this in the module. Obviously not for D7.


@jdudeziec, We're no using POSIX regular expression functions, we're using PCRE functions. Look at the fifth paragraph on PCRE subpatterns.

Instead of directly hacking the official releases, why don't you just install (or at least try) the -dev versions?
Or, look at the commits mentioned in #4 and apply them to the 6.x-2.3 or 7.x-2.0 release. It's just a single value that needs to be changed in ckeditor.inc to make it recognize the version again.

And yes, I'm going to talk to sun about making new minor releases sooner after changes in the editor libraries.

We're no using POSIX regular expression functions, we're using PCRE functions. Look at the fifth paragraph on PCRE subpatterns.
Good to know. Then, do you have any idea why preg_match is not catching the string?

Instead of directly hacking the official releases, why don't you just install (or at least try) the -dev versions?
Thanks for instruction ;). 'At least' I tried 6.x-2.x-dev, it had the same problem with preg_match:
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@', $line, $version)) {

Patch from #4 does not solve THIS problem, so tried to investigate it on my self. Sorry if you feel bad about this. I feel kind of a problem reading your message.

Let's don't waste time on writing, I found something, I published it to help other users and you don't have to use it ;). At least I tried. And by the way I think you are doing great job with this module.


@jdudziec, I'm sorry, I did not mean for you to take my second paragraph personally. I was just getting a bit annoyed by all the activity here discussing 6.x-2.3 and 7.x-2.0 instead of 6.x-2.x-dev and 7.x-2.x-dev where this has already been addressed.
I greatly appreciate your efforts and willingness to help others get around problems you've encountered. I have absolutely nothing against that and it's great to see people contribute in this way. Points to you for that! (And even more points for a patch file, ;) ) I just want to nudge you in the right direction and show that your regexp change isn't required once the read length change has been applied. The regexp is valid for PCRE and the -devs work. I'm not sure why you find that the regexp change is still needed with the -devs. I can't find any technical reason for it so I'd just like to ask you to confirm that with a fresh -dev. The only reason I see for preg_match() not matching would would be that the version string either doesn't look the same anymore or it's been split by the line reader.

Here's follows some fairly detailed background info on why simply increasing the read length value fixes this issue, for anyone interested.
The reason I'm writing this is not to prove I'm right and rub it into someone's face or anything like that. It's just my way of winding down and thinking about something else after a very long, hot, windy and intense couple of days learning [or trying to learn] the basics of herding sheep with my Australian shepherd hehe... ;)

The version detection in the official Wysiwyg releases reads up to eight "chunks" of the ckeditor.js file - a chunk is a string starting from the current position to the next newline or a maximum of 140 characters, whichever comes first. The "current/starting" position is moved to after the last character read into the previous chunk, after each chunk has been read.
In CKEditor 3.6 (perhaps earlier) the version string was moved slightly in the source so it no longer aligns well with these chunks. Each chunk is compared to the regexp discussed above: @version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@.
The read chunks from ckeditor.js (version 3.6) are:

  1. /* These first chunks are not interesting at all, so we keep going.
  2. Copyright (c) 2003-2011, CKSource - Frederico Knabben. All rights reserved.
  3. For licensing, see LICENSE.html or http://ckeditor.com/license
  4. */
  5. (empty line)
  6. (function(){if(window.CKEDITOR&&window.CKEDITOR.dom)return;if(!window.CKEDITOR)window.CKEDITOR=(function(){var a={timestamp:'B49E5BQ',versi This chunk is too short, it'll match the beginning of the regexp, but not the rest.
  7. on:'3.6',revision:'6902',_:{},status:'unloaded',basePath:(function(){var d=window.CKEDITOR_BASEPATH||'';if(!d){var e=document.getElementsBy This chunk starts too late, it matches the end of the regexp, but not the beginning.
  8. TagName('script');for(var f=0;f<e.length;f++){var g=e[f].src.match(/(^|.*[\\\/])ckeditor(?:_basic)?(?:_source)?.js(?:\?.*)?$/i);if(g){d=g[1 This chunk is also processed since none of the above resulted in a regexp match. After this, just quit to indicate 'no version detected'.

When changing the max chunk length to 500, chunk 1-5 are still the same because they have a newline within the limit.
Chunk 6 gets a lot longer and becomes:
(function(){if(window.CKEDITOR&&window.CKEDITOR.dom)return;if(!window.CKEDITOR)window.CKEDITOR=(function(){var a={timestamp:'B49E5BQ',version:'3.6',revision:'6902',_:{},status:'unloaded',basePath:(function(){var d=window.CKEDITOR_BASEPATH||'';if(!d){var e=document.getElementsByTagName('script');for(var f=0;f<e.length;f++){var g=e[f].src.match(/(^|.*[\\\/])ckeditor(?:_basic)?(?:_source)?.js(?:\?.*)?$/i);if(g){d=g[1];break;}}}if(d.indexOf(':/')==-1)if(d.indexOf('/')===0)d=location.href.match(/^.*
The regexp will then match the now complete version:'3.6',revision:'6902 string. The two subpatterns will match 3.6 and 6902 as intended.

Once you've applied the "chunk length fix" the problem of the 'version:' string getting split into two chunks is no more and the regexp can extract the correct values. After this fix, there would need to be MASSIVE changes to the CKEditor source before the version string could ever move out of those ~0.5kb. If there has been that much change, it's very likely we'll need to rewrite much of our CKEditor integration just to get it to work anyway.

Most, if not all, "version detectors" in Wysiwyg's editor integrations work this way, with variations to suite each editor. Sometimes it's hard to predict how much a version string can actually move around in a file, since it can depend a lot on the inner workings of automated tools used by the editor communities to create their releases. Hopefully, as we find and fix issues like this, the detectors get general enough to identify each release, without having to load the entire file into memory and scan it with several algorithms just to find out if we're using v1.0.5b or v1.5.0a.

I would have created a new 7.x-2.1 release today, but didn't find this change in CHANGELOG.txt, so I'm not sure which other changes I'm missing since 7.x-2.0. Will have a more in-depth look at this ASAP.

Here's my patch to fix this issue in WYSIWYG for Drupal-7 & CKEditor 3.6.

The problem is reading in 140 characters at a time, truncates the string we're trying to preg_match on in two. To resolve this, I've removed this character limit, so 1 entire line will be read at a time. I do not believe 500 character limit is a good solution either, as it has the same problem as 140 characters.

I changed my ckeditor.inc according to J0rd's fix and it works !!!
My first approach to drupal community is really fantastic. GREAT !!!

Thank you very much and thanks to jdudziec too

thank you for the patch, but creating your patches from your doc root makes it unusable for anyone else without editing the patch file. you should create them from the module directory. Just saying.

@emackn Thanks for the advice, but until I figure out how to properly make patches with GIT, you'll be getting these :)

Any ideas on the commands I need to run?

@sun, this was first noticed on 3.5.4 but most people have had trouble with 3.6 which was released at the same time for some reason.
CKEditor releases
#1143104: Newer ( 3.6.3 ) CKeditor version not detected by ckeditor.inc
26b48879a6d712068cd3f085dec8d8182304887f (master, 7.x-2.x)
40f635e0287e23e5c51f15f44db02d5d6171ceaa (6.x-2.x)
0153433d0c580b39302714d438b659735af50d7a (5.x-2.x).

@j0rd, if we don't specify a limit it'll read the whole file. The first number of rows are short, but the one we want has the whole script on it. We've already taked care of this in the commits above.

EDIT: j0rd's patch could probably be applied with patch -p7 < filename.patch or something like that - but again, the fix is already in the -dev snapshots so you don't need it if you're using one of them. To create proper git patches, see http://drupal.org/node/1015228.

@jOrd I would just create the patch from the module directory.

So i checked line 67 and i've already while ($max_lines && $line = fgets($library, 500))

It still cannot detect the version though...
What else should i do?

@WilliamB and anyone else having problems with Wysiwyg 7.x-2.1 or 6.x-2.4 (or the -devs).

  1. Make sure the library was extracted correctly. ("Extract here" in sites/all/libraries/ if on local computer should get things right.)
  2. Make sure you don't have two versions of the library in sites/all/libraries or sites/[default|sitename]/libraries. The first one encountered will be used.
  3. If uploading via FTP, delete sites/all/libraries/ckeditor, try changing the file transfer mode in your FTP client and upload again.
  4. Make sure you don't have two installs of wysiwyg in sites/all/modules, sites/[default|sitename]/modules. If you've backed up an older version of the module then make sure the backup is not in either of those folders, even if renamed.
  5. If the CKEditor version is still not detected, please file a new support request and we can dig deeper without everyone else here getting "pinged".

I'm retarded.
Somewhat i had the ckeditor drupal module in the libraries folder instead of the real ckeditor.

Status:Fixed» Closed (fixed)

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

I checked all of #54, but my 6.x-2.4 will not detect CKEditor 3.6.4. It does detect FCKeditor.

My 7.x-2.1 detects CKEditor 3.6.4 OK.

Sorry, I did not have 6.x-2.4 but some older version.

On updating to 6.x-2.4, It does detect CKEditor 3.6.4 OK. Thanks.

I still see that this is still a problem. I was able to install the latest dev of WYSIWYG w/ CKeditor to function properly.

There have been no changes to the CKEditor version detection code since the release of 7.x-2.1 so I'm not sure how that's possible. The only CKEditor variant known not to be supported is the "Drupal edition" of CKEditor (becuase it bundles the ckeditor module). We did add a note about that variant being unsupported after 7.x-2.1 was released, but that did not change any existing detection logic.

I find it ironic that "The only CKEditor variant known not to be supported is the "Drupal edition" of CKEditor." But, I can't get Drupal 7.19 to recognize the fact that I have uploaded the standard version to sites/all/libraries either.

Thanks for the response, TwoD!
I noticed the same issues being discussed in the Drupal LinkedIn group.

I downloaded and unzipped the full version. I found quite a few different mentions of the patch, but which witch is which? Also, I'm finding that mention of where the various patches correspond with files that don't exist in the full version. For example, response #2 says:
"The new version of ckeditor used " instead of ' in de js file.
line: 81
if (preg_match('@version:\'(?:CKEditor )?([\d\.]+)(?:.+revision:\'([\d]+))?@', $line, $version)) {
if (preg_match('@version:[\"|\'](?:CKEditor )?([\d\.]+)(?:.+revision:[\"|\']([\d]+))?@', $line, $version)) {
I'm guessing that these are fixes to the code in the ckeditor library, not some core hack.
However, editors/ckeditor.inc doesn't exist in the files I downloaded.
I tried uploading the files, just to see ... , but CKEditor is still listed as "not installed" in the WYSIWYG. I'm not sure what exactly Drupal looks for to decide if something if a library is installed, but it's not there. I have successfully installed two libraries previously.
Thanks again for your help.

The latest patch file in #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected. applies to the integration files in Wysiwyg module. We never patch 3rd party libraries such as CKEditor. No Drupal Core patches/hacks are needed because it does not care about or use the CKEditor library, only the Wysiwyg module does.

Wysiwyg module always looks for editor libraries in your sites/all/libraries/ or sites/default/libraries or sites/sitename/libraries folders, so that's where you extract the Full CKEditor library package you get from ckeditor.com. You then download and apply the latest patch file from #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected. to the Wysiwyg module (version 7.x-2.x-dev) folder in sites/default/modules/wysiwyg or sites/all/modules/wysiwyg, depending on where you installed it.

That makes it possible for Wysiwyg module to find and use the CKEditor 4 library without modifying any files in it.
There are still a few issues to be resolved (like the Teaser Break plugin not working correctly) so there will be new patch files in that issue in a while. Then remove the old Wysiwyg module folder, extract a fresh version 7.x-2.x-dev there again and download/apply the new patch. When the issues are finally resolved and the patch code committed to Wysiwyg module, the Wysiwyg 7.x-2.x-dev package will already include the code from the patch so you won't need to apply it again. The next official release after that (7.x-2.3) will also have the updated code and no patches will be necessary.

To everyone struggling with this issue using the 7.x-2.2 stable release of WYSIWYG module, here's a tip - this version works fine with CKEditor release upto 3.6.61 but starts failing from CKEditor 4.0 onwards.

Initially, I downloaded the latest 4.x version of CKEditor and had the same problem reported in this issue. Then, I downloaded 3.6.61 and WYSIWYG correctly detected the module without me having to touch a single line of code.

I installed wysiwyg .dev and with that version no problem with ckeditor 4.1. In fact I had a problem with ckeditor 3.6.61 with IMCE. With CKeditor 4.1 no problem with IMCE anymore. May be a new stable release is necessary to overcome this problem?

greetings, Martijn

I installed WYSIWYG and then CKEditor 4.1 into a Drupal 7.22.

CKEditor version 4 presents the error "version of CKEditor could not be detected" when installed in Drupal 7. This is due to a change of quote marks in CKEditor V4. It can be solved by editing the file: .../modules/wysiwyg/editors/ckeditor.inc about line 81:

> if (preg_match('@version:\'(?:CKEditor)?([\d\.]+)(?:.+revision:\'([\d]+))?@', $line, $version)) {
> to
> if (preg_match('@version:\"(?:CKEditor)?([\d\.]+)(?:.+revision:\"([\d]+))?@', $line, $version)) {

After I did this, I was getting the following error: "PDOException SQLSTATE 42S02". I also had to uninstall and reenable WYSIWYG to get it working.

@tstermitz, this issue is about CKEditor 3, not CKEditor 4 which changed a few things and needed different patches. CKEditor 4 compatibility was handled in another issue and has now working in the -dev snapshots.

@tstermitz - thanks for your suggestions as it helped me to work around the issue. I use drush and disabled and re-enabled the module and it seemed to work fine. I did receive a PHP warning about the return and just had it return the first part to avoid an undeclared offset 2 error. I'm not sure what issue the CKEditor 4 compatibility was handled in. It might be helpful to post the link to it here for folks who are looking for it. Peace - Anthony

Status:Closed (fixed)» Needs work

Same issue:
- Wysiwyg 7.x-2.2
- CKEditor version:'',revision:'7696'

Never use regex to find version.

same issue: "The version of CKEditor could not be detected."

wysiwyg 7.x-2.2
ckeditor 4.1.2
in the correct place

i replaced wysiwyg with the latest dev. version 7.x-2.x-dev - and it works now

I did have similar issues also with the latest tinymce library (4.0.1); but (unfortunately only) with an older version (3.5.8) the wysiwyg 7.x-2.x-dev also works.

Status:Needs work» Closed (fixed)

@freibadschwimmer, CKEditor 4 and 4.1 is only supported in the 7.x-2.x-dev version for now. Some issues still remain with it (content is being filtered before being loaded by CKEditor's new Advanced Content Filter, which may actually cause data loss if not correctly configured - see the CKEditor ACF issue in the queue.)

@codeyourdream, Wysiwyg does detect CKEditor rev 7696, I'm using it right now. Just make sure you don't use the Drupal-specific build of CKEditor as it bundles ckeditor.module and uses a different folder structure. Using regex works and is a lot easier to work with between versions where the location of the version string may shift around in the code. Any other method is equally bad at detecting versions when library owners keep changing the versioning scheme or move it between files. Implementing a system capable of reading any version scheme in any file would be overkill and a lot more difficult to debug.

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

Version:6.x-2.4» 7.x-2.x-dev
Issue summary:View changes

Please don't change the version for no reason.

This happened again when I installed the march 9 2014 update to 7.x-2.x-dev. How do I fix it?

I reinstalled the dev version and it is working again. Perhaps the Drupal module update process updated my dev version with the release version.

Why hasn't the release version been updated in so long to include these critical fixes?