Example migrate process plugin to convert basic "node/123" links to the correct format

1. +++ b/src/Plugin/migrate/process/LinkitLinks.php
   @@ -0,0 +1,133 @@
   + * Also converts "node/123" links from D6/7 to the expected "/node/123" format.
   

   What about links that linkit generated that use path aliases?

2. +++ b/src/Plugin/migrate/process/LinkitLinks.php
   @@ -0,0 +1,133 @@
   + * Note: this will skip rows where the entity cannot be loaded. This will happen
   + * if the entity doesn't exist, the primary reason being that it has not been
   + * migrated yet. As such, it may be necessary to run any migration this process
   + * is added to twice, once to pass dependencies for other migrations, and a
   + * second time when the entities have been loaded. YMMV.
   

   This is very problematic :| But I don't see an elegant solution either.

   If you have a foo node that is referring to another foo node, it's impossible to know the UUID of the referred node until it's migrated, but it could be migrated in the reverse order.

   Even if you could order this "correctly", it would still not solve circular references. Which are definitely allowed in text fields.

   Tricky.

   I wonder if the migration system maintainers have elegant solutions for this. Basically this process plugin can only be reliably run after the migration has already run once. It's almost like a "post-process" phase.

   The only thing I can think of is to make \Drupal\migrate\Plugin\MigrateProcessInterface::transform() track unresolvable links (time A), and create a new/separate linkit_post_processor migration whose rows are effectively the ones tracked at time A, so that while the migration at time A is running, the number of rows to process is literally generated during the migration.

   Then at a later time B, we could in principle reliably update all of the tracked rows!

   (Yes, I'm handwaving a lot here. I'm hoping this will trigger a response from one of the migration system maintainers pointing out a much better way to do this 😄)

We do the post-process as you described... in your source plugin for your post-processer you select all nodes inner joined with your migrate map table. And then you convert links to linkit format. It gets even more fun coming from a non-drupal system where you may be converting non-drupal a tags to linkit links that could have image assets inside of the tag that get converter to media entities. ;)

+ * Because the plugin doesn't match links which have extra attributes before the
+ * "href" attribute, it might be worth testing the migration first, seeing what
+ * items are missed, and then adding extra str_replace commands first.

It seems this would be better off extending the dom_str_replace plugin in migrate_plus.

We do the post-process as you described... in your source plugin for your post-processer you select all nodes inner joined with your migrate map table. And then you convert links to linkit format.

Care to share example code?

What about links that linkit generated that use path aliases?

This would be good to have. You could do a lookup on the path_alias table but would you want to do this for all links or just those with /node/123 pattern? Also the aliases may not exist yet (or at all) on the destination site.

It almost seems it would be better to develop this as a standalone batch task that can be run at any time.

I noticed the examples in this issue all show the site being at the root of their server. This solution should work with sites that are not at the root, for example: <a href="/site-path/node/123">

Is there a reason site paths are included at all? See related issue.

This hasn't had any traffic in over a year, but I'm running into the same issue. I figured out how to create a migration to fix broken links when the node IDs/aliases changed from a migration a former coworker did, but the links are converted to the node/ID format, and Linkit doesn't seem to do anything with them to make them into their nicer looking alias without those extra data-attributes. I thought if I just resaved the pages it would kick in but it doesn't I guess w/o those attributes.