amazeelabs / ckeditor5_sections Goto Github PK

These vulnerabilities are all addressed by dependabot here: https://github.com/AmazeeLabs/ckeditor5_sections/network/alerts but these are not addressed yet.

Currently, yarn audit outputs this:

355 vulnerabilities found - Packages audited: 706
Severity: 339 Low | 5 Moderate | 11 High

There are some dependabots PR that deal with some of these, but not all.

Status quo

• Sections stores HTML data in simple rich text html fields. Historically the idea was to be able to use the HTML “as is”. Maybe we should rethink if this is worth it.
• A computed property provides access to the “raw” information when needed.
• The configuration which templates apply for a given field is stored in the editor settings.
• It is already possible to transform from HTML to raw data and the other way around.

Problems

• Template changes require a drastic upgrade through all existing content. Even if the stored data did not change.
• Typing is fuzzy, since typed data has no access to the format that is being used during editing and therefore doesn’t know about the used template. Right know its “guessing”.
• Each field requires its own input format to be able to enforce a document structure.
• Parsing raw data at runtime is rather costly with a big amount of templates.

Solutions

1. Move template settings from the editor plugin to field instance. This solves 2 & 3.
2. Store parsed JSON instead of HTML and re-assemble to a full html document on demand (editing/preview). Solves 1 & 4.

Steps to take

1. Provide a dedicated field type
   • Settings for template directory and root template
   • Stores JSON data
   • Computed property gives access to assembled document
   • Field widget transforms between html and data back & forth
     • still use editor plugins, but only “compatible” ones? Possibility: WYSIWYG (CKEditor) and JSON/YAML (CodeMirror or similar)
   • Enable output filters on JSON data or run them on separate properties later on?
     • tokens
     • link replacements
     • … ?
2. Provide an upgrade path
   1. Create new field of the new type.
   2. Migrate data from old html field to new one
      1. Has to run for each revision of each affected entity type
      2. Solid batch process necessary
3. Provide a data update API for the remaining template changes that modify the underlying structure
   * New required properties
   * Field type changes
   * Renaming fields
   * ....

An idea how this update API could look like:

<?php
function my_module_post_update_teaser_changes() {
  \Drupal::service('sections.update_manager')->update([
    'Teaser' => function($teaser) {
      // Renamed "title" field to "headline"
      $teaser['headline'] = $teaser['title'];
      unset($teaser['title']);
    }
  ]);
}

Open questions to discuss

• Output filtering on JSON?
• Use editor plugins for new field type?

Replace the builtin link plugin with a custom one that also uses linkit, like the button component does right now.

Currently, pasting replaces selected widgets and leave the editor in a non-operational state.

Token replacement should not happen during data extraction. Depending on how data is, tokens should possibly not be replaced (e.g. for translations).

Re-enable running the tests for the include ckeditor5 plugins from within this directory. From Travis as well as locally.

@pmelab @monya007 I tested the PR on NOBEL. GraphQL part is broken.

Media fields are turned into simple text fields.

Originally posted by @Leksat in #35 (comment)

Hi Amazees,

first of: I really, really like the approach taken in this (suite of) module. WYSIWYG editors have had a bad reputation for a reason but the mere possibilty of using webcomponents or the prospect of collaborative editing make me rather giddy :)

I struggled a bit to get a development environment set up that would allow to tinker (and create tests) with the modules that make up ckeditor5_sections.

I thus ultimately upgraded to the latest ckeditor5 v12. I am aware that that v12 introduces several breaking changes but was able to get all tests to pass with relatively minor changes. Please see my fork of the CKeditor repo which pulls in the ckeditor5-master as well as the upgraded forks for ckeditor5-drupal-media, ckeditor5-drupal-linkit, ckeditor5-template.

The tests are green (adjusting some output in a few limited cases) - but I certainly would not claim to have fully grokked all that is going on. As I couldn't get the tests to run in the current setup, I wasn't either fully able to check all manual tests and there remain some CSS that isn't properly resolved (on running yarn run manual).

To review please clone the main repo and run tests.

1. git clone [email protected]:frega/ckeditor5.git --branch ckeditor5v12 ; cd ckeditor5
2. mgit sync
3. yarn install
4. Followed by yarn run manual and yarn run test --files=template && yarn run test --files=drupal-media && yarn run test --files=drupal-linkit.

Let me know what your plan with regard to CKeditor5 v12 is and whether you'd like me to open PRs in the respective (sub)repositories.

Best, Fredrik