#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

Comments

drumm created an issue. See original summary.

drumm’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes

Any 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 and iframe for full_html.

small is still missing for filtered_html and full_html.

hestenet’s picture

Issue summary: View changes
drumm’s picture

Issue summary: View changes
tvn’s picture

Issue summary: View changes
drumm’s picture

Assigned: Unassigned » drumm
drumm’s picture

Issue summary: View changes

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

The span in a.link-button is no longer required.

  • drumm committed 8aaafef on 7.x-3.x
    Issue #2741227: Allow all classes for full HTML
    
drumm’s picture

Issue summary: View changes

Images are now a bit better behaved. Left/Right alignment now use our left and right classes.

drumm’s picture

Issue summary: View changes

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

drumm’s picture

Issue summary: View changes

<p>&nbsp;</p> everywhere is a problem.

tvn’s picture

>> 'width' and 'class' attributes on Only local images are allowed. are being removed by CKEditor when editing previously saved content
This is still happening for % values.

drumm’s picture

Have links to sample content?

tvn’s picture

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

drumm’s picture

Issue summary: View changes
  • Instead of <p>&nbsp;</p> we now get <p></p>. That’s kinda like progress.
  • Insert template defaults to not replacing the existing content.
  • <small> is no longer stripped.

Currently, left, right, and center 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.

drumm’s picture

For pages like https://www.drupal.org/about/strategic-initiatives, I added a new aside-half class to be combined with left & 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.

drumm’s picture

Assigned: drumm » Unassigned
Issue summary: View changes

That has been deployed.

I think this might be in an okay enough place for me to take a break on this issue.

tvn’s picture

Issue summary: View changes
tvn’s picture

Issue summary: View changes
eojthebrave’s picture

On this page https://www.drupal.org/docs/develop/coding-standards/api-documentation-a..., id= is being stripped from h3 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.

  • drumm committed 8aaafef on 2741227-ck-allowed-tags
    Issue #2741227: Allow all classes for full HTML
    
hestenet’s picture

Issue summary: View changes

I didn't format my commit messages correctly - but! we've just deployed a fix to allow dd, dl, dt tags and id=".." attributes on any tag. Looks like that page doesn't get broken now @eojthebrave.

eojthebrave’s picture

Awesome. Thanks @hestenet and everyone else for the quick fix.

drumm’s picture

Issue summary: View changes

Adding “Adjacent code tags can be merged improperly” from #2811359-7: WYSIWYG editor breaks code formatting

drumm’s picture

Something going on with the spacing/new lines here https://www.drupal.org/node/2773581/revisions/view/9915967/9975443

That looks “by design,” CKEditor does do some code reformatting.

tvn’s picture

Issue summary: View changes

Adding one more todo item.

drumm’s picture

Issue summary: View changes

Something going on with the spacing/new lines here https://www.drupal.org/node/2773581/revisions/view/9915967/9975443

This looks okay. CKEditor’s HTML wringer standardizes whitespace. It doesn’t look like there were substantive changes to the markup in that revision.

drumm’s picture

Issue summary: View changes

From #2762837-42: Migrate documentation into the new system, adding

Markup within code like https://www.drupal.org/node/930760/revisions/view/8570555/10246693 around “A paragraph about some stuff”

drumm’s picture

drumm’s picture

Issue summary: View changes

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

drumm’s picture

Issue summary: View changes

<small> tags apparently aren’t fixed

drumm’s picture

Issue summary: View changes

  • drumm committed 75a9c37 on 7.x-3.x, dev
    Issue #2741227 by B_man: Enable CKEditor for forums
    

drumm credited B_man.

drumm’s picture

drumm’s picture

Issue summary: View changes

Markup 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 has been deployed to fix this.

rachel_norfolk’s picture

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

pdjohnson’s picture

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

hestenet’s picture

One 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?

markhalliwell’s picture

No 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?