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.Problem/Motivation
This module now ships with a custom skin path setting. But that setting's not optional, at least with local versions of the editor library.
When updating from 7.x-1.19 to a newer version (1.20 or 1.21), the setting is empty, so no matter what the skin is set to on admin/config/content/ckeditor/editg, the skin won't load anymore, until the path is explicitly set ($form['ckeditor_advanced_settings']['skins_path']).
This is a bit puzzling for admins.
Steps to reproduce
Use a local CKEditor version (in sites/all/libraries)
Update from 7.x-1.19 to a newer version
The skin is where it was before, it ships with the library beneath sites/all/libraries/ckeditor/skins/moono
Moono is also the setting on admin/config/content/ckeditor/editg
It's the latest version of CKEditor (4.16.2).
Proposed resolution
Per #3230470-9: After updating to 7.x-1.20+ skin path setting is required, a proposed solution might entail:
1) Populate default value if field is blank to match library location
2) Update hook for upgrading from 7.x-1.19 or older
3) Document breaking changes in project page / release notes for version
4) Test new changes against multiple configurations / don't include breaking changes in regular releases.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | ckeditor-d7-kama-4-17-1-fails.jpg | 82.47 KB | izmeez |
| #15 | ckeditor-global-profile-skins-path-set-screenshot.png | 140.93 KB | izmeez |
| #15 | ckeditor-global-profile-skins-path-default-none.png | 128.72 KB | izmeez |
| #15 | ckeditor-skin-selection.jpg | 14 KB | izmeez |
| #15 | ckeditor-global-profile-edit-screenshot.png | 135.54 KB | izmeez |
Comments
Comment #2
indigoxela CreditAttribution: indigoxela commentedComment #3
indigoxela CreditAttribution: indigoxela commentedComment #4
WebbehI suppose this might be caused by https://git.drupalcode.org/project/ckeditor/-/commit/92b3637c20d7400142a... and #2671806: Add custom skin support.
Should this be an update_hook based on what the CKEditor plugin library setting is to determine and set the skin location if it is null? Or, should the module provide a workable default value (that is derived from said library setting)?
Comment #5
indigoxela CreditAttribution: indigoxela commentedWhatever's feasible. ;-)
As there's a user interface for that value, maybe an update hook makes sense?
But people are probably happy with anything, that works.
Comment #6
indigoxela CreditAttribution: indigoxela commentedSeems like I forgot the most obvious: describe what to do when the editor initializes, but looks as messed as in my screenshot:
In my case it's
%l/ckeditor/skins, as my editor library is locally installed under /sites/all/librariesComment #7
indigoxela CreditAttribution: indigoxela commentedComment #8
indigoxela CreditAttribution: indigoxela commentedSome more details:
Out of curiosity I created a new CKEditor4 build (using my build-config.js), but switched the theme in that build to moono-lisa.
After flushing caches, the editor worked with module version 7.x-1.21. Without an additional theme path setting.
So the main glitch is the assumption that local CKEditor libraries always ship with the default skin. The actual skin setting on /admin/config/content/ckeditor/editg gets ignored and actually overwritten. Which IMO is not as intended.
Comment #9
omarsidd CreditAttribution: omarsidd commentedConfirming this still exists with 7.x-1.22 and ckeditor library 4.17.1. Thanks to OP for reporting.
Adding a new required config field and not populating it (or putting it obviously in the docs) isn't a great idea, much less for a module this popular. Suggest:
1) Populate default value if field is blank to match library location
2) Update hook for upgrading from 7.x-1.19 or older
3) Document breaking changes in project page / release notes for version
4) Test new changes against multiple configurations / don't include breaking changes in regular releases.
Comment #10
WebMetod CreditAttribution: WebMetod commentedHello. I cannot get this module to work since the release of ckeditor 7.x-1.20, and for this reason I still keep 7.x-1.19 on all my projects. I created dozens of sites with the ckeditor module and never had to configure anything in the global profile - it just worked!
Where can I read what exactly has changed since 7.x-1.19 and how to configure the latest versions?
Comment #11
WebbehComment #6 should help describe how to implement this.
Per #10, can you describe why 1.20 isn't working. What's not appearing as you would expect? Does the solution outlined in #6 fix it for you?
Comment #12
indigoxela CreditAttribution: indigoxela commentedSorry to hear that. If you're struggling with the problem (using a non-default skin from a former build):
In the Global settings on /admin/config/content/ckeditor, section "CKEditor skins" set the path to
%l/ckeditor/skins. That should do the trick. If not, inspect your browser console for additional nagging.Alternatively switch the skin your build (CKEditor library) uses to Moono-lisa - then no settings need to get updated:
Grab the file
build-config.jsfrom /sites/all/libraries/ckeditor/ and uploaded it here: https://ckeditor.com/cke4/builder (hit button "Upload build-config.js")Switch the skin to Moono-lisa, leave everything else untouched, download that build and replace the library on your sites.
Why build-config.js? Maybe you didn't, but I did some customized builds in the past and don't remember on which sites. So I'm using that file to get exactly the same plugins/languages again with a newer CKEditor (library) release.
Either of these approaches should work.
Comment #13
izmeez CreditAttribution: izmeez commentedI think the problem is with the change to the skin path. As I recall if you simply go to the ckeditor config
admin/config/content/ckeditorand select the profiles and save it will revert to the default skin and should work. You can then look at changes needed for a different skin. It is interesting to note that older Drupal 6 sites include a warning with a link to the profiles and each of them may need to be opened and saved.Comment #14
keha3912 CreditAttribution: keha3912 commentedAdding %l/ckeditor/skins in /admin/config/content/ckeditor/editg really me helpfull )
After that all my skins are correctly read from sites/all/libraries/ckeditor/skins
Comment #15
izmeez CreditAttribution: izmeez commentedThere are actually several problems related to the skins.
First, on the global profile, there is the lack of a path to the skins. While the path to the skins is empty the select box will incorrectly show previous skins and the new default as available when they really are not.
Once the skins path is set and saved , the selections will accurately show the skins that are available.
Another, possibly related, issue that surprised me was that downloading new skins kama-4.17.1 and moono-4.17.1 and placing them in the skins directory then enabling them failed to load icon images as below:
Comment #16
Patricia_W CreditAttribution: Patricia_W commentedPossibly I am not understanding this discussion but I was able to fix it (to my satisfaction) by downloading the moono skin to the skins directory.
Comment #17
nagy.balint CreditAttribution: nagy.balint at Agence Inovae commentedI can confirm the issue, setting the path like on #12 worked to fix it.
Comment #18
v.kydyba CreditAttribution: v.kydyba as a volunteer and at Drupal Ukraine Community commentedA #12 solution works for me as well.