Comments

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

The new version of ckeditor used " instead of ' in de js file.

Solution:
editors/ckeditor.inc
line: 81

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

#2 Works, thanks!

Shall this be committed to the dev version?

Status:Active» Needs review
StatusFileSize
new726 bytes

Here is a patch for it.

Patch works. Thanks a lot.

#2 Worked for me thanks.

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

thanks

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/ckeditor.inc
Hunk #1 succeeded at 68 (offset -10 lines).

No problems with the new editor so far.

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

thanks

Status:Needs review» Reviewed & tested by the community

Patch is good

Works for me too.

Working well for me.

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.

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.

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.

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

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.

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

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

Status:Reviewed & tested by the community» Needs work

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.

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

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.

#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.

Thanks
Andrew

Assigned:Unassigned» pjcdawkins

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

StatusFileSize
new715 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.

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.

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.

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

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

.

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.

#4 work for me

Will this be fixed on version 6 too?

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

I would also like to added that there is work on ckeditor 4 being done in http://drupal.org/project/wysiwyg_ckeditor

Status:Needs work» Needs review
StatusFileSize
new3.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?

Cheers

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

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:

<?php
$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);
?>

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

didn't intend to change status

I applied patch in #35 to my D6 site.

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

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

Cheers

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

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

Cheers

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

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.

Cheers

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?

@Graham_W

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.

Cheers

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

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.

#46 works great for the combi Wysiwyg + CKeditor 4

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

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.

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

#46 patch working on D6, no issues detected.

We are also having problems with the alignment buttons

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
admin/structure/types/manage/page/fields/field_body
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

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/ckeditor.inc).

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.

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.

@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?

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

@#55

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.

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 http://drupal.org/project/wysiwyg_template
Replace
Flash
Smiley
Div container
iFrame
Font
Font size
Select all
Search
Show blocks
Forecolor
Backcolor
Align right
Justify
Left-to-right
Right-to-left
Align left
Align center

@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.

I made this makefile which contains the patch and the full CKEditor package to download https://gist.github.com/4564855

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.

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.

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

I downloaded the ckeditor plugin 4.0.1 from Jan 8 2013, from http://ckeditor.com/download

and I applied the patch #46 like this:
curl http://drupal.org/files/wysiwyg-support_v4_ckeditor-1853550-46.patch | 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

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

Then I found this: http://ckeditor.com/builder
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

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.

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

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)

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.
Cheers!

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?
Thanks

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...

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

@yanniboi
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?

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

@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.

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

Thanks!!

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

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
wysiwyg-support_v4_ckeditor-1853550-73.patch
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

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.

StatusFileSize
new38.49 KB

@idflood

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.

Thanks

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

Status:Needs review» Reviewed & tested by the community

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

H

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.

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 ckeditor.inc 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: "4.0.1.4.0.1

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.

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

Thanks

@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.

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

@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!

Has anyone noticed this error?:

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

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.

@S@ilor,

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][] = http://drupal.org/files/wysiwyg-support_v4_ckeditor-1853550-73.patch

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

<?php
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;
?>

@alexweber

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)

<?php
function wysiwyg_ckeditor_version($editor) {
 
$library = $editor['library path'] . '/ckeditor.js';
  if (!
file_exists($library)) {
    return;
  }
 
$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)) {
      
fclose($library);
      
// 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];
    }
   
$max_lines--;
  }
 
fclose($library);
}
?>

This part

<?php
     
return $version[1] . '.' . $version[2];
?>

is at line 75 ...

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

<?php
function wysiwyg_ckeditor_version($editor) {
 
$library = $editor['library path'] . '/ckeditor.js';
  if (!
file_exists($library)) {
    return;
  }
 
$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)) {
     
fclose($library);
     
// 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];
    }
   
$max_lines--;
  }
 
fclose($library);
}
?>

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...

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

Yes, patch in #73 combined with downloading the Full preset from http://ckeditor.com/builderr seems to work well. Thank you very much.

Thanks, Alex.

