Provide ability to reference current value of process pipeline as a source property

Nice!

Just some things I see:

1. +++ b/core/modules/migrate/src/MigrateExecutable.php
   @@ -67,6 +67,13 @@ class MigrateExecutable implements MigrateExecutableInterface {
   +  protected $value;
   

   If this is public, should it be added to the interface?

2. +++ b/core/modules/migrate/src/MigrateExecutable.php
   @@ -67,6 +67,13 @@ class MigrateExecutable implements MigrateExecutableInterface {
   +  protected $value;
   

   Should this be something more descriptive than $value? $currentProcessPipelineValue?

3. +++ b/core/modules/migrate/src/MigrateExecutable.php
   @@ -407,18 +415,28 @@ public function processRow(Row $row, array $process = NULL, $value = NULL) {
   +    return $this->value ?? NULL;
   

   Do we have/need coverage for the NULL return?

@danflanagan8:

Thanks for opening this issue. I think it would be great to have better ways of supplying arguments to process plugins, and this issue gets the discussion going.

We discussed this issue at #3236461: [meeting] Migrate Meeting 2021-09-23. Two of the maintainers of the migration subsystem (@mikelutz and I) agreed that we do not want to modify the core get plugin for this purpose. From memory, here are some of the reasons:

1. It does not add new functionality, since you can accomplish the same thing using "pseudofields".
2. It adds complexity to the get plugin.
3. We need the get plugin to be reliable, since it is the start of nearly every process pipeline.
4. The get plugin is already too weird.

I have never seen a pipeline that does not start with get, but I said "nearly" to avoid inciting people to prove me wrong.

Usually, get is implicit, called when another process plugin sets a source option.

I realize that (3) cuts both ways: since get is used so much, and used implicitly, it will be a lot easier to use this feature if it is implemented in get.

I did not bring it up at the meeting, but I also do not like the implementation here, since it relies on the executable class. There are other executable classes out there (Drush, Migrate Tools, Migrate Source UI). I am afraid that migrations using this feature might work with some executables and not others.

Again, the get plugin is weird: its input is an array of source and destination properties. Shouldn't that be configuration instead?

I think a better idea would be to create a new plugin:

• It has direct access to the pipeline value, since that is the argument to its transform() method. There is no need to get it from a class property on the executable.
• It has configuration like the arguments to get: an array of source and destination properties.
• Besides source and destination properties, it can have literal strings and the pipeline value.
• If we can think of use cases, the configuration could be a nested array

For the sake of discussion, let's use the following syntax for the configuration items:

• source:field_foo for a source property
• dest:field_bar for a destination property
• pipeline: for the pipeline value (argument)
• literal:any string for a literal string

That is verbose, but it is clear. We can choose something shorter if we actually implement this plugin.

With this proposal, I would handle the example from the issue summary like this:

process:
  processed_value:
    -
      plugin: callable
      source: field_product
      callable: ucfirst
    -
      plugin: get_arguments
       inputs:
         - 'literal:i'
         - 'pipeline:'
    -
       plugin: concat

I think that is only 2 lines longer than the example in the summary, and some of that is saved because you do not need to define contants.i in the source.

If we do create a new process plugin, it will probably be a candidate for the migrate_plus module, not core.