Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I have a problem, when using wysiwyg with the newest ckeditor on site which resides on my local computer new skin 'kama' is loaded as it should be, but when using the same two mentioned above on my live site, skin that is loaded is 'v2' and in order to display the same 'kama' skin i have to delete the 'v2' skin. Does anyone know why is this occuring?
Comment | File | Size | Author |
---|---|---|---|
#29 | wysiwyg-DRUPAL-6--2.skin-sorting.737318.29.patch | 380 bytes | TwoD |
#19 | wysiwyg_ckeditor_themes-sort.patch | 544 bytes | dboune |
#19 | wysiwyg_ckeditor_themes-natcasesort.patch | 551 bytes | dboune |
Comments
Comment #1
TPerkins CreditAttribution: TPerkins commentedI am having the same problem.
On the local copy of my site, it loads up Kama, and works great. On the live site, it uses Office 2003 and has a couple display issues.
Comment #2
TwoDThat's odd, it should always use kama now as we don't have GUI code in to override that with a user selected skin/theme yet. It is possible that it will use another skin if you have previously tested a patch which allows you to change the default value and then reverted that patch without removing and recreating the editor profile as the old setting would still be stored in the database. Wysiwyg will also try to load a different skin/theme if the selected one is not available (folder can't be found).
Does the value of
Drupal.settings.wysiwyg.configs.format#.skin
match the skin actually being used? (It should be 'kama'). If not, could you check which skin/theme value is stored in the wysiwyg table and see if that is the same? (The settings are a serialized array) If it says 'kama' in the database but something different inDrupal.settings.wysiwyg.configs.format#.skin
, Wysiwyg is probably overriding the value because it can't find the skin folder.Try removing the editor library and uploading a 'fresh' version. If that doesn't help, try removing the editor profile and recreate it.
I'll see if I can reproduce this when I get home.
Comment #3
Kirk CreditAttribution: Kirk commentedI am having the same issue. I installed WYSIWYG on a new site, installed the CKEditor library and get the "Office 2003" skin. This is what is in the DB table.
If I delete the 'office 2003' skin, it works with Kama, as expected.
WYSIWYG 2.1
CKEditor 3.2
Comment #4
2id CreditAttribution: 2id commentedBefore ck editor i was using fck editor with the default theme and i did't use a patch to try to change that. In database there is nothing about which theme is being used as in the post above. I don't know where to find Drupal.settings.wysiwyg.configs.format#.skin so i can check the value.
Comment #5
TwoDIf you're using Firefox, install the Firebug extension. Then go to a page where the editor appears. Click the bug-icon to the right of the statusbar to bring up Firebug and switch to its DOM tab. There you can browse the Document Object Model representing the markup elements and all global JavaScript objects like a tree. Open Drupal->settings->wysiwyg->configs->editorName (I missed this above)->format# (where # is the format the editor is used on) and look at the value of the skin property. This should be set by Wysiwyg to one of the available skins (kama to be exact).
Do this without modifying the ckeditor files and then do it again after removing the 'offending' skin's folder.
Comment #6
2id CreditAttribution: 2id commentedWith v2 skin folder:
skin "v2"
theme "default"
Without v2 skin folder:
skin "kama"
theme "default"
Comment #7
penguin25 CreditAttribution: penguin25 commentedI also have the same problem: I get the v2 skin on my live site, and kama on my development site.
Checking Drupal->settings->wysiwyg->configs->editorName->format# shows both sites have a theme of "default", and a skin that matches the one that is being used.
Looking in the database at the wysiwyg table, both sites had 's:5:"theme";s:8:"advanced";' in the middle of their settings for the input format in question. I tried chaging s:8:"advanced" to s:7:"default", which had no effect. I then changed it to s:4:"kama", which fixed the problem, and kama is now used on both sites.
It's worth noting that my live site and development site are on two different servers - they aren't just different copies of the site on the same server, so is it possible there could be different settings on the server itself that are affecting things, rather than a Drupal/Wysiwyg/CKEditor configuration? How does Wysiwyg/CKEditor decide which skin is the "default"?
Am changing the status of this issue from "maintainer needs more info" to "active" again - apologies if this is the wrong thing to do.
Comment #8
m.stentaI am also experiencing this. With WYSIWYG 2.1 and CKeditor 3.2.1.5372, the skin that is used is office2003.
penguin25's comment #7 worked to change it back to 'kama' for me (changing s:8:"advanced" to s:4:"kama"). Not sure this is the right way to do it, because it seems that the "theme" setting is different than the "skin" setting. My guess is that this change is simply confusing the WYSIWYG module into going back to the default skin. Not sure though... a more deliberate fix would be preferred.
If you need more info about my setup, let me know what info would be helpful.
Comment #9
robbertnl CreditAttribution: robbertnl commentedSame problem, default is v2 skin.
Changed using mysql: UPDATE wysiwyg SET settings = REPLACE(settings, 's:8:"advanced"', 's:4:"kama"') WHERE editor = 'ckeditor';
Using latest version of ckeditor and wysiwyg.
Comment #10
TwoDDon't run that SQL code if you have TinyMCE enabled, or it'll break. A
WHERE editor = 'ckeditor'
condition probably helps. ;)Yes, Themes and Skins are very different things. The Theme is something we don't want to change as it often changes how toolbars etc are defined so we'd need to duplicate much of the logic in Wysiwyg for each Theme. Skins are much more "light weight" changes to the visual appearance of the editor, like the color scheme, though this is usually what people think of when you say theme.
Wysiwyg's internals don't [yet] account for this distinction so in the case of CKEditor, we use the 'theme' settings to store the value of the selected skin. By default, wysiwyg.admin.inc sets this to "advanced", but this should be overridden once Wysiwyg is able to list the contents of the ckeditor/skins folder (again, this is done in the callback actually meant for themes) and should be set to "kama" as this would be the first skin encountered.
Wysiwyg doesn't put a meaning to the value "default" when it comes to themes/skins, but if the editor supports it, that's what Wysiwyg should fall back to if all else fails. In the case of CKEditor, "default" is the only actual theme available in the ckeditor/themes folder, so we always hardcode that value.
CKEditor doesn't accept the value "default" for skins, but has "kama" as its default instead. As Wysiwyg always sets the "skin" setting, we also default to "kama" when no other skins are found. Note that our CKEditor implementation currently scans the ckeditor/skins folder and uses the first skin it finds, which should be kama. The only time "v2" or "office2003" should be used is if kama isn't encountered first. (If no folders are found, "kama" is still used as a value.)
Why Wysiwyg's default theme value "advanced" is not overridden, I don't know yet, but thanks to all the info you guys provided above I can probably figure it out.
Sounds confusing? It is, and we really need to clean this up and account for the Skin/Theme differences. But we don't want to add much more to the profile configuration before we can customize it for each editor, or we'd get more problems with editors that don't support skins or themes at all, but the options would still show on their profiles.
I think a big part this should be resolved when #414496: Allow to select editor theme/skin gets fixed. For the editors supporting them, we need to think of Skins as Themes for while longer until #313497: Allow configuration of advanced editor settings gets in as well.
Comment #11
a_c_m CreditAttribution: a_c_m commentedCan confirm this issue, and that rm'ing the v2 dir sorts it out short term. Tempted to push this to critical, as it renders the editor unusable till you do the work around.
Comment #12
Daniel Wentsch CreditAttribution: Daniel Wentsch commentedSubcribing.
Had the same problem after moving from dev to live server.
After deleting the office2003 skin folder everything works on the live machine as it already did previously on the dev machine. Strange behaviour, as nothing was changed while going live, neither files nor database.
Comment #13
shake-and-bake CreditAttribution: shake-and-bake commentedHaving the same issue, I believe it might have something to do with the WYSIWYG module. I'm running a Drupal site without the WYSIWYG module and the karma skin appeared on default. But today I created a new Drupal install and loaded CKeditior using the WYSIWYG module and no pretty karma skin, only the ugly office 2003 skin.
Comment #14
iantresman CreditAttribution: iantresman commentedJust looking at my installation online, and comparing with the CKeditor Demo page, I have the Office 2003 skin showing.
My libraries/ckeditor/skins folders shows all three skins present, with the same data and time stamp, and changing the date/time seems to have no effect.
Comment #15
leoklein CreditAttribution: leoklein commentedSubscribing
Comment #16
mpaler CreditAttribution: mpaler commentedto get the kama skin to display I put the following in a custom module. Added bonus is the setting to set the color of the Kama UI.
Comment #17
weri CreditAttribution: weri commentedWe have the same problem:
The problem is the sort order from the skins in the array (function wysiwyg_ckeditor_themes in 'modules/wysiwyg/editors/ckeditor.inc'). The php function 'opendir' or 'readdir' returns a different sort order on the dev or live server!
One solution: Delete the other skin directories
Set the Skin on alter: #16
Or it is possible to change the sort order from the php function or the underlying system?
Comment #18
TwoDThank you for that information, weri! It prompted me to look up readdir() again, this time determined to actually read what it says:
Different filesystems = different sort order...
How about going via scandir() etc instead?
A comment says scandir can't handle non-english characters in folder names due to Unicode not being supported before PHP 6, but I can't find whether readdir is having the same issue. I doubt it'll do much difference for our use case though as libraries tend to stick to ASCII in their 'machine' names.
Comment #19
dboune CreditAttribution: dboune commentedI'm not sure where wysiwyg stands on PHP4 compatibility since I don't use PHP4 myself. It is notable that scandir is only available since PHP5. Neither scandir nor readdir fully support unicode file names at this time, and it's not likely we'll see that in php for quite some time to come.
A simple sort restores the expected result of returning kama as the default theme, will support php4, and will provide a nice sorted menu later for a UI.
Commented code in tinymce.inc performs an asort which is still incorrect here since asort maintains index associations.
wysiwig.module selects index [0] if the "selected" theme doesn't exist, which would still hold the same value as before the asort. The $selected_theme defaults to "advanced" which doesn't exist for ckeditor and so index [0] is chosen.
Here are a set of working patches for ckeditor.inc, one using sort, and one using natcasesort. I like natcasesort myself.
Comment #20
lee20 CreditAttribution: lee20 commentedSubscribing.
The "sort" patch from #19 worked for me. The "natcasesort" patch did not.
Comment #21
TwoDI had the same experience as in #20.
natcasesort will also maintain index associations, but regular sort will do fine, for now at least.
It's a simple solution, though it'll have to be done for each editor. I don't think that's much of a problem as each editor implementation is responsible for making sure the first value is a valid fallback anyway. Editor libraries are currently expected to be all lowercase letters so we shouldn't see any "A-Z then a-z"-issues either.
UPDATE: We could probably use natcasesort if we also do a array_values to reindex the array. I like natural sorting as well, so if there aren't any objections I'll add reindexing to that patch. and use it instead
Comment #22
paganwinter CreditAttribution: paganwinter commentedSubscribing...
Comment #23
xandeadx CreditAttribution: xandeadx commentedSubscribing
Comment #24
jfine CreditAttribution: jfine commentedSubscribing.
Comment #25
sunThanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #27
ericbroder CreditAttribution: ericbroder commented"Delete the other skin directories" from comment #17 works for me on Wysiwyg 6.x-2.1. I'm glad we found a better solution.
Comment #28
ericbroder CreditAttribution: ericbroder commentedComment #29
TwoDThis issue still exists: #1020714: Skin broken after 1:1 copy of site.
The previous patch was missing the
array_values()
call mentioned in #21 so the array was never re-indexed.Fixed with the attached patch.
Thanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #30
John Pitcairn CreditAttribution: John Pitcairn commentedI'm using the 3rd-party "chris" skin from http://www.chrisherberte.com/blog/ckeditor-skin, loading it from module code:
I'd like to keep 3rd-party skin folders outside the ckeditor folder, so ckeditor updates don't delete it. Is there any way I can specify the path to a skin from wysiwyg_editor_settings_alter(), to avoid editing config.js or anything else inside the ckeditor distribution folder?
Comment #31
TwoDYes, you can do that, see the CKEditor config documentation for the syntax to seelect an external skin.
Comment #32
John Pitcairn CreditAttribution: John Pitcairn commentedBad link there.
Yeah, I've seen that. I've tried it as several variations of:
Didn't work. Looking for an actual example I guess.
Comment #33
TwoDFixed the link, thanks.
That should work (though $context is not passed by reference), have you checked with Firebug for Firefox or a similar tool to see which path is actually loaded? This should not be an internal path but an absolute "external/public" path as seen from the browser's perspective.
Comment #34
John Pitcairn CreditAttribution: John Pitcairn commentedI can't give it a full path with domain, the site gets moved between development/deployment fairly often. I was giving it the absolute path from root, ie:
No good. I'll investigate further with Firebug.
Comment #35
TwoDTested this with:
sites/default/modules/custom/custom.info:
sites/default/modules/custom/custom.module:
Set up the skin with this:
The skin worked nicely but some things are still missing, like an icon for the new iFrame plugin in 3.5.
Comment #36
John Pitcairn CreditAttribution: John Pitcairn commentedWell, yeah, that's exactly what I had. The other day it didn't work ... today it does. Weird.
Definitely some missing icons, mostly for stuff I neither want nor need however. It's a nice skin, integrates well with the Rubik theme for editing/admin.
Comment #37
bryancasler CreditAttribution: bryancasler commentedThanks TwoD! I had to make some changes to your code to get it working.
sites/default/modules/ckeditor_skin_switcher/ckeditor_skin_switcher.info:
sites/default/modules/ckeditor_skin_switcher/ckeditor_skin_switcher.module:
Comment #38
John Pitcairn CreditAttribution: John Pitcairn commented@animelion: the whole point of this code was to be able to store new skins outside the ckeditor directory, so that when you update ckeditor you don't delete your 3rd-party skins. If all you want is to activate a skin that is inside the default ckeditor skins directory, you just need:
Comment #39
bryancasler CreditAttribution: bryancasler commentedThanks johnpitcairn, great point
Comment #40
jrsinclair CreditAttribution: jrsinclair commentedI had the same issue with incorrect theme/skin on our production server with D7. Can confirm that upgrading to latest dev version (7.x-2.x-dev, 2011-Feb-25) of WYSIWYG fixed the issue.
Comment #41
lifepillar CreditAttribution: lifepillar commentedReplying to #32: the path should start with / and it should be relative to the web document root. So, the following works for me:
(wysiwyg_custom is a small module I've made to keep my Wysiwyg tweaks and in which I've put the chris folder). Using the above syntax, migrations should not be a problem, as long as Drupal is always installed at the document root.