Problem/Motivation

The current profile overview page needs some love...

When editor libraries are upgraded, especially between major versions, there is a great chance that some settings, plugins or buttons are renamed, moved, removed, replaced, or added.

It is difficult to compensate for these differences before displaying the editor profile form while being sure changes to settings default states are only applied when the installed version has been changed.
It can be even more difficult to ensure settings are migrated this way when the profile has not been saved before an editor instance uses
settings meant for an older version of the editor - or even know which editor version the settings were built for.
As some editors evolve faster and faster, this becomes more and more important to keep track of.

The profile overview always shows the currently installed version after an editor name, which isn't very useful, and there is no information about the editor versions currently supported by Wysiwyg module.

Proposed resolution

  1. Store the installed editor version with the profile. Use this version record with the currently installed editor version to invoke a callback on the editor implementation before displaying an editor instance or the profile form. The callback will be responsible for applying any known changes needed to the settings object before it is used to set form defaults or it is processed for sending to an editor instance on the client.
  2. Let an editor implementation declare which library versions it supports as a minumum to maximum range. Display this range with the installation instructions to make it easier to download a supported version.
  3. Have each profile listed in the overview show the version it was built for, along with a warning if it does not match the currently installed library version. Present the same version when actually editing a profile and say if a profile could be automatically migrated to the currently installed library version or not.
  4. Make the profile creation process a bit less confusing by only allowing one profile to be created at a time.

Remaining tasks

  1. Allow settings migrations for external native plugins declared via hook_wysiwyg_plugin(). Only enabled plugins need be migrated.
  2. Go through changelogs of every version of all supported editors and add the needed upgrade code to callbacks. (See an example pattern to follow in the CKEditor implementation.
  3. Support downgrading library versions? This is already possible to do in the callback, but would it be useful or expected to be able to roll back?
  4. Reroll the TinyMCE 4 patch on top of this.

User interface changes

  • The profile paths now use the token %wysiwyg_ui_profile instead of %wysiwyg_profile to allow "temporary" profiles to be created and edited using a separate cache. Works the same way as when creating a View, including the ability for profiles to be "locked" for editing by other users until the locking user has saved the profile, or someone breaks the lock. (Only available if CTools is installed, nothing yet locks a profile, but it was easy to implement and would allow for things like multi-step forms later.)
  • There's now a single "Create profile" button at the bottom of the list of profiles on the overview page on the same row as a dropdown showing text formats without an assigned profile, and a dropdown with the names of all installed editors.

API changes

  • Added "verified version range" key to editor definitions. Array with two version strings for min and max versions it's known to work woth.
  • Added "settings migration callback" key to editor definitions. A string with the name of a function with the responsibility of updating settings fetched from the database when the installed library version has changed.
  • Profiles without an assigned editor (non-functional) are removed from the database.
CommentFileSizeAuthor
#1 wysiwyg.profile_management.2375679.1.patch52.85 KBTwoD
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TwoD’s picture

rocketeerbkw’s picture

All the complaints about a stable release and not a single reviewer yet?

I looked over the patch and in general I think this is a good approach. So the settings form callback code won't change really, it still has to support all the naming differences between editor versions. But the migrate settings callback should make it easier for users to switch editor versions. You still have to load and save the profile after you change editor versions, but if you didn't remember what settings you had, this new patch would save them.

If the migrate callback can work so migrating from 1.o to 2.0 goes through 1.0 > 1.1 > 1.5 > 1.8 > 2.0 instead of just a straight 1.0 > 2.0, than supporting downgrading shouldn't be much more work. I've downgraded TinyMCE before (can't remember why), so I think it's useful to support if possible. If it's a ton of extra work, leave it for later.

Can we break out the remaining tasks to separate issues? I haven't tested this patch yet, but if there are no problems it can go in now and editor migrations can be handled in other issues (create a meta style issue to keep track).

I think "allowing one profile to be created at a time" could be done separately but it's not huge change to include now.

TwoD’s picture

Hehe, you see my dilemma now. ;) Thanks for commenting!

Yes, settings for callback wont' change much. Don't really think there's much we can do about that as deciding whether to include a form element or not depends on the editor version is currently installed. I have thought about introducing a new FAPI property in the style of '#wysiwyg_editor_version_range' => array('3.5.7', '3.9.9'), and toggle #access in some post form build callback, but I'm not sure that would actually be useful yet.

Note that migrate settings callback is also invoked in wysiwyg_get_editor_config() so if a migration was possible, the editor should still work even before the profile is saved. If no migration was possible the situation is the same as before (the editor may of course handle some backwards compatibility on its own).

Exactly how migrations are performed is entirely up to the editor implementation itself, all it gets is the profile version and a "target/installed" version. Performing migrations "incrementally" like you described has indeed been the easiest way to do them. Supporting downgrades would probably be fairly straight forward by "undoing" what each upgrade does, though it may be a bit more "destructive" to the profile since going back to older versions may mean some plugins are no longer available so their settings will be discarded. Printing a warning about that as part of the migration should suffice, so the user can decide before saving.

Profile migration was a bit unreliable before "one profile at a time" was also in because the profiles could have a couple of additional states like "new and completely empty (no version info)", "empty with no editor assigned". I worked on that in parallel, but I could probably break it out pretty easily and rebase this on top of that.

Thanks again for your comments, it's very valuable to know I'm on the right track with this!

  • TwoD committed 5a68827 on 6.x-2.x
    - #2375679 by Twod, rocketeerbkw: Improved profile management.
    
    This...
  • TwoD committed 35ac0cc on 7.x-2.x
    - #2375679 by Twod, rocketeerbkw: Improved profile management.
    
    This...
TwoD’s picture

Status: Needs review » Fixed
TwoD’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.