We recently transferred an application from a server with CF11 with FCKeditor 2.6.4 to CF 2018 with CKeditor 4.
Everything seems to be perfect except for one thing. When we load content in CKeditor it erases certain styles such as table cell borders. And if I try to reenter the deleted styles in the source, as soon as a swith back to the wysiwyg view, styles are erased. Very annoying.
Is there a filter activated somewhere that filters certain styles? Something I could change in a config file. Or is it simply a bug. Any ideas ?
Also when I right-click in a table cell in ckeditor, the contextual menu only offers the “table properties” option and not the “cell, row and column” options.
I really need help. Thank you in advance.
Ran into a similar issue with my CF 2018 fully patched (Update 7) server. (On my dev Mac & prod Windows server).
Google Dev tools showed failure to load: /cf_scripts/scripts/ajax/ckeditor/skins/moono/editor.css?t=I63C
The quick fix was to back up the ‘moono’ folder, duplicate and rename the ‘moono-lisa’ to ‘moono’. I’m surprised this wasn’t picked up adobe yet, it’s 2020.
Hi, Yaron (and very long time, no talk).
About this, did it happen upon doing an update *OF* cf2018? From what update? Or was it a move *TO* CF2018, like Francois had reported?
And either way, is it the same kind of specific action as he reported here, that leads to the error you see? Or is it a request for *any* page using cftextarea?
Or is it perhaps your *own* use of ckeditor? If so, what version?
I’m trying to help narrow down why Adobe might not have” picked up on this” before now, as you said.
For what it’s worth, this is still happening. For me the editor doesn’t show up at all because the .css file isn’t in the moono folder. Downloaded a fresh version of 2018. Installed patches, 4,8,10. The editor is looking in the wrong folder. Renaming works.
What also works is setting the property of the cftextarea: skin=”moono-lisa”. That way we don’t have to change the folders on all our environments.
Seems that at some point the default changed to just ‘moono’ but the moono folder is mostly empty.
I can do that. Also turns out 2016 has moono as the default, so the default hasn’t changed. The moono-lisa skin also exists on 2016. So in 2018 the plugin is missing whatever is in the moono folder.
Great. Thanks, Joey, not only for the bug report but the extra detail. With that, I was able to confirm the problem more easily, and I have added a vote. Hope others will, and that Adobe will resolve it.
Sad to think that somehow this wouldn’t have gotten caught in some sort of UI testing when Adobe builds CF.
I would also be curious to know when it started. As I look at my install of CF2018 on Windows, I don’t see the moono files having been backed up in any of the updates applied. That doesn’t MEAN they weren’t removed by an update, though it SHOULD confirm that.
Perhaps more interesting, I can confirm that in the Docker images for CF 2018, even back to the very first release, the moono folder DOES have the files in there, which may suggest that this is a Windows-only problem. I don’t have ready access to my machine with a Linux install of CF to check.
(And for those not familiar with Docker or the Adobe CF Docker images, they are in fact Linux-based, even if you run them via Docker Desktop on Windows.) For any who may want to see it themselves, you can see it readily with this single line, which will start a container, show the contents of the folder, and terminate (and remove) the container:
docker run –rm -e acceptEULA=YES eaps-docker-coldfusion.bintray.io/cf/coldfusion:2018.0.0 ls ../wwwroot/cf_scripts/scripts/ajax/ckeditor/skins/moono
Of course, if you have never pulled down that the image with that 2018.0.0 tag, then you will have to wait the download (of several hundreds megs–whose size is due to be reduced significantly in CF2020).
Thanks for your reply. All files required for the editor are transferred except one (tableCell.js) which could explain why table cell properties are not available. I have to investigate.
As for the styles being deleted, it appears that the Advanced Content Filter introduced in 4.1 could be the source of my problem. Probably certain Disallowed Rules are implemented by default. I was able to solve my problem by adding in the config.js file the folowing line of code:
config.allowedContent = true;
You must be logged in to post a comment.