CKEditor 3.6.3: 'The version of CKEditor could not be detected.'

CKEditor module is n/a for D5, or that's what I would have used.

The workaround is to hack the .inc file for CKEditor (or FCKEditor). Unfortunately that didn't do me any good, as the current version of WYSIWYG for D5 can't handle font styles for CKE or FCK.

TwoD: The issue is that the fixes didn't get applied to the D5 branch. I was able to hack the .inc file for CKEditor to make WYSIWYG detect it. Same worked for FCKEditor. As noted, though, the fix wasn't ultimately useful due to the style issue. The solution I arrived at was to move them to TinyMCE, which will work better for them anyway -- its support for pasting from Microsoft Word, while not strictly speaking as good, appears to be more consistent, which is more important for this client.

(Also, I had taken care to make sure I wasn't using the "drupal version", having run across other issues about that.)

The style issue is as you describe. This was something that needed to be solved quickly and permanently, so the TinyMCE migration was really a more timely solution than a patch -- I needed something that would be stable in case someone else updated the module in future, since this is not a for-sure regular client.

In any case, I had suspected there might be editor issues (I do understand this particular one is a module defect), which was another reason I wanted to use WYSIWYG on this task instead of trying to fix or patch fckeditor.module.

Are you sure 5.x-2.1 doesn't support CKEditor? Because it sure seemed to ;-) (aside from not loading the custom styles).

5.x-2.1 is in fact the version I used -- I just checked the .info file -- and it definitely recognized and loaded CKEditor after modification. Here's the .info:

; $Id: wysiwyg.info,v 1.1.2.3 2008/10/22 05:33:30 sun Exp $
name = Wysiwyg
description = Allows users to edit contents with client-side editors.
package = User interface
dependencies = jquery_update

; Information added by drupal.org packaging script on 2010-03-08
version = "5.x-2.1"
project = "wysiwyg"
datestamp = "1268063713"

But it's a good thing you asked me this, because I was confused about FCKEditor: That code is fine, as you say. It was the TinyMCE .inc file I had to modify.

Here are the changes I made.

For CKEditor, I modified editors/ckeditor.inc as shown here:

/**
 * Detect editor version.
 *
 * @param $editor
 *   An array containing editor properties as returned from hook_editor().
 *
 * @return
 *   The installed editor version.
 */
function wysiwyg_ckeditor_version($editor) {
  $library = $editor['library path'] . '/ckeditor.js';
  $library = fopen($library, 'r');
  $max_lines = 8;
//  while ($max_lines && $line = fgets($library, 140)) {
  while ($max_lines && $line = fgets($library)) {
    // 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]);
      //$version[1] = '3.6.3';
      return $version[1] . '.' . $version[2];
	  //return '6.3';
    }
    $max_lines--;
  }
  fclose($library);
}

i.e., removed the '400' parameter for fgets().

For TinyMCE, I modified editors/tinymce.inc as shown here:

/**
 * Detect editor version.
 *
 * @param $editor
 *   An array containing editor properties as returned from hook_editor().
 *
 * @return
 *   The installed editor version.
 */
function wysiwyg_tinymce_version($editor) {
  $script = $editor['library path'] . '/tiny_mce.js';
  $script = fopen($script, 'r');
  // Version is contained in the first 100 chars.
  //$line = fgets($script, 100);
  $line = fgets($script);
  // 2.x: this.majorVersion="2";this.minorVersion="1.3"
  // 3.x: majorVersion:'3',minorVersion:'2.0.1'
  if (preg_match('@majorVersion[=:]["\'](\d).+?minorVersion[=:]["\']([\d\.]+)@', $line, $version)) {
    fclose($script);
    return $version[1] . '.' . $version[2];
  }
  fclose($script);
}

i.e., removed the '100' parameter for fgets().

TwoD, when is the cost of loading the entire file into memory incurred? Only when loading the config page, right?

OK, thanks, just trying to figure out whether I need to hassle them to let me patch the module. That's probably an acceptable cost for that client. They edit pages rarely and the editor is never loaded for anon visitors. If it were every page load period I'd hassle them to let me patch it.

I don't want to get into the weeds on this with client-specific stuff. I'm just trying to gauge whether it's worth their $$ and our time to re-engage to install an update.

so as I look over the current status and the thread, I think this satisfies criteria for some version of 'fixed' (since it's in dev), but not sure what the right status is.