Problem/Motivation

The current version of the CKEditor codesnippet plugin ships with highlight.js 8.0, which offers a no-highlight option to disable highlighting.

However, that choice is not available when creating a code snippet.

Proposed resolution

Add "no-highlight" to this module's configuration as a language option, which will expose the option when creating a code snippet in the editor:

screenshot of proposed solution

CommentFileSizeAuthor
#3 codesnippet-add-no-highlight-3025663-3-D8.patch402 byteskentr
Screen Shot 2019-01-13 at 3.43.18 PM.png28.06 KBkentr

Comments

kentr created an issue. See original summary.

kentr’s picture

kentr commented
Issue summary: View changes
kentr’s picture

kentr commented
Status: Active » Needs review
StatusFileSize
new codesnippet-add-no-highlight-3025663-3-D8.patch402 bytes

Here's a patch that fixes the issue.

I've confirmed that it works as expected. highlight.js detects no-highlight and returns in highlightBlock() as it should.

The patch is actually rolled against 8.x-1.6, because codesnippet.settings.yml doesn't appear to exist in 8.x-1.x.

jwilson3’s picture

jwilson3
Primary language English
Location Ecuador
commented

Highlight.js has support for 'plaintext', so the way I'm doing this is:

  1. manually add a row to codesnippet.settings.yml with plaintext: 'Plain Text'
  2. Run drush cim to import the new language option.
  3. Go to Basic HTML in UI and enable the new Plain Text checkbox in the Codesnippet settings.
  4. Run drush cex to get the Basic HTML config change into code.
  5. Go to https://highlightjs.org/download/#download-form and find and click the "plaintext" checkbox, then click the "Download" button.
  6. Unzip the custom highlighjs build into path/to/docroot/libraries/codesnippet/lib/highlight folder.

Done. No patches needed for this in my opinion, as this ^ is the standard procedure for enabling any other language you might want to support. Doing this also get's you the latest version of highlight.js 9.x, which has a large number of improvements in the highlighting engine and theming customizations.

kentr’s picture

kentr commented

@jwilson

No patches needed for this in my opinion, as this ^ is the standard procedure for enabling any other language you might want to support.

Yeah, it's possible to do it that way, and that's how I did it originally. But this misses the point.

Opting out of automatic highlighting is a typical enough use-case that it's a sane default feature for this module.

Drupal is making efforts to gain credibility and marketshare as a platform that's easy to use out of the box, and it's ridiculous that anyone would have to perform this manual workaround to simply use the opt-out feature that already exists in the bundled Highlight.js library.

Doing this also get's you the latest version of highlight.js 9.x, which has a large number of improvements in the highlighting engine and theming customizations.

In my experience, that doesn't work with composer-based deployment to stage / prod. For me, composer consistently overwrites the custom Highlight.js library with the bundled version.

This technique works with composer.