SPIKE Validate what migration path can be supported

[maxime-rainville]

As a team, we want clarity on what migration path our users could need.

Timebox

• Half a day

Acceptance criteria

• Pre-existing link solution are identified and we have a general idea of how common they are.
• Validate what happens if you try to migrate from older version of the module.
• Review pre-existing migration task.
• We're in a position to formulate what migration path we want to support.

Possible data that could be migrated

(Not an exhaustive list.)

• Migration from older version of LinkField (including DBJson)
• Migration from gorriecoe/silverstripe-linkfield

Note

• There's an unrelated SilverStripe\ElementalBannerBlock\ORM\FieldType\DBLink in Elemental. That will probably have to wait for CMS6 to be nerf.
• Instructions to change the Title field to LinkText for v4 was added this issue

[emteknetnz]

I did a quick internal slack survey about link solutions used, the following 3 link modules are relevant:

• silverstripe/linkfield v2 | v3
• gorriecoe/silverstripe-linkfield
• sheadawson/silverstripe-linkfield

Note that gorriecoe + sheadawson both use the 'Link' table for their model, so may be issues with having both installed at once

silverstripe/linkfield v2 | v3

• After running composer update you'll need to run the script in the README.md to convert Title to LinkText
• We should update this script to also drop the "Title" column from the tables
• OwnerID, OwnerClass and OwnerRelation are unpopulated, so we'll need to create a script to populate these
• Users will want to version linkfield afterwards and auto-publish all the links, so we'll need to add a script for that
• DBLink which stored data as JSON was previously surveyed to be basically unused, so I recommend we just ignore this

sheadawson/silverstripe-linkable

• sheadawson doesn't install out of the box easily because has a constraint for composer v1, not composer v2, I used a workaround to install it in CMS 5
• There is an existing sheadawson migration script to silverstripe/linkfield
• Before running script you'll need to unversion linkfield v4 first - there's instructions in README.md on how to do this
• It works, though OwnerID, OwnerClass and OwnerRelation are unpopulated
• Users will want to version linkfield afterwards and auto-publish all the links, so we'll need to add a script for that

gorriecoe/silverstripe-linkfield

• No existing migration script
• Uses many_many to do what we do with has_many, so there will be some complexity in writing a migration task

[GuySartorelli]

Seems sensible.
Worth noting that gorriecoe/silverstripe-linkfield has config for allowing/disallowing link types per field and disallowing a title (aka link text) so the upgrade guide should call that out.

All in all sounds doable and probably worth doing.
Dunno what the next step is... new card for actually doing the migration guide/scripts? Probably one card per migration path?

[maxime-rainville]

What I'm reading is that while some of the migration might be difficult, know of them are obviously impossible or prohibitive.

I'm going to assume there's not much overlap between the guidance needed for each migration type. My inclination is that each migration guide should be a separate article.

The 3 cards will probably follow a similar pattern, but will be scope individually.

sheadawson/silverstripe-linkable has the most daily installs peaked in 2019 and has been declining steadily ever since.

gorriecoe/silverstripe-linkfield current daily installs is growing and is currently 6 times that sheadawson.

Looking at our install stats on SC

• sheadawson/silverstripe-linkable: 70 + 19 from forks
• gorriecoe/silverstripe-linkfield: 139
• silverstripe/linkfield: 17

We have substantial clients using all three modules. I think don't we have a choice but to put substantial effort in making this transition as smooth as possible, otherwise we'll just be paying for this somewhere else.

[maxime-rainville]

Follow up cards have been created. silverstripe/silverstripe-elemental#329