Problem/Motivation

When migrating a site from Drupal 7 that had the WYSIWYG module installed and configured on text formats, the expectation is that the new text formats will be configured to use ckeditor5 if that module is installed on the Drupal 9 site. Currently this doesn't appear to always happen, but the cause is not certain.

Steps to reproduce

Migrate a site from Drupal 7 to Drupal 9 that had WYSIWYG enabled on text filters, along with other (core supplied) text filters.

Proposed resolution

Document what is necessary to make the migration to ckeditor5-powered text formats.

Remaining tasks

Identify what is preventing ckeditor5 from being used as a filter on text formats.
Identify whether this should be handled in messages in the UI during the migration, or if it should just be handled in documentation.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

TBD

Comments

DamienMcKenna created an issue. See original summary.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

In my specific case there are a wealth of modules listed in the install profile:

Drupal core:
automated_cron, block, block_content, book, breakpoint, ckeditor5, config, contextual, datetime, dblog, dynamic_page_cache, editor, field_ui, file, help, image, media, media_library, menu_link_content, menu_ui, node, options, page_cache, path, shortcut, taxonomy, toolbar, views, views_ui

Commerce:
address, commerce, commerce_authnet, commerce_cart, commerce_checkout, commerce_log, commerce_order, commerce_payment, commerce_price, commerce_product, commerce_promotion, commerce_shipping, commerce_store, commerce_tax, entity, inline_entity_form, physical, token, weight

Other contrib modules:
admin_toolbar, admin_toolbar_tools, antibot, crop, ctools, csv_serialization, entity_reference_revisions, exif, facets, field_group, field_hidden, field_permissions, focal_point, link_fix_absolute_urls, menu_block, metatag, paragraphs, pathauto, search_api, search_api_solr, tb_megamenu, transliterate_filenames, twigsuggest, viewfield, views_attach_library, views_bulk_operations, views_conditional, views_data_export, webform

Migration:
migrate, commerce_migrate_commerce, migrate_exclude_entities, migrate_plus, migrate_skip_on_404, migrate_tools, migrate_upgrade, webform_migrate

Once those are installed I run the migration using "drush migrate:upgrade --configure-only" and then "drush migrate:upgrade".

After the migration finished I went to the text formats and none of them had ckeditor enabled, when I went into each one it indicated that ckeditor couldn't be enabled because:

CKEditor 5 only works with HTML-based text formats. The "Convert URLs into links" (filter_url) filter implies this text format is not HTML anymore.

So I'm trying to work out what needs to be changed on the D7 site so that I can run the migration cleanly and have ckeditor5 be set up where wysiwyg currently runs.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Component: documentation » ckeditor5.module
Status: Active » Postponed (maintainer needs more info)
Issue tags: +migrate-d7-d9, +migrate-d7-d8

When migrating a site from Drupal 7 that had the WYSIWYG module installed and configured on text formats, the expectation is that the new text formats will be configured to use ckeditor5 if that module is installed on the Drupal 9 site

Did this happen for Drupal 7 → Drupal 8 with the CKEditor (4) module? 🤔

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Document how to provide a clean upgrade path to ckeditor 5 » Document how to provide a clean migration path from Drupal 7 + WYSIWYG to Drupal 9 + Text Editor + CKEditor 5

Also, this is not about an upgrade path; an upgrade path is definitely provided from Drupal 8/CKEditor 4. This is about a migration path from Drupal 7 + https://www.drupal.org/project/wysiwyg.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Postponed (maintainer needs more info) » Active

You are correct, the issue is about the migration path from D7 + WYSIWYG.

I reran the migration using ckeditor 4 and it comes out the same, so maybe it's a more general problem?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Document how to provide a clean migration path from Drupal 7 + WYSIWYG to Drupal 9 + Text Editor + CKEditor 5 » Migration path from Drupal 7 + WYSIWYG to Drupal 8|9 + Text Editor + CKEditor 4
Component: ckeditor5.module » migration system
Category: Task » Feature request

That's my point: there has never been a migration from the wysiwyg module in Drupal 7 to editor + ckeditor in Drupal 8.

There is no need to worry about the 8 → 9 (CKEditor 4 → CKEditor 5) migration path. The CKEditor 5 module has that covered.

That's why I'm retitling this and rescoping this to what is the real blocker here: a migration path into Drupal 8|9's CKEditor 4.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3061571: If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up

To clarify: there is a text-format-only migration path for the majority of text formats, since #3061571: If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up added support for most Drupal 7 filter plugins. This is asking for something else.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue tags: +Needs issue summary update
Parent issue: #3238333: Roadmap to CKEditor 5 stable in Drupal 9 »

Updating issue metadata for #6.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Thanks for the clarification, Wim, I thought that there might have been a migration path for it.

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

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now 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.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Status: Active » Postponed

The Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.

Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.

quietone’s picture

quietone commented
Issue tags: -migrate-d7-d9

just updating tags

quietone’s picture

quietone commented
Status: Postponed » Closed (won't fix)

The Migrate Drupal and Migrate Drupal UI modules are deprecated and will be removed from Drupal 12. For these modules, effort is now focused on bug fixes and necessary tasks. Therefore, this feature request is closed as won't fix.

Thanks to all for working on this!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.