This is fixed in 7.x-2.x-dev and 6.x-2.x-dev and will be part of the next release!


With the latest Ckeditor 4.0, released yesterday, WYSIWYG API reports:
"The version of CKEditor could not be detected."
at '/admin/config/content/wysiwyg'

Members fund testing for the Drupal project. Drupal Association Learn more


Joe Melody’s picture

I have the same problem man,I don't know what to do

bassie111’s picture

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)) {

dieppon’s picture

#2 Works, thanks!

Shall this be committed to the dev version?

rwohleb’s picture

Status: Active » Needs review
726 bytes

Here is a patch for it.

galch24’s picture

Patch works. Thanks a lot.

munyiva’s picture

#2 Worked for me thanks.

aiphes’s picture

same issue on d6 the patch work on D6 too ?
is this will be committed to dev version ?


achton’s picture

The patch in #4 actually applies to 6.x-2.4:

localhost:~/www/drupal/sites/all/modules/wysiwyg$ patch -p1 < wysiwyg-ckeditor4-1853550-4.patch
patching file editors/
Hunk #1 succeeded at 68 (offset -10 lines).

No problems with the new editor so far.

aiphes’s picture

good, how do you proceed to do that ? via ssh ?
where do i put the patch file ? in the same directory as module ?


DuaelFr’s picture

Status: Needs review » Reviewed & tested by the community

Patch is good

ShaunDychko’s picture

Works for me too.

rli’s picture

Working well for me.

TwoD’s picture

Sorry for not adressing this earlier, had to take a break for a while but I promise to take a look at this within 24 hours.

I don't know yet if version detection is the only thing which needs to be modified, there may also be new/removed/renamed plugins or buttons which could require tweaks to the integration files before they are available for use through Wysiwyg.

TwoD’s picture

Oh, just in case someone wonders if fixing support for CKEditor 4.0 automatically means we'll also get "inline editing" as demonstrated on the CKEditor demo page (in Drupal terms - editing nodes/fields directly from the View tab), the answer is no.

The amount of work and changes required to do that is way out of scope for this module, and it's not so easy to do in D6/7 because there's no direct support for it in Core. If another module is able to do some AJAX magic to present the normal textfield and format selector for editing nodes or fields inline, Wysiwyg 7.x-2.2 should already be able to attach a regular editor instance to those textareas.

TwoD’s picture

I've confirmed the #4 patch will make almost everything in CKEditor 4 work as expected. The API is mostly the same but the editor build/packaging process has changed a bit and there's also a new tool on the CKEditor download page to compose your own package with just the plugins you need. This makes the detection of available buttons/plugins more difficult for our integration code.

This means that if you only apply the #4 patch you may not get an accurate list of the available buttons and plugins on the profile configuration page. I will need some more time to figure out a reliable way to auto-detect that without parsing through files on each page request.

ñull’s picture

Not yet in the dev version? Will it be backported to 6.x?

TwoD’s picture

No, it's not yet in -dev, and yes, I'll backport it unless figuring out which plugins are available means having to add a major new feature which depends on something only in D7 - which is unlikely.

pjcdawkins’s picture

After applying #4 and installing CKEditor 4.0 I get the JS error:

Uncaught TypeError: Object [object Object] has no method 'addCss'

pjcdawkins’s picture

Status: Reviewed & tested by the community » Needs work
p0wer’s picture

According to API Changes in CKEditor 4:

The "additional CSS" feature provided by CKEDITOR.editor#addCss is now moved to a global CKEDITOR.addCss, with specified style rules applies document wide.

Thus the proper way for a plugin to style it's editable content is to call CKEDITOR.addCss inside of the plugin's onLoad function, rather than it's init function in v3.

pjcdawkins’s picture

OK so we need some kind of patch to accommodate #20 only if we've detected version >=4.

trotskyicepick’s picture

Inline editing is highly likely to be available as of Drupal 8 core. It may well take the form of CKEditor or Aloha editor dependant on which the devs prefer.

trotskyicepick’s picture

#2 not working for me, WYSIWYG v7.x-2.2 CKEditor 4.

My file structure is as follows:

sites - all - libraries - ckeditor - ckeditor.js
which is what the WYSIWYG module seems to expect.

Not done anything fancy, just built a custom CKEditor with additional plugins, downloaded and installed.


pjcdawkins’s picture

Assigned: Unassigned » pjcdawkins

I'm working on a patch, as per #20 and #21.

chrisrd’s picture

715 bytes

With ckeditor 4.0, the revision string has also changed from all numerics to hex digits. See attached for trivially revised patch to pick up the whole revision string. @pjcdawkins, you might like to incorporate this in your larger functional patch.

trotskyicepick’s picture

Downloaded just the standard "FULL" package for CKEditor 4.0, dev version of WYSIWYG module, applied above patches and it detects the library fine now.

Do not download a custom build CKEditor package as the package builder does not create a full and minified ckeditor.js.

TwoD’s picture

The CKEditor package builder does create a minified ckeditor.js file, unless you choose to build a "Source (Big N’Slow)" package.
I'm working on extending Wysiwyg so it can scan for available packages/languages/etc. Been trying to avoid that for a while since it can be a pain to just keep it recognizing the version strings, but I see no other way to support custom packages.
Note that this will most likely only detect whether a known plugin is installed or not (and cache it so it won't happen on every page load). Detecting unknown plugins and figuring out which buttons or settings are available would be nice, but it's not something I'm aiming for now.

trotskyicepick’s picture

I did choose the Big N'Slow option, so was obviously expecting an unminified package, but not one that was only 42 lines long. This happened twice in a row. I'm happy with the standard "FULL" package which now works.

PS. Think the new Moona skin looks fab ;D

tallship’s picture

I applied the patch in #4 above as per #8 above and all seems well.

I attempted to apply the patch in #25 but got an error.

I had installed wysiwyg, and ckeditor4.x, I did the "FULL" package, I did NOT choose the "Source (Big N’Slow)" version, just the regular one, but I did choose a couple of additional plugins beyond just the standard "FULL" package - such as inline and maybe one or two others.

I got the error that ckeditor version couldn't be determined and showing that it was not installed at admin/settings/wysiwyg. Once I applied the patch in #4 everything worked as it should.

I have a couple of concerns / questions...

1.) When I do a 'drush up', and there's a new version of wysiwyg, will I have issues requiring me to re-apply the patch, etc.?

2.) I could have done a 'drush dl ckeditor', followed by a 'drush en ckeditor', instead of installing wysiwyg. How would that have been different than the method I chose and wouldn't that have worked as well? Would there have been differences in the editor operationally?

Thanks :)


TwoD’s picture

Yes, you will need to re-apply the patch if we haven't committed it already. I can however promise we won't make a new official release before it has been committed though.

The CKEditor module works a lot like Wysiwyg module nowdays but it, of course, focuses only on integrating that editor library. You can not use both Wysiwyg module and CKEditor module together since that may cause the CKEditor library to be loaded twice, and you may end up with two instances of the editor for each field, causing all kinds of weirdness. They have come further than we have when it comes to allowing editor settings to be tweaked via the Drupal GUI, where we currently provide a code hook for that.

truyenle’s picture

#4 work for me

magpie5212’s picture

Will this be fixed on version 6 too?

nitrosx’s picture

#25 and wysiwyg 7.x-2.x-dev works for me... so far

gopherspidey’s picture

I would also like to added that there is work on ckeditor 4 being done in

jm.federico’s picture

Status: Needs work » Needs review
3.9 KB

This is a patch that includes the regex from #1853550-25: Ckeditor 4.0 - The version of CKEditor could not be detected. and also groups buttons.
When all buttons are enabled, some of them get hidden as they all get printed in 1 row.

Grouping was made according to the default of ckeditor in V3.

As per the issue in #1853550-18: Ckeditor 4.0 - The version of CKEditor could not be detected. for the addCss method, I haven't been able to reproduce.
How did you manage to trigger it?


Graham_W’s picture

Installed the patch at #35 to WYSIWYG 7.x-2.2.

