This editor appears to have moved away from their old site at wymeditor.org and now have a new site and their code on github:
https://github.com/wymeditor/wymeditor/

The old URL still works and all the info there remains relevant for the version last supported by Wysiwyg (0.5-rc1), so I suspect few knew it was actually still in development.

I don't have time to look into this now, and AFAIK this editor is not widely used with Drupal. Postponing this at least until there's been another Wysiwyg release.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jfhovinne’s picture

The 'official' website at http://www.wymeditor.org/ has been updated with current information and links to download the latest 1.0.0b6 release.

Here is a patch to support that release (remains compatible with 0.5).

Note: WYMeditor 1.0.0b6 does not load its skin CSS anymore via JS. I guess it should be loaded with drupal_add_css(), but I do not know where to put that code.

TwoD’s picture

Thanks!
I'll check this out soon (at work now), but I just noticed this change:

+      '1.0.0-b6' => array(
+        'js files' => array('wymeditor.js'),
+      ),

Unless the JS file (or other metadata) is different from the one used with 0.5-rc1 is different, we don't need to specify it again since the keys mean "version X and above".
However, since you mention the need to add the CSS file, we could use the 'css files' key, and then we do need to redeclare the 'js files' key since only the last matching version-specific metadata overrides are applied. (I hope that sentence makes sense, hehe.) See wysiwyg.api.php for the available keys.

I haven't downloaded the library yet, but by the looks of the patch, the version number has moved down a couple of lines. Am I right?

jfhovinne’s picture

Yes, the version number is now in the 4th line, instead of 2nd, which explains the fgets() loop in wysiwyg_wymeditor_version().

The default 'compact' skin CSS file is located at $editor['library path']/skins/compact/skin.css, what should be the value of the 'css files' key ?

TwoD’s picture

It should probably be 'js files' => array('skins/compact/skin.css'), not verified that yet though.

jfhovinne’s picture

Status: Postponed » Needs review
FileSize
3.46 KB

Here is the updated patch (using git format-patch).

  • Added 'css path' and 'css files'.
  • Added a 'load callback' in order to load inline CSS which removes a margin-top on dropdowns that prevents to click on the list items.
  • Added inline CSS to make the editing area a bit higher, since it is only 200px high in the default skin.

Editing seems to work flawlessly.

bubu’s picture

Upgrade patch to current WYMeditor 1.1.1

TwoD’s picture

Priority: Minor » Normal
FileSize
6.96 KB

A few notes:

The 'css path' key is meant to indicate where CSS files needed to better integrate a library are located, not files which belong to the library itself.
For example, the inline styling tweaks added here are better put in their own file, which is then loaded for the appropriate version(s) using the 'css files' list.
Unfortunately, the list of library files only accepts JavaScripts, but since determining which skin file to load actually depends on the configured skin we can do that from inside the settings hook instead. Earlier editor versions auto-loaded skins, so only do this for 1.0 and up. (I could only find one RC release to download, and I'm intentionally not aiming to support it anyway.)

I found a couple of settings which are no longer used, and a couple of API changes, which merits creating a separate integration file for versions 1.0 and up.
A couple of tweaks were useful for the older versions as well so those are includeded here, like reindexing the instances list after removing one. The older versions handled not being re-indexed better, but 1.0 and up assume the list has no gaps. The new vanish() method fortunately helps us determine what needs to be done when detaching the editor from now on.

Having to dig through 100+ lines for the version number feels wrong, but there's not much else to do about that yet. In the future I'll probably grab that info from the profile and only verify it on the admin page though.

TwoD’s picture

Issue tags: +Release blocker
Parent issue: » #2273635: WYMeditor 1.0.0 release
TwoD’s picture

bubu’s picture

@TwoD, thanks for the patch. It's much better.

There are one more outstanding issue: wymeditor 1.1.1 will not open dialog windows, for example: "insert link", "insert table".

From 1.0.0b5 to 1.0.0-rc.1: dialogs work well.
1.0.0-rc.2: This is the first release where dialogs doesn't work.

TwoD’s picture

FileSize
8.69 KB

Wow, this library had a really inconsistent version numbering scheme hehe.

Added a couple of more tweaks. The dialog buttons now apparently need another class to open...

bubu’s picture

@TwoD, thanks for you persistence! Yes, this last patch works as expected. I think, feature is done, you can commit this patch.

  • TwoD committed 7cc73bd on 6.x-2.x
    - #2273635 by jfhovinne, TwoD, bubu: Added WYMeditor v1+ compatibility.
    
  • TwoD committed 60a686f on 7.x-2.x
    - #2273635 by jfhovinne, TwoD, bubu: Added WYMeditor v1+ compatibility.
    
TwoD’s picture

Status: Needs review » Fixed

This will now finally be part of the next release, thank you for helping!

A small disclaimer: The D6 version is very similar to the D7 version when it comes to the editor integration files, but WYMeditor 1+ requires a newer version of jQuery than what D6 (even with jquery_update installed) can run. The editor will load and can probably be used, but there will be issues as it tries to use jQuery methods which are not there. Even so, this patch remains backwards compatible with the older WYMeditor versions so I pushed it to the D6 branch to keep it in sync.

Status: Fixed » Closed (fixed)

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