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.
#2578695: Use CKEditor on *.drupal.org sites got CKEditor enabled for a handful of content types. More work is needed to make sure it is good to be expanded.
Known Issues
<img class="left|right"
should be how images are classed for alignment. That should show in the editor too.- The<span>
stripped from<a href="https://ftp.drupal.org/files/projects/drupal-8.1.3.tar.gz" class="link-button"><span>Download Drupal 8.1.3</span></a>
span
is no longer required.'width' and 'class' attributes on<img>
are being removed by CKEditor when editing previously saved contentInsert template should never replace the whole content of the field.Improve classes for images. See #14, #17Missing tags:div
,iframe
,small
<p> </p>
<p></p>
everywhereid-s removed from h2 and a tags, dd and dt replaces by p here: https://www.drupal.org/node/937/revisions/view/9756663/9979319Something going on with the spacing/new lines here https://www.drupal.org/node/2773581/revisions/view/9915967/9975443<small>
tags apparently aren’t fixedMarkup within code like https://www.drupal.org/node/930760/revisions/view/8570555/10246693 around “A paragraph about some stuff”#2725111: < within <?php is not escaped for codefilter_prism- https://www.drupal.org/module-development needs custom markup replaced.
- https://www.drupal.org/node/2407497/revisions/view/8016071/10446063 needs custom markup replaced.
- Insert code button needs a new icon. It isn't high-resolution, and looks greyed out.
- Look over UI in general. Is there anything that can be simplified?
- Remove link target UI.
- Try out various uses of code filter, switching CKEditor on & off. Does the code continue to be rendered correctly?
- Adjacent code tags can be merged improperly
- Add a generic centering class to center things like CTAs in release announcements.
Comments
Comment #2
drummComment #3
hestenetAny tag allowed in our text formats that doesn't have an explicit CKEditor button, or isn't in the allowed tags config of CKEditor will be stripped.
We found and fixed
div
andiframe
forfull_html
.small
is still missing forfiltered_html
andfull_html
.Comment #4
hestenetComment #5
drummComment #7
tvn CreditAttribution: tvn at Drupal Association commentedComment #8
drummComment #9
drummThe
span
ina.link-button
is no longer required.Comment #11
drummImages are now a bit better behaved. Left/Right alignment now use our
left
andright
classes.Comment #12
drummThe width of the Drupal Composer icon at https://www.drupal.org/drupalorg/blog/whats-new-on-drupalorg-june-2016 isn't being stripped if I edit.
Comment #13
drumm<p> </p>
everywhere is a problem.Comment #14
tvn CreditAttribution: tvn at Drupal Association commented>> 'width' and 'class' attributes on are being removed by CKEditor when editing previously saved content
This is still happening for % values.
Comment #15
drummHave links to sample content?
Comment #16
tvn CreditAttribution: tvn at Drupal Association commentedI tested here: https://www.drupal.org/about/strategic-initiatives, had to specify pixels in the end. If you use CKEditor's image properties pop up it won't even let you enter %. 'Should be a number' error message.
Comment #17
drumm<p> </p>
we now get<p></p>
. That’s kinda like progress.<small>
is no longer stripped.Currently,
left
,right
, andcenter
are the allowed classes for images. (No, center does nothing, but CKEditor likes having that UI.) We should add responsive classes for the widths to replace percentages.Comment #18
drummFor pages like https://www.drupal.org/about/strategic-initiatives, I added a new
aside-half
class to be combined withleft
&right
. The commit is http://cgit.drupalcode.org/bluecheese/commit/?id=fd13de7. It will be deployed next time bluecheese is updated.There isn’t an easy way to add a class field to CKEditor’s image2 dialog. For now, it can be added by switching to editing HTML. The class isn't removed on loading CKEditor.
The class is meant to be used in content that uses 2/3 of the page width, 8 of the 12 columns. It sets up the content width to be half, 4 of those 8 columns. At small phone sizes, it takes over the full width.
Comment #19
drummThat has been deployed.
I think this might be in an okay enough place for me to take a break on this issue.
Comment #20
tvn CreditAttribution: tvn at Drupal Association commentedComment #21
tvn CreditAttribution: tvn at Drupal Association commentedComment #22
eojthebraveOn this page https://www.drupal.org/docs/develop/coding-standards/api-documentation-a...,
id=
is being stripped fromh3
and other tags. Which means you can't edit this page without breaking all the existing anchors in the TOC.CKEditor has the ability to insert anchors using
<a>
tags, but it would be a LOT of work to replace them all on this page, and I'm sure there are other pages where we're using ids to create a TOC like on this one.So I guess my vote is to have CKEditor stop striping ids from elements if possible.
Comment #24
hestenetI didn't format my commit messages correctly - but! we've just deployed a fix to allow
dd, dl, dt
tags andid=".."
attributes on any tag. Looks like that page doesn't get broken now @eojthebrave.Comment #25
eojthebraveAwesome. Thanks @hestenet and everyone else for the quick fix.
Comment #26
drummAdding “Adjacent code tags can be merged improperly” from #2811359-7: WYSIWYG editor breaks code formatting
Comment #27
drummThat looks “by design,” CKEditor does do some code reformatting.
Comment #28
tvn CreditAttribution: tvn at Drupal Association commentedAdding one more todo item.
Comment #29
drummThis looks okay. CKEditor’s HTML wringer standardizes whitespace. It doesn’t look like there were substantive changes to the markup in that revision.
Comment #30
drummFrom #2762837-42: Migrate documentation into the new system, adding
Comment #31
drummAdding https://www.drupal.org/module-development to list.
Comment #32
drummWe can also remove some fields from the link dialogs. For example the target attribute should be used only in special cases and shouldn't get a UI.
Comment #33
drumm<small>
tags apparently aren’t fixedComment #34
drummComment #37
drummWe are enabling WYSIWYG for the forums today, https://www.drupal.org/forum/general/news-and-announcements/2017-10-19/w...
Comment #38
drumm#2725111: < within <?php is not escaped for codefilter_prism has been deployed to fix this.
Comment #39
rachel_norfolkWhat would it take to get CKEditor working on the issue queues? Every time a non-code initiative chooses to use a different tool than the Drupal.org issue queues to manage their work, we lose another opportunity to demonstrate we credit code and non-code contributions equally.
This is becoming an increasingly urgent and important issue in our community, I believe.
Comment #40
pdjohnson CreditAttribution: pdjohnson as a volunteer and at CTI Digital commentedI don't often spend time in the issue queues but recently an opportunity has arisen for me to manage a Promote Drupal project through queues e.g. https://www.drupal.org/project/promote_drupal/issues/3000857. Frustratingly I cannot access text formats which support the CKEditor formatting available in the UI.
I spent a few minutes using the strikethrough formatting to indicate progress on our project, just like you have above. However upon saving discovered this was just plain text. So I had to remove the formatting code.
As a non developer (now) and someone motivated to contribute, this is a total turnoff to using issue queues and the temptation to use something else is extremely strong.
In the workshop at Drupal Europe I laughed at the proposal of a leader in Europe suggesting marketeers and copywriters use issue queues. This is precisely the type of problem which contributes to my having this opinion (it would be far easier to use Goolge docs but that doesn't result in credits and is also not visible).
If we as a project want to have more non developers contributing, this topic needs to be taken seriously.
Comment #41
hestenetOne of the reasons this was put on hold is because it would likely break Dreditor integration. We had been hoping to either have a temporary workaround in place, or perhaps a pull request for Dreditor for CKEditor compatibility - but in the absence of those this has languished.
That said - we could reconsider moving forward with this without the Dreditor fixes in light of the upcoming GitLab work? OR we can continue to wait until the GitLab work is fully deployed. We're very close to having GitLab for code viewing - which does not wholly replace the functions of Dreditor by any means, but would perhaps make that transition easier?
Comment #42
markhalliwellNo one, besides myself, is actually willing to work on Dreditor. The most anyone really does is just complain about it, despite laying out a fairly clear plan for others to follow and repeated calls for help. That being said, even I haven't been able to put in the time I was hoping I would be able to.
IMO, I think it's safe to state that Dreditor (as we knew it) is just straight up "dead"; regardless of whether people still actively use it.
The majority of the "textarea" features though were created, primarily, because d.o didn't have anything like CKE (at the time).
This issue may, in fact, help replace most of those remaining features with something better and more universal.
Any remaining user based features we can leave #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features to pick up the slack.
The quicker GitLab and issues like this are implemented, the smaller the downtime people will have when issues like this break Dreditor's "integration".
I will say that implementing this issue will not likely break Dreditor's actual "review" aspect of patches, however, the line-by-line commenting of said patches and then pasting those review comments into d.o's comment textarea on an issue afterward will indeed likely break.
So, until that functionality is transitioned to GitLab... perhaps this issue should be postponed. Does an issue for that exist somewhere?