Instructions on /admin/config/content/wysiwyg:

CKEditor (Download) => http://ckeditor.com/download

Extract the archive and copy its contents into a new folder in the following location:
sites/all/libraries/ckeditor

So the actual library can be found at:
sites/all/libraries/ckeditor/ckeditor.js

Many people will go and download the Drupal Version on http://ckeditor.com/download. = Fail

Add notice to download the Non-Drupal Version on http://ckeditor.com/download

Comments

I was having a problem with chkeditor (I got an error message when I tried to upload images into an article) so I tried the above suggestion.

I unchecked chkeditor in my modules admin page
I removed the chkeditor and downloaded and unzipped the plain vanilla (not drupal) version.
I moved the directory from sites/all/modules to under a sites/all/libraries folder - I had to create 'libraries' because it was not there.

I now have no chkeditor function and it does not show up under modules.

I don't think these instructions are correct!

Frank

@FColosimo

I unchecked chkeditor in my modules admin page

I now have no chkeditor function and it does not show up under modules.

If it showed up under Modules, you are not using Wysiwyg module, you are using the separate CKEditor module. If you are using both that module and Wysiwyg module, remove one of them and create a new issue for the module you keep - also include the error message if it comes back. The modules are not compatible.

I got an error message when I tried to upload images into an article

If you had installed the currently unsupported "Drupal Version" of CKEditor in sites/all/libraries, Wysiwyg module would not have been able to recognize and load it at all. If you decide to keep Wysiwyg module instead of CKEditor module, you need to put the CKEditor library into sites/all/modules just like you did.

@thomasvum
CKEditor's "Drupal Version" has a couple of new Drupal-specific plugins we'd need to support for that variant to be useful. But it should not be too hard to make Wysiwyg at least recognize it.
To complicate things a bit, that variant also includes the whole CKEditor module. If the package is extracted to sites/all/libraries there should be no risk of conflicts with Wysiwg, as Drupal won't pick up the module, but it's easy to get that wrong.

Thanks for the reply. I was not using WYSIWG, as far as I know. I was working only with the ckedit modules, and I think that I now understand what you are saying.

Anyway, I completely removed Drupal from my server, created a fresh DB, and reinstalled only ckedit. It shows the same error so I will open a new ticket on that.

