Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#11 | wysiwyg.wymeditor-1.2273635.11.patch | 8.69 KB | TwoD |
Comments
Comment #1
jfhovinne CreditAttribution: jfhovinne commentedThe '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.
Comment #2
TwoDThanks!
I'll check this out soon (at work now), but I just noticed this change:
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?
Comment #3
jfhovinne CreditAttribution: jfhovinne commentedYes, 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 ?Comment #4
TwoDIt should probably be
'js files' => array('skins/compact/skin.css')
, not verified that yet though.Comment #5
jfhovinne CreditAttribution: jfhovinne commentedHere is the updated patch (using git format-patch).
Editing seems to work flawlessly.
Comment #6
bubuUpgrade patch to current WYMeditor 1.1.1
Comment #7
TwoDA 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.
Comment #8
TwoDComment #9
TwoDWrong way around...
Comment #10
bubu@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.
Comment #11
TwoDWow, 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...
Comment #12
bubu@TwoD, thanks for you persistence! Yes, this last patch works as expected. I think, feature is done, you can commit this patch.
Comment #14
TwoDThis 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.