All good now

Hi all,
I saw some similar issue here...so 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/ckeditor.inc).

<?php
  
if (preg_match('@version:"(?:CKEditor )?([\d\.]+)(?:.+revision:"([\d]+))?@', $line, $version)) {
     
fclose($library);
     
// 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];

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

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.

Subscribe

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.

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.

@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

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

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

#73 works

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.
Cheers!

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

Status:Needs review» Needs work

Let's summarize here:

CKEditor 4 API changes according to http://docs.ckeditor.com/#!/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.

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.

@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.

Per the comments on http://drupal.org/node/534548, 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.

@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.

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?

I tried the patch, but ckeditor 4.0.1.1 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?

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

@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.

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

10-4 Thanks @TwoD!

Tip in comment #2 worked for me, too.

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

+1 for RTBC.

Status:Needs work» Needs review

Same patch as #73 - submitting for testing.

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

No valid tests...

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

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?

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?

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.

@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.

Wow - lot's of confusion http://bit.ly/YJAESw 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.

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

StatusFileSize
new71.02 KB

@akmalfikri I beg to differ.

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new8.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

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.

@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/ckeditor.inc...
Checking patch editors/js/ckeditor-3.0.js...
Applied patch editors/ckeditor.inc 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.

#136 applies cleanly on Mac, using git apply

Status:Needs review» Reviewed & tested by the community

+1 for #136 on OSX

@TwoD
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 editor.name 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.

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.

CKEDITOR.editor.name does still exist and is the same as the name of the original field. We do already use CKEDITOR.editor.id, 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.

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.

Status:Reviewed & tested by the community» Needs review

blur:
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.

selectionChange:
so you still use var node = event.data.selection.getSelectedElement(); ?
This is not cross browser, i did not note it, but i think it was the IE or the Firefox. Use var node = event.data.selection.getStartElement(); - 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).

init:
$('head', $('#' + ev.editor.id + '_contents iframe') is what we have used for now..since $('head', $('#cke_contents_' + ev.editor.name + ' 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

blur
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?

selectionChange
I've not encountered any problems with CKEDITOR.dom.selection.getSelectedElement() - which is what that event.data.selection.getStartElement() 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...

init
The patch does use ev.editor.id 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_' + ev.editor.name + ' iframe, #' + ev.editor.id + '_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.

blur:
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.

selectionChange:
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.

init:
Sorry, missed that - blame me! :)

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

@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).

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

thank you!

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

thanks!

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.

I get the following error when patching:

irfanped@irfanpedia.org [~/public_html/help_african_women/sites/all/modules/wysiwyg/editors]# patch < wysiwyg-ckeditor-4.1853550.136.patch
patching file ckeditor.inc
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.

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

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

#136 worked for me as well. Thanks

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

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

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.

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

#136 works for me as well.

@idflood - thanks that did the trick!

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.

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.
Cheers!

You guys are awesome! Thanks!

Another example of great Drupal community teamwork! Go team!

Priority:Normal» Critical

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

Priority:Critical» Normal

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

Priority:Normal» Critical

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.

Thank u very much for ur help!

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

+++ 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.

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

Bassie - thank you so much. Editing ckeditor.inc 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.

@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).

Thanks Bassie, #2, that did the trick!

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.

@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!).

Should this stay open until released stable?

Priority:Normal» Major
Status:Closed (fixed)» Needs review
StatusFileSize
new424.71 KB
new20.34 KB
new8.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 ckeditor.inc (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!

Priority:Major» Normal
Status:Needs review» Closed (fixed)

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.

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.

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.

@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.

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.

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.

@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.

Assigned:Unassigned» jacieyang

#55 works for me. thanks.

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.

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 ckeditor.inc
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

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.

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

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!

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?

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

StatusFileSize
new724 bytes

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

StatusFileSize
new724 bytes

Correction

@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.

Issue summary:View changes

@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: https://drupal.org/node/2141117

@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.

@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.

StatusFileSize
new65.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.