Follow up to #1890502: WYSIWYG: Add CKEditor module to core.
The PHPDoc of hook_ckeditor_css_alter() currently says:
* Front-end themes (and base themes) can easily specify CSS files to be used in
* iframe instances of CKEditor through an entry in their .info file:
This, however, doesn't make clear what situation this is needed for. It's for when a front-end theme wants to add to the CKEditor's iframe CSS even when the editor appears in an admin theme.
In #1890502-61: WYSIWYG: Add CKEditor module to core, quicksketch says:
Often times the front-end theme uses a significantly different font and colors (say a dark theme instead of a light one). So the front-end theme may want to provide CSS that is used in the iframe of the editor, so that the appearance lines up more closely to the front-end.
We should refine that some and include that in the docs, and improving the corresponding examples for the .info and _alter() approach.
Comment | File | Size | Author |
---|---|---|---|
#4 | ckeditor_theme_css_docs-1905028-4.patch | 1.43 KB | Wim Leers |
Comments
Comment #1
Wim LeersAssigning to quicksketch, because this is right up his alley, I think :)
(Sorry if it's not, then unassign or assign to me.)
Comment #2
quicksketchComment #3
jhodgdonAs requested, all docs issues related to ckeditor are moved into that component.
Comment #4
Wim LeersThank you! I lost track of this issue because it wasn't in the CKEditor module issue queue! Here's a patch that explains things.
Comment #5
jhodgdonOK, now I'm even more confused. This newly added documentation seems to be telling me I don't need to implement the hook at all. So ... why would I want to implement the hook, and how is that different from the "add to the info.yml" method? That is what the issue summary here is asking for, but I don't think the current documentation makes it clear.
Comment #6
jhodgdonComment #7
Wim LeersThe newly added documentation informs you about an alternative to the hook, that's only possible if you're implementing a theme, not a module. Themes can choose to just declare another entry in their
*.info.yml
file, rather than implementing this hook.So the answer to is: you only want to if you're a module, if you're a theme, you'll want to use this alternative.
I wish we wouldn't have to document this additional theme
*.info.yml
entry there, but sadly there's no other way.Comment #8
jhodgdonCan you make it clearer then in the newly added documentation, when you would want to use the hook and when the alternative? To me it wasn't clear.
Comment #9
jhodgdonI took another look at this, and I'd like to (hopefully) clarify my review...
One problem I'm having with the current patch is that the @code section is offset from the text by blank lines. This made it slightly unclear to me whether the new 2nd paragraph was part of the discussion of the first part or not. Can we remove those two blank lines, so it is clearer that all of that information goes together?
That will help a bit... So, reading further... The existing docs of this hook say:
And now this new section basically says that front-end themes do not need to use the hook. So I would like to see the hook documentation explain:
a) Who should use the hook.
b) Who should use the .info method.
c) What the difference is between the two methods, if not covered by (a) and (b). After reading the existing and patched documentation, I really have no idea what the difference is.
Comment #11
hkirsman CreditAttribution: hkirsman commentedJust saying that the example code has changed to:
instead of
ckeditor_stylesheets[] = css/ckeditor-iframe.css
Anyways thanks for the issue, this was the only hint I could find to define the custom css.
All in all I think the solution would be to add custom css path back to admin. That was the first place I searched for and it's not there :(
Comment #22
quietone CreditAttribution: quietone at PreviousNext commentedSearching D10 and this hook is not found, so it must not be part of ckeditor5. Therefor, I am moving it to the contrib project.