It looks like we are running into name space collision with http://drupal.org/project/ckeditor. This may confuse update_status a lot, but I'm not sure.

I hope there will be an upgrade path from previous contrib versions to new core. It looks like core does not support the same features, what is not really wrong, but we may end up with tons of stale variables in the database? Is core going to cleanup them or is there a need to uninstall under D7? I do not like the last variant with a smooth upgrade in mind!

Comments

jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented

I think this belong to contrib just like Views Drupal 7 to Drupal 8 upgrade.

hass’s picture

hass CreditAttribution: hass commented

Cck was migrated a lot easier and I expect that Views is automatically upgraded, too.

wwalc’s picture

wwalc CreditAttribution: wwalc commented

Hmm the first thing to keep in mind is that the contrib version (the old "CKEditor" module) provides lots of various features, which are not available in D8 (and there's nothing wrong with that, just a matter of approach).

For me, it looks like the right path to upgrade would be to uninstall completely the Drupal 7 version of CKEditor module to remove all variables, tables etc. and then upgrade to Drupal 8, where a totally different module with the same name is installed by default. It works in a different way, provides different (and less) options, different set of plugins and buttons, so there is almost nothing from the list of configuration options that could be ported to Drupal 8.

If someone would like to preserve all settings, then I guess the only way to do this would be to write another module, that extends the functionality of the default D8 CKEditor module and makes it possible to set again all the things that was possible to set in the "old" CKEditor module. However, we're talking in such case about a module that would have to be maintained forever, not something that would be installed just during the upgrade process.

hass’s picture

hass CreditAttribution: hass commented

If someone had ckeditor in D7, we can expect that he like to stay with it in D8. I'm not sure how many will uninstall ckeditor.

I thought about something like:

  • ckeditor module was enabled in D7, keep it enabled in D8
  • Text formats with ckeditor assigned stay as is with D8 ckeditor
  • Every button configuration we may be able to upgrade should be upgraded
  • All other variables no longer a feature in D8 can be deleted.
  • How about custom css files?

Everything we can upgrade should be upgraded.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Issue tags: +Spark, +CKEditor in core

Like #1, I seem to remember that modules moved into core must provide upgrading functionality in their latest "previous core" versions? I could be wrong though.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Status: Active » Closed (won't fix)

The upgrade path of modules that have been moved from contrib into core are always handled in contrib.

Aside from that, I agree with most of what @wwalc said in #3. The modules are completely different, so uninstalling before upgrading is the most sensible thing to do.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
CreditAttribution: klonos commented
Status: Closed (won't fix) » Active

The upgrade path of modules that have been moved from contrib into core are always handled in contrib.

Who says we should stick with the old ways? We should give this a second thought.

Same with Views and Views Drupal 7 to Drupal 8 upgrade: #1942936: Should this module be part of D8 core?

Uninstalling a module destroys all its data. Instead of asking people to do that or wait for these migration modules to be ported to D8 we should take care of upgrading/migrating/moving things during core update.

hass’s picture

hass CreditAttribution: hass commented

Commented my point of view on the other case, but I see it like you.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented
Status: Active » Closed (won't fix)

I think ideally, there would be a "light" upgrade path, which migrates as many settings as possible. However, the number of settings that can possibly be migrated is rather low: parts of the enabled buttons could be migrated.

Unlike with Views, the complexity of configuring CKEditor is significantly lower, and the number of CKEditor configurations is typically *one*, at most two or three. The number of Views is typically at least an order of magnitude larger.

Finally, the configuration of a View in D7 is very, very similar to the configuration of a View in D8. So, migration makes sense. In the case of CKEditor, everything is fundamentally different: it's much more simple in Drupal 8 core, and much more tightly integrated with Drupal's text format/filters. It's crucial that when people migrate, they re-evaluate their CKEditor configuration. It is not crucial that they re-evaluate their Views.

Hence, closing this issue once again, hopefully for good. I too have the best intentions, but the only sane way to deal with this is to ask site administrators to set up CKEditor again for their text formats.