All works except that only one line of buttons appears in the toolbar.

When I installed the patch, using Netbeans (I'm not a coder - this looked the easiest way of applying a patch under Windows and WAMP), I got an error that the patch was not completely applied. However, comparing the patch with the amended code, nothing obvious was missed).

jonhattan’s picture

Status: Needs review » Needs work

re #15 @TwoD: the zip for any build (custom or not) contains a file build-config.js with a relation of plugins (and languages). I've managed to parse it with this snippet:

$match = array();
$js = file_get_contents('ckeditor/build-config.js');
preg_match('#plugins : (\{.*?\})#s', $js, $match);
// Valid json requires keys are enclosed in double quotes.
$json = strtr($match[1], "'", '"');
$plugins = json_decode($json);
jonhattan’s picture

Version: 7.x-2.2 » 7.x-2.x-dev
Assigned: pjcdawkins » Unassigned
Status: Needs work » Needs review

didn't intend to change status

ericrdb’s picture

I applied patch in #35 to my D6 site.

wysiwyg version: 6.x-2.4
ckeditor (full version):

I get multiple rows of buttons as expected. The site recognizes the version and I'm able to configure editor's buttons, etc.


jm.federico’s picture

#25 is for a 7.x-2.x not for D6.

@Graham_W can you post the exact error that you got when patching?


keesje’s picture

patch #35 works fine for me, thanks
@Graham_W: patch is valid for 2.x-dev, try that instead of 2.2

jm.federico’s picture

Hi Guys

New version of the patch that will use group labels to improve accesibility.
No new functionality, just better way of soing things than the one in #1853550-35: Ckeditor 4.0 - The version of CKEditor could not be detected.


Graham_W’s picture

I hadn't kept a note of the error message, so started from scratch. Clean copy of Wysiwyg. Opened both the .inc and .js files in Netbeans, applied the patch with no error message.

It still looked like one line on menu. Tried another theme and got two lines but some selected buttons were missing.

After a bit of hunting around I found that the default download of ckeditor4 from the ckeditor front page does not include all the plugins that were present in the default Drupal download of the previous release. Going back and creating a custom download with all the plugins that I use resulted in these buttons reappearing on two lines. So I seem to have a working installation.

It looks like Wysiwyg doesn't check what ckeditor plugins are installed (some additional potentially useful plugins don't appear on the list) nor does it check if the plugin exists if it has been selected in the editor profile configuration page. Is this a separate issue?

jm.federico’s picture


The no plugin check might be a separate issue, as it affects any version of ckeditor (and pretty much any version of any editor, available buttons are hardcoded).

also, please remember that patches are against 7.x-2.x-dev version.


tweaker’s picture

CKeditor build 3.6.6.xxxx works with regular (non-dev)

klaasvw’s picture

Tested the patch and it seems to work fine here.

One thing that was missing is the new templates button that was introduced in CKEditor 4. The attached patch adds support to #42 for the templates button.

pvhee’s picture

#46 works great for the combi Wysiwyg + CKeditor 4

cedewey’s picture

The patch resolves the issue of WYSIWYG detecting CKeditor 4, but there are still several editor buttons that do not display (such as align left, align right, align center, iframe).

TwoD’s picture

Marked #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected. a duplicate of this issue.

Sorry for the lack of updates. Among other things, I got caught up in a couple of Core issues related to bringing WYSIWYG editing into D8, and we're very keen on getting it right and making sure it's compatible with Wysiwyg. It also involves inline-editing-capable editors like CKEditor 4 so it does overlap with this issue with what's needed to make Wysiwyg recognize and configure CKEditor 4 properly.

Patrick Nelson’s picture

Agree with cedewey in #48 - justify buttons still do not appear, even after installing the patch(s). Last patch installed was from #46.

pauloamgomes’s picture

#46 patch working on D6, no issues detected.

yanniboi’s picture

We are also having problems with the alignment buttons

GiorgosK’s picture

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

#42 works for the latest drupal 7.18
but noticed it does not respect the "number of columns" in the field settings
and the editor always comes up with default height
(I think other editors respect the rows and translate it to height is it done from wysiwyg ?)

NOTE: I had to apply #8 d7 patch from #1278886: Default text formats are not saved properly without accompanying values in order to get the text format to be saved

EDIT: following is WRONG js overrides this .css setting
I had to put following css rules in my .css to make height smaller