All I am trying to do is to get an upgrade from the plain editor that comes with Drupal. I wish there was a simple-to-install editor upgrade but my searches showed only VERY old editors, or ones not supported by v7, or ckedit (which I can't get to work). We should close this ticket, but if you a suggestion for a newbie on how to get a rich text editor into D7, I would appreciate it.

thanks much,
Frank

@FColosimo, thomasvum's feature request has not yet been dealt with so I will not close the issue yet.

Well, it is pretty easy to install Wysiwyg module (or CKEditor module for that matter), download/extract a supported editor librari as per the module instructions and configure them for your needs. You just have to remember that the installation/configuration instructions for the Drupal module you're using "outweigh" those in the editor package, mostly because the module does a lot of the code integration for you and automate certain steps. We (the Wysiwyg module maintainers) also strive to let users keep both Wysiwyg module's code - and that of the editor libraries - intact to ease upgrades. For that reason we've for example changed how editor settings can be manually set. Where using just the CKEditor library (or the CKEditor library with the CKEditor Drupal integration module) make you edit a JavaScript file residing inside the editor library to put your own settings in, we've created a GUI in Wysiwyg module to override some of them and added the code hook hook_wysiwyg_editor_settings_alter() to let a small custom Drupal module override the rest. It may seem like an additional step to write a small Drupal module to permanently override some settings, but it'll actually save you time when a new version of Wysiwyg or the editor library is released.

That also ties in with this feature request in a way. Since we try to let users avoid file modifications, we've must keep even steps with the editor libraries and add meta-data to Wysiwyg about each button and plugin they have - or Wysiwyg wouldn't be able to activate them from the GUI. Adding that meta-data for the "Drupal Version" of the CKEditor library is what this issue is about, but nobody's had the time to dig into it yet.

I did not understand the relationship between WYSIWYG and ckeditor. When I installed WYSIWYG and put ckeditor in the libraries directory, it all worked just as you suggested.
Thanks much for the explanation and help!

Frank

Title:Notice to download ckeditor NOT the drupal ckeditor VersionAutodetect library variants
Component:Documentation» Code
Status:Active» Needs review
StatusFileSize
new41.27 KB

I'm re-purposing this issue a bit. It annoyed me that we should have to avoid a specific variant of an editor library, one that even states that it's compatible with Drupal. So I decided to do something more than add a notice.

Problem 1: Figure out which files are available.
An editor library can come in different "shapes" depending on the environment in which it's to be used. The most common are a "standard" variant for production use. It's often minimized to not waste bandwidth, but difficult to step through in a debugger. That leads to the "source" variant, most often uncompressed code spread across several files. Then there's perhaps a "debug/development" variant, giving you an abundance of console messages and assertions, at the cost of performance.

I've tried to solve this by letting each editor implementation with known variants scan its folder and return an array with the names of discovered variants. This array gets stored in $editor['installed variants'] when an editor is loaded.

Problem 2: Figure out which version is installed.
Not all of the library variants include a version string, making it impossible to guess which version we've found. We can't reliably determine if our meta-data for the editor and its plugins can be used.

Some libraries have a changelog.txt or similar bundled with all their variants. I've tried to rely on it instead where possible, which should simplify the detection code and make it more robust. Otherwise, it falls back to fetching version info from another installed variant. (Most "source" and "debug" variants often come bundled with a minified variant which does include a version string.) We also don't support modifying library packages, meaning these files _should_ be there unless one is experimenting.

(@todo Determine if it's reasonably safe to assume we're dealing with the very latest version if none was found - our version detection code can get out of date, as has happened before.)

Problem 3: Which variant do we use?
It's often preferable to use a minified variant by default, as most users will simply want to drop it in and have the best performance. If they are developing plugins or otherwise debugging, they are capable of determining when a different variant is preferable to use.

If the editor profile does not explicitly specify a variant to use, I've made it use the first variant listed as installed, and then the first listed variant. This means a "debug/development" variant could theoretically be picked in a production environment if no other variant is detected.

#862100: Allow to configure the library/execMode to use will let you specify a preferred version when saving the editor profile, but the code here will still use a fallback if that variant isn't installed. TBD is how to sync this value between profiles - we can't load two variants on one page or all hell will break loose.

Problem 4: Some variants are packaged in subfolders.
As noted above, CKEditor's "Drupal version" puts everything related to the CKEditor library in a subfolder, effectively shifting everything down one level. Every path for loading internal plugins/skins etc now needs to have '/ckeditor' before it.

We've previously had two properties of the $editor meta-data array which point to the installed library. These have been used interchangeably at some points, and they've meant different things at some other points.
I've decided to let $editor['library path'] always point to the main folder where the library is installed. Ie, it can be "sites/default/libraries/tinymce", "sites/sitename/libraries/tinymce", "profiles/myprofile/libraries/tinymce" or "sites/all/libraries/tinymce", but never "sites/default/libraries/tinymce/jscripts/tiny_mce".

That's where $editor['editor path'] comes in. It points to [a subfolder of 'library path'] where the main script files are located. Most often, everything below this folder is the same regardless of which editor variant is loaded.
Variants can add a path suffix using the 'editor path' (final name TBD) in their 'libraries' section which automatically sets $editor['editor path'] = $editor['library path'] . $editor['variants'][$variant]['editor path'] when a library is loaded. (Note: the editor is not yet "loaded" when the theme callback runs, so it can't use this value, but $editor['installed variants'] is populated.

Problem 5: New versions add or remove variants or variants are completely separate packages.
I've put variant detection together with version detection to leave the decision up to the implementation. Since variant and version lookups happen in the same callback, it's easy to skip/add variants depending on the detected version, or the other way around. This is important for CKEditor because detecting it's "Drupal version" variants means we have to exclude the "regular" variants.
If both the "Drupal version" variants, and the "regular" variant were listed as installed, it would be difficult to determine which folder to actually load the files from. We currently try to detect the available themes/skins without having access to the editor profile (which would hold the actual variant to be loaded), so we need to make this decision based on the available folders alone.

NOTE: This patch does NOT add a GUI to pick a variant you'd prefer! I leave that to be followed up in #862100: Allow to configure the library/execMode to use.
We'll also need to consider variants with external dependencies, something which should be possible to detect as well. See #276465: Add support for TinyMCE gzip compressor.

This patch adds auto-detection of variants for CKEditor, TinyMCE, YUI Editor and WYMeditor. Those were the ones I could find variants for now. It also adds meta-data for a couple of "Drupal version"-specific plugins for CKEditor.

Big patch, I know, but it felt best to do this in one sweep to know it's working.
Tested with TinyMCE 2.x and 3.x, CKEditor 3.x, latest YUI and WYMeditor and all their variants except for g-zipped TinyMCE which needs the patches mentioned above.

mmm, I'm not sure about this. - actually I'm against this. :-/

The "Drupal download" of CKEditor is not a variant for Drupal, it is the complete Drupal CKEditor module, additionally having the CKEditor editor library bundled within. Providing such a download is wrong in itself for a multitude of reasons. I don't understand why CKEditor did this.

But anyway, I don't think we can or want to support that special download.

That said, the variant detection changes are a good idea. However, we need to coordinate this with Libraries API, as there's quite some code for variant handling in it already (and the variant issue applies to any kind of front-end library in Drupal). So I don't think it's a good idea to diverge Wysiwyg's code even further -- instead, I think we should replace our own code and integrate with Libraries API instead (which most likely requires to open up 7.x-3.x).

Heh, was expecting a response to that effect. ;)

I don't understand why CKEeditor did this either. As I noted before, it causes a great deal of confusion. But people are going to instinctively download that package because it has the Drupal label and try to use it with Wysiwyg. And they're not going to blame ckeditor.module when wysiwyg.module doesn't recognize it. People find this whole "wysiwyg.module" vs CKEditor vs "ckeditor.module" vs "WTF!" thing hard enough as it is. So I thought we could at least make the "ok, you didn't get it quite right, but the lib is at least there"-situation more transparent to the user. The lib's there, we've got an extra module doing nothing, but it won't hurt anyone, and disk space is cheap...

Ok, it's not a real variant since the library code is identical, but it does bundle a few plugins we can "borrow", and it's not that difficult to detect it anyway. If you don't want to support it, that's ok by me, but we're going to have to add that notice somewhere. Perhaps we need to let implementations amend /alter the installation instructions to be able to make these things clear?

If we can use Libraries API for this, we should of course do that. I did not know it had matured enough where we could seriously begin integrating with it, but I admit I haven't follow it closely for some time. Bringing in a dependency like that will be too big for a minor version, yes. Perhaps time to bring in something more as well if we need it?

Wysiwyg 2.x could still benefit from a patch like this though. If not only because it makes debugging easier than if we have to hack Wysiwyg to switch library variants.

Time for me to read up on Libs API...

yeah. To that extent, I'd be ok with adding a (ugly) hook_EDITOR_install_note() callback hack and implementing a wysiwyg_ckeditor_install_note() to that effect, stating "Do NOT download the 'CKEditor for Drupal' edition."

Title:Autodetect library variantsAllow editors to add install notes.
StatusFileSize
new1.49 KB
new1.13 KB

Did you mean an actual [pseudo-]hook or a callback?]

