open_basedir error

Submitted patch looks exactly like D7 change, and when I tried it for D6 version of WW API some time ago, it did not work, only old version with 'path' did. I just double checked Wysiwyg 6.x-2.4 and latest 6.x-dev code, both handle splitting 'path' into 'filename' (see below code pasted from \sites\all\modules\wysiwyg\editors\tinymce.inc).

I suspect something else is going on in your case. Your patch should not make any difference. What version of Wysiwyg API do you have installed? Can you convince me that the below code does not work in your case and proposed patch somehow makes it right?

I am opposed to committing this patch as there is no mechanism to check for older versions of WW API (back when it did not use 'filename' at all), and patch will break sites that still have older WW API.

function wysiwyg_tinymce_plugin_settings($editor, $profile, $plugins) {
  $settings = array();
  foreach ($plugins as $name => $plugin) {
    if (!empty($plugin['load'])) {
      // Add path for native external plugins; internal ones are loaded
      // automatically.
      if (empty($plugin['internal']) && isset($plugin['path'])) {
        // TinyMCE plugins commonly use the filename editor_plugin.js, but there
        // is no default. Previously, Wysiwyg's API documentation suggested to
        // have the 'path' contain the 'filename' property, so if 'filename' is
        // not defined, automatically extract it from 'path' for backwards
        // compatibility.
        if (!isset($plugin['filename'])) {
          $parts = explode('/', $plugin['path']);
          $plugin['filename'] = array_pop($parts);
          $plugin['path'] = implode('/', $parts);
        }
        $settings[$name] = base_path() . $plugin['path'] . '/' . $plugin['filename'];
      }
    }
  }
  return $settings;
}

Re wysiwyg 6.x-2.4+8-dev version - I hope you meant 6.x-2.x-dev.

Anyhow, I think I understand the problem better now. From the errors you are getting, it looks like your server refuses to serve the plugin as it somehow gets a relative path for the files in its filesystem. Can you check that your Drupal configuration sets $base_url properly and global $base_path is pointing to your Drupal installation?

Also, can you confirm that you have spellcheck plugin working with your patch? Do you have the test that is mentioned in the INSTALL.txt pass with the patch? It is not clear from you prior posts.

Missing detail in the issue was that the error happens on the Wysiwyg profile page. I found code in Wysiwyg that is responsible for the errors due to the snipped I pasted in #1 not being invoked and 'path' not split out. Poor design of Wysiwyg API module.

Anyhow, I've committed the proposed fix into 6.x-1.x-dev, which will require all installations to update to the latest version of Wysiwyg module.