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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers’s picture

Assigned: Unassigned » quicksketch

Assigning to quicksketch, because this is right up his alley, I think :)

(Sorry if it's not, then unassign or assign to me.)

quicksketch’s picture

Assigned: quicksketch » Unassigned
jhodgdon’s picture

Component: documentation » ckeditor.module
Issue summary: View changes

As requested, all docs issues related to ckeditor are moved into that component.

Wim Leers’s picture

Component: ckeditor.module » documentation
Assigned: Unassigned » Wim Leers
Status: Postponed » Needs review
FileSize
1.43 KB

Thank you! I lost track of this issue because it wasn't in the CKEditor module issue queue! Here's a patch that explains things.

jhodgdon’s picture

Status: Needs review » Needs work

OK, 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.

jhodgdon’s picture

Component: documentation » ckeditor.module
Wim Leers’s picture

Component: ckeditor.module » documentation
Status: Needs work » Needs review

The 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 why would I want to implement the hook 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.

jhodgdon’s picture

Status: Needs review » Needs work

Can 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.

jhodgdon’s picture

I 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:

 * Modify the list of CSS files that will be added to a CKEditor instance.
 *
 * Modules may use this hook to provide their own custom CSS file without
 * providing a CKEditor plugin. This list of CSS files is only used in the
 * iframe versions of CKEditor.

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.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hkirsman’s picture

Just saying that the example code has changed to:

ckeditor_stylesheets:
  - css/ckeditor-iframe.css

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 :(

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Project: Drupal core » CKEditor 4 - WYSIWYG HTML editor
Issue tags: -CKEditor in core

Searching D10 and this hook is not found, so it must not be part of ckeditor5. Therefor, I am moving it to the contrib project.