Title:Allow editors to add install notes.Allow editors to expose install notes (and clarify CKEditor library download)
Version:7.x-2.1» 7.x-2.x-dev
Issue tags:+Needs backport to 6.x

oh, yeah, the callback variant. Thanks for showcasing both! ;)

Looks RTBC to me (if it works), after quickly adding 'install note callback' to wysiwyg.api.php.

Only minor thing I'm not sure about is the (lack of) wrapping HTML; i.e., the other instruction lines are output in paragraphs, but wrapping the callback return in a paragraph might be bogus. Perhaps best to call the install note callback and then wrap the result in a DIV.editor-install-note (perhaps even .warning or .info - AFAIK, D7 automatically applies some fancy styling for those).

Status:Needs review» Needs work
StatusFileSize
new1.61 KB

Oops, forgot the p wrapper... but yes, it works.
Hmm, we can't be sure whether the message will be a warning or just some information so maybe we should leave that to the implementation? A DIV.editor-install-note sounds nice so I added it, but also putting .warning on there gave it a repeated yellow-triangle background, so I put it on the p instead.

Umm, not sure where to add it in wysiwyg.api.php. #900220: How to integrate a new editor needs to get in first.

Status:Needs work» Needs review

StatusFileSize
new26.73 KB

So this is what it looks like:

wysiwyg-install.png

Yep, that's it.
Likes/dislikes/comments?

I like #14 very, very much. I've done about 10 ckeditor installs over the years, and I ALWAYS forget, screw it up and download the drupal edition of ckeditor rather than plain version. The simple addition of "Do not download the drupal edtion of ckeditor.." would be most welcomed!

Status:Needs review» Reviewed & tested by the community

ok, I guess this is fine. Still not sure about the actual markup and styling (playing with the idea of adding .warning also to the wrapping DIV, so the install note appears like a warning message [including icon])... but I guess we can figure that out later and see how it goes. It's more important fix the installation instructions for users right now.

Status:Reviewed & tested by the community» Fixed
Issue tags:-Needs backport to 6.x

When I did that, the div got the icon background, but repeated, as I noted in #12, so we probably need more complex markup or custom styling for it.

Anyway, comitted this to D5, D6 and D7. The -dev snapshots will be updated within 12hrs and this improvement will be part of the next releases.

Note: The #12 patch had some line-ending issues, had to use apply -p1 instead of git apply.

Status:Fixed» Closed (fixed)

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