Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The docs for EmptySource at https://api.drupal.org/api/drupal/core%21modules%21migrate%21src%21Plugi... say:
> This will return a single row containing 'entity_type' and 'field_name' elements, with values of 'user' and 'image', respectively.
But when I tried this, it doesn't work:
source:
plugin: empty
constants:
title: 'My title'
type: 'default'
uid: 1
process:
title: title
type: type
uid: uid
I had to do this instead:
process:
title: constants/title
type: constants/type
uid: constants/uid
Using constants like that is no different from what can be done with any other migration source plugin.
The documentation claims the row will be populated with the constant values, but it's not. Looking at the code, I don't see that the plugin is doing anything of the sort.
Issue fork drupal-3197749
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
quietone CreditAttribution: quietone as a volunteer commentedI don't think that how to use 'constants' is documented at all. :-(
Adding this to the meta for documenting source plugins.
Comment #3
joachim CreditAttribution: joachim as a volunteer commentedI'm not sure whether this issue here is a documentation error, or a code error. The two don't agree, but which should be taken as correct?
Comment #5
quietone CreditAttribution: quietone as a volunteer commentedI could not find where the use of 'constants' is documented. I am not sure where to put it but I think that SourcePluginBase is the best option. The term 'constants' isn't a configuration key and in fact one can use any name or have several names. For example, the following is valid.
It is just the way that \Drupal\migrate\Row::get works.
Comment #6
quietone CreditAttribution: quietone as a volunteer commentedComment #7
quietone CreditAttribution: quietone as a volunteer commentedComment #8
joachim CreditAttribution: joachim as a volunteer commentedPatch looks good, apart from documenting the use of other keys. I think that's a bug we should be removing.
I kinda thought populating fields with the constant names was a nice feature, but at the same time, having one source plugin where constants behave differently was a potential WTF.
Comment #9
quietone CreditAttribution: quietone as a volunteer commented@joachim, I wasn't sure if the ability to add other keys should be documented or not. I added it for completeness and to see what reviewers would say. I am happy for it to remain undocumented.
I don't think it is a bug either. Any value can be placed on the row and source plugins can define any configuration properties they want. How would Row::getSourceProperty distinguish a that a property name, e.g. 'other', from the other properties on the row or in the source configuration.
Comment #10
quietone CreditAttribution: quietone as a volunteer commentedComment #11
joachim CreditAttribution: joachim as a volunteer commented> I don't think it is a bug either. Any value can be placed on the row and source plugins can define any configuration properties they want. How would Row::getSourceProperty distinguish a that a property name, e.g. 'other', from the other properties on the row or in the source configuration.
Wouldn't it be possible for properties set in the migration YML to clash with data the source plugin wants to put into the row as well? Anyway, we can open a new issue for discussing whether this is a bug to be fixed, or a feature to be documented.
Patch here looks good!
Comment #12
alexpottCommitted and pushed 499e358acd to 9.2.x and 714570280d to 9.1.x. Thanks!
Backported to 9.1.x as this is a documentation fix.