Version callback failed to open stream

You should not be able to get those warnings as the version callback is not called when the editor is not installed. (It counts as installed if wysiwyg_get_path() finds it.).
When do they appear?

Yes I noticed that they include jQuery etc too. I'm not sure jWysiwyg was packaged like that before.

The installation instructions do mention that:

So the actual library can be found at:
sites/all/libraries/jwysiwyg/jquery.wysiwyg.js

If you unpacked it like that, there's no way the editor could be detected as installed, but throw those warnings because the file can't be located.
To make that happen, the path must have been something like sites/all/libraries/jwysiwyg/jwysiwyg/jquery.wysiwyg.js, in which case the editor itself won't load.

Currently, the "is installed"-check is as simple as

if (!($editors[$editor]['installed'] = file_exists($editors[$editor]['library path']))) {
  continue;
}
</code>
If that passes, the version will be checked with:
<?php
// Detect library version.
if (function_exists($editors[$editor]['version callback'])) {
  $editors[$editor]['installed version'] = $editors[$editor]['version callback']($editors[$editor]);
}
if (empty($editors[$editor]['installed version'])) {
  $editors[$editor]['error'] = t('The version of %editor could not be detected.', array('%editor' => $properties['title']));      $editors[$editor]['installed'] = FALSE;
  continue;
}

If that fails, we'd like to know why. The warning you see indicates that the file could not be found at all. After this patch, it's a near-silent fail which doesn't indicate the path is a problem (might as well be the RegExp check failing).
I think a better approach would be to check the handle returned by fopen and only continue if it was successful. Flooding the logs with the fgets() warnings is unnecessary when they are a secondary problem.

An even better solution (maybe in combination with the above) would be to make the "is installed"-check look for one of the actual files instead of just the folder. With jWysiwyg, this happens to be the same file the version is read from but that's not always the case when multiple library variants are available. The problem with that approach is that we need to know the version before we know which file to check so it's a kind of catch 22...

Good call.

In general, and if possible, like in Drupal core, changes go into HEAD first, and are backported afterwards. Note however that 90% of Wysiwyg module is identical between major versions of Drupal core. Most patches apply cleanly to all branches.

I'm fine with the patch as it is and I agree that the warnings are not so useful for the end users that we should let them show. Just not sure how the warnings would appear in the first place and if the patch might not just hide that there might be something wrong with the library placement?

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

+++ editors/openwysiwyg.inc	30 Mar 2010 19:21:47 -0000
@@ -45,7 +45,10 @@ function wysiwyg_openwysiwyg_editor() {
 function wysiwyg_openwysiwyg_version($editor) {
-  $changelog = $editor['editor path'] . '/changelog';
+  $changelog = $editor['library path'] . '/changelog';
+  if (!file_exists($changelog)) {
+    return;
+  }

This change broke openWYSIWYG. I already felt uncomfortable with that change when I did it. #713942-6: OpenWYSIWYG broken, jWysiwyg needs jQuery 1.3+ explains why.

Sorry.

Powered by Dreditor.

um, what works now? Did you want to attach a patch? :)

git patches are ok, but only if you use git diff --no-prefix

Thanks for reporting, reviewing, and testing! Committed to all branches.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.