.cke_contents {
	height: 150px;

but otherwise the textarea tag does get the number of columns specified in the field settings

xdade’s picture

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

Patch #46 works fine for me.

But latest version, Ckeditor 4.0.1, introduced a new issue. On every page appears this message:

Notice: Undefined offset: 2 in wysiwyg_ckeditor_version() (line 85 of /my/path/sites/all/modules/wysiwyg/editors/

magicmyth’s picture

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

@xdate It seems the revision label changed its format as well (they used to be just numbers). You can fix this by changing what was mention in comment #2 by bassie111 to:
if (preg_match('@version:[\"|\'](?:CKEditor )?([\d\.]+)(?:.+revision:[\"|\']([\da-z]+))?@', $line, $version)) {
Now the code should correctly capture the revision value.

Note I've not tested that fix much so use at your own risk as I'm not sure if the expression is a little too broad.

cedewey’s picture

Status: Needs review » Needs work

Setting this issue to needs work because of the confirmation that there are still issues with some of the toolbar components.

achton’s picture

@TwoD: #1853550: Ckeditor 4.0 - The version of CKEditor could not be detected. is this issue, so it can't be the dupe you are looking for. Which issue did you intend to mark as a duplicate?

TwoD’s picture

@achton, haha, nice catch! Copy/paste error... I meant #1883456: New CKEditor 4.0.1 release.

Kazanir’s picture


The patch in 46 worked out of the box for me. What error does the change you mentioned cause? I installed the full 4.0.1 CKEditor and haven't seen bugs yet although I haven't gone after every button to be 100% sure.

crystal_alexandre_froger’s picture

The patch work fine as well here, I mean CKEditor pops up, but a lot of options are still missing in the toolbar, some of them being pretty critical, such as the alignement options:
Insert templates
Div container
Font size
Select all
Show blocks
Align right
Align left
Align center

magicmyth’s picture

@crystal_alexand are you sure you downloaded the "full" version of CKEditor? The default download option is now standard and those plugins you mentioned appear to only be in the full version. I thought div was failing to show as well at first but looking in the CKEditor plugin folder it was not present. I then realised you have download options on CKEditor's website and after grabbing full and doing a hard refresh on the editor page (icons were missing) all plugins worked as expected. I have tested div, Smiley and flash and each worked as intended.

danillonunes’s picture

I made this makefile which contains the patch and the full CKEditor package to download

markabur’s picture

I've applied #46 to both D6 and D7 and it works for me with CKEditor 4.01. I use a pretty minimal toolbar, though. I'm not seeing the error mentioned in #54.

arrrgh’s picture

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

Patch at #46 applied on 7.x-2.x-dev and CKEditor 4.01. Not seen any errors yet.

caillou’s picture

Patch at #46 applied on 7.x-2.2 and CKEditor 4.0.1.
Works for me, thanks.

drupalycious’s picture

I downloaded the ckeditor plugin 4.0.1 from Jan 8 2013, from

and I applied the patch #46 like this:
curl | git apply

at this point everything seemed to have worked well as the version of the editor was detected.

I went to the wysiwyg profiles page (/admin/config/content/wysiwyg) and verified that all the buttons and plugins were checked for the "full_html" format.
Then I tested the editor by trying to write an article.

The buttons that are present work as expected but several buttons are missing as pointed out in #60.

Look at the images I enclose

idflood’s picture

I tried the same as sp-drupy in #66 and first had the exact same result.

Then I found this:
Selecting "Standard package" left the "Color button" in the list of available plugins. So I went back and this time downloaded the "Full package" instead of the Standard.

I then had to clear the browser cache to have the missing buttons images show up but now a lot of the missing buttons are showing up. In fact I think all buttons are displayed : )

edit: I tested with the media module, and even the "Media browser" button is working

idflood’s picture

Status: Needs work » Needs review

Looks like the issues about the missing buttons after #46 are fixed by downloading the "Full package" so marking the issue as needs review again.

yanniboi’s picture

Using the 'full' package alongside patch #46 works fine for me.

wwalc’s picture

I can confirm that missing buttons might be caused by using "invalid" packages. The default "Standard" version of CKEditor has much less plugins than version 3.x. Even the full package does not have all plugins that were available in the default package in CKEditor 3.6.x.

If you notice that certains buttons are missing, you have two options:
- try the full package
- build your own CKEditor using the online builder (start with the full preset and any extra plugins you like)

DYdave’s picture

Hi guys,

Thanks very much for following up with this patch and clarifying the testing procedure.
I have tested as well exactly as explained in #69 and #70, with the very helpful link to the online builder, kindly suggested by wwalc and everything works fine/as expected (not buttons missing).

It seems we were quite a few people to mistakenly download the standard package, without further reading or checking anything on the site or in the downloaded folders, just to be able to download it as quick as possible.

I was wondering if it would be worth mentioning this somewhere in the module, perhaps on the Wysiwyg profiles settings page (admin/config/content/wysiwyg page), in the Installation Instructions for CKEditor. Maybe a small comment could mention that as well in wysiwyg_ckeditor_install_note, something like:

All plugins and buttons are only available if you download the full version of CKEditor.

Other than that, everything seems to work fine with this patch.

Thanks again very much to all for your great work, comments, and follow ups.

watchdog’s picture

I installed current dev version, applied the patch from #46 and downloaded the full ckeditor. Everything seems to work so far, I got all the buttons.

But the buttons are all displayed in one huge row, so that the Editor is very wide and the page needs to be scrolled on smaller monitors. Any suggestions?

yanniboi’s picture

I have taken the patch from #46 and added a note to the ckeditor install note to make sure people use the full package.

@watchdog you just need to limit the width of your editor in the admin theme. Turning off the overlay would also do the trick...

HydroZ’s picture

The submitted patch worked for me as well with ckeditor 4.
Thanks a lot!

watchdog’s picture

Thanks for your help! I have overlays disabled, so this does not work. I use Rubik as my admin theme. Is there a way to make this work without having to alter the admin theme? Also, in Rubik the with is normally automatically scaled to the window width. I tried to set the ckeditor-div to 100%, but that does not work, only if is set it to a fixed pixel size.

Does anyone else have the same problem?

BrightBold’s picture

I wholeheartedly agree with @DYdave that this should be prominently mentioned on the module page, but I'd change the wording to say:

All plugins and buttons are only available if you download the CKEditor full (not standard) package.

The words "standard" and "package" appear on the CKEditor download page, but the word "full" isn't visible until you've clicked on standard, so if we only use the words "full version" it may be harder for people to find what they need to change. (Frankly, I hadn't even noticed there were package options until I read this thread!)

yanniboi’s picture

@watchdog, i think the buttons are all just floated left. They will fill as big a width as they can but if you limit the width available then they will move onto the next line.

With respect to what @DYdave said and my patch in #73 I have put a message on the editors page in the WYSIWYG configuration. This just made sense because after installing WYSIWYG module, this is the page with instructions on how to download specific editors (eg. Ckeditor). Feel free to suggest alternative wording to make it more clear.

silkogelman’s picture

Patch from #73 seems to work perfectly: version is detected and ckeditor buttons appear like they should.


batigolix’s picture

Just to mention that there is a lengthy forum topic about this issue.

gregmarsh’s picture

I loaded the patch with no errors but now I have a blank edit error when choosing rich text edit. I can switch to code view and all is there but when I switch to rich text edit I can not edit anything - the summary shows html though which seem strange.

All my settings seem intact and I have made changes/ and saved the profiles again. This did not help so I created new ones / same problem.

I deleted all the code and loaded the code again / same issue.

I will back all the changes out and try again but there were similar problems noted in very old posts and I was wondering if others had the same problem now.

It looks the WYSIWYG code is what is broken - for when I turned off ckedit I had the same problem.

*** the following patch with comments failed for me
So I used the previous one
The patch worked but I got the error above.

The other symptom I just found is if you go to configuration / ckedit and choose a profile / then look at the editor appearance - it too is gone - there is the space though (big blank area).

I am going to try to load another editor to try and isolate this to the patch.

**** loaded tinymce and it failed as well until I removed the patch.

So hope there is an update to the patch / I am used the latest from each site as of Jan 27/2013

RobW’s picture

I had the same problem as greg, but then remembered that I have a custom module setting certain ckeditor settings in code. In my case I was setting a cked theme that didn't exist, and using the autogrow plugin, both of which caused a blank white space on their own. After I removed them everything is working perfectly.

+1 for RTBC.

drupalycious’s picture


just to mention that you were right I didn't download the full package of ckeditor, as I didn't notice that there were several options for download.

After getting the full version, all buttons and options are present.


danbohea’s picture

I used the make file (module + patch + lib) posted by danillonunes in #62 and have had no problems. +1 RBTC

RobW’s picture

Status: Needs review » Reviewed & tested by the community
gmclelland’s picture

The patch in #46 works for me with the Media-2.x-dev module and shortcodes module.

Steph64’s picture


timbrandin’s picture

I can successfully say that #73 (which is an improvement on #46) also works with Nodestream with the latest patch: #1904548-5: Change wysiwyg to use ckeditor 4.x.

keithtoo’s picture

I just installed the 4.0.1 release from the website. I got the same error as the OP, which I fixed with #2. That fixed the detection problem, but also issued a php indexing error notice. The preg_match() at line 82 of returns a 2 element array, if I read the documentation right. Function wysiwyg_ckeditor_version() returns $value[1] and $value[2] (line 86), where $value[2] is the invalid index. Changing the index values to 0 & 1, respectively, returns with an unknown revision error given as: "

I've gotten Drupal to accept the value returned by only returning $value[1] (the 2nd element). $value[0] contains a leading quote (which is also an invalid revision format) along with essentially the same value as $value[1].

It now works, but I'm sure this wasn't the intention when the version strings were parsed.

drupauler’s picture

Hi, slightly off topic, sorry

How do I apply the patch referenced in #73 using git?

I invoke git via drush, all running under windows, amd looking to install CKEditor V4.0.1


TwoD’s picture

@paulsx, You don't need to use git to apply the patch, any patching tool you're comfortable with works. See Apply patches on Windows. Just beware that you may need to pass an argument to the patch tool to strip the first segment of the paths in the patch file, as git begins file paths with a and b. The normal patch command under *nix systems need the -p1 switch for that.

1q84’s picture

EugenMayer’s picture

/me hints
CKeditor 4.0 will not work with this patch by far

alexweber’s picture

@Eugen, I can confirm that it does indeed work and I've been using this patch for a while now, even the Media button integration works perfectly!

S@ilor’s picture

Has anyone noticed this error?:

Notice: Undefined offset: 2 in wysiwyg_ckeditor_version() (line 75 of /--/htdocs/sites/all/modules/wysiwyg/editors/

I have applied the above patch, and it works, but I get this error every time I save after editing. A refresh of the page removes this message, but I'm still wondering.

alexweber’s picture


I don't know what to say man, it just works for me. I'm using version 2.2 with this patch and it's flawless so far:

projects[wysiwyg][version] = 2.2
projects[wysiwyg][type] = module
projects[wysiwyg][subdir] = contrib
projects[wysiwyg][patch][] =

The weird part is, I don't even have anything on line 75 that would suggest a reason for this error you mention:

 function wysiwyg_ckeditor_version($editor) {         // line 72
  $library = $editor['library path'] . '/ckeditor.js';
  if (!file_exists($library)) {
    return;                                                                // line 75
  $library = fopen($library, 'r');
  $max_lines = 8;
S@ilor’s picture


Thanks for replying. I have version "7.x-2.2+7-dev" myself.

Could I ask you to copy/paste the entire section?

Mine looks like this (beginning at line 60, ending at line 80)

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, 500)) {
    // 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];

This part

      return $version[1] . '.' . $version[2];

is at line 75 ...

alexweber’s picture

@S@ilor, mine is pretty much identical except for the line numbers:

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, 500)) {
    // version:'CKEditor 3.0 SVN',revision:'3665'
    // version:'3.0 RC',revision:'3753'
    // version:'3.0.1',revision:'4391'
    // version:"4.0",revision:"769d96134b"
    if (preg_match('@version:[\'"](?:CKEditor )?([\d\.]+)(?:.+revision:[\'"]([[:xdigit:]]+))?@', $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];

From your code snippet, it doesn't look like you have the patch applied (notice the 4.0 comment).

I've been using this a lot with no issues or notices whatsoever (running strict mode too).

Try a fresh git clone and apply the patch using git apply...

Mohammed J. Razem’s picture

I confirm the patch in #73 worked fine. I'm using the latest WYSIWYG 7.x-2.2+8-dev and CKEditor 4.0.1.d02739be4b

rwilson0429’s picture

Yes, patch in #73 combined with downloading the Full preset from seems to work well. Thank you very much.

S@ilor’s picture

Thanks, Alex.

All good now

raavi’s picture

Hi all,
I saw some similar issue i do not open new defect. Im using wysiwyg 7.x-2.2 + CKEditor 4.0.1
I got this error messages :
Notice: Undefined offset: 2 in wysiwyg_ckeditor_version() (line 87 of /home/rckamion/public_html/sites/all/modules/wysiwyg/editors/

   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];                                                                    <----- LN 87

When i open wysiwyg to check the version of the CKEditor i see this : "4.0.1." (there is a dot at the end)
I changed :
- return $version[1]. '.' . $version[2];
+ return $version[1];

dddave’s picture

Patch works for me without issues (apart from minor offsets in all hunks).

Anonymous’s picture

Any idea when this is going to get rolled into dev? I just installed 7.x-2.2+8-dev, and it still doesn't work - I still get the "The version of CKEditor could not be detected" error.

kingswoodute’s picture


jsimonis’s picture

Well, I grabbed the latest dev, did the patch (no errors), and grabbed the latest full version of ckeditor. Before I did that, I had the "standard" files. It worked under standard, there were just a bunch of buttons missing. Under full I get nothing - no editor box at all. There's just a big blank space.

Tried a different admin theme just in case this one had been edited or for some reason wasn't working right (it's the one that comes with Drupal). I switched to Shiny. Cleared all caches. Still no editor.

Tried switching back to standard. It works. Tried adding in the plugins that were missing. The buttons don't show. I even added them in my config file for CkEditor. Nothing.

RobW’s picture

When I updated I had some config for my old ckeditor that was incompatible with 4.0 and caused a white space (autogrow, I believe). After removing it the editor worked correctly.

EugenMayer’s picture

@alexWeber: well, then wait for a while :) Making the warpper compatible does not mean just making the version parse.

@ TwoD:
- they changed the selection API, the current implementation is basicaly useless for nearly all browsers ( except IE ) (for both, isNode and data.node)
- dont use the native selection object for the "content", use the wrapper method .. the current one fails on .. i think WebKit or Mozilla, cant remember

EugenMayer’s picture

Status: Reviewed & tested by the community » Needs review

changing status..just to ensure thats not going to be stable and hit the devs right after the release...with a gazzilion issue-request

attiks’s picture

Is there a change the fix for the version can be committed and that other problems are solved in a new issue?

#73 works

DYdave’s picture

Thanks attiks for your suggestion.
Given the number of tests and comments in this post I would surely agree with this.

It would also prevent from mixing multiple different issues with this one.
That's why I would also be in favor of getting suggested/tested patch rolled in first and creating other issues for additional problems reported.

Feel free to let us know what you would think about that.

danbohea’s picture

+1 for getting this patch committed and then creating subsequent, separate issues. Isn't that how an issue queue is supposed to work anyway?

TwoD’s picture

Status: Needs review » Needs work

Let's summarize here:

CKEditor 4 API changes according to!/guide/dev_api_changes, where I've removed those not relevant to Wysiwyg:

  1. CKEDITOR.config.corePlugins is not needed any more. Not relevant to us directly, but all plugins in the package will now be enabled by default. We need to be able to use CKEditor's removePlugins setting to list plugins which we don't want enabled on some formats. Let's put that in a follow-up issue since it's not critical to getting CKEditor 4 working.
  2. plugins/selection/plugin.js => core/selection.js, the "select all" feature originally provided by the selection plugin is now a standalone selectall plugin. Maybe what causes the problem @EugenMayer mentions in #107.
  3. Changes to skin handling do not affect us directly, but there's a new default skin called moono.
  4. Skin/theme handling in general needs an overhaul because CKEditor 4 can only use one skin per document while Wysiwyg expects one theme/skin per instance, and there are no "themes" at all anymore. No direct action needed right now since the only way to change the skin is via hook_wysiwyg_editor_settings_alter()
  5. CKEditor 4 no longer requires an iFrame to edit content and can use a div instead, aka "inline editing". Wysiwyg module will (and can) only support the usual way of editing content right now. That is, we still need the textarea containing the 'raw' input on an editing form rather than figuring out which parts of a viewed node are editable and managing all that on our own. Drupal 8 has much better support for inline editing in general, but it's not possible in Drupal 6 or 7. Therefore, we will still use the iFrame based editing area plugin provided by CKEditor. There's a slight problem though. The id of the div container surrounding the iFrame has changed, so the selector we used to inject stylesheets from cross-editor plugins no longer works. This breaks the styling for the Teaser Break plugin, among others. The plugin itself works, but you won't be able to see the placeholder it uses in WYSIWYG mode.

The remaining parts not targeted for other issues are pretty easy to fix so I'll put up another patch either when I get home from work this evening or early tomorrow.

kepenek’s picture

I spent partly 3 days to solve this problem , I have installed demo site from scratch , at last found a solution below;
1. WYSIWYG module not necessary ,i installed ckeditor for drupal module and enable it
2. I downloaded ckeditor full (it could be standard or custom , i think)and extract its content into /sites/all/modules/ckeditor/ckeditor folder.
3. I configured the ckeditor from modules/configure button.

My problem was misconfiguration of ckeditor because of WYSIWYG module.

Thats all.

travelertt’s picture

@kepenek CKEditor - WYSIWYG HTML editor and the WYSIWYG module are not related. This is stated on the Ckeditor project page. You also put the ckeditor package in a directory that the WYSIWYG module doesn't look for. Look at the Instructions in the WYSIWYG module for where to put the ckeditor files if you want to you the WYSIWYG module.

Nora McDougall’s picture

Per the comments on, I was looking for editors/ckeditor ... to be at the root level. Now I see that the starting point is sites/all/modules/wysiwyg.

It's like not starting a question with what version of Drupal or what install you used. Too many assumptions of what your audience knows. But the patch works! And the client now has the HTML block format option, which does not come with TinyMCE.

TwoD’s picture

@Nora McDougall, all patches in contributed modules, themes, install profiles, etc are assumed to be created from the root of that project rather than the Drupal root since there are many locations in which they can be installed. This should be reflected in the steps described to create/apply patches in the documentation. If you think that wasn't clear enough, those pages are editable by any registered user so feel free to edit them for clarification.

jojojibba’s picture

Patched made things work! Nice.
However, the buttons only show on one line...
Did I miss something?
I opened the code and removed where the patch showed a "-" and added lines where it showed a "+"
I will admit, I am no programmer.
Did one of the other lines which didn't have a "+" or "-" in the patch need to be applied as well?

sonicthoughts’s picture

I tried the patch, but ckeditor using builder does not add plugins. ckeditor is recognized, but plugins do not work. At this point, if I understand correctly, I must uninstall wysiwyg and install the drupal ckeditor module until this is supported?

sonicthoughts’s picture

yes, I agree, all the ckeditor modules / wrapper / etc are very confusing. Takes a while to get this right!

TwoD’s picture

@jojojibba, no you did not miss anything. Wysiwyg is currently only capable of putting buttons on the first toolbar row. Please see #277954: Allow to sort editor buttons and the sort_buttons branch in git for work on a better toolbar designer.

@sonicthoughts, to make any plugins/buttons work correctly, the Wysiwyg module must know about it. With this patch, it knows about all the plugins in the Full package. If you add additional plugins to that, you will need to create a module and implement hook_wysiwyg_plugins() to tell Wysiwyg about the plugins you added and which buttons each one has. Note that in this case, the CKEditor builder will auto-enable all plugins and merge them into the ckeditor.js file. Therefore, the metadata key 'internal' must be set to TRUE and the 'load' key to FALSE (since CKEditor already loads the plugin on its own). See wysiwyg.api.php for details on the hook.

Ideally, Wysiwyg should be able to parse out all the plugin metadata from the plugins themselves, but that would pretty much mean parsing/running JavaScript on the server just to extract a few bits of information which takes a couple of minutes to do by hand, once you get the hang of it, and is only needed once for each plugin.

sonicthoughts’s picture

Yikes, not to promising. Will be interesting now that Ckeditor is in D8 core ...

jojojibba’s picture

10-4 Thanks @TwoD!

evrix’s picture

Tip in comment #2 worked for me, too.

kaidjohnson’s picture

Patch in #73 works well for us.
- Drupal 7.20
- Wysiwyg 2.2
- CKEditor 4.0.1

+1 for RTBC.

kaidjohnson’s picture

Status: Needs work » Needs review
kaidjohnson’s picture

Same patch as #73 - submitting for testing.

EDIT: Blarg! Anyone know why the issue queue won't pick up this patch?

hass’s picture

No valid tests...

alexweber’s picture

Status: Needs review » Reviewed & tested by the community

Can we please get this committed and file new issues as follow-ups?

The patch might not be 100% perfect but it does work, including Media integration so we really should put this out there... thanks

soundboy89’s picture

Hi, I read this whole thread and I see there is a solution for D7, but is there currently a way to get ckeditor 4.0 working properly with wysiwyg in D6? Does the current dev version support it?

soundboy89’s picture

Also, I have another (related) question which I couldn't find an answer for.. what's the latest fully supported version of CKeditor for 6.x-2.4?

TwoD’s picture

All variants of Wysiwyg support support CKEditor 3.x.x. This patch should work with Wysiwyg 7.x-2.x, 6.x-2.x and maybe even 5.x with little or no modification. New features and fixes go into 7.x first and then get backported as far as needed/possible.

No, I won't commit this yet. CKEditor 4 changed, amongst other things, the id of the div surrounding the editing area iframe so Wysiwyg is no longer injecting stylesheets from cross-editor plugins. This will break placeholders for several modules. That is a pretty easy fix, which I'll roll in later today, but we also need to look deeper into the selection issue mentioned earlier in here to see if it's specific to CKEditor 4.

Also, are we sure all plugins are working as they should? Does disabling plugins work as it should too? I doubt that since CKEditor 4 now enables all bundled plugins by default. That means we can't simply leave them out of the extraPlugins list to have them disabled, we must explicitly add them to the removePlugins list instead.

alexweber’s picture

@TwoD the plugin part seems to work as expected. We need to go with the full CKeditor 4.x download and all plugins like Media, Teaser an also the default CKEditor ones work as expected and can be toggled on/off with the WYSIWYG interface.

sonicthoughts’s picture

Wow - lot's of confusion with ckeditor 4, WYSIWYG, compatibility, etc. This is like the pre-WYSIWYG module days :).

The Ckeditor module does work with version 4. I'll do some more testing on WYSIWYG and this patch.

akmalfikri’s picture

Patch doesn't seem to detect CKEditor v4.0.1 and v4.0.1.1

alexweber’s picture

@akmalfikri I beg to differ.

TwoD’s picture

Status: Reviewed & tested by the community » Needs review
8.85 KB

This updated fixes the cross-editor plugin stylesheets I mentioned in #112 and the selection API problem @EugenMayer mentioned in #107. It also takes care of backwards compatibility with CKEditor < 3.6.0 which did not have button groups.
The kama skin is no longer assumed to be installed for CKEditor 4. It didn't seem to cause problems, but I feel it's better to make the code look to see if it's likely to exist before just assuming it's there. Since we can't set the skin from the GUI yet, that setting only being a shortcut to the global skin setting isn't a problem [yet] since it'll always get the same value.

The code now ensures existing profiles aren't suddenly altered by not having button grouping enabled by default and adds a checkbox for it under "Editor appearance". That will also maintain compatibility with the toolbar alterations many have performed via the settings alter hook (see #829266: Fixing toolbar for the CKeditor / Using the settings hook).

When falling back to using the default button groups, where available, I would much prefer to simply set $settings['toolbar'] = NULL as that falls back to the editor's own toolbar definition. It has much better group descriptions and spreads groups across multiple rows. We could then get rid of the new helper function for group lookups.

A problem with setting $settings['toolbar'] = NULL is that we then must fill $settings['removePlugins'] with a list of all bundled plugins which aren't enabled. Otherwise, all buttons provided by all bundled (and thus enabled by default) plugins will show up in the toolbar regardless if we've checked them or not.

I've tested these changes with Chrome, Firefox and IE 6-10 and it now works in all of them all the way from CKEditor before version 3.6.0 and up to the latest CKEditor 4 release.
IE6 did have an odd thing where it sometimes wouldn't show the contents of the older CKEditor 3 editors unless you first right-clicked and chose "refresh", but I couldn't trace that to something caused by Wysiwyg.

Now, that's at least 4 bugs fixed on what was considered an RTBC patch. ;P

rwilson0429’s picture

I got the following errors trying to apply the patch in #136. I was able to apply the patch in #78 with no problems.

git apply -v wysiwyg-ckeditor-4.1853550.136.patch
wysiwyg-ckeditor-4.1853550-136.patch:10: trailing whitespace.
  $output = '<p class="warning">' . t('Do NOT download the "CKEditor for Drupal" edition.') . '</br>';
wysiwyg-ckeditor-4.1853550-136.patch:11: trailing whitespace.
  $output .= t('Make sure you install the full package as not all plugins work with the standard package.') . '</p>';
wysiwyg-ckeditor-4.1853550-136.patch:12: trailing whitespace.
  return $output;
wysiwyg-ckeditor-4.1853550-136.patch:21: trailing whitespace.
    // version:"4.0",revision:"769d96134b"
wysiwyg-ckeditor-4.1853550-136.patch:22: trailing whitespace.
    if (preg_match('@version:[\'"](?:CKEditor )?([\d\.]+)(?:.+revision:[\'"]([[:xdigit:]]+))?@', $line, $version)) {
fatal: corrupt patch at line 240

I'm using cygwin on a Windows7 machine to apply the patches. Have not tried applying the patch in #136 on Lynux. Given the error messages returned when trying to apply the patch, doesn't seem like environment will matter.

benjifisher’s picture

@rwilson0429, I disagree: environment has everything to do with whitespace errors. The patch applied cleanly on my Mac, with a fresh git download of the wysiwyg module and using wget to download the patch:

$ git status
# On branch 7.x-2.x
nothing to commit (working directory clean)
$ git apply -v wysiwyg-ckeditor-4.1853550.136.patch 
Checking patch editors/
Checking patch editors/js/ckeditor-3.0.js...
Applied patch editors/ cleanly.
Applied patch editors/js/ckeditor-3.0.js cleanly.

There are many things that could go wrong, but my first guess is that your patch is (as the error message suggests) corrupt. Look at the patch file: does it have trailing whitespace on lines 10, 11, 12, 21, and 22? If so, try downloading it again. If not, there might be a problem with your git configuration.

FWIW, the patch applied cleanly when I used patch instead of git apply.

roborn’s picture

#136 applies cleanly on Mac, using git apply

alexweber’s picture

Status: Needs review » Reviewed & tested by the community

+1 for #136 on OSX

EugenMayer’s picture

TwoD, trust me, check blur API changes before you put this out. Iam not sure how many plugins build on this on d.o. (smells media) but its def. worth an mentioning, since this will make it a VERY hard to debug issue, when people use vertical tabs or tabs or anything what can use display:none instead of left:-999999 to hide the editor. Its a timing issue.

just mention it so people double-check it on their side, before the queue gets flooded.

+ the selection bug is not fixed. This is only once place, check selectionChange
+ Drupal.wysiwyg.editor.instance.ckeditor::init will need some love, they again changed the API. There is not anmore, use id

@alex i would kindly ask you to stop pushing this forward with eyes closed. This is yet absolutely not stable at all, eventhough you still might think this. WYSIWYG is used way to often so a quick-fix-hack should do it. There are way more scenarios you might not ever have covered in your tests.

TwoD’s picture

Status: Needs review » Reviewed & tested by the community

@EugenMayer. I'm not sure what you mean about the blur API and timing issues. Do you want it to unset Drupal.wysiwyg.activeId when the editor gets blurred? Would that also be triggered if the editor is for some odd reason moved off screen? (Don't think any of the other editors do that, but it would be nice to have.) I don't get the references to tabs here, unless you mean editors inside vertical tabs?

I'm not having any issues with the selectionChange code. The [Teaser Break] toolbar button state changes correctly and it receives its placeholder element in the isNode() method if I selected it, and null if there was no element selection.
The selection bug I noticed was mostly related to newer IE versions not having selection.getNative().createRange() anymore. CKEditor's own wrapper method already works around this. I could not find any issues in Webkit based browsers or Firefox. does still exist and is the same as the name of the original field. We do already use, a random per-instance id, to locate the iframe for injecting stylesheets since it won't find anything based on the name property with CKEditor 4 (still works with version 3).

EDIT: Btw, thanks for helping with this. Your experience building cross-editor plugins and working with the selection issue is really helpful.

alexweber’s picture

Status: Reviewed & tested by the community » Needs review

@Eugen, I'm not doing anything with eyes closed man. I tested it, it worked and there were a bunch of other people that also seemed to think so.

Either way, no hurry, back to needs review so it can get more eyes.

EugenMayer’s picture

Status: Reviewed & tested by the community » Needs review

The issue is, when the editor is hidden, right. So its not directly related to WYSIWYG, but it is for CKEditor. Since display:none removes any sort of browser-render-engine-dom-attributes from the editor, the timing issue is:
- you are in the editor, click out directly on a tab/vertical tab/whatever
- since the event is delayed (200ms), the first thing is fired is the "tab" click, so anything hide related. When this happens with display:none, this removes all attributes
- blur fires after that. Any feature build on those attributes will be broken (+ some other ugly things)

Its an edge/special case, but it is very ugly to debug. In CKEditr 3.x they did not use this delay and it worked flawlessly.

so you still use var node =; ?
This is not cross browser, i did not note it, but i think it was the IE or the Firefox. Use var node =; - this works very well. The issue with getSelectedElement is, what you need to select so it detects the correct element.

getStartElement() is a heck of a lot better here - in all cases. Its just the better algo to find the "most outer container", for now getSelectedElement is completly useless (no idea how they tested this).

$('head', $('#' + + '_contents iframe') is what we have used for now..since $('head', $('#cke_contents_' + + ' iframe') will not match.
Therefore, those extra style-sheets you want to apply for the editor will never get loaded. It might be something you did not test, could that be? (since that is a special-setting and not default).

@alex: no worries, it wasnt an offence, but this just backfires - this is WYSIWYG (not the plugin, the tech) - its to worsed place to be :) Its fugly complicated to get anything x-browser dont properly. x-editor makes stuff even more complicated, this this gets even more complex and needs a heck of a time...

@TwoD: your welcome

TwoD’s picture

I don't know anything which gets triggered on the blur event (and we don't expose it through Wysiwyg) so I'm not sure how to test this or what to do about it. I'll take another look at it when I get home. Do you have example code for when this becomes a problem?

I've not encountered any problems with CKEDITOR.dom.selection.getSelectedElement() - which is what that ends up as - in Chrome, Firefox or IE6-9 with the Teaser Break placeholder. It very accurately returns just the image placeholder and activates the TB button when I click the placeholder, and not when I begin selecting it using the keyboard and continue selecting other stuff.
If we use getStartElement() instead, it returns the placeolder image if I have clicked on it previously, hold shift to keep it selected, click somewhere about it to make the selection stretch upwards, change my mind and click somewhere below the placeholder to make the selection stretch downwards instead. That would trick the toolbar button to be in the active state and tell the plugin that just its element has been selected, even though several other elements after it are also selected and would later be replaced by anything inserted/edited by that plugin's insert() method.

Hmm, we need to get back to working on providing a cross-editor and cross-browser selection API to plugins, but that's for another issue...

The patch does use there, since I did notice earlier in the issue that Teaser Break's stylesheet didn't get added:

+++ b/editors/js/ckeditor-3.0.jsundefined
@@ -184,7 +184,8 @@ Drupal.wysiwyg.editor.instance.ckeditor = {
+              var iframe = $('#cke_contents_' + + ' iframe, #' + + '_contents iframe');
+              $('head', iframe.eq(0).contents()).append('<link rel="stylesheet" href="' + settings.css + '" type="text/css" >');

This correctly grabs a reference to the iFrame for both CKEditor 3 and 4 and is able to inject the stylesheets correctly.

EugenMayer’s picture

i see. Maybe just mention it. Its basicaly for plugin reacting on "after the user changed something in the editor" which do want to have e.g. the sizes of tables (which are dom attributes, not css) and so forth.

Yes, thats right - but in much more cases getStartElement work better then getSelectedElement . It is, IMHO the much more practical way to determine selections. Eventhough i get, this is not really CKEditor 4 related, but getStartElement got a lot better in CKEditor 4 - thats the reason. For now getSelectedElement is in 80% of the cases of a normal user - useless. We are NOT talking about the web-pro which will try to select the whole container with the mouse (properly) - and is not using IE and stuff.

Sorry, missed that - blame me! :)

drupalstrap’s picture

#126 worked for me. I am surprised such problems with such a popular editor. Thanks for the patch!

TwoD’s picture

@talengix, Thanks for testing it. The problems stem from us not finding out CKEditor 4 was on the way (and exactly what had changed in it) before the beta had already been out for a while, and at the time I could find very little information about the actual API changes from version 3. Them building a whole new packaging system (the CKEditor Builder on their site) also caused quite a lot of confusion on top of that.

We've got those bits sorted out now and we're basically left with hunting down any bugs here and there (as well as figuring out if we can remove/alter any previously necessary workarounds).

drwits’s picture

#136 worked for me on windows with cygwin and patch.

thank you!

lolhonk’s picture

plz can someone tell me how i can install a patch-file with drupal7?


attiks’s picture

kimjoel’s picture

If you are using linux for this specific patch,

Download the patch to: ...sites/all/modules/wysiwyg/editors
Run this command: sudo patch < exactnameofpatch.patch

I don't know about mac or windows.

Ali.T’s picture

I get the following error when patching: [~/public_html/help_african_women/sites/all/modules/wysiwyg/editors]# patch < wysiwyg-ckeditor-4.1853550.136.patch
patching file
can't find file to patch at input line 217
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
|diff --git a/editors/js/ckeditor-3.0.js b/editors/js/ckeditor-3.0.js
|index ae22a94..87d281c 100644
|--- a/editors/js/ckeditor-3.0.js
|+++ b/editors/js/ckeditor-3.0.js
File to patch:

Any help would be much appreciated.

benjifisher’s picture

The error message is spot on: you need to invoke patch with the -p2 option. Normally, I invoke patch from the top-level directory for the module (modules/wysiwyg in this case) and use -p1. If you want to do it from the subdirectory modules/wysiwyg/editors then you should use -p2.

# man patch
David4514’s picture

Patch from #136 seem to work for me. Looking forward to this being committed. Thanks.

ifrik’s picture

#136 worked for me as well. Thanks

ryanissamson’s picture

Would absolutely be thrilled to have a D6 reroll when the D7 patch is committed. :D

blackspiraldancer’s picture

...patch works fine for me too, WYSIWYG version 7.x-2.2, Drupal 7.21 and CKeditor 4.1 RC - thanks!

Danny Englander’s picture

I tried the patches from #126 and #136 and in each case, I could not get any alignment buttons (left, right, center) to show up. The patch applied cleanly and I see the changes in my local Git repo to the two files that were patched. I cleared cache as well so I am not sure what I am doing wrong. All other buttons seem to show up fine.

idflood’s picture

@highrockmedia: Did you download the "Full" preset of ckeditor? It seems that the alignement buttons are part of the "Justify" plugin.

nagy.balint’s picture

#136 works for me as well.

Danny Englander’s picture

@idflood - thanks that did the trick!

TwoD’s picture

Status: Needs review » Fixed

I'm not really too happy about having the button group lookup function in there since that info is already in the editor's own button definitions and it'll use them if we simply skip defining the toolbar. BUT, we current'y can't skip defining the toolbar without properly detecting which plugins are installed and which are safe to add to the removePlugins setting without reliable metadata about plugin dependencies. That feels like it goes out of this issue's scope and it'll probably have to wait for #277954: Allow to sort editor buttons to make sense.

Therefore, I've committed the #136 patch to Wysiwyg 7.x-2.x and 6.x-2.x - after fixing the spelling of "accessible" in a new comment.

Thank you to everyone for reporting, reviewing, testing and participating in adding support for CKEditor 4!
I'm sorry if I missed someone in the commit message. I basically tried to list everyone who posted a patch and did not read through all the text again. If you feel you deserve a mention, don't be shy and speak up and I'll try to make up for it.

The -dev snapshots will be updated within 12 hours and this patch will be part of the next D7 and D6 releases.

DYdave’s picture

After following this issue for two months and seeing all the work and testing to get these patches rolled in, I would like to quickly thank everyone for the hard work put into this ticket.

ryanissamson’s picture

You guys are awesome! Thanks!

sk33lz’s picture

Another example of great Drupal community teamwork! Go team!

L-four’s picture

Priority: Normal » Critical

Changing priority to critical because WYSIWYG + CKEditor will not work without this patch.

L-four’s picture

Priority: Critical » Normal

Sorry, I am way to tried to be on d.o.

gthing’s picture

Priority: Normal » Critical
dddave’s picture

Priority: Critical » Normal

There is nothing to see or do here guys. The fix is in the dev, clicking here won't help anyone with anything.

lolhonk’s picture

Thank u very much for ur help!

heddn’s picture

I need a patch that will apply cleanly against 7.x-2.2 for a drush make install.

TwoD’s picture

+++ b/editors/ckeditor.incundefined
@@ -315,8 +336,23 @@ function wysiwyg_ckeditor_settings($editor, $config, $theme) {
+    // Organize groups to use lables to improves accesibility

Btw, that is the "accessibility" typo I fixed before I committing the other patch.

Hmm, If you're making a patch against 2.2, you might want to diff the current 7.x-2.x and 7.x-2.2 changes for the CKEditor files and use all the changes since stable as it fixes a couple of annoying minor issues as well.

JamesIII’s picture

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

Bassie - thank you so much. Editing did the trick.

I wonder why this hasn't been made a permanent change. Am a noob here so perhaps it's a dumb question.

TwoD’s picture

@JamesIII, it has been. I committed the latest patch here to the repository a while ago (hence why this issue is marked "fixed") and the -dev snapshots now reflect it. New releases will be made once I've been able to go through all open issues and determine if what's worth waiting for and putting time into has been done, or if people will be satisfied with what's already fixed since the last ones (nobody ever is =P).

johnlaine’s picture

Thanks Bassie, #2, that did the trick!

TwoD’s picture

Status: Fixed » Closed (fixed)

Seriously? The patch in #136 was committed to 7.x-2.x-dev a while ago and contains a lot more fixes than just the main version issue in #2.

Since this issue does not seem to want to fall out of the queue, I'll close it manually.

jcisio’s picture

@TwoD should we release a stable release? The noise is because people are recommended to use a stable release. And if we want to patch something, #2 is a much easier patch to manage (if it works for him, great!).

sonicthoughts’s picture

Should this stay open until released stable?

clcl’s picture

Priority: Normal » Major
Status: Closed (fixed) » Needs review
424.71 KB
20.34 KB
8.92 KB

#2 did not work for me Drupal 7.22 wysiwyg 7.x-2.2 and the latest full version of ckeditor 4.1 but I had to put this into the ckeditor.js version:'CKEditor 4.1.1 SVN',revision:'80c139aa' where the version in ckeditor.js = 4.1
I did #136 and that worked for me. At least the output is now there but I'm missing the disable text layout button. So I can not see any button at all. Can somebody help me please?

I did the changes in ckeditor-3.0.js (module wysywyg/editors/js) and (module wysywyg/editors) (just like the patches in #136 and ckeditor.js (libraries/ckeditor) where I putted the version as mentioned in the beginning of this writing.

In case someone has to do the patch I attached my version of the changed files. Hopely I help some people and someone helps me.
Can't do the upload getting this message:
Validation error, please try again. The file you attempted to upload may be too large. If this error persists, please contact the site administrator.
Ok, if ad .txt and now its atached.

I really want to work with wysywyg and ckeditor because afterwords I would like to install geshi filter. If anyone could give me advise please do!

hass’s picture

Priority: Major » Normal
Status: Needs review » Closed (fixed)
TwoD’s picture

I'll make a release once a few more patches have gone in.

I know people are recommended to use stable releases. If however you really want to stick with the very latest library releases, I seriously recommend at least running a -dev snapshot and update if the library isn't working. Some of the more popular libraries have fairly rapid release schedules and many more active maintainers than we do.

Running the Wysiwyg -dev snapshots will mean you will at least have the latest stable fixes (we don't commit if we know a patch breaks something), and it'll be a lot easier to apply patches which haven't been committed yet.
We haven't broken our existing APIs between minor releases (AFAIK) and since Wysiwyg isn't touching database tables or data belonging to other modules, there's very very little risk involved. Plus, we need the all the testers we can get.

sonicthoughts’s picture

Great points! Perhaps calling it beta or rc and using the recommend flag would help differentiate that as this is a bit different than other modules.

caspercash’s picture

I have also encountered this kind of message but what I did was that I used the CKEditor version 3.x instead of 4.x. I am not really sure why it couldn't detect the 4.x version of CKEditor.

TwoD’s picture

@caspercash, that's what this issue was all about. They made several changes to CKEditor which prevented Wysiwyg from interacting with it in the same way it used to. The comments above have all the details.

MacMladen’s picture

With all the respect for the great work you've done I still think you should commit this slight change that enables detection of the version 4.

While I'm not acknowledged developer, I do some coding and development upon need, just to say I understand your concerns.

But I've used wysiwyg with wysiwyg_filter on many sites ever since CKEditor v.4 emerged and haven't bumped into single issue, really.

I cannot be sure if everything under every condition is working but I do use very complex settings in order to protect my site editors and produce nice code and every site just works with the little patch from #2. I'm not even sure what specific issue are other talking about.

It's been a long time CKEditor v.4 came, it is accepted in D8 so I pledge you to make official WYSIWYG release that accepts CKEditor v.4, it is really bummer doing patch and even there are some issue doing it in drush make for some reason.

TwoD’s picture

The change has already been committed and will be part of the next official releases. You can use 7.x-2.x-dev without patching until then.

I dare say NONE of the Drupal sites using CKEditor 4.1 through Wysiwyg module will work reliably with just the #2 patch, and nothing else changed. Because of the new content filter introduced in that version, CKEditor may actually remove some of your tags without mercy. This is part of why I've not yet made an official release.

That is to be dealt with in #1956778: Ckeditor 4.1 ACF but I've simply not had time yet to implement it between my job, matters at home and all the other activity in this issue queue.

sonicthoughts’s picture

@TwoD thanks so much for all your contributions and of course balance is critical to a happy life :) We are all very excited by this fix and 4.1 support when avail.

jacieyang’s picture

Assigned: Unassigned » jacieyang

#55 works for me. thanks.

jenlampton’s picture

kenorb’s picture

Priority: Normal » Major
Issue summary: View changes

This should be included in the latest stable release, as it's quite critical. CKEditor can't work at all without this fix.

ostami’s picture

I'm confirming that Patch #136 works in a test install against wysiwyg-7.x-2.2. This means after successfully applying the above patch, I was also able to use the editor to create a page, type text, insert an image from the media library, change the image's alignment, save and view the page - using CKeditor 4.3 installed in /var/www/sites/all/libraries/ckeditor.

/ # cd /var/www/sites/all/modules/wysiwyg/editors/
/var/www/sites/all/modules/wysiwyg/editors# patch -p2 < wysiwyg-ckeditor-4.1853550.136.patch 
patching file
Hunk #4 succeeded at 211 with fuzz 2.
Hunk #5 succeeded at 219 (offset -2 lines).
Hunk #6 succeeded at 286 (offset -3 lines).
Hunk #7 succeeded at 301 (offset -3 lines).
Hunk #8 succeeded at 336 (offset -3 lines).
Hunk #9 succeeded at 480 (offset -3 lines).
Hunk #10 succeeded at 499 (offset -3 lines).
patching file js/ckeditor-3.0.js
rwscid’s picture

I installed Drupal only a few days ago (7.24) wysiwyg a few hours ago (7x-2.2) and CKEditor (4.3.1 standard) one hour ago, and wysiwyg tells me -

"The version of CKEditor could not be detected."

What to do now?

My first time asking for help so if I am committing any faux pas I apologize in advance.

As for patches ... I know what they are, not quite sure how to apply one.

dddave’s picture

per #187: It seems using the dev version should work fine.

spicon74’s picture

Thank you all! I have Drupal 7.25 and I had the same error message (The version.... be detected...)
I change the line and everything works fine now!

eigentor’s picture

If you have this problem: use the dev version of Wysiwyg. Version 7.2.2 is from October 2012 (!) But I guess there are good reasons holding up a new stable release.
Would put my bet on Drupal 8 core stuff?

jorisx’s picture

I just(automatically) upgraded to wysiwyg vers:7.x-2-2, with "CKEditor" and had to put the fix of #2 (
Fix works flawless.

CarlHinton’s picture

724 bytes

To simply change the one line of code then use this patch

CarlHinton’s picture

724 bytes


TwoD’s picture

@CarlHinton Those changes are simply wrong and it will come back and bite you later. I've repeated this several times in this issue. CKEditor 4 has changed a couple of plugins and made other changes which this does not account for. It just won't work right.

Use the 7.x-2.x-dev version (which includes a bunch of other good changes) until there is a new release. There are no known regressions since the latest release so it will only be a positive experience.

Posting patches (with the same changes rejected over a hundred comments ago) for releases instead of the development branch only confuses things since they won't apply correctly, so please avoid that.

TwoD’s picture

Issue summary: View changes
dan.mantyla’s picture

@TwoD you are correct, the patch by posted does cause CKeditor to be detected, but it shows error message at the top. I installed the dev version as advised and it works well, thank you. I believe this newer issue is related:

CarlHinton’s picture

@TwoD I do not mean to confuse anyone. Whilst I agree that the patch of #199 is not the correct way to fix things; it was the only patch that would work for my configuration, and therefore a good interim measure for my immediate needs and probably the needs of others in the community.

I am using the 7.x-2.x-dev version with ckeditor 4.3.2 (full). The regex supplied in the other patches does not recognise the newer full versions of ckeditor.

I thank you for all your contributions and I look forwards to the final fix being incorporated into a stable release, so that I do not have to use a 'fudge' to make what is a very useful module work.

TwoD’s picture

@CarlHinton, you do not need any patches at all. 7.x-2.x-dev detects all known versions of the CKEditor Full variant out of the box, including CKEditor 4.3.3 released on 25 February.

dremy’s picture

65.25 KB

So this is related to #160. I'm using the full CKeditor 4.3.4 with "Justify" plugin and updated to 7.x-2.x-dev and the alignment button images will not show up. See the attached image. I checked the source code for other button images that were showing and they were using a sprite that had all the other images already inside.

dealancer’s picture

Status: Closed (fixed) » Needs work

Still having this issue with wysiwyg 7.x-2.2 and 4.4.0. Opening this ticket.

dealancer’s picture

Status: Needs work » Fixed

looks like this problem was fixed in the dev version.

Status: Fixed » Closed (fixed)

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

Pete B’s picture

Great work on this patch. Is there anything blocking a release?

jgibso’s picture

Still not fixed

torgosPizza’s picture

@jgibso: It's fixed in the -dev version of WYSIWYG.

fgjohnson’s picture

Where to I extract the -dev version of wysiwyg?...

/profiles/wetkit/modules/contrib # tar xvfz wysiwyg-7.x-2.x-dev.tar.gz
# drush cc 1

Same error:
media_wysiwyg (Missing) -> in Metatag, Widgets and WYSIWYG

torgosPizza’s picture

@fgjohnson - that sounds like an unrelated issue and possibly not relevant.

This error is about the WYSIWYG module not finding the CKEditor library, not an extra module missing from a modules list (which is what it sounds like you are describing).

hamedsbt’s picture

I installed "Wysiwyg v7.x-2.2" and latest ckeditor so had same problem and my friend fixed it for me :)

1)Open "\sites\all\libraries\ckeditor\ckeditor.js" file in a text editor.
2)Add "// version:'4.4.3',revision:'4391' " in first line (without double quotations) and save it.


Aavas’s picture

@hamedsbt Thank you. That worked for me too.

clawki’s picture

@hamedsbt you are a rock star. I ignored this at first when I saw that the comments started at 2 years old, but in exasperation I thought I would look down the line, and ther you were ;-) Thanks

clawki’s picture

@hamedsbt you are a rock star. I ignored this at first when I saw that the comments started at 2 years old, but in exasperation I thought I would look down the line, and there you were ;-) Thanks

clawki’s picture

@hamedsbt you are a rock star. I ignored this at first when I saw that the comments started at 2 years old, but in exasperation I thought I would look down the line, and there you were ;-) Thanks

rooby’s picture

I would recommend always checking the most recent comments in an issue.
Ignoring an issue because of how long ago it was opened will not serve you very well in finding fixes to your problems.

greggmarshall’s picture

Ignore this patch, I hadn't read the entire thread carefully enough.

woei’s picture

this patch should be applied to wysiwyg module of 7.x

woei’s picture

this patch should be applied to wysiwyg module of 7.x
anyone can help?

greggmarshall’s picture

Comment removed, sorry.

datanai’s picture

@hamedsbt Thanks. Works for me too!

TwoD’s picture

STOP DOING THIS, You are shooting yourselves in the foot this way!

More than just the version check is broken because of CKEditor 4

I've said over and over again, A PROPER PATCH has been pushed into 7.x-2.x-dev already.

I'm ignoring this issue from now on. I don't need people complaining later about half-broken editor profiles due to applying a patch to an otherwise pretty stable release. I need people to test what's going to be the next release and actually has a fully working integration with the Full CKEditor 4 package. Patches should help detect other package variants of editors (using a custom download without some of the plugins from CKEditor 3 does not work as expected, for example, and most want to se only the pluginx which can actually be enabled instead of everyhjng that wax in CKEditor 3).

DYdave’s picture

Well said @TwoD!
Just wanted to show my support on your latest comment and thank you very much for your patience, perseverance and tremendous efforts maintaining the module.

dddave’s picture

People: This is fixed in DEV. Use it! Also please read #225

Commenting is closed now.

psychonaute’s picture

doesn't work for me with 7.x-2.x-dev and ckeditor 4.4.7. And can't get an earlier version of ckeditor in full package on their website.

Any suggestion?

kenorb’s picture

@psychonaute: Please read #225 or raise a new support issue, as this one